ARM chips really have my interest now. They seem so modern and are becoming easier to use from a package perspective.
This is really making me contemplate a switch to them again.
One such example is my audio trigger project I am working on. It can be done with avr and it can be done with a pic. On the other side it can easily be done with a nxp 810 8pin dip and do more.
In the future as I need more there is even tssop which by the looks would be easy to hand solder.
I think I am finding what I enjoy in electronics and that is mucking about with different sorts of audio applications for micros.
With this considered would it be smart for me to switch to arm now or should I stick to 8bit then move to something like the pic32 which has mor dip versions or just go right into pic32.
My assumptions tell me audio need more oomph especially if I want to do any encoding or decoding.
Look carefully into compiler and IDE support before you make the decision which way to go.
PIC32 has a MPLAB X and the free XC32 compiler, which may well be all you ever need.
ARM processors are supported by a wide variety of options, but so far I've yet to find one that's anything like as cost-effective or capable - it's strictly one or the other. Most of the major tool vendors provide limited versions of their products for free, but only if your project will fit into 32k.
There's CoIDE, which is free and unrestricted in that sense, but it only supports a limited range of processors, and I've had all kinds of problems downloading code to my board with it. Or if you have a lot of free time and are prepared to spend it installing software, setting it up, and learning your tool chain's inner workings, you could go with Eclipse, Yagarto and OpenOCD. (If you find a tutorial that's actually up-to-date and accurate, please let me know).
For strictly personal / hobby use, you can get a very good price indeed on CrossWorks for ARM, and that would be my choice without a moment's hesitation given how I've spent the last couple of weeks (installing and trying to get free tools to work correctly).
Yea pic32 has 100% free cpp/c compiler and IDE. I was looking at nxp chips and their IDE is free as well for cpp/c but with a 256kb size limit. This seems reasonable. For unlimited 1 person with nxp it is a $500 upgrade. Their IDE is based off eclipse. I guess the real question if switching is the right decision would more be a mips vs arm thing...
I don't really think you get much out of those arm chips that you don't out of the 8-bit chips, for what you do.
Audio is very slow (for mcus), other than fft and potentially graphics. If it is simple controling of a relay, or a digital pot, or bias adjustment, or speaker protection, etc. your 8-bit mcus, especially multiple of them each dedicated to a particular job, would be a more efficient way to go.
Having said that, the arm chips offer a lot of value. I have no problem what soever with CoIDE (a big fan) on STM32 and older Luminary chips. The issue of limited device support, as mentioned earlier, is true, only if the device you intend to use isn't supported.
I would also recommend TI's ARM chips particularly their launchpads - incredible value for a feature rich chip. The free version of ide (CCS) is fully functional as well.
I am also a big fan of PIC24 chips and think they offer a lot for such a little known chip. You do, however, have to pay for the compiler for a fully functional / uncrippled version.
I simply use Eclipse and GCC (sourcery lite for ARM) which supports any code size and any ARM CPU or microcontroller you can think of. If you have an OpenOCD compatible JTAG dongle you can debug all you like. The latest version of Eclipse has improved support for cross platform compilers so setting up a project is peanuts. Google can find a huge amount of tutorials on how to setup Eclipse and GCC for ARM so start there.
I simply use Eclipse and GCC (sourcery lite for ARM) which supports any code size and any ARM CPU or microcontroller you can think of. If you have an OpenOCD compatible JTAG dongle you can debug all you like. The latest version of Eclipse has improved support for cross platform compilers so setting up a project is peanuts. Google can find a huge amount of tutorials on how to setup Eclipse and GCC for ARM so start there.
I did this also for some time, and it works well enough. Just a couple of things to be aware of:
- With sourcery compiler you wont have hard floating point unless you buy their standard licence. I.e. the free and cheap licences don't do hard floating point.
- A lot of the tutorials are very out of date, so you'll likely have to try a few until you get something that works properly.
My recommendation would actually be to use one of the code limited free tool chains until you've got the hang of the libraries for whatever device you're using. The 32kB limit on Keil tools will get you quite a long way with small projects unless you're storing large chunks of data in flash (e.g. GUI sprites.)
Yea the tools are not something I was worried about as now a days things can be a bit easier to setup. Overall I am just trying to figure out if it is worth the effort of switching over to a more powerful micro that is more difficult to work with (meaning for some chips I will need to make breakouts for breadboard proto) from the perspective of audio processing and such. For instance my original intent was to use the audio trigger for a stopwatch. After prototyping I realized it was so much fun the project is now becoming and audio visualizer. IE. It will display generated patterns based off of the actual audio signal.
Like dannyf said it may be possible to get away with multiple 8 bit micros one for each task.
On the other side there is the MIPS based PIC32 which has quite a few 28+ pin dips and I am already familiar with the PIC environments and my PICKit3 can program/debug these chips as well. There is also a 100% free C++ compiler for these (because I think it is straight up GCC unlike the XC32 C compiler which is not free unless you lose optimization).
It does seem like more people use ARM over PIC32 but I do not know the reasoning behind this besides age as MIPS M4K is actually a more efficient core from what I understand.
It does seem like more people use ARM over PIC32 but I do not know the reasoning behind this
Most people do that because others do that,
I don't think cores make that big of a difference (or any meaningful difference). The peripherals and vendor support do.
ARM-based chips are widely available and quite inexpensive. They really offer a lot for the money.
As to pdip, you can either get adapters; or some of those boards have onboard connectors or are shaped like dip devices (lpcxpresso for example).
- With sourcery compiler you wont have hard floating point unless you buy their standard licence. I.e. the free and cheap licences don't do hard floating point.
AIUI it still does softfp, ie. generates floating-point instructions but passes floating-point parameters in integer registers. If you're eg. a heavy user of the C floating-point library you might notice a performance difference, but you can usually design your own code so it doesn't use lots of fp function parameters.
On the other side there is the MIPS based PIC32 which has quite a few 28+ pin dips and I am already familiar with the PIC environments and my PICKit3 can program/debug these chips as well. There is also a 100% free C++ compiler for these (because I think it is straight up GCC unlike the XC32 C compiler which is not free unless you lose optimization).
Microchip's "free C++ compiler" is a license key to the base XC32 C compiler which enables compilation of C++. It does not change the available optimization levels. However, since the compiler is GCC you can
download the source code and rebuild it with all optimizations enabled (the same goes for their XC16 compiler). If you're not worried about legalities you can also see exactly how the license check is implemented and maybe figure out something that way. Since it's all open-source there's no point in a complicated protection scheme.
From a business perspective I think Arm is used so you have multiple competitors offering almost identical (core) products. Its bad business if you have to deal with a single microcontroller source.
Still also with Arm you have to read the datasheets closely not to get caught with differentiations between products. To give an example one of the STM32's ( thought it was the 103 but not sure) has a flash read wait state penalty if the core runs over 48MHz. That kind of things ,or peripherals that have too many errata sheets to be comfortable.
Its bad business if you have to deal with a single microcontroller source.
Everyone's Cortex-Ms have different peripherals and pinouts, so if you have to change manufacturer you have to redo the board and much of the software anyway. There's very few true second sources on the market anymore.
Yea the tools are not something I was worried about as now a days things can be a bit easier to setup. Overall I am just trying to figure out if it is worth the effort of switching over to a more powerful micro that is more difficult to work with (meaning for some chips I will need to make breakouts for breadboard proto) from the perspective of audio processing and such.
For this purpose I have made several PCBs which holds an ARM controller and some other circuitry (power, clock, USB components). I piggy bag this PCB on prototype circuits (breadboard or self etched PCBs). This works pretty well. Ordering 10 PCBs from (for example) Iseeed is pretty cheap.
Or if you have a lot of free time and are prepared to spend it installing software, setting it up, and learning your tool chain's inner workings, you could go with Eclipse, Yagarto and OpenOCD. (If you find a tutorial that's actually up-to-date and accurate, please let me know).
The guys at Olimex went to the trouble of packaging Eclipse, Yagarto (GCC) and OpenOCD into a bundle and wrote some documentation on how to use it:
https://www.olimex.com/Products/ARM/JTAG/_resources/OpenOCD/. Granted, they primarily target their own hardware, but if you just happen to use the same chips (or their actual hardware, it's cheap) it might make things easier for you.
one of the STM32's has a flash read wait state penalty if the core runs over 48MHz.
Um, a LOT of the ARM microcontrollers are unable to access their flash memory at the full clock speed of the CPU. They put assorted schemes in place (wide fetches, pseudo-caches, etc.) to minimize this, often causing cycle-accurate timing to become quite difficult. NXP LPC18xx gets configured to take up to 9 clocks to access flash, for example (or maybe 16), but it has as "flash accelerator." It seems that flash memory technology that provides faster than 20ns access is just ... uncommon.
To some extent, I rate ARM vendors on how well they manage to explain the flash system performance.
Thats why with the LPC18xx you have quite some RAM to run code from, at true 180 MHz. They even ship them as Flashless parts, where you can have a lot of external spi flash. Of which I think you can run approx. 70 MHz on.
But I think the reason why ARM is getting so popular is because the core architecture is very similar. If you take a piece of code, from an LPC11xx for example and put in an STM32F4xx, it will run without much change in the core structure. For peripheral access a lot has to be changed, since this is where the competitive market is located, but if your software is properly build up in layers, you should be able to swap a driver without changing everything.
There are also some standardised library things out there, like CMSIS, but they do not seem very clear to me.
Another reason to use ARM, is runs an (RT)OS very easily. It is basically designed for that.
And to respond to the start-post, LQFP is also a excellent candidate for hand soldering, just make sure your pads are long enough. You can get those LPC18xx in LQFP-massive
.
If you expand your view to LQFP a whole new world of chips becomes accessible.
It does seem like more people use ARM over PIC32 but I do not know the reasoning behind this besides age as MIPS M4K is actually a more efficient core from what I understand.
Didn't Microchip announce years ago that they were collaborating with MIPS on a new M14K core line of PIC32's? Did it eventuate?
one of the STM32's has a flash read wait state penalty if the core runs over 48MHz.
Um, a LOT of the ARM microcontrollers are unable to access their flash memory at the full clock speed of the CPU. They put assorted schemes in place (wide fetches, pseudo-caches, etc.) to minimize this, often causing cycle-accurate timing to become quite difficult. NXP LPC18xx gets configured to take up to 9 clocks to access flash, for example (or maybe 16), but it has as "flash accelerator." It seems that flash memory technology that provides faster than 20ns access is just ... uncommon.
I'm not sure if this is true for the LPC18xx series but the NXP controllers I've used so far all have a flash accellerator. The flash itself is 128bit wide so it can sustain the maximum execution rate and it has a pre-fetch unit so it will start to fetch the next instructions or data before the CPU actually needs them. It works bit like a cache.
To answer my on question, the new line will be the PIC32MZ series and rumour has it that more info will be available toward the end of this year with chips available early next year and to continue with unfounded rumours 200MHz, DSP, MMU, upto 2MB flash, upto 512k ram... personally I'm excited
If you take a piece of code, from an LPC11xx for example and put in an STM32F4xx, it will run without much change in the core structure.
Only to the extent that your code doesn't touch the peripherals. A generic layer across different peripherals from different vendors would be very difficult to maintain - there are such examples, in one or two types of peripherals but across multiple peripherals from different vendors has not been done.
but if your software is properly build up in layers, you should be able to swap a driver without changing everything.
We should eliminate hunger; we should have world peace, .... Unfortunately, reality is quite different.
with chips available early next year
Unless they offer something you cann't have from anybody else, why wait?
As for PIC32 I am not sure of the quality of the chips. In my research I have come across numerous instances of people getting faulty chips. I know for my current project I can't use a 8 bit PIC due to a silicon bug that was never fixed and is present on all chips. The issue is with the input pins. When you have input coming in at fast intervals like audio from my Electret Mic the Interrupts do what I call a miss and things hang up. It is due to the the data coming in faster then the interrupt latency I believe causing the issues so I have been working with my ATTiny2313A with no issues with the interrupts minus the occasional self correcting hiccup. With the pic you literally need to hit the microphone to get it to unhang.
With the pic32 I heard of lots of issues with faulty resets and such not sure if this has been fixed. On the side of ARM I do not see too much of this issue anywhere except on the LPC810 dip with a faulty ADC which they are fixing in the next revision.
I do understand there are bad chips and it happens it just seems like from a research perspective more of the issues I find are from PIC32. Then again the PIC32 is very very new compared to ARM.
Right now I am leaning towards picking up a LPCXpresso and tinkering around with their IDE which seems quite lenient 256k limit on free version. Then to upgrade to the Pro it is only $500 which seems for sure in the hobbyist price range if you get serious enough that you actually need the unlimited space.
Just not sure which chip to look at from their M0 lineup.
The issue is with the input pins. When you have input coming in at fast intervals like audio from my Electret Mic the Interrupts do what I call a miss and things hang up.
The latency is about 15 - 20 clock cycles on PICs (similarly on AVRs), or 20 us max with 4Mhz crystal, or 4us max with 20Mhz crystals. That's considerably less than 50us (20Khz signal) min for your audio signal.
Effectively, if your hardware / software is right, you shouldn't have any problem, even at the low-end of the speed, to deal with audio signal in a PIC.
I think the reason why ARM is getting so popular is because the core architecture is very similar.
Oh, I agree. But I'm not sure that it's a VALID reason, given that peripherals can be dramatically different, even on something supposedly trivial like GPIO. If you were programming in a HLL, a lot of that similarity would be implemented by your compiler regardless of underlying hardware. It's also not entirely clear than CA8, CM3, and CM0 are really any more like each other than PIC32, PIC18, and PIC16 chips. There are some pretty significant instruction set and architecture differences.
Oh, I agree. But I'm not sure that it's a VALID reason, given that peripherals can be dramatically different, even on something supposedly trivial like GPIO. If you were programming in a HLL, a lot of that similarity would be implemented by your compiler regardless of underlying hardware. It's also not entirely clear than CA8, CM3, and CM0 are really any more like each other than PIC32, PIC18, and PIC16 chips. There are some pretty significant instruction set and architecture differences.
I couldn't agree more but I think the reason these are used so much is the ability to run OS simply and the fact that there are many suppliers - therefore you can get lower price which is all that matters, right?