I've been reading your progress on the channel9 forum, its an exciting prospect to run C# code natively on an ARM. If you do go the assembler route please be aware there are different ARM instruction sets, ARM, THUMB, THUMB2. Some of the more recent ARM based chips (Cortex-M3) only support THUMB2, where as the ARM7TDMI chips support ARM & THUMB, but not THUMB2.

Anyone have any further development with this? I too, am using the M3 (SAM3S-EK board) under the advice of a wise man for a project. I have yet to figure out how to port it over to .NETMF. Any advice in a jumping-off point would be greatly appreciated!

I've done a partial port for a Cortex M4 (Freescale's Kinetis), if you wish to embark on a port for the STM32 some of that should be useful (NVIC, some Thumb2 tweaks). http://kinetismf.codeplex.com/

I hit a bit of a brick wall with the above now as i've run out of space with GCC in debug mode (even using 4.5), so i cant really do much more (i.e. Ethernet) Depending on your requirements you will encounter the same, unless you have the KEIL compiler. I'm waiting for the 1mb parts coming out later this year (hopefully...).

There are some 1mb STM32 parts out now (with Ethernet and USB host), unfortunately the dev-kits are nowhere to be found.

One fairly simple optimization is to use direct threading - using labels instead of a switch statement - however that wont really help for the ARM7TDMI as it has no branch prediction. I will have a look at that as i'm currently doing a Cortex-M4 port (*PLUG* - http://kinetismf.codeplex.com/) which should benefit from it. Also some of the other compilers (non GCC) may not support it as it is not ANSI C. Update: had a look and keil does support this as well (http://www.keil.com/..._ch03s07s12.htm), and reading some more on this technique it does reduce the instruction count (no range check instructions) so this is still worthwhile for the netduino.

Wow thanks for the link. I like the fact that it's not per-board it's per-area. Sure, sometimes you may only want one or two boards but who couldn't use extras for a decent price? If you've got a 3x4" board they'll make you 8 of them for $100? Including shipping? That's fantastic. Love it.

Ah - the catch is no testing on 2 layer boards with a 15% fail rate. 4 layer and higher they test and have a 2% fail rate. Still, using the example above you'd have 1-2 boards fail per batch. Even with 2 failed boards you're talking about ~$18 per board. Not bad at all.

I've found seeedstudio http://www.seeedstud....html?cPath=185 to be cheapest for small prototyping even with the import duty & delivery costs. $35 for 10 boards of a max size of 10cm by 10cm.

I use diptrace (paid for version), however there is a freeware (300 pin limitation) and a non-profit version (500pin limit - i think you have to email them for this one). http://www.diptrace.com/download.php http://www.diptrace.com/nonprofit.php I tried to use eagle and designspark, eagle was just wierd in its UI and i really didnt like its pcb layout part. Designspark was a lot better in the schematic, and the pcb layout was ok but i still prefer diptrace. One thing i found about diptrace was repositioning/resizing 45degree tracks was a lot easier, eagle and designspark would tend to mess them up if i tried to adjust them. One thing that is great about eagle however is the ammount of part libaries for it, however both designspark and diptrace can import them.

Tangent: for SimpleNgen, I probably could have saved myself a lot of work by letting GCC do the code generation. That is, we could narrow SimpleNgen's job to be that of translation from (a subset of) MSIL to C source, and then we would let GCC translate from C to ARM (or Thumb, or anything else). Perhaps I ought to have done it that way, but I wanted to play around with writing a compiler.

There was a partial implementation of modding gcc to compile cil to native - the frontend part of this project:

http://gcc.gnu.org/projects/cli.html

Just to add a suggestion for the native side compilation, using VALA (its basically a c#-like preprocessor that spits out c code) in some way might be cute. Maybe you could have stub managed classes for intelisense for talking to the device, which get swapped out for native ones written in vala when compiling via vala + gcc.

Although i suspect statically linking with stuff vala needs may cause license issues to arise.

There is a port for the STM32, however the site is in chinese: http://translate.goo...04/5863524.aspx

When trying to find out info regards the porting kit, i found this chinese blog who have done a guide for their port to a STM32 processor, which like the NXP is a Cortex M3 although not as high spec. http://translate.goo...04/5863524.aspx

Heres a very basic KS0108 driver that uses native code to speed up the screen update. A little video of the kind of performance i got out of it: quality of the video isnt the best. This is using a framebuffer (2k of ram used!) method to keep things simple and get the best speed, it could be modified to be do a read/modify/write method. Its also using a lot of IO, i wired up the LCD as per an article i found for the arduino http://www.arduino.c...Code/GLCDks0108

Just a tip for anymore else putting this into their own custom firmware, i had to enable the "Generate native stubs for internal methods" option in the project properties, with a root name of "BitBanger" and a folder called "stubs". If you dont do that the firmware download complains about a missing checksum in the assembly.