21 replies to this topic

[hanzibal]

Hi there! I'm in the need for speed and having looked over the diversity of ARM development boards I haven't really found anything but the ST Mbed to be comparable to the Netduino mini when it comes processing power, flash and RAM size given the formfactor. The MBed seems nice but I'm not in favour of the online IDE (web based!). So here I am thinking of programming the Netduini mini natively without going through the CLR. Here are some questions that I like to ask those of you who have done this journey before me: 1. What toolchain do I need in order to do this in the C programming language or even C++ if possible? 2. How can I do debugging? 3. Are there any libraries available in terms of not having to reinvent the wheel, for example when it comes to SD cards and such? 4. How does deployment work, SAMBA? All tips and recommendations would be greatly appreciated. Thank you and best wishes!

[Magpie]

Hi Hanzibal
You could try FreeRtos

http://www.at91.com

These guys might help.

Tell us how you go.

[hanzibal]

You could try FreeRtos

Cool, I'll check that out. Thanks.

[CW2]

1. What toolchain do I need in order to do this in the C programming language or even C++ if possible?

There are many toolchains available for ARM processors, from free GCC-based to several thousand dollars commercial ones - for example Yagarto, Sourcery CodeBench, Rowley CrossWorks for ARM, IAR EWARM, Keil MDK-ARM, ARM RVDS...

2. How can I do debugging?

Netduino boards do not expose microcontroller's JTAG pins, so debugging is not available. You'd need a development board for that (or custom made PCB, AT91SAM7X requires just a few capacitors and a crystal to operate) and JTAG debugger. Most commercial toolchains can be obtained with such debugger, often it is just OEM version of Segger J-Link or similar (cheap clones available on the Internet), they also support OpenOCD.

3. Are there any libraries available in terms of not having to reinvent the wheel, for example when it comes to SD cards and such?

Try Atmel's AT91SAM7X-EK Software Package (zip) or samples which come with the toolchain. There are also numerous projects on the Internet...

4. How does deployment work, SAMBA?

You'll be using JTAG for application deployment during development.

[hanzibal]

Thank you for that thorough answer. Debugging is pretty important and so maybe the mini isn't right for me after all. I'll look into the things you mentioned.

[hanzibal]

To be frank, all of this sounds a bit overwhelming (as one might expect) and I begin to really appreciate what Secret Labs has done for me. Even though I'm not a complete fool when it comes to embedded programming, this whole starting strip seems as if constructed by people who want to keep it all a secret to people like me (not meaning you CW2).

[Geancarlo]

I'm not really experienced, but when I think about ARM this is what comes to my mind: Compiler/IDE+JTAG debugger+complex documentation/beginner unfriendly=$$$$$$ well, that's about it for "pre" arm cortex devices. If you want an easy to play development kit you should try STM32F4-Discovery. It comes with a programmer/debugger, CMSIS libraries making life easier, DSP libraries and you can use a free license IDE with it(Attolic True Studio).

[hanzibal]

If you want an easy to play development kit you should try STM32F4-Discovery. It comes with a programmer/debugger, CMSIS libraries making life easier, DSP libraries and you can use a free license IDE with it(Attolic True Studio).

Found this STM32 board:

http://www.micro4you...ment-board.html

It's currently out of stock but it's small, fast (72Mhz) with plenty of Flash and RAM, JTAG, all the cpu pins are available - and it's cheap too.

[hanzibal]

If you want an easy to play development kit you should try STM32F4-Discovery.

Ordered an STM32F4-Discovery board today and we'll see how far it takes me

[hanzibal]

Ordered an STM32F4-Discovery board today and we'll see how far it takes me

Got the board yesterday and even though I know this doesn't really belong here I couldn't help myself.

So here's a short little video that I made showing the board running a multithreaded program upon FreeRTOS. The program uses the onboard 3-axis accelerometer, one of the UARTs and four of the LEDs and the ever so famous FTDI 3.3V USB to TTL cable in order to send debug messages to HyperTerminal on Windows XP:

http://www.youtube.com/watch?v=1C4QhtvSMRM

Found the demo here and it compiled beautifully with Atollic TrueStudio Lite which is free.

[Geancarlo2]

Hey, saw your post on tinyclr forums so I remembered about this thread lol Nice timing with the FEZ Cerberus release!

[hanzibal]

Nice timing with the FEZ Cerberus release!

Yeah, I think well at times but oh so slowly :-)

