ARM controller - Page 1
Forum section: electronics / general

author: DavidDLC
author_rank: Frequent Contributor
timestamp: August 27, 2014, 06:07:03 pm
content: 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.

author: ctz
author_rank: Contributor
timestamp: August 27, 2014, 06:26:27 pm
content: 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.

author: Skimask
author_rank: Super Contributor
timestamp: August 27, 2014, 06:28:54 pm
content: 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?)

author: dannyf
author_rank: Super Contributor
timestamp: August 27, 2014, 06:46:39 pm
content: QuoteWhy 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.

author: DavidDLC
author_rank: Frequent Contributor
timestamp: August 27, 2014, 06:50:12 pm
content: I want to learn. O0David DLC.

author: Skimask
author_rank: Super Contributor
timestamp: August 27, 2014, 07:47:33 pm
content: 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.

author: Bassman59
author_rank: Super Contributor
timestamp: August 27, 2014, 08:43:19 pm
content: Quote from: DavidDLC on August 27, 2014, 06:07:03 pmSilicon Labs SiM3 series devices. Easy tools, cheap programming dongle and cheap and easy-to-add-to development boards.No question.

author: nctnico
author_rank: Super Contributor
timestamp: August 27, 2014, 08:52:25 pm
content: 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).

author: Kjelt
author_rank: Super Contributor
timestamp: August 27, 2014, 09:13:33 pm
content: 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

author: SirNick
author_rank: Frequent Contributor
timestamp: August 27, 2014, 09:15:07 pm
content: 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 ...

author: janoc
author_rank: Super Contributor
timestamp: August 31, 2014, 09:20:33 pm
content: Quote from: nctnico on August 27, 2014, 08:52:25 pmAFAIK, 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 31, 2014, 09:28:32 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: August 31, 2014, 09:48:37 pm
content: Quote from: nctnico on August 31, 2014, 09:28:32 pmucMon ? custom like ucMon (aka micro monitor) ?

author: janekm
author_rank: Unknown
timestamp: August 31, 2014, 10:26:20 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: August 31, 2014, 11:16:55 pm
content: Quote from: legacy on August 31, 2014, 09:48:37 pmNot 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.

author: janoc
author_rank: Super Contributor
timestamp: September 05, 2014, 04:17:26 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: September 05, 2014, 10:57:49 pm
content: 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.

author: janoc
author_rank: Super Contributor
timestamp: September 06, 2014, 05:54:12 pm
content: Quote from: nctnico on September 05, 2014, 10:57:49 pmEhm. 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.

author: nctnico
author_rank: Super Contributor
timestamp: September 06, 2014, 08:38:28 pm
content: Interrupts -> oscilloscope & pinUSB 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.

author: dannyf
author_rank: Super Contributor
timestamp: September 06, 2014, 09:07:31 pm
content: QuoteYou have this uncanny ability to spot those experts who can only talk the talk,

author: westfw
author_rank: Super Contributor
timestamp: September 07, 2014, 05:26:50 am
content: QuoteYou 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: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.)

author: nctnico
author_rank: Super Contributor
timestamp: September 07, 2014, 11:15:04 am
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: September 07, 2014, 09:54:57 pm
content: (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.)

author: nctnico
author_rank: Super Contributor
timestamp: September 07, 2014, 10:19:07 pm
content: 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/

author: Kjelt
author_rank: Super Contributor
timestamp: September 08, 2014, 07:35:56 am
content: 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 the LSB or is Array 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.

author: remixed123
author_rank: Regular Contributor
timestamp: September 10, 2014, 07:04:57 am
content: If you are looking at ARM and also want Wi-Fi easily working together, then check out TI's CC3200 LaunchPad -andhttp://www.ti.com/ww/en/launchpad/launchpads-connected-cc3200-launchxl.html?DCMP=univ-en&HQS=univ-energiaccs6-univblog-20140902-lpcc3200-en#tabsGreat for IoT, Home Automation or any device that requires Wi-Fi connectivity, and the MCU and Wi-Fi are all on a single chip.

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2014, 07:27:24 am
content: Now that looks very neat! I'm wondering how mature the example code is though.

