ARM controller

[DavidDLC]

Hi to everybody, I need your help on this:

I'm not new to microcontrollers, I have used PIC and the lovely Arduino. I have done work with the ADCs, I2C, USART, SPI,  USB, PWM, Comparators, Interrupts.

Now I need to jum into the world of ARM controllers, based on the information I provided, what will be a good ARM controller to start with ?

Thanks for your replies, this is very important for me.

David DLC.

[ctz]

I find the STM32 range to be pretty good. The STM32F407 Discovery eval board is dirt cheap (£12/$20), the chip is really quick (168MHz clock with FPU and standard ARM DSP isns) and has a ton of flash (1MB). For prototyping, you can buy minimal boards from the far east (usually just the chip, crystal and all pins broken out) for a couple more dollars than the chip costs.

[Skimask]

STM32F4 Discovery Board (rather large, pretty powerful, lots of "stuff on it", ~$30), or the Teensy 3.1 (really small, fairly powerful, not a lot of "stuff" on it, ~$20, did I mention it was SMALL?)

[dannyf]

Now I need to jum into the world of ARM controllers,

Why do you need to jump into ARM?

If an 8-bit mcu does the job, it does the job. No reason to waste time on something else.

If you want to learn, that's a different story.

[DavidDLC]

I want to learn.  O0

David DLC.

[Skimask]

Just noticed you referred more to actual "chips" than "boards"...
While I haven't yet, I plan on doing the same thing eventually.  From what I've read, you learn one ARM chip, you've basically learned them all...obvious differences between all the different chips out there not withstanding...
I say "go big or go home"...which is what I plan on doing.  Find the biggest, fastest, most bad ass, yet usable in a hobbyist environment (even if a guy has to use an SMT-DIP adapter for a breadboard) ARM chip available for a decent price and go balls to the walls with it.
I figure if a guy can make blinky with switchy on an MCU, everything else on said MCU is a stepping stone away.
For reference, I'm probably going to go with something like an STM32F439 when I get to that point.  Looks like one of the top-of-the-line, yet semi- hobbyist friendly ARM chips out there at the moment.

[Bassman59]

Now I need to jum into the world of ARM controllers, based on the information I provided, what will be a good ARM controller to start with ?

Silicon Labs SiM3 series devices. Easy tools, cheap programming dongle and cheap and easy-to-add-to development boards.

No question.

[nctnico]

I would take a look at NXP's ARMs as well. I know lots of people work with the ARM controllers from ST but they never really appealed to me. Especially the early ones had wonky peripherals and the flash couldn't keep up with the CPU. I liked the ones from NXP much better and stuck with those; I find them very easy to use. Not just because of the straightforward peripherals but also because the serial bootloader makes it easy to program them using a simple USB-to-serial converter. No fuss with JTAG dongles at all (and keeping the JTAG pins available for regular use).

[Kjelt]

What you need is the search button, there are tens of these posts made already in the last few months and everyone is still saying their same thing 

[SirNick]

Yep.  There's a similar thread in progress as we speak, in this same subforum.

Short answer:  Depending on the poster, you should use ST or NXP or Atmel or Cypress or PIC32 or PIC24 or ...

[janoc]

I find them very easy to use. Not just because of the straightforward peripherals but also because the serial bootloader makes it easy to program them using a simple USB-to-serial converter. No fuss with JTAG dongles at all (and keeping the JTAG pins available for regular use).

AFAIK, the serial bootloader is a standard ARM feature (the STM32 has it as well). I haven't seen an ARM without it so far, but perhaps I am wrong.

On the other  hand, the JTAG/SWD is indispensable if you need to debug your code - it is a lot faster debugging than by blinking LEDs and printing messages through an UART! Bootloader is cool, but no replacement for JTAG/SWD.

[nctnico]

Although pretty common a serial bootloader definitely is not a standard feature! You better check before using a device. In the past 20 years I never even used a JTAG debugger to debug code running on a microcontroller. I use a command line interpreter which allows me to use commands to do testing and monitoring status even when a product is in the field. About half the firmware engineers do their job without using a JTAG debugger. All in all I wouldn't call JTAG/SWD absolutely necessary.

[legacy]

I use a command line interpreter which allows me to use commands to do testing and monitoring status even when a product is in the field

ucMon ? custom like ucMon (aka micro monitor) ?

[janekm]

You could also have a look at the platforms supported through "mbed" (a sort of Arduino-style online IDE) which has an initially shallow learning curve: https://mbed.org/platforms/
(and your code can be portable up to a point, and there are many convenience libraries and drivers already written by others).
The dev board will show up as a "USB drive", you can compile the code in the online compiler and drag&drop it to program the dev board, so you don't even need to install anything to get started.

[nctnico]

I use a command line interpreter which allows me to use commands to do testing and monitoring status even when a product is in the field

ucMon ? custom like ucMon (aka micro monitor) ?

Not ucMon but probably something similar. I think at some point everyone has cooked up or copied some kind of command line. There is not much to it. Just fill a buffer with characters until <enter> and then split the buffer into a command and arguments. Find the first argument (aka command) and pass the argument list to a function which should be called for that command.

[janoc]

If you want a command shell built-in, look at ChibiOS. It comes with one included (along many other goodies). It really does make (not-only) ARM hacking a breeze.

And re JTAG - I am not talking about debugging stuff in the field, if you need JTAG there, then something likely went very seriously fubar. Shell and terminal are cool, but being able to single step code on the bench is still very useful and speeds up the code development a lot.

[nctnico]

