Another look into ARM

[blewisjr]

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.

[dannyf]

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.

[Kjelt]

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?

[ElectroIrradiator]

Nice! I just can't find anything on their website, is this a rumour or confirmed?

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.

[denizcan]

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..

[casinada]

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
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? 

[TheDirty]

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.

[Kjelt]

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.-

[AlfBaz]

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

[denizcan]

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..

[denizcan]

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..

[AlfBaz]

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

[Harvs]

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.

[AndyC_772]

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.

[andersm]

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.

[boz]

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.

[alm]

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.

[nctnico]

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.

[Kjelt]

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?

[boz]

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.

[Rufus]

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.

[denizcan]

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..

[tszaboo]

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.

[enz]

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.

[Harvs]

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.