Protected & Obfuscated Code?

[jfrey]

Digging into the MBD I've found that almost all of the core functionality is obfuscated and protected with the matlab pcode function. 

I can understand hiding some of the licensing code, but is there a reason that almost all of the callbacks and functions are hidden?

For example I would like to change the Largest atomic size from Double to Single, however the code that sets the variables is hidden: Bad example. Matlab imposes this 'lock'. Point still stands.

I understand that "open" development is relatively new to NXP (and 'our' industry as a whole) however with the code available everyone that uses it would have the opportunity to fix and improve it. 

Understandably lawyers can be skittish when it comes to this, however it seems to be the way almost all software development is going.

[jfrey]

I'm going to go ahead and raise this issue again especially after debugging this problem: Bug if C: is not first disk.

Is there a good valid reason (lawyers don't count) that this tool is licensed when you're giving it away? All of these issues and hoops customers are jumping through to try and use your product are potentially driving customers away with no value added benefit for NXP/Qualcomm. 

For kicks I went ahead and removed all of the licensing lockdowns and spent less time doing that than I did debugging the above issue. (I won't give away the secret, but it's trivial). It has the added bonus of speeding up any Simulink update or build actions because it's not pinging an external function call.

Then I looked at what the Installer was actually doing and found that, for some reason, it's almost twice as large as it needs to be. Model Based Design Toolbox for MPC574xP.msi is only 91MB but setup.exe is 162MB.

Extracting the MSI I was able to package it into a Matlab toolbox (along with the above licensing "fixes") and had myself a Matlab mltbx file that was dead simple to deploy and install:

I tested it on a few machines I had and it's how it should have been packaged to begin with.

It didn't require admin access (school labs & corporate machines) or any licensing (school labs & corporate deployments). It makes me wonder how much time NXP has invested internally to be a thorn in the side of its customers, let alone how much time us out here have spent trying to use a tool we want to use.

For comparison, this is what it took to get started with Simulink on your competitors' products:

It was that easy for Pi, Arduino, Texas Instruments™ C2000™, TI RM57/RM46 Launchpad, STMicro STMF4 and multiple others.

Even NXP's FRDM boards are that easy:

[Daniel_Popa]

Hi jfrey‌,

In regards with license - no comments yet - we need to maintained due to corporate decisions.

In respect with the toolbox package - we have good news - the next release we have (October 16th) will be delivered as mltbx package and will be installed as Matlab Add-on.

Here is a snap-shot of it:

Install wizard:

Matlab integration:

Currently, we have some issues with toolbox deployment over MathWorks File Exchange. Do you have experience with such systems ? The actual toolbox for S32K is 225MB in size. 

Best regards,
Daniel

[jfrey]

I checked the package I made for the E200 MBD toolbox. It was ~91MB. It didn't include the compiler (it relies on S32 being installed).

If you have a way, I can send it to you. However I've removed the license checking so it's easier to deploy so I will hold off uploading it to Github.

[bobpaddock]

"The first thing we do, let's kill all the lawyers." - Dick the butcher.  The Second part of King Henry the Sixth by Shakespeare; Henry VI, part 2, Act 4, Scene 2.

[Daniel_Popa]

Hi jfrey‌,

Unfortunately, i can't provide a satisfactory answer to this. That's the way we have done it in the past and what others are doing as well.

I'm going to take this to our management and see if we can improve for the future. 

Thank you for highlighting this to us!

Best regards,

Daniel

[jfrey]

Before I get ahead of myself, where is NXP trying to place the DEVKIT-MPC57XXs in the market? Before management signed off on making 2 - $35 boards, at seemingly little to no profit margin, I'm betting there were lots of discussions as to what the end game was for each of them.

In my head I see a lot of potential for these products, but perhaps I'm building up lots of big ideas and possibilities for market(s) that NXP isn't actively targeting.

Based on the marketing on being Arduino shield compatible I've assumed that it was aimed at the hobbyist market, competing with Arduino. Also competing with the ~$15 STMicro Discovery boards. With the MBD toolbox it would be a perfect fit for higher education where Embedded Coder licenses are cheap and plentiful, while giving students the opportunity to learn on 'real' hardware.

Or are you more positioning it for the corporate environment to compete with your existing "low cost" PPC development boards and Infineon/STMicro boards in the $200+ range?

Or at this point do you really not know and just throwing things at the wall to see what sticks?

[wem_sperez · Accepted solution]

  Hi Jed,

  These evaluation boards are meant to provide a low cost solution for rapid prototyping automotive and industrial applications where a high-performance tool is not required. With these we mostly cover that kind of customers that develop more generic applications, but we also  want that students and hobbyist put their hands on it.

  There’s this other type of evaluation system consisting of a mother board and daughter card which is fit when customers want an evaluation tool with high-performance peripheral and interfaces included in the tool.

  This is just a quick answer, but I'd really like to get more details of what you're thinking, looks like it's headed to an interesting conversation!

  I hope this worked in the meantime, looking forward to reading more from you.

  Regards!
Wences  

[jfrey]

Apologies for the delay. I wanted to make sure I best gathered my thoughts and tested some things out.

All of this is written as constructive criticism. I realize that not everyone is a native English speaker (and I won't claim to be that good at it either) so I don't want feedback or connotation to get lost in the translation. I want to thank everyone at NXP that has put work into this from marketing and engineering to management that has put work into these boards. Your efforts have not gone unnoticed. 

A short preface on my self & experiences to give you a background into my feedback.

• Professionally I've been doing model based development since I graduated in mid-2000s. Starting with Vector CANape 6.0 and MATLAB R13 and working exclusively with Motorola/Freescale/NXP MPC55xx, MPC56xx, MPC56X chips.
• As a hobbyist I have one of about everything. For embedded I have dozens of Arduinos, a few ESP8266, two STM32F4-Discoveries. For 'headless PCs' I started with a SheevaPlug and now have a few Raspberry Pi3s, CubieBoard4, and Wandboard (based on NXP's i.MX6)
  
  

On to the feedback:

 low cost solution for rapid prototyping automotive and industrial applications

For existing commercial customers I think you developed a great product. All companies, everywhere, always have budget concerns. At $35 I don't think most managers will think twice at purchasing some. I personally just bought 2 because it's worth $35 of my time to have a personal development board and not have to deal with purchasing.

Additionally it lets engineers play a bit fast and loose during rapid prototyping. Letting the magic smoke out of a $35 board is better than letting it out of a $200 or $2000 board.

Finally most of your corporate users are used to licensing nonsense and annoyances. It never ceases to amaze me how many different problems the same group of individuals can have when installing engineering tools. Can't reach the licensing server, the licensing environmental variables aren't set correctly, etc.  Compared to Wind River, Mathworks, IBM, Green Hills, dSpace, AVL, Vector and others the hoops to jump through to get the DEVKIT-MPC574** development environment setup are par for the course.

but we also  want that students and hobbyist put their hands on it.

The thing that makes or breaks how much I use a board I've bought all comes down to software support. Arduino didn't take over the world because the 8-bit AVR was technically superior to any of the other products out at the time. The Cubieboard4 is technically superior to the Pi and i.MX6 but is a paperweight because AllWinner is a notorious GPL violator and there is virtually no hardware support for the A80 in main... 

In this regard I don't foresee that you will make much progress into the hobbyist or student market because your software is not competitive with competitive hardware's software. I realize that most of these suggestions are going to be counterintuitive because of most of the markets you have historically served. However for the DEVKIT-MPC57XX products to be a success in the non-commercial market I think the following need to happen:

1. Ditch software licensing. Most of the trouble people seem to be having with the S32 and MBD packages is getting them licensed. It eats into a considerable amount of resources to help these people, plus resources on the backend to verify the licenses.
   
   The situation with the MBD licenses is even worse because it is 1 per account. Imagine you're a professor trying to setup a lab full of computers, how do you license them all?
2. Embrace opensource. For a company as big as NXP your GitHub repository is shockingly empty. Even Apple has gone all in and highlights what they do for opensource: Open Source - Apple Developer. 
   
   This will also allow us to contribute back. I had to start my own repository with the tools I've written for the MBD Toolbox. I personally think the init and setup functions could use some cleaning up but I have no way to contribute those back. 
   
   It also gives you a public bug tracker so you aren't relying on forums to report bug issues.
   
   Help us help you. Better software makes for better hardware. 
3. With regards to the MBD Toolbox, get it added as an official Matlab Support Package. This is the Arduino Support page and this is the STM32F4-Discovery page. Here is the Hardware Support page for everything available from Mathworks.  Getting up and running on any of those platforms is a few clicks away. Getting started working with the NXP products.
4. Make it work with the Arduino IDE. Eclipse is a massive toolbox for a new user. It can be overwhelming for a new developer to get started on. Arduino has support for other boards and architectures. I even went through and made you guys a proof of concept to get started: GitHub - jed-frey/Arduino_Boards: Board definitions for SparkFun-manufactured AVR, ARM, and ESP-base... 
   
   Supporting Arduino shields is only half way there. Users should be able to open any Arduino project, switch to the DEVKIT- boards and compile. This will let you leverage the massive amount of Arduino software already out there. It just requires some work on your part to explain to the compiler what pin "Digital 0" is to the MCU.
   
   Once that is complete anyone will be able to grab inexpensive shields like the Motor Control Shield L293D or a LCD/Keypad shield and use the DEVKIT-MPC57xx products to drive it.
5. Along with that, the Motor Control Class with MBD was a great tutorial however it is slightly above the reach of most hobbyists and students.  If you get #4 done you could take something like this "Smart Car Robot Starter Kit for Arduino" and drop in your DEVKIT- boards. The shield will physically fit but the software is missing to make everything work.
6. Ditch GCC. Reading through the mailing list history of GCC and the VLE/e200 extensions it looks like it never made it into mainline GCC because it was a niche CPU and instruction set. Which means you're working on a branch of a fork of a very outdated GCC. Leading to versioning confusion. You have Version 1.1.3 of GCC version 4.9.2. (Latest GCC is v7). 
   
   I have still not successfully been able to build a my own version. I feel like it's one of those fragile software packages that requires me to stand on one leg and touch my nose while facing north to compile. I tried tracking down all of the individual files you use to build it and couldn't even find some on the web. Others didn't have matching checksums with those that were available. As time goes on your port is going to deviate further from mainline GCC and is just contributing to technical debt that no one needs.
   
   GCC and the GPLv3 also make a slight headache when it comes to the industries that you serve. LLVM is the new cool compiler in town. It's supported by Apple, Qualcomm(!), Google, Mozilla, Sony, Intel and others. The licensing means you can release binaries without the source code to keep some things secret.
   
   There's a presentation on "Building an LLVM Backend". I would suggest making a clean break and starting a 'from scratch' LLVM backend that targets the MPC57xx series. Because of the way LLVM is split up you can leverage the LLVM frontends and optimizer and just spend time on the backend.
   
   
   
   Along with that, it should give you the opportunity to build a compiler that works on multiple architectures and OSs. Right now you only ship for x32 Windows & Linux. I would like to be able to turn my Raspberry Pis into build machines / CI servers. I have a proof of concept setup for building Arduino in a CI environment. Building for your products should be just as easy.
   
   Plus maybe it'll kick the commercial compiler providers in the pants and get them to improve. Mathworks suddenly put effort into R&D when Python got popular. Dealing with Wind River's diab compiler reminds me of the late 90s. No spaces in file paths, no weird characters, must be installed to C:\WindRiver, etc. The lack of adequate competition has made them lackadaisical. Companies that need ISO26262 certifications aren't going to abandon ship for opensource, but it will perhaps give them some incentive on improving their product. 
7. Needs some sort of case. 3D printers are prolific enough that hobbiests & students should have access. Thingiverse has 6,301 results for Arduino, 3,790 for Raspberry Pi and 0 for any of the DEVKIT-MPC57xx.
8. Something needs to be done about the "Open"SDA USB connection. It's flaky, requires drivers, and a far inferior solution to avrdude and stlink for stm32 discovery.

In short you need to put yourself in the shoes of the market you're targeting. Getting started on the Arduino takes just a few steps. Download the IDE (free, no licensing, in a compressed file. Available for Windows, OS X, Linux for x86, x86-64 and ARM). Plug in your board and flash. Depending on your internet connection you could have something on board in 10 minutes. I don't know if I could make heads or tales of Eclipse in 10 minutes.

[jfrey]

There are dozens of ways to solve the above problems. One way would be to try and do everything internally. Devote resources to it. However it is probably the most expensive in terms of both fiscal and manpower costs.

The cheapest and fastest way, in my opinion, to do it would be to 'outsource' it to students by sponsoring projects. 

#7 could be done by an entry level CAD modeling course.

#4 & #6 would probably make perfect college capstone projects for CS, EE or CompE students. LLVM itself was a graduate project. I've been looking at what it would take to sponsor a senior project at local universities.

Total costs could be as little as a donated $35 board. Even if it cost $2,000 USD per project per year it would be a fraction of what it would cost an internal engineer.

Bonus is that you will have students entering the workforce familiar with both e200 PPC cores and NXP's automotive product line. Right now students are graduating with AVR and ARM knowledge making it difficult for companies in the Automotive and Industrial markets to find engineers straight from college with 'real' experience.

Once #3, #4, #6, #7 and #8 are complete these would be amazing boards for higher level controls, mechatronics and similar classes.

And if there are any college students that would like to take on either of the above projects, let me know.

[wem_sperez]

  Hi Jed,

  Your inputs are really interesting and appreciated. It's clear that while we are working on enabling the rapid prototyping with our SW and HW tools, there are still some areas to be exploited. Some of the points above are being addressed now and some other are still under discussion. Generally speaking, the internal actions are in progress, while integration with third parties partners will take some more time. In the meantime, our integration with Mathworks is moving on, we have presence in their web site right now with the NXP Support from Embedded Coder and the Motor Control Development Toolbox pages, these are on revision at this moment so you can expect some improvements in the mid-term. Also, I invite you to take a look at the latest SW announcement we did: NXP Expands its Software Solutions for MPC56 and MPC57 MCUs Based on Power Architecture Technology.

  Please bear with us as we work on the integration with other partners and the open source discussions, these are areas of interest for us and it will take some time to develop the whole project because of all the implicated processes for the company. Nevertheless we'll be looking forward to keep you up to date as discussions progresses.

  Regards!

Wences

[jfrey]

Thanks for your feedback. I realize that it's a lot to take in for your industry when you have historically done things completely different.

Personally and professionally if I had to pick one thing from the list it would be the MBD toolbox licensing. It makes it incredibly difficult to 'scale' MBD to more than one development machine. What is the correct way to be able to use it on both my desktop and laptop? Do I create a second NXP account? Go through the license checkin/checkout process every single time?

It also makes it near impossible to work collaboratively in a professional environment. Getting the hardware is trivial. Even 10 boards is very reasonably priced for almost all educational and corporate budgets.

I'm already creating some internal development tools but I haven't come up with a good way to deploy them to co-workers. Do I have everyone sign up for NXP, then individually license? It would be amazing to just say "Unzip this file from our shared drive and plug the board into USB".

[Daniel_Popa]

Hi jfrey‌,

To get a license for a different PC/Laptop you can do it simply from a single NXP account using RETURN option.

After each license generation you could use return, refresh and then generate the license once again for a different host ID.

Regarding the licensing system - that's something we need to live with at least for a while. We have plans to integrate out toolboxes with Matlab directly to allow the installation via Add-On. In that context we will probably need to reconsider our strategy: we have a couple of possible approaches that we are currently dealing with.

At the moment the licensing is a way to measure our impact to community and a tool for measuring the number of downloads. As any other company our main goal is to drive the business and customer satisfaction.

The tool is free, but the development and support comes at a cost - that can only be justify by the number of downloads, community interactions (like this one) , customers feedback and ultimately the business impact. These metrics keep us in the business and make all this support possible.

Please continue to provide feedback to all the good/bad things your are dealing with (this is valid for everyone in this community) and i can guarantee your voice will be heard.

Best regards,
Daniel

[jfrey]

To get a license for a different PC/Laptop you can do it simply from a single NXP account using RETURN option.

That was what I feared and suspected.

Right now I have 3 machines I would like to build on.

- Laptop for mobile development.

- Desktop for heavy weight development.

- Continuous integration server for automated builds.

It's just not reasonable to be checking in and out licenses constantly to fit into my workflow. I can make it work by limiting myself to a single machine however for the educational market (Which wem'sperez‌ mentioned is a market) it is not feasible. 

Pretend that I would like to buy 10 of these boards to donate to the local university for use in a Mechatronics course. How should the professor go about getting all of the lab machines a license? Have every student sign up for a license? (Requires time taken away from Lab work). Create 10 fake persons? 

Additionally in a university environment you sometime have thousands of machines that students will have access to log into. It would be a great benefit to be able to sit down at any machine, work on some MBD code and leave without having to get the disk Id for every machine and go through the check in/out process repeatedly.

At the moment the licensing is a way to measure our impact to community and a tool for measuring the number of downloads. As any other company our main goal is to drive the business and customer satisfaction.

Understandable, management always likes to attach dollar signs to decisions to make sure that they were the right decision. However there comes a point at which that gets in the way of progress.

What do you think the fiscal benefit was to Atmel for the Arduino project? No user registration, a simple interface and download. Thousands if not tens of thousands of individuals from middle school students to professionals now have exposure to the AVR ecosystem simply because of how easy it was to get started with an Arduino board.

For those used to the 'old' economy participating in the 'new' economy may be a bit jarring. Sometimes there is no direct measurable fiscal result but it makes a better product in the end.

IBM contributes heavily to FreeBSD and Jupyter. Apple contributes to CUPS, Clang, and multiple other opensource projects. Other divisions of NXP (that weren't former Freescale assets) have done that. Parent company Qualcomm has just opensourced it's AI optimization software. Even Microsoft is changing its old ways and getting onboard with the new economy: Microsoft · GitHub 

If the MBD toolbox was available, no strings attached, on GitHub I would happily volunteer my time to add features and fix bugs. While they would be directed towards my use case, the entire community would benefit. I already have a simple repo started GitHub - jed-frey/nxp_mbdtoolbox: Tools and scripts I've written for the NXP MBD Toolbox.  That has a much cleaner init and a tool to make a model from scratch programmatically. However trying to do much more feels like swimming in handcuffs because of the protected/obfuscated code.

[Daniel_Popa]

Hi jfrey‌

I think i was misunderstood in respect with licensing Return option.

It's just not reasonable to be checking in and out licenses constantly to fit into my workflow. 

Once you have generated a license for a host, that license will continue to be active for as long as you need it since it is a permanent node lock license. The Return is just a trick to allow the system to generate another license from the same account. This does not invalidate the previously generated licenses. Those licenses will continue to be valid.

In respect with opening the toolbox to mass markets - the first step has been made: toolboxes are now free of charge and anyone can benefit of those. I think is just a matter of time until all your highlights will be addressed.

Best regards,

Daniel

[jfrey]

Once you have generated a license for a host, that license will continue to be active for as long as you need it since it is a permanent node lock license. 

Excellent, thank you. I was thinking that it worked like other 'checkins' where the one license would no longer work.

That definitely makes life easier.

I think is just a matter of time until all your highlights will be addressed.

Please do not take my comments too harshly as criticism! You have no idea how overjoyed I am with what you have provided so far.

Years ago I started helping with the rusEfi GPL open source DIY ECU, I have an old VW TDI engine I would like to run my own controller on. I ended up stepping away from the project because of the hardware they chose. They ended up going with a STM32F4-Discovery board because the GCC VLE compiler was not available: http://www.chibios.com/forum/viewtopic.php?f=19&t=1570  Working in the industry I just couldn't pull myself to use a device that wasn't designed for vehicle powertrain.

What you have released so far should keep me busy for the next few years. I just know how slow large corporations are to change and I figure if I poke you with a stick now maybe by 2020 I'll be ready for what I'm asking for now.

Thank you again to all of the NXP / Freescale / Qualcomm personnel that have contributed to these projects. (Especially to those that are forward facing that get to deal with customers like me).

[wem_sperez]

  Thanks again for your inputs jfrey‌,

  We see good opportunities to grow in the fields you mentioned, and we are looking forward to it.

  Now, I know I committed to keep you up to date with the availability of the DEVKIT-MOTORGD, and unfortunately it's now delayed by two weeks. The web page is almost ready, so at least you'll be able to get the real material very soon. Thanks for your patient, I'll come back with updates in case of any news.

  Regards!

Wences

Post Edit: Motor GD DevKit is now available: The MotorGD DevKit integrated motor control shield official product page

[Daniel_Popa]

Hi jfrey‌,

This thread has been forwarded to our Marketing team - and we are waiting for their feedback.

Best regards,
Daniel

[paulvlase]

Hi jfrey‌,

I can answer to your problem only. The Largest atomic size for floating-point is disabled by Matlab, not by us.

The list of supported devices is offered/populated my Matlab. I am new so I don't know exactly how the Freescale and NXP devices got there, but to fix your issue we have to speak with Matlab engineers to update it.

Can you tell us why do you want to change that parameter?