Well single stepping through code can also be done when it is compiled for a PC. It is way more easier to debug code on a PC than when it runs in a microcontroller.

[janoc]

Well single stepping through code can also be done when it is compiled for a PC. It is way more easier to debug code on a PC than when it runs in a microcontroller.

Ehm.  I would love to see how you would debug issues with the micro's peripherals, interrupts or something like an USB stack by "compiling for a PC", not even talking about the completely different architectures (and issues that it involves). You really seem to have a rather particular view of what firmware development is about.

Anyway, all this discussion is off-topic, so I will end it here.

[nctnico]

Interrupts -> oscilloscope & pin
USB stack (or any protocol stack for that matter) -> test bench on a PC (*)

(*) You can test all the nasty error conditions which may occur as well this way.

[dannyf]

You really seem to have a rather particular view of what firmware development is about.

You have this uncanny ability to spot those experts who can only talk the talk,

[westfw]

I would love to see how you would debug issues with the micro's peripherals, interrupts or something like an USB stack by "compiling for a PC"

You can't, except on the simplest level, but not ALL of an embedded system's software is dealing with low-level peripherals.  There is usually a lot of code dealing with algorithms and data structures and c-compiler quirks and utilities that debugs fine with a PC compiler.

For example, a while ago a wrote some menu library code for arduino that ended up being mostly about defining macros that would make the menus easy to define:

Code: [Select]

MENU_START_W_PROMPT(menu_3deep, "Three Deep Menu (AYZ X):")
MENU_ACT('X', menu_up)
MENU_ACT('A', menu_boot)
MENU_ACT('Y', menu_yboot)
MENU_ACT('Z', menu_zboot)
MENU_END_W_PROMPT(menu_3deep)

MENU_START(menu_A)
MENU_ACT('X', menu_up)
MENU_ACT('A', menu_boot)
MENU_SUB('B', menu_3deep)
MENU_END(menu_A)
If your coding style is "good" (IMO), then the parts of code that talk directly to peripherals are well separated from parts of code that are essentially environment independent, and those latter parts CAN be debugged ... anywhere.
(and besides, the manufacturer always provides excellent and bug-free libraries for dealing with the peripherals, so you shouldn't have to touch any of that low level stuff.  Cough.)

[nctnico]

Seperating software into hardware drivers and other logic is a good start indeed. I had the good fortune to have worked with very experienced & smart software engineers early in my carreer. They taught me that debugging C code on a microcontroller should be avoided as much as possible because debugging code on a microcontroller is a limited, slow and tedious process compared to debugging on a PC.

My graduation project involved building an ISDN telephone which also involved implementing an ISDN protocol stack. I started with wanting to use the in circuit emulator/debugger (ICE) for the embedded firmware (at that time JTAG wasn't standard and ARM microcontrollers didn't even exist). One of the software guys talked me out of wanting to use the ICE; he convinced me to start writing the protocol stack on a PC because that would allow injecting all kinds of messages, write a detailed log into a text file, single step through code, use an unlimited number of breakpoints, etc. It was a totally different mindset for me (I see the same objections I had back then on this forum) but I followed the advice of that experienced software engineer. All in all it did allow me to develop faster and test the code much more thouroughly than possible on a microcontroller. At the end of the project I had a working ISDN telephone and code which (when compiled on a PC) could test itself. Later on I have used 'my' ISDN protocol stack in several projects. A few devices with that piece of software are probably still out there taking calls every day.

[westfw]

(of course, some of this "debugging on a PC is easier" mindset comes from being old enough to be scarred by the fact that embedded debugging REALLY SUCKED in the old days.  Simulation and ICE-like devices were (or could be) very slow, the upload time was ridiculous (remove/erase/reprogram/reinsert UV EPROMs), and on-target debugging was invasive enough not to be useful for a lot of things.  PROBABLY today's JTAG and debug-subsystem on ARM are better than than the on-PC debugger nctnico used for his ISDN code, or I used porting <largish 68k codebase> to an embedded i186 (remember DOS "debug"?  Yeah; that was the "better" debugger!) But I expect that desktop system debuggers will always be somewhat ahead of embedded debuggers, even if the only reason is the communications link speed.)

[nctnico]

I think I used Borland's Turbo-C for that project which already had a pretty good debugger. The biggest problem was managing the text based 'windows' on an 80 column text based display.

Here is an interesting article on the limitations of debugging software running on a modern ARM microcontroller:
https://community.freescale.com/community/the-embedded-beat/blog/2012/09/17/software-and-hardware-breakpoints/

[Kjelt]

I guess every programmer has its own preferred way of working.
My viewpoint is that PC debugging is very usefull for utils/algos/services that are higher up in the architecture, you can easily extensively if not fully test the API with blackbox tests that are megabytes large, who cares on a pc. BUT keep in mind that there are pitfalls such as: endianess, working with large integers for instance 128bits numbers consisting of a 16 byte array they have given me some nightmares in the past (is Array[0] the LSB or is Array[15] the LSB? is a question of definition and stick to it).

The lower level stuff (under the HAL) I always use an on target debugger, run the code then break and check if all the critical registers are still as expected. Esp. if you have large projects where some alternate functions of pins are swapped while running.
Anyway I guess the old school embedded sw engineers still have a lot of grudge against the ontarget debugging since it was a mess in the past but nowadays I find it a very smooth experience.
What I do find strange however is that with a cheap STM8 i can use as many breakpoints as I want, no problemo, but with an expensive ARM STM32F I can only use 8,    and that is exactly what that article points out, remember your limitations.