8 replies to this topic

[jeremy]

Chris, What toolchain are you using to build the firmware. I'd like to use this as a platform to understand the porting process and add some features as a learning exercise. I'm assuming the bootloader will not need to be changed for this, but just in case I really munge things up is the ICSP header on the board populated. (I only ordered the board today). Jeremy.

[Chris Walker]

What toolchain are you using to build the firmware. I'd like to use this as a platform to understand the porting process and add some features as a learning exercise.

I'm assuming the bootloader will not need to be changed for this, but just in case I really munge things up is the ICSP header on the board populated. (I only ordered the board today).

Hi Jeremy, thanks for the post!

We use RVDS to build the firmware (so that you get the smallest firmware with the most RAM available). But .NET MF supports GCC (the free compiler) as well If you use GCC, you will want to erase the board and flash the GCC-compiled bootloader (long story short: GCC makes bigger code, and the flash map needs to match). The ERASE pin is located directly underneath D0 on the board; just short it to 3V3 or 5V and then disconnect and reconnect your Netduino--and then use SAM-BA to deploy the bootloader.

The "ICSP" header on the board is just for compatibility with the few Arduino shields that need it. There are no additional features on those pins. And the Atmel ARM chip uses USB programming to program the chip (nifty, no?). You can also program a fully-erased Netduino via the serial (D0/D1) pins instead of USB if you prefer (or if you're on 64-bit Windows and have any troubles loading Atmel's SAM-BA drivers).

Chris

P.S. no, the 6-pin "ICSP" header on the board is not populated. This helps us keep costs down for users...but allows users to solder a ~$0.50 part onto the board if they ever need compatibility with a shield which might use it (XBee comes to mind).

Edited by Chris Walker, 05 August 2010 - 03:50 PM.
Added P.S. note on ICSP header

[jeremy]

Hi Jeremy, thanks for the post!

We use RVDS to build the firmware (so that you get the smallest firmware with the most RAM available). But .NET MF supports GCC (the free compiler) as well If you use GCC, you will want to erase the board and flash the GCC-compiled bootloader (long story short: GCC makes bigger code, and the flash map needs to match). The ERASE pin is located directly underneath D0 on the board; just short it to 3V3 or 5V and then disconnect and reconnect your Netduino--and then use SAM-BA to deploy the bootloader.

I was quoted rather a lot of money for the RVDS toolchain! I see that GCC is supported officially by MS.

Thanks for the note about matching the bootloader to the compiler. I'm not sure why larger code would effect the bootloader though. Typically it's not an issue as long as the program being compiled knows where the bootloader is so it gets loaded at the correct offset.

This has got me curious. I'm going to guess that it is easier to rebuild the entire chain than to try and mix and match the RVDS linker maps and the gcc linker maps to make GCC aware of the bootloader location.

The ICSP header on the board is just for compatibility with the few Arduino shields that need it. There are no additional features on those pins. And the Atmel ARM chip uses USB programming to program the chip (nifty, no?). You can also program a fully-erased Netduino via the serial (D0/D1) pins instead of USB if you prefer (or if you're on 64-bit Windows and have any troubles loading Atmel's SAM-BA drivers).

Chris

Neat. I didn't know that about programming over USB with the Atmel chip. Very nifty.

Jeremy

[Chris Walker]

This has got me curious. I'm going to guess that it is easier to rebuild the entire chain than to try and mix and match the RVDS linker maps and the gcc linker maps to make GCC aware of the bootloader location.

Yes. If you're going to compile your own firmware, go all the way with the same C++ compiler. RVDS, Keil, or GCC.

Techie details: The bootloader stores the flash map file. It knows where the .NET MF runtime goes, where your code goes, etc. But the .NET MF runtime needs to have a matching flash map (so it can load your code, etc.). If you use the RVDS-compiled bootloader and a GCC-compiled runtime, they may think that code needs to be deployed one place and run in another. Or they might be happy together. Not sure. It's best to compile everything one way and know that you're good to go.

BTW, GCC is free, which is awesome...but it tends to create larger code so you have a little less room for your C# code. In addition to RVDS, I know that Keil (same compiler...less money) is also supported. See the .NET MF porting kit readme for supported compilers/versions. Also, you can always remove the FileSystem support or other features and free up lots more flash for your C# code if desired.

Chris

[ajcg1973]

I come from the land of the Microchip PICs and after the Netduino I'm completely interested in ARM chips ([font="""]AT91SAM7X512[/font]). What do I need (harware wise) to program the ARM chip to have the same USB comm port bootloader that is on the Netduino after a D0 copper pad reset? I'm hoping that a new ARM single chip purchased from Mouser or Digikey might have this programmed in by default but I even doubt that. I'm sure I would probably need a programmer like other Microcontrollers but I don't know where to start looking for an inexpensive programmer to program the USB comm bootloader. Anyone have any suggestions for an ARM newbie? Thanks.---AJB

[Chris Walker]

I come from the land of the Microchip PICs and after the Netduino I'm completely interested in ARM chips ([font="""]AT91SAM7X512[/font]). What do I need (harware wise) to program the ARM chip to have the same USB comm port bootloader that is on the Netduino after a D0 copper pad reset? I'm hoping that a new ARM single chip purchased from Mouser or Digikey might have this programmed in by default but I even doubt that. I'm sure I would probably need a programmer like other Microcontrollers but I don't know where to start looking for an inexpensive programmer to program the USB comm bootloader. Anyone have any suggestions for an ARM newbie? Thanks.---AJB

Once you erase the Netduino, you can use Atmel's SAM-BA tool (on Windows or Linux) to program the Netduino. SAM-BA can program the Netduino via USB or Serial (D0/D1), at least on Windows.

Chris

[ajcg1973]

Once you erase the Netduino, you can use Atmel's SAM-BA tool (on Windows or Linux) to program the Netduino. SAM-BA can program the Netduino via USB or Serial (D0/D1), at least on Windows.

Chris

Thanks Chris for the quick reply...I have used the SAM-BA many times to program the Netduino but I was curious if the SAM-BA comes pre-programmed on new chips purchased from a distubutor like a Digikey or a Mouser. I love the Netduino but I would like to take code that I have written on the Netduino platform and make a smaller form-factor custom device.

[Chris Walker]

Yes, SAM-BA will program any "empty" Atmel ARM chip.

[ajcg1973]

Great news, thanks again!---AJB