51
Vote

Upload native code and break up tinyclr

description

This has been mentioned several times before in various forms: It would be really nice if you were able to upload/deploy native code along with your managed code. Perhaps even with standard P/Invokes etc. "Custom Native code" is a necessary evil when the managed code isn't jit compiled. (Which is fine.)
 
If you want to add native code today, you have to recompile the whole netmf source and reflash it. This presents several problems:
 
  1. Reflashing the tinyclr is not always easy. And it varies from platform to platform. (This might have been adressed in netmf 4.2 already though. Fw updates.)
  2. Compiling the netmf is not always easy.
  3. A lot of companies doesn't give out their distribution of the netmf. (Hence you can't compile it.)
  4. Compiling with free or low cost native compilers will often yield bigger and slower results than the company compiles. As an example you can take a look at the Netduino boards from Secret labs. Add TCP/IP to the tinyclr and the resulting compile won't fit. The RVDS compile from Secret Labs will however.
     
    This leads to the next point. If you could upload native code, you would be able to break up the tinyclr into several compile images. This would mean the world to small resourced boards like eg. the USBizi boards from GHI and the Netduino boards from Secret Labs. (And the netmf is meant to be small right?) Today when you add a reference to eg. Microsoft.SPOT.Hardware.SerialPort to your project. You're not really adding anything but a "managed header". The actual (native) code is already compiled into tinyclr and is already on the board. The tinyclr could be much smaller if it didn't contain everything. And the netmf could become much bigger if it didn't have to worry too much about the tinyclr size. Eg. if you could add just the right (few) amount of references, in each of your projects, it wouldn't matter if the whole netmf didn't fit on the board.
    This would also improve the PK. With a smaller tinyclr it would be easier to make a new port. (Or perhaps just faster.) You would only have to fokus on the basics. All the extra stuff like drivers and nice-to-have could then be developed later and/or by the community.

comments

Psychlist1972 wrote Mar 23, 2011 at 7:17 PM

You have my vote on the spirit of this one (not sure what the final implementation would look like). I like the idea of breaking up the runtime, but I'd be happy just to be able to easily/cleanly integrate native code with my apps.

I know some companies like GHI have their own custom solutions to enable integrating native code. Netduino currently doesn't have it, and I'd really like it there. With the managed code performance being what it is, I've run into a number of places where a little native code could mean the difference between continuing a project and scrapping it. Doing my own build of the firmware (using an inefficient compiler like GCC) is a pretty heavy hammer to solve this issue.

staceyw wrote Mar 30, 2011 at 2:17 PM

I agree. Side by side native would seem so natural. I have resisted GHI RLP for this reason of not wanting to bounce back and forth to gcc or re-learn another IDE/compile/debug UX. Windows going ARM anyway, so would think ARM compilers already running.

juliusfriedman wrote Jul 30, 2011 at 8:43 PM

Or allow the Creation of Managed C++ Projects which can be used for more advanced development which requires precise timing, et al.

Alex111 wrote Aug 7, 2012 at 1:51 PM

Maybe sometimes there will be a JIT compiler? Maybe optional for bigger devices?

Sign in to add a comment or to set email notifications