EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: blewisjr on October 12, 2013, 01:27:52 pm
-
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 (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023073) 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/ (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 :P.
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.
-
with chips available early next year
why wait?
What's a fan-boy to do?
-
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?
-
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.
I let the C compiler deal with that. The difference in architecture aren't that big either. All the old ARM microcontrollers I've seen seen used the ARM7TDMI core which can execute regular ARM code and 16 bit thumb code. Some have multiple busses which allow the processor to keep fetching instructions while a peripheral does a DMA transfer (all this magic is completely transparent to the programmer). The newer Cortex devices have the thumb2 instruction set and an integrated IRQ controller. If you come from a controller family which has the vectored interrupt controller then the operation isn't much different. All in all Cortex Mx devices is more like an upgrade from ARM7TDMI than a radical change.
Whether the peripherals are different depends on the vendor. If I look at ST they probably are very different. The peripherals on the STR700 series are a complete joke. NXP on the other hand always had good peripherals and kept as much from the ARM7TDMI controllers as they could. To me their Cortex Mx controllers feel just like the old controllers with a new CPU under the hood.
-
Prices for 1+ quantities from one Polish online shops (this one deals mainly in microcontrollers and embedded stuff)
-ATMega8-16AU - 5.81PLN (1.38€)
-STM32F030F4P6 - 3.68 PLN (0.87€)
-LPC1111FHN - 6.62 PLN (1.57€)
-PIC16F628 - 6.87 PLN (1.63€)
Now please give me one reason to use AVR or PIC?
-
Now please give me one reason to use AVR or PIC?
For you there is probably no reason.
For me on the other hand, I can have that PIC screaming it's tits off, doing exactly what I want in under 10 minutes.
The arms on the other hand by there very nature are several orders of magnitude more complex for somebody that hasn't used them before... It'll take me ten days just to get a tool chain set up ::)
-
I give You a few from Polish _hobbyist_ perspective :-) :
- lack of DIP packaged ARM's. I know only two of them (LPC8xx and LPC1114).
One is 8 pin, second is hard to get. When I want to make some simple hacking, proof of concept I don't want to solder chip to some breakout board that costs more than ARM chip itself,
- IDE setup - I know it should be easy but believe me from time to time I really have some issues with some chips.
I do have LPC810 breakout board and from some reason this chip won't work with Segger J-Link under Linux. Don't ask me why. I tried everything.
Lots of chips means that there is no nice and good IDE to "rule them all" (under Linux).
Those two are serious limits from my perspective.
If I need 32bit PIC32 is also quite good choice. MPLAB X works like a charm under Linux, it's complete IDE, PICkit3 works, chip can be obtained with single pieces with reasonable price (3-4 Euro/12-15 PLN) in DIP28 package.
It takes few minutes to get such chip running on breadboard.
Of course from company view all those issues are non important :)
-
-STM32F030F4P6 - 3.68 PLN (0.87€)
The F0 series is very aggressively marketed indeed.
For me on the other hand, I can have that PIC screaming it's tits off, doing exactly what I want in under 10 minutes.
I can get any major flavors of chips, arms or not, screaming its tits off in under 10 seconds.
Well, maybe not 10 seconds but definitely in 30 seconds - I have accumulated a fairly large library for the standard peripherals.
- lack of DIP packaged ARM's. I know only two of them (LPC8xx and LPC1114).
Some LM3S chips are soic - but you are generally right.
- IDE setup - I know it should be easy but believe me from time to time I really have some issues with some chips.
CoIDE excels in this area. However, their support of chips is limited.
-
I came in the thread to post I was considering to take the jump from PIC32 to ARM to take advantage of the speed boost, DRAM memory interfaces and the ADC boost, then I saw about the PIC32MZ! Think I'll hold on a bit longer!
-
the PIC32MZ
Don't hold your breath: they have been talking about that for quite some time now.
In the chip business, there is no need to wait for anything: there are many alternatives.
-
there are many alternatives.
I know nothing about arm processors and I'm just a hobbyist so please take this as a genuine questionremark.
If those specs are anywhere near true, then a quick cursory google search for that speed, that amount of ram, peripheral laden MCU, readily available in single chip quantities, etc etc, there appears to be slim pickin's
-
the PIC32MZ
Don't hold your breath: they have been talking about that for quite some time now.
In the chip business, there is no need to wait for anything: there are many alternatives.
This is true, about alternatives. For me personally, I had such a hard time learning the PIC32's (and still am, in many ways) that starting over on a new platform is kind of daunting. Especially as a non-pro "just hobbyist". I'm willing to wait half a year longer if it means I can keep the compiler and specific knowledge I have.
Had I been in a pro environment, with deadlines and price considerations, I probably would have already switched to ARM by now.
-
readily available in single chip quantities
If that (ready availability) factors into any of your consideration for a chip (between ARM and 14K core chips), you would have to side with ARM: the whole point about the 14K chip is that they are *****not***** available now.
-
I'm willing to wait half a year longer if it means I can keep the compiler and specific knowledge I have.
That is a reasonable position to take.
My personal approach to migration is to replicate my peripheral library to a new platform. I would start with the bare minimum of setting up the chip and going into a loop; from there I write pieces that operate the gpio; then software delays; then timers; usarts, spi, adc, ...
It helps if there is a vendor library: you can build your library on top of that. And in the future, you can gradually swap out the vendor library calls with equivalent register operations to gain a little bit performance and reduce overhead.
With that approach, going from a new platform to another has been quite enjoyable and in the process, you build up a library from which you build your own application code.
-
Here is my general take on 32-bit chips vs. 8-bit chips:
1) switching to 32-bit chips makes sense for three kind of people: a) you want to make a living off the 32-bit boom - that market is literally exploding now with opportunities after opportunities; b) you want the performance - much faster chips and much richer peripherals; c) you just want to learn - enough said;
1) staying with 8-bit chips makes a lot of sense for two groups of people: a) you have a large code base in 8-bit chips -> moving would be exceedingly expensive; b) you don't need the 32-bit performance - do you really need a 144Mhz Cortex-M4 with FPU, FSMC, DMA, 24 timers, 8 usarts, 2 1MSPS adcs, etc. to blink an led?
8-bit chips are considerably inexpensive and simple to code; 32-bit chips are more complex - those that complexity can be managed fairly easily - and diverse so building up the economy of scale is more difficult there.
-
I loved Atmel AVRs back in the nineties, but come on, a decent 32bit controller is just so much less hassle.
With an Cortex M3 or Cortex M0+, you get 32bit multiplication (typically single cycle), 32bit division (M3) and usually also 32bit timers. E.g an LPC812 on the low end or LPC1768 on the high end is so much more capable than any comparable 8bit controller that the comparison is really futile.
Ok, if you need to count cents for a commercial product, an 8bit CPU might be still worth the trouble, but for a hobby project I don't really see why I should go back to struggling with limited ALU, peripherals and resources when I can have a modern microcontroller with full debugging capabilities, free development tools etc. for just a bit more.
-
Just one note to add regarding ARM Cortex M series compiler toolchains. I've been using the GCC ARM Embedded toolchain which can be found at https://launchpad.net/gcc-arm-embedded. This comes pre-built for Mac, Linux and Windows and is maintained as an open source project by ARM employees. So it seems like the most likely compiler to keep up with the latest ARM processors. I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite or Summon ARM toolchain. So far, I've had good luck with it, including using hardware floating point on some M4 processors.
-
I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite
2nd that. I use the same toolchain as you do and couldn't have been happier. Never understood why anyone would use Codesourcery, etc.
-
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 :)
The Chinese-language datasheet is "available", and most of the new and updated reference manual sections can be downloaded from Microchip's own Chinese-language site, so there's not many rumours left when it comes to the hardware. The only big remaining question is the launch date (and how buggy it'll be. Their track record doesn't look good on that front.)
Software-wise Microchip have been more tight-lipped and there's been no public indication of what their support is going to look like. For instance, with the MMU the chip could run a "full" OS like Linux, but will they provide more than the basic compiler and peripheral library?
-
I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite
2nd that. I use the same toolchain as you do and couldn't have been happier. Never understood why anyone would use Codesourcery, etc.
Perhaps Codesourcery is easier to find. Finding a precompiled GCC for linux is easy (apt-get install....) but binaries for Windows are more scarce. The first I found was Codesourcery so I used that.
-
Not perfect, but pretty usable, based on GCC toolchain, supports several ARM families and is free:
http://www.coocox.org/CooCox_CoIDE.htm (http://www.coocox.org/CooCox_CoIDE.htm)
-
I'm not sure why it doesn't seem to be as well known as some of the other toolchains like Codesourcery Lite or Summon ARM toolchain.
The CodeSourcery toolchain has been around for far longer, so it's more known and referenced in more guides and tutorials. They also do a lot of compiler work for other companies, so they also get around that way.
-
there are many alternatives.
I know nothing about arm processors and I'm just a hobbyist so please take this as a genuine questionremark.
If those specs are anywhere near true, then a quick cursory google search for that speed, that amount of ram, peripheral laden MCU, readily available in single chip quantities, etc etc, there appears to be slim pickin's
Personally I haven't found anything that I couldn't do on an M4F, that didn't otherwise really need a proper operating system to handle mass storage devices and internet comms. Once you get to the point you need Linux etc, I think you can't go past just getting a cheap off-the-shelf solution (e.g. beagle bone black, RPi), and not have to worry about dealing with DDR ram etc. Or possibly moving to a dedicated DSP if raw number crunching is in order.
There's a few eye catching specs on the website's I've seen. But, we're so spoilt for choice at the moment, the only thing that would make me give it a second look is when it's on Digikey/Farnell for the same price as some other option that will fill the need.
-
The thing is, I knew the mx32 core, tools and libraries very, very well and this is the main source of my excitement over the possibility of this new release.
However, I know arm is the way forward and to that end I've recently taken the plunge. What's holding me up is the plethora of choices and how boring it is to compare technical products that you know little about (remember I do this for fun).
With that in mind I've decided to just pick one manufacturer, one ide/compiler and get to know that. "Armed" with that knowledge I should then be able make better choices down the road
Know I'm faced with another decision... Is CMSIS worth learning? I've always been in favour of reading datasheets and hitting the regs directly but if the variation from device to device is as great as reported by some...
-
With that in mind I've decided to just pick one manufacturer, one ide/compiler and get to know that.
A good strategy - they are quite similiar, even between the 8-bit chips and the 32-bit chips. Once you have mastered one, the other is easy.
In the direction, I would recommend CoIDE + one of those STM32 chips it supports - it is really really good, particularly the wizard.
A close 2nd would be CCS + one of those launchpads. The TI chips are far more powerful than the ST chips, but a little bit on the buggy side so a little bit more frustration from time to time.
Know I'm faced with another decision... Is CMSIS worth learning?
CMSIS is just for the start-up and some (simple) house keeping options. I don't think compiler vendors now offer non-CMSIS start-up files anymore. It is for the most part transparent to the programmer.
A real choice is between direct register access and vendor libraries. If you are comfortable with reading the datasheet, try direct register access. Otherwise, you can use the library (which also requires reading the datasheet) and later on if you wish, you can swap out the library calls one at a time.
The TI chips have the (some of the) "library" ROM'd on the chip so that helps save a little bit of rom space.
-
Thanks for the tips Danny
-
In the direction, I would recommend CoIDE + one of those STM32 chips it supports - it is really really good, particularly the wizard.
I'll second this, CoIDE does make it very easy indeed to add files from the STM32 standard peripheral library to your project, and the on-line help isn't bad either.
-
I've mentioned it elsewhere, but also have a look at ChibiStudio (http://sourceforge.net/projects/chibios/files/ChibiStudio/). Mainly for STM32, and for use with the RTOS ChibiOS, but it is open source unlike CoIDE.
The ChibiOS community is very helpful.
-
I've used/been using PIC (not for 6 years) AVR, LPC21, LPC23, LPC17, LPC13 chips. And nowadays CC430, STR32F0 and STR32F4.. However, for 2 years I've been using Cortex M3 and M0's for most of the time. CC430 series for it's integrated wireless.. For different projects, different chips offer different peripherals and different prices.. I also help people on their migration to ARM processors..
What I see is, ARM chips have a lot to configure to do simple tasks. IDE's are garbage and frustrating for newcomers. CMSIS, is really ugly code to deal with.. All other Keil's library are garbage.. Even the IDE's are not just plug and play. If you download Code Red's IDE, you just can't get flash a led easyly.. ARM is a little difficult to grasp for people.. Just think of GPIO on AVR/PIC and in STR32F4 series.. Look at the number of pages you have to read to work on.. AHB clocks, Mode registers, SET/CLEAR registers, alternate function registers.. You have to do a lot of bit shift, and, or, not's.. It is really difficult for a starter.. And look at an AVR. Just a few easy to understand registers, and you're ready..
Another example is the timers.. LPC series have really bad designed 16/32 bit timers, however they are still powerfull and more complex than PICS and AVR's. STR32's??? They are really but really nice, loved them, but not for starters.. What about UARTS, SPI's, I2C's..
People just hate reading manuals, and big companies are good at creating junk.. :) The common problem across the new starters of LPC is the IAP pin.. You have to pull up the P2.10 in reset to let MCU run the user code.. This information is somewhere in the manual, not obvious to the one who just jumped in.. etc. etc.
To sum up, ARM is difficult for starters, there are a lot of walls the starter is going to hit until just run his first code.. However, if you get it going, you won't look back to 8 or 16 bits, unless they offer something different. For instance some PIC's have CLCs. If you need a few and's and OR's and CPLD's are a little big for your application, why not use 10F32 instead of descrete logic chips?
BTW, the worst chip and documentation I have ever had is MSP430 series. (I know it is not ARM) It's hardware is nice. Having DMA on a small chip is fantastic. The pleasure of being able to connect any pin to any peripheral cannot be described.. But API and documentation is really really bad. Even there isn't a naming consistency in the macros. What I see is big companies have the ability to create hardware but not software..
-
Someone said audio is slow for MCU's.. Not for 8 bit, event 16 bit though.. I've been designing an emergency system that user carries. Something like medallion.. It detects the movements of the person. In an event, it also enables the person to communicate with the base.. There are band pass filters and very simple ADPCM encoding/decoding. I used CC430 on pendant as it has wireless and 16 bit computing in a small package. I had to make encoding distrubuted across time to overcome induced large delay before transmit.. I mean CC430 encodes when it samples the audio. This way encoding is distributed over time.. When there is an incoming frame that request the audio back to base station, it just sends the encoded buffer.. However, in base station there is and ARM MCU, it takes microseconds to encode the whole same frame.. This makes coding a lot easier.. If I need to add some other filtering etc on CC430, there is nearly CPU time to do that..
Main problem with audio is multiplication, the worst problem is the division.. And you need both..
On second prototype I am using two chip solution on pendant: 4mm x 4mm ARM and CC1101.. This will also enable me using I2S audio chip, 16 bit at 32KHz sampling (after bandpass and some other filtering, it will be sampled to 8KHz) instead of 12 bit at 8KHz. I am guessing it will generate far better audio quality..
-
you just can't get flash a led easyly.
An operator issue?
-
An operator issue?
I mean you have to deal with a lot to just blink a led.. This is what "hello world" application of MCU is. Isn't it? :)
-
Just think of GPIO on AVR/PIC and in STR32F4 series.. Look at the number of pages you have to read to work on..
Yeah I know what you mean, when I got bit banding in my course I was laughing my ass off, using 1MB codespace so with writing directly one word you can toggle 1 bit. Then ofcourse with a memoryspace of 4GB you have some room to spare, but what a waste if you look at it from an 8 bit POV.
Anyway you can see it in the size and numbers of datasheet/familymanuals, with an 8 bitter you have the datasheet of the particul chip and a microcontroller family reference manual and some errata sheets, finished. With an ARM chip you have those (which are much bigger also) for the peripherals but then you go to the ARM website to look up the documentation of for instance the M3 Cortex core and you are flooded with MB's of documents. And then there are also errata sheets on different versions of this core and you have to find out which version is in your controller, anyway yeah a lot of work but when you take the effort and time to wrestle through it all sure is worth while.
-
you have to deal with a lot to just blink a led
Not really sure what you meant here. To blink an led, a few things are involved, regradless of which chips you are on:
1) start-up: for most 8-bit chips, it is fairly simple and transparent to the programmer; for most CMx chips, it is done by CMSIS and transparent to the programmer as well;
2) setting up the pins: for most 8-bit chips, you need to control the direction register; for most CMx chips, you need to enable the clock to the port and configure the pins; This can be easily packaged into a functional call similar to the 8-bit world;
3) flip a pin: roughly the same for the 8-bit/CMx chips;
4) delay: simply a software delay will do. identical for the 8-bit/CMx chips.
So not much more is involved - as a matter of fact, I can write a same blinky that will compile on a CMx chip and a 8-bit chip without a single change (aside from the chip header files).
-
Not really sure what you meant here. To blink an led, a few things are involved, regradless of which chips you are on
dannyf, I agree with you. however, for starters why the compiler adds "startupxxx.s" is a problem, to access a port it is easier to use CMSIS, however you have to add this to your workspace if you are using Code Red. uVision adds header automatically..
You know what registers to work on, however a newbie has to read all related stuff to blink a led. Talking on NXP, there is no organization in documentation that "for starters use LPC_GPIO0->FIODIR reg to set it direction as output, and LPC_GPIO0->FIOSET register to set, LPC_GPIO0->FIOCLR to clear"..
In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. :) You have to use LPC_GPIO0->FIOSET.. This is another headache.. :) While reading you delve into the lots of registers. In practice, you just needed the above.. But after filtering you may have this knowledge.. Just think how a starter sees the documentation..
Talking about the "same blinky", you can do single code, multiple platform I know.. I know because I did.. This code runs in any platform, ST, LPC, MSP430, ATMEGA as same:
#include <hal>
int main()
{
core.init();
Pin led(P1_0, OUTPUT); // depending on MCU, for ST PA_0 for intance
while (1)
{
led = !led;
wait(500);
}
}
only platform depended part is the enumaration P1_0, on ST it they name it PA, PB etc.. Look at include, you even don't need MCU header, library automaticaly chooses corresponding header..
this is two leds, two loops:
#include <hal.h>
Pin led1;
Pin led2;
Task<128> task1; // task with 128 byte stack
void handleLed1Task()
{
while (1)
{
led1 = !led1;
wait(250);
}
}
int main()
{
core.init();
led1.init(P1_0, OUTPUT);
led2.init(P1_1, OUTPUT);
task1.start(handleLed1Task);
while (1)
{
led2 = !led2;
wait(500);
}
}
Those two loops runs parallel in any mentioned platform.. Unless something like this, and install & just use IDE, I think it is hard for ARM to embrace the hobbiests..
-
The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..
-
Wouldn't a beginner just grab a code sample and go from there? Last time I checked NXP provided example projects, at least for their LPCXpresso devboards, that included a blinky program. From this you can easily modify the program to change the frequency / duty cycle, blink multiple LEDs, wait for a button, etc. All the complex stuff like GPIO setup is handled by the provided project, although eventually one has to figure out what those mysterious lines that you copy-pasted mean.
The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..
Some C++ features add overhead. Virtual methods add an extra layer of indirection to every method call, for example. Many embedded applications are sensitive to overhead, although I'll admit that a blinky program on an ARM Cortex is not one of those. Historically compiler support for C++ has also been weak for embedded targets. The free version of the Code Red IDE does not support C++.
-
Wouldn't a beginner just grab a code sample and go from there?
Sure, wise man does that.. But I don't think Nxp is the correct company that knows how to write documentation, teach their platform, even write usuable libraries.. Guys, it is not problem for an experienced developer. Think like novice..
Some C++ features add overhead
I think this is also historic and a little biased.. A virtual method call just adds a VMT lookup load.. But if you want to do the same with C, you usually use switch states, wise man use function pointers, which adds a lot more instructions.. I've been using C++ for over 3 years in my applications. My OS, Timers, UART and related protocols (such LINBUS), I2C, I2S, UI is handled by CPP code.. Even in time critical applications I've never came across a performance issue.. Additionally I think, most of the time, code re-useability is much more important than performance.. Development time cost is incomparable to high performance chip cost..
-
In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. :) You have to use LPC_GPIO0->FIOSET.. This is another headache..
I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.
BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?
-
Well you can always define your own macros...
-
Yeah I know what you mean, when I got bit banding in my course I was laughing my ass off, using 1MB codespace so with writing directly one word you can toggle 1 bit. Then ofcourse with a memoryspace of 4GB you have some room to spare, but what a waste if you look at it from an 8 bit POV.
It's an unusual feature (maybe added so 8051 programmers would feel more at home?) but it can sometimes be useful. In one application I had to control a bunch of LEDs, and using bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.
-
Wouldn't a beginner just grab a code sample and go from there? Last time I checked NXP provided example projects, at least for their LPCXpresso devboards, that included a blinky program. From this you can easily modify the program to change the frequency / duty cycle, blink multiple LEDs, wait for a button, etc. All the complex stuff like GPIO setup is handled by the provided project, although eventually one has to figure out what those mysterious lines that you copy-pasted mean.
The code above is not C, but CPP btw. I also don't understant why embedded community does not use C++.. Using virtual methods, templates it openned a lot of oportunities..
Some C++ features add overhead. Virtual methods add an extra layer of indirection to every method call, for example. Many embedded applications are sensitive to overhead, although I'll admit that a blinky program on an ARM Cortex is not one of those. Historically compiler support for C++ has also been weak for embedded targets. The free version of the Code Red IDE does not support C++.
Great discussion and all guys. Just one new tidbit here. The new code red ide LPCXpresso 6 had the restriction upped to 256kb and they now allow C++ support in the free version.
-
using bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.
Bit-banding is the opposite: by writing to a memory location (could be a byte / half-word / word, depending on the setup) you could change a bit.
What you are talking about is masked read / write: one write to a memory location could impact multiple bits if they are masked.
-
Arghh. I have to be missing something.
At a quick glance bit-banding seems as useful as an ashtray on a motorbike
It appears that for a bit to indicate anything the LSB has to be set in the value you are writing/modifying in the alias region. Wouldn't this mean storing data in bits 31..1, setting bit 0 a bit of ORing and shifting etc... If that is indeed the case, there's not much atomic about that process
-
Bit-banding is just a clever way to implement bit access without special opcodes or read/modify access. If you want to access the whole 32bit word, you access the real address, if you want to read/write only a bit, you access the alias address.
Also note that access to a single bit via bit-banding is atomic while a read/modify access isn't.
-
At a quick glance bit-banding seems as useful as an ashtray on a motorbike
It is for speed as well as atomicity.
-
At a quick glance bit-banding seems as useful as an ashtray on a motorbike
It is for speed as well as atomicity.
What the ashtray or bit-banding :)
seriously though, I'll have to so more reading it's SOP for my first impressions to be completely wrong
-
using bit-banding each could be represented by a single bit in memory without having to do a lot of masking and shifting.
Bit-banding is the opposite: by writing to a memory location (could be a byte / half-word / word, depending on the setup) you could change a bit.
That's exactly what I was talking about. Instead of having to shift and mask to set/clear or read single bits from words of memory, I used the bit-band alias to address them individually. This simplified the software a lot and didn't cost anything in terms of RAM use.
-
In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. :) You have to use LPC_GPIO0->FIOSET.. This is another headache..
I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.
BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?
You still talk like experienced developer.. I am sure you just grab a MCU, and start using it in a few hours.. Was the discussion about why ARM was a little tougher than 8 bit-ters?
I was talking about NXP's LPC17 series..
-
Actually the problem was not shifting. On ARM shifting is nearly free of charge.. :)
The major problem is load-modify-store architecture.. Which makes it at least 3 instructions, non atomic.. Think about an interrupt after after load instruction..
Another benefit is memory saving. You may use whole byte for 8 booleans. If you define macro or getter/setter methods it is easier than you think.
-
In documentation it says FIO0SET, however in CMSIS there is no FIO0SET definition. :) You have to use LPC_GPIO0->FIOSET.. This is another headache..
I am not sure which chips you are specifically talking but it is not unique to CMx chips that you need to read the compiler manual + header files in addition to the datasheet. Those structs are well documented in there. In my view, they are far better than the Luminary / TI / typical 8-bit approach of using discrete memory addresses for such names.
BTW, the CMx chips have fairly standard naming convention (of using FIOSET/DIR/CLR...). Where did NXP use the FIOxSET/DIR/CLR convention?
You still talk like experienced developer.. I am sure you just grab a MCU, and start using it in a few hours.. Was the discussion about why ARM was a little tougher than 8 bit-ters?
I was talking about NXP's LPC17 series..
No actually the discussion was originally about me possibly making the move to ARM or PIC32 (I do have some background on PIC 8 bit chips) because I am starting to get into interests revolving around audio and video processing with embedded chips. Somehow it got derailed a bit along the way with discussions about ARM chip setup and peripheral access...
-
On ARM shifting is nearly free of charge..
Twisting on ARM is another story, however.
:)
-
No actually the discussion was originally about me possibly making the move to ARM or PIC32 (I do have some background on PIC 8 bit chips) because I am starting to get into interests revolving around audio and video processing with embedded chips. Somehow it got derailed a bit along the way with discussions about ARM chip setup and peripheral access...
It got there to show that learning curve of ARM is a little flatter than learning an 8 bit MCU or PIC32.. Simple example is GPIO.. You have to read and read a lot to get started.. Same for other peripherals.. But as mentioned before, if you get used to, you don't want to go back..
Am I twisting? :)
-
Oh I do understand there is a lot of reading... There always is I find it hard to remember everything and I always have to go back for the odd ball stuff I do not use all the time. I do also understand once you get over the hump you never want to go back. Heck I had to force my PIC chips to do what I wanted to work through some output issues on PIC because turns out if you interrupt at the speed of a audio frequency the ports get out of sync.. I was using AVR for it to get around the issue till the new firmware for my programmer bricked 2 chips :S Yes literally killed the uC's while going into debugWire mode even HVP would not fix them.
Overall I think a move to ARM will increase my options for projects greatly even at the cost of simplicity. Audio Visualizers, maybe even a little game handheld, or even try my hand at building a Cortex M series mini computer and writing my own OS. All of which interests me. I love the nitty gritty low level aspects of development and love low level projects that teach the nuts and bolts of how computing works. Just a interest I always had. Only issue is my interests often force me to re invent the wheel so to speak.
-
learning curve of ARM is a little flatter than learning an 8 bit MCU or PIC32
You meant "steeper" I assume?
The complexity is initial and can be easily managed to a point where it is no more complex than it is on an 8-bit chip - we talked about that earlier.
-
Just one new tidbit here. The new code red ide LPCXpresso 6 had the restriction upped to 256kb and they now allow C++ support in the free version.
Nice! I just can't find anything on their website, is this a rumour or confirmed?
-
Nice! I just can't find anything on their website, is this a rumour or confirmed?
Confirmed (http://lpcware.com/content/faq/lpcxpresso/how-to-evaluate). You should have a look at LPCWare (http://lpcware.com/lpcxpresso/code-red) for the latest version of LPCXpresso 6 (6.0.4). Code Red Tech's old website is still up, which may create some confusion. They were bought out by NXP a while ago, which is why their website is no longer updated.
-
learning curve of ARM is a little flatter than learning an 8 bit MCU or PIC32
You meant "steeper" I assume?
The complexity is initial and can be easily managed to a point where it is no more complex than it is on an 8-bit chip - we talked about that earlier.
Interesting, I agree with you.. :) But with an addition.. :) At first a little flat, than a jump.. It is like a threshold.. You have to have patience until you stepped that threshold.. As far as I see, the drawback of ARM is this.. Because of this people scare and continue using their 8 bit MCU's..
-
If you're beginner probably is a good idea to pick a Microcontroller that is supported in Academia. There are lots of textbooks and online classes for the ARM Cortex based on some of the TI chips such as the TM4C123 to name one. The textbooks have a step by step approach that should be easy to follow given that you have the same hardware they use (Launchpads, etc).
http://users.ece.utexas.edu/~valvano/arm/outline3.htm (http://users.ece.utexas.edu/~valvano/arm/outline3.htm)
Look at the chips that have the most support, not only by the manufacturer but also by the amount of books written for them. There are lots of books for AVR, AVR (arduino), PIC, MSP430, ARM Cortex (mostly TI). Other chips might be more attractive depending on your needs and or feature set such as the Cypress Semiconductor PSoC family.
There are so many options, the sky is the limit but which option is going to take you from zero to blinking an LED? :)
-
Wow. Are books still a thing?
I would pick a microcontroller that has the most online support. I think that would be LPC/ST and to a lesser extent TI's Tiva. There's plenty of people here with experience in both LPC and ST Cortex chips that can answer questions.
-
Confirmed. You should have a look at LPCWare for the latest version of LPCXpresso 6 (6.0.4). Code Red Tech's old website is still up, which may create some confusion. They were bought out by NXP a while ago, which is why their website is no longer updated.
Ah ok thanks :-+ Always used Keil at work but now for home projects this might be the way to go. Keil doesn't have affordable licenses for hobbyists so I am gonna check this one out. The drawback is ofcourse NXP chips only or pay $999.-
-
Whilst complexity and learning curves are an issue they are compounded if you come from say an 8 bit pic background instead of say an avr background.
I made the jump from 8 bit pics (18F series) to the 32 bit pics and it was relatively easy. Same IDE, different compiler but managed through the same interface (same check boxes/radio buttons but producing different command line args), same style of datasheets, and a limited choice of resources. Whilst MIPS had their documentation about the core the most talked about core reference was "See MIPS run"
Now jumping to ARM we have different styles of data sheets from different manufacturers, a buttload of IDE's and compiler incarnations to choose from, every man and his dog has written ARM core references, umpteen libraries, more rtos's than you can poke a stick at and when you want to know something the simple task of locating that info requires multitudes of monitors each with a pdf in it... Having to much choice is not always a good thing
I imagine if you were on 8 bit avr's the jump to their 32bit arms would have been as simple as it was for me to jump to 32 bit mips but alas, I am where I am
-
Oh I do understand there is a lot of reading... There always is I find it hard to remember everything and I always have to go back for the odd ball stuff I do not use all the time. I do also understand once you get over the hump you never want to go back. Heck I had to force my PIC chips to do what I wanted to work through some output issues on PIC because turns out if you interrupt at the speed of a audio frequency the ports get out of sync.. I was using AVR for it to get around the issue till the new firmware for my programmer bricked 2 chips :S Yes literally killed the uC's while going into debugWire mode even HVP would not fix them.
Overall I think a move to ARM will increase my options for projects greatly even at the cost of simplicity. Audio Visualizers, maybe even a little game handheld, or even try my hand at building a Cortex M series mini computer and writing my own OS. All of which interests me. I love the nitty gritty low level aspects of development and love low level projects that teach the nuts and bolts of how computing works. Just a interest I always had. Only issue is my interests often force me to re invent the wheel so to speak.
Yes it will.. Also you can use I2S ADC/DAC/Amplifier chips, microphones.. If you want to compress/decompress you will have plenty of CPU time, even floating point processor that will be your friend on filters.. 16 bit is not good enough for filters.. You will need floating point..
Please someone, don't jump and say "you can do it on fixed point".. I know it can be done, but it is a lot easier with FP.. :)
-
Whilst complexity and learning curves are an issue they are compounded if you come from say an 8 bit pic background instead of say an avr background.
I made the jump from 8 bit pics (18F series) to the 32 bit pics and it was relatively easy. Same IDE, different compiler but managed through the same interface (same check boxes/radio buttons but producing different command line args), same style of datasheets, and a limited choice of resources. Whilst MIPS had their documentation about the core the most talked about core reference was "See MIPS run"
Now jumping to ARM we have different styles of data sheets from different manufacturers, a buttload of IDE's and compiler incarnations to choose from, every man and his dog has written ARM core references, umpteen libraries, more rtos's than you can poke a stick at and when you want to know something the simple task of locating that info requires multitudes of monitors each with a pdf in it... Having to much choice is not always a good thing
I imagine if you were on 8 bit avr's the jump to their 32bit arms would have been as simple as it was for me to jump to 32 bit mips but alas, I am where I am
Thank you.. This is what I've been trying to say.. :)
-
Another thing I'm finding a real PITA is these F*wits who insist on defining symbols in some ide dialog box rather than in the code what's that about I don't see people pushing proprietary project files into repositories.... and coide doesn't do assembly files wtf
-
I imagine if you were on 8 bit avr's the jump to their 32bit arms would have been as simple as it was for me to jump to 32 bit mips but alas, I am where I am
I have never used their ARMs, but I tried exactly this a few years ago with their AVR32. And no, the experience wasn't at all like going from a PIC to PIC32. Their AVR software framework (at least at that time) was a steaming quagmire of dog turd, and their examples were even worse. It was the first experience I had with manufacturers example code that contained as many #ifdef statements as useful lines of code, and I can only presume purposefully obscured details deep within several layers of file hierarchy.
The next 32-bit chip I picked up was the PIC32, and I found it really nice. A totally different experience.
-
and coide doesn't do assembly files wtf
You may have already tried this, but IIRC it requires them to have a .S suffix - capital S, not lowercase. It's an Eclipse thing, apparently.
-
You may have already tried this, but IIRC it requires them to have a .S suffix - capital S, not lowercase. It's an Eclipse thing, apparently.
When using the GNU toolchain, there's also the detail that .S files will be passed through the C preprocessor, but .s files will not.
-
As with the 8 bit and 16 bit pics, with Microchip you know that the PIC32 or something better will still be there with the same pin-out in 10 years time. This is probably more important to me than having the latest and greatest core or an extra MB of flash as it means that if I need to support or upgrade my customer project for however long I can generally pop in a compatible chip that compiles the same source.
Microchip make a few mistakes like everyone, but they are pretty good at owning up to and eventually fixing them, they keep there prices competitive, and in 1 off quantities, support DIP parts, generally have the popular stuff for delivery from stock next day, and the IDE while not perfect is still amongst the best and supports the whole product range for free. The optimisations that are turned off in the free version generally affect the code size not performance and then not by much, above all it still compiles and flashes a 32K pic32 C program in under 7 seconds on my Core i5 laptop (984 lines, just timed it!)
This is not to say the choice of ARM is not a good one, ARM chips are generally slightly cheaper and have better performance, RAM and Flash options, but the amount of one-upmanship going on in the ARM market and different chips out there every other day is quite staggering to the point of confusion, also I'm not sure if there really is room for half a dozen ARM chip manufacturers, and with my luck I would pick the wrong one!
if your on this roller-coaster, then stick with it and enjoy the ride, but I prefer a more sedate ride and in times like this I am really glad I work for myself and don't have some trendy manager choosing which chip I use.
-
As with the 8 bit and 16 bit pics, with Microchip you know that the PIC32 or something better will still be there with the same pin-out in 10 years time. This is probably more important to me than having the latest and greatest core or an extra MB of flash as it means that if I need to support or upgrade my customer project for however long I can generally pop in a compatible chip that compiles the same source.
Just because that has been historically true for the 8-bit PICs does not mean the same will be the case for the PIC32. I would expect them to develop at a faster pace to keep up with the competition. I certainly wouldn't count on being able to buy a DIP PIC32 in ten years time unless Microchip guarantees availability.
-
and coide doesn't do assembly files wtf
You may have already tried this, but IIRC it requires them to have a .S suffix - capital S, not lowercase. It's an Eclipse thing, apparently.
Its a gcc feature which has nothing to do with Eclipse.
-
As with the 8 bit and 16 bit pics, with Microchip you know that the PIC32 or something better will still be there with the same pin-out in 10 years time. This is probably more important to me than having the latest and greatest core or an extra MB of flash as it means that if I need to support or upgrade my customer project for however long I can generally pop in a compatible chip that compiles the same source.
You can never ever make that assumption cause you will get burned sometime. If you promise a customer support up to X years, better make sure you logistically back that support up with stockpiling spare parts/boards OR update/replace your design as time passes. I am unaware of the number of products you have to warrant which is ofcourse very important to this discussion but the point is you can never trust/depend on a supplier, all you know they go bankrupt next year and then what?
-
You can never ever make that assumption cause you will get burned sometime. If you promise a customer support up to X years, better make sure you logistically back that support up with stockpiling spare parts/boards OR update/replace your design as time passes. I am unaware of the number of products you have to warrant which is ofcourse very important to this discussion but the point is you can never trust/depend on a supplier, all you know they go bankrupt next year and then what?
Trust in Allah, but tie up your camel just in case. :-+ - Point Taken.
-
discussion but the point is you can never trust/depend on a supplier, all you know they go bankrupt next year and then what?
But you can trust some more than others. Microchip have a reputation for continued availability of parts, I can still buy the PIC I designed into something 23 years ago. I also have personal experience of redesigns due to ST, NXP, and Atmel making parts obsolete.
-
What kind of industry requires some product to be continued for 10 years? Military? I am sure not consumer.. Nowadays, MCU's, the sensors, analog stuff etc does not have shelve life more than a few years.. You don't look back, continue and continue.. You always have to evolve..
-
What kind of industry requires some product to be continued for 10 years? Military? I am sure not consumer.. Nowadays, MCU's, the sensors, analog stuff etc does not have shelve life more than a few years.. You don't look back, continue and continue.. You always have to evolve..
Industrial. Think of a production line for example. They have to work for tens of years, and you need to have replacement parts, because it generates thousands of dollars every hour, downtime is not an option.
Medical, same reason, it has to work, and it has to be repeatable.
Niche products with expensive approval regulations.
And a dozen more.
-
Of course not for consumer electronics.
But most decent industrial and automotive applications need that timeframe to deliver the actual product and spare parts.
You don't want to redesign your product every two or three years just because a new hip CPU is thrown out.
But on the other side, all of the reputable brands (NXP, ST, Freescale, Atmel, Infineon, ...) guarantee at least 10 years of delivery after initial release for the actual Arm Controllers.
-
Military?
Think more like 20-30yrs. However, the last 15 yrs of that will probably scrambling around finding old pieces of equipment to extract parts from.
-
I understand your concern. However, the technology gets faster and faster. I would aggree to the last bit if it was 10 years ago.. Today, even medical equipment goes into trash bin in less than 10 years.. New technologies emerge, doctors calculate buying new one's benefit (in money of course, not patient care), and they force hospital to buy new things.. I hate medical being business btw, however it is..
Today, you always have to invent. You can't just produce same board for 10 years and make money.. Or can we? For industry, just keep in mind what you designed, and make new designs as compatible as possible to the past.. Give more time on designing for future compatibilty.. Isn't that wiser?