[Fred]

I'm also thinking about some native ARM coding and got a STM32F4 discovery board. The interesting thing is that now the Go and Shield Base have very similar JTAG and STM ARM processors. Any progress I make on the Discovery board should translate across nicely. If I get some time to devote to it of course. That's always the problem! It's even crossed my mind that porting the .NET framework across to this board might not be so tricky if leveraging the hard work that's been done by KodeDaemon. Just think of all those directly accessible IO pins! I'm not sure I'll get round to giving it a go but somebody might.

[CW2]

It's even crossed my mind that porting the .NET framework across to this board might not be so tricky if leveraging the hard work that's been done by KodeDaemon. Just think of all those directly accessible IO pins! I'm not sure I'll get round to giving it a go but somebody might.

Actually, it is easier than you think: KodeDaemon's port runs on the STM32F4 Discovery board, it just needs to be adjusted to different crystal frequency (8 MHz vs. 25 MHz on Netduino Go), i.e. changing a few #define-s.

Or, to be more precise: Netduino Go firmware is STM32F4 Discovery port adjusted to different crystal frequency, by changing a few #define-s

[Chris Walker]

Or, to be more precise: Netduino Go firmware is STM32F4 Discovery port adjusted to different crystal frequency, by changing a few #define-s

Well, before adding in the go!bus IO virtualization and such

Chris

[CW2]

Well, before adding in the go!bus IO virtualization and such

Oops, forgot to mention that. Sorry (blush smiley)

[Joel Kunze]

Actually, it is easier than you think: KodeDaemon's port runs on the STM32F4 Discovery board, it just needs to be adjusted to different crystal frequency (8 MHz vs. 25 MHz on Netduino Go), i.e. changing a few #define-s.

Or, to be more precise: Netduino Go firmware is STM32F4 Discovery port adjusted to different crystal frequency, by changing a few #define-s

It has been way too long since I have worked at this level, I'm stumbling all over ...

I don't have a Netduino Go yet, and I've got some STM32F4 Discovery boards here and the time limited RVDS 4.1 compiler.
I've found spots in the source code for getting the clock setup for an 8MHz HSE

1) Line 47 of platform_selector.h looks like it was changed from 8MHz to 25MHz so I assume I should change it back?
#define SYSTEM_CRYSTAL_CLOCK_HZ 25000000 // 8MHz external clock

2) Line 91,92 of stm32f4xx.h is already at 8MHz and I think HSE_VALUE is already defined by the time it gets here.
#if !defined (HSE_VALUE)
#define HSE_VALUE ((uint32_t)8000000) /*!< Value of the External oscillator in Hz */

3) Line 26 of STM32_bootstrap.c defines a divisor.
#define PLL_M 25

So, I change 1 and 3 to 8000000 and 8 respectively. Build the solution. Use the ST-Link utility to flash the resultant ER_FLASH (bin or hex).

The controller doesn't appear to start up properly. Plugging in the micro USB (while powering from the mini USB) doesn't register as a USB device at all.

Do you know if I have addressed the correct locations in the source code to get set up for an 8MHz HSE? Or is my problem potentially elsewhere?

[CW2]

Do you know if I have addressed the correct locations in the source code to get set up for an 8MHz HSE? Or is my problem potentially elsewhere?

IMHO the changes are correct. But, you have to flash ER_BOOT too, and preferably ER_CONFIG. Alternatively, you could use tinyclr.axf for development and debugging, it contains all the sections.

[Joel Kunze]

IMHO the changes are correct. But, you have to flash ER_BOOT too, and preferably ER_CONFIG. Alternatively, you could use tinyclr.axf for development and debugging, it contains all the sections.

Thank you...
I was unable to figure out how to flash the .axf file :S
I think I took a long way around, but I used DFU File Manager to inspect the posted Secret Labs tinyclr.dfu.
I used fromelf on the .axf to verify the loading address for each of the 3 boot, config and flash files.
Then I used DFU File Manager again to combine the 3 bin files into a DFU.

Success, I have a STM32F4 Discovery running netmf.

Again, thanks for your help.

Looking forward to the source patches for GCC!

[CW2]

I think I took a long way around, but I used DFU File Manager to inspect the posted Secret Labs tinyclr.dfu. I used fromelf on the .axf to verify the loading address for each of the 3 boot, config and flash files. Then I used DFU File Manager again to combine the 3 bin files into a DFU.

Hats off to you for figuring this out