author: Brutte
author_rank: Frequent Contributor
timestamp: September 10, 2014, 11:19:07 am
content: QuoteOn ARMs you can use as many software program breakpoints as you like. No problem to fill all the flash and/or ram with asm("bkpt 00");.In the default ARMv7M configuration there are 6 program breakpoints (these catch on address of instruction, fetch), 2 data bus ~patches (these catch on some specific literal, 0xDEADBEEF for example) and 4 watchpoints (these are configurable, can catch on instruction fetch, data r,w,rw, from some range, masked values etc,). The ARMv6M are stripped versions (w.r.t. mentioned resources) and offer reduced functionality and of about half of that.Your debugger/dongle can be a dumb one or it can be a smartass. Do not blame the uC for that.

author: mikerj
author_rank: Super Contributor
timestamp: September 10, 2014, 12:11:48 pm
content: Quote from: Kjelt on September 08, 2014, 07:35:56 amDefinitely. If I'm developing a complex algorithm/state machine etc. then I tend to do it on a PC before running it on the micro. I have even managed to run nearly a whole embedded application on a PC by simply running some very basic firmware on the target to read/write peripherals via a COM port. Not suitable for timing critical stuff, though I was running multiple PID loops running at 100Hz with no problem.

author: nctnico
author_rank: Super Contributor
timestamp: September 10, 2014, 03:17:46 pm
content: Quote from: Brutte on September 10, 2014, 11:19:07 amIt is not that straightforward. In order to insert a software breakpoint in flash you'll need to erase & reprogram the flash. A lot of debuggers can run code from SRAM but the problem is that there usually is only a little bit of SRAM compared to the amount of flash.

author: Brutte
author_rank: Frequent Contributor
timestamp: September 10, 2014, 03:47:07 pm
content: QuoteI didn't say it is straightforward. It is just that inserting software breakpoints is possible and there are no internal uC limitations for the count or location of those. With STM8, AVR8 and AFAIK even (some) PIC8 can do that. Also ARMv7M can (in both flash and sram). I am pretty sure some companies (keil? lauterbach?) offer debuggers that can insert software breakpoints in flash. Doesn't OpenOCD or texane-stlink already support that?If you do not like the idea of constant reprogramming of flash during development then you can trySplitCode.

author: David Hess
author_rank: Super Contributor
timestamp: September 10, 2014, 04:47:24 pm
content: Quote from: nctnico on September 06, 2014, 08:38:28 pmThese are my favorite methods. Dedicating a couple of output pins to drive oscilloscope vertical inputs is great for precise timing and using a simple interface, I prefer RS-232, to send real time diagnostic data to a terminal is extremely useful.Another alternative is to use an SPI connection to a custom but simple display and keypad run from either the main program loop or an interrupt service routine.

author: dannyf
author_rank: Super Contributor
timestamp: September 10, 2014, 10:22:53 pm
content: The latest debugging mechanism on the cortex chips is RTT. Much faster than SWO, and requires no additional connection. So two lines on most chips and a single wire on some chips, plus ground, is all that's needed.

author: enggricha
author_rank: Newbie
timestamp: September 22, 2014, 07:19:24 pm
content: Not sure what has transpired here, but I recently wrote a article for starters with ARM controllers for my students. This was oriented towards students looking to start projects with ARM, but you might find this usefulhttp://www.ingenstech.com/arm-based-projects/

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: September 26, 2014, 12:22:32 am
content: Take a look at the NXP line of Cortex-M3 and M4 parts. For a development environment, LPCXpresso is free and allows up to 256K of code. For JTAG, the LPC-Link 2 works very well and is only USD$20.