How are micros programmed in real world situations?

[VEGETA]

Extremely low cost: PICs are hard to beat on price. The really cheap ones are a bugger to work with though, and the MPLAB software is a bit naff. If you go this route try to stick to the PIC24 and PIC32 lines if possible, as they are much easier and nicer than the crappy old PIC12, PIC16 and PIC18 ranges.

So working with PIC24 and PIC32 is easier than just PIC16? Can you explain this a bit please. I worked with some PIC16 stuff, didn't try others yet. But I am interested to learn about 18,24, and 32. How about dsPIC33?

__________

I have tried PICs and found them nice with PICKit3. I am interested in Cypress PSOC and Renesas. I haven't tried working with an ARM-based MCU, and I wonder If I can work easily with them just like using MPLab with the datasheet of the MCU... or is there more effort to be done?

I read a lot about renesas and their great MCUs, what do you think? They have CISC and RISC ones, but since I am gonna be using C all the time, what is the difference here?


thanks!

[dom0]

More powerful chips often come with some sort of low level standard library to avoid manually programming the hundreds to thousands of registers.

Thanks for the reply guys, that makes sense. What are the most common micros in real life projects? Microchip or Atmel? or maybe both?

8051 derivatives are extremely common. ARM chips, too. AVR and PIC not so much, but are seen, sometimes.

[dannyf]

So working with PIC24 and PIC32 is easier than just PIC16?

I use a lot of PIC24 (no PIC32 at all). Comparing to PIC12/16/18 chips, the 24s have more capable peripherals, bigger memories and generally faster. But three things stand out for the 24 vs. 12/16/18:

1) vectored interrupt controller: the co-mingled 1/2 interrupt vectors on the 12/16/18 are hard for modular programming;
2) remappable pins: the best on any chips I have seen. With some exceptions, you can pretty much re-route any peripheral functions to any pin. Fabulous.
3) consistent peripherals: many of the peripherals on in the 24 family are identical or highly alike so once you have written for one, you have pretty much written for them all - code is highly portable.

They are my favorite chips.

[hans]

The PIC16 and PIC18 share the same XC8 compiler, which is the HiTech compiler under the hood. It's a completely propriatary tool chain, which in itself is OK, albeit that it lacks some very basic functionality and support (like C99). Sometimes you get an error like: "cannot generate code for this expression", or the compiler will not optimize an all constant expression built from a few parameters; but instead generate software LUTs and execute the expression in runtime.

More over, the way the 8-bit PIC cores work are a pain. The hardware stack can be really limiting, both in terms of call depth and what you code can and can't do. Call the same function from inside an interrupt and in your main program? In worst cases the compiler will have to compile that function twice, because it has no fast way to "push a variable onto the stack". Stack variables are statically allocated, and the compiler does some call analysis to build a call tree and re-use RAM locations where it can. However, it assumes an interrupt can fire at any moment, and so it cannot make this assumption. Thereby it sometimes needs to create 2 separate functions which both use the variables on different RAM locations. The HiTech compiler is very specifically tailored to the PIC16/18 platform, and does the best job it can for the platform, but can't do magic and make the limitations disappear with no cost.

Having a vectored interrupt controller would make this issue even worse, especially when interrupts can be nested (which is what you want if dealing with vectored isr's & priorities). In that case the compiler would have to re-compile code for each ISR and statically allocate the stack variables for it.
Dealing with pointers is also quite slow, because there really isn't a native way to work with pointers in the instruction set. It is done with extra core registers that allow indirect RAM access. This in turn means that most pointer access on PIC16/18 will easily generate 3+ instructions worth of code, where on practically any other core (MSP430, PIC24, AVR, ARM, MIPS, etc.) this can be done in a single instruction.

So a big proportion of applications will run on a PIC16 or PIC18, but not at very fast speeds. This can be fine if all you do is read an I2C sensor and switch a relay on a threshold. But as soon you're dealing with complex protocols (the "connected world") that needs packets, data buffers, pointers, etc, code can run rather slowly. In this case I would quickly go to a PIC24 or ARM chip, because I don't have to fear these performance limitations that quickly.

[nctnico]

ARMs are a bit harder to work with than 8 and 16 bit micros

Please stop with this nonsense. Getting an ARM going is just as hard as getting an 8 bit microcontroller going.

[Howardlong]

Regarding PICs, it largely depends on the job at hand which one you go for. It is absolutely true that the PIC10/12/16/18 series suffer due to their architecture, but sometimes that's all that's needed. I wrote a real time battery powered satellite tracker for a PIC18 about a decade ago... just as smartphones were about to hit the scene and rendered many vertical hardware applications like this largely irrelevant! (http://www.g6lvb.com/articles/LVBTracker2) Trying to shoehorn floating point orbital mechanics iterative numerical methods into a PIC18 was fun both in terms of compiler limitations and speed. The compiler I used did not automatically manage the bank allocation of statics, I had to do the allocation manually.

The PIC24/dsPIC series introduced around 2006 were a serious step up. I remember getting some engineering sample parts back then, it was a pretty amazing device with a proper stack and decent addressing modes without the need to be continually using bank switching (there is still bank switching in the PIC24/dsPIC devices but it's used far less than in the PIC10/12/16/18 series where all but the most simple task will need bank switching). Much of the basis for the PIC24/dsPIC core is based on the PIC16 at a very fundamental level, but the wider busses make life a lot easier. Also the PIC24/dsPIC benefit from a two phase rather than a four phase clock speeds things up.

The PIC32MX was introduced about 2009, and this was a departure from the proprietary core, using MIPS. This introduced some additional complexity regarding cache and clocking. With the PIC32MX1xx/2xx series, these cache related issues can be ignored, as in these devices the flash runs at the full core rate: these make a very good start for PIC32. The PIC32MZ announced in 2013 is still in a state of flux: it was announced and released far too early, and not only has the silicon been full of bugs, Microchip decided to completely change the programming paradigm around with the introduction of a new programming framework, namely Harmony, another "work in progress" making backward compatibility impossible: as a result everything for the PIC32MZ will need to be a re-write. Whether Microchip ever manage to gain much traction in the mid range 32 bit space as a result remains to be seen, but I am sceptical following these two unmitigated disasters, with many previous PIC32 aficionados having jumped ship following these latest debacles.

The good thing about PICs is that they have roughly similar peripherals, so there are few surprises as you go up through the families. yes, there are differences even between PICs in the same family, but they are usually manageable and generally maintain backwards compatibility.

The benefit of starting with a simple device like a PIC16 is that you are inevitably constrained by what you need to learn. Almost everything's in a single datasheet. When you move to the PIC24/PIC32, they have split everything up and you have no choice but to continually cross reference a dozen or so documents.

[andersm]

I read a lot about renesas and their great MCUs, what do you think? They have CISC and RISC ones, but since I am gonna be using C all the time, what is the difference here?

Renesas have basically pared down their portfolio to three lines: RL78 is their 8-bit MCU targeted at the low-end, distantly related to the Z80. RX is a 32-bit CISC MCU, covering basically the same markets as the Cortex-M3/4/7. Lastly there's the RZ series of ARM Cortex-A applications processors (there's also V850 for automotive). Development of the other lines has more or less stopped, and should probably be avoided for new applications.

RISC (or rather load-store architectures) produce slightly larger code, otherwise the difference is pretty much irrelevant.

[zapta]

ARMs are a bit harder to work with than 8 and 16 bit micros

Please stop with this nonsense. Getting an ARM going is just as hard as getting an 8 bit microcontroller going.

I switched recently from to an ARM M0 (NXP LPC11U35) and it's actually easier to use than the ATMEGA328p I used before.

Uniform memory space (no distinction between flash strings and ram strings), orthogonal memory mapped I/O  (easy to manipulate with simple indexing), better free IDE (eclipse/lpcxpresso, single package IDE/tool-chain install and support all three platforms), doesn't require additional hardware or software to program (just drag and drop the binary file to the USB/ISP virtual disk),  compatible with optional $25 hardware debugger, small footprint (5x5mm), runs at 48Mhz, and requires very few extra parts. Life is good.

https://github.com/zapta/arm/blob/master/pro-mini/board/arm-pro-mini-schematic.pdf

[VEGETA]

I read a lot about renesas and their great MCUs, what do you think? They have CISC and RISC ones, but since I am gonna be using C all the time, what is the difference here?

Renesas have basically pared down their portfolio to three lines: RL78 is their 8-bit MCU targeted at the low-end, distantly related to the Z80. RX is a 32-bit CISC MCU, covering basically the same markets as the Cortex-M3/4/7. Lastly there's the RZ series of ARM Cortex-A applications processors (there's also V850 for automotive). Development of the other lines has more or less stopped, and should probably be avoided for new applications.

RISC (or rather load-store architectures) produce slightly larger code, otherwise the difference is pretty much irrelevant.

So CISC and RISC will not have a difference if working with C except the resulting code size?

V850 for automotive... now what makes it for automotive? what features? there is also SuperH.

I've seen some great kits in their websites such as starter kit and display it one... but the price seems big. what is the kit to use for RZ ones and what price? I'd like a low price one if possible.  and i figure the IDE is the one based on Eclipse.

[andersm]

So CISC and RISC will not have a difference if working with C except the resulting code size?

Not really, no.

V850 for automotive... now what makes it for automotive? what features? there is also SuperH.

I misremembered, it's the RH850 series that's marketed exclusively for automotive. SuperH is another dead-end architecture. A good sign is looking at tool support. E2 Studio (their newest, Eclipse-based IDE) supports RL78, RX, RZ, SH-2/2A (and apparently you can debug RH850 code with it). The rest are supported only in HEW (old, last updated in 2012) and CubeSuite (not marketed outside Asia).

Another example is the GNU toolchains provided by KPIT (I believe under contract by Renesas). Only the RL78, RX, RZ and V850 toolchains are marked as active, the rest are considered legacy.

what is the kit to use for RZ ones and what price? I'd like a low price one if possible.  and i figure the IDE is the one based on Eclipse.

No idea. This one seems cheap.

[VEGETA]

Seems that RZ\A1 is the most popular and good. E2 studio works well with it too... but I need an official dev kit. Starter kits are pricey! one of them is 1.1k! The HMI one is great o_O

Hmmm working with the bare chip is another option but not good for starters. Especially that their programmers are also VERY pricey! not like PICKit3 or something. Very hard choice just to learn the thing.

[andersm]

but I need an official dev kit.

Why?

Hmmm working with the bare chip is another option but not good for starters. Especially that their programmers are also VERY pricey! not like PICKit3 or something. Very hard choice just to learn the thing.

The RZ/A are not suitable for beginners. Download the 3100+ page hardware manual and consider really carefully if you want to "just learn the thing." It's an applications processor mainly intended for running Linux or some other "real" operating system. As for debuggers, as an ARM CPU it supports the standard ARM debug interface. If you really want to use E2 Studio, I'm fairly sure it supports Segger's J-Link for debugging RZ/As, but if you're going to be writing Linux applications you'll be debugging using gdb over Ethernet anyway.

I found an Arduino-like board that's supported in the mbed environment, but it looks like it's not for sale yet. It seems there's also several boards from Japanese manufacturers if you search around a bit.

[VEGETA]

Well, no.. I am not interested in linux. I read that it supports RTOS (like FreeRTOS). So, is it that much different than just programming via C, just like PIC? I don't know how to use RTOS yet.

I don't know what project will I do with it yet, I just want to check it out and learn it. The other thing is that it is an ARM based MCU, which I have never used before. Their HMI stuff are great too. In general, I feel their MCU are a higher quality than most others.

I've used PIC16 with MPLab X and PICKit3. I want to try ARM-based 32-bit MCUs and found that Renesas is the best. I don't know why you are making it extremely hard to learn as I read many stuff online and in this forum saying that using ARM is not that much hard at all (not implying that it is extremely easy too).

Looking at their prices, it looks like they don't care about low-end customers like makers or hobbyists unlike PIC or ATMEL, which is bad for me xD.

[andersm]

Well, no.. I am not interested in linux. I read that it supports RTOS (like FreeRTOS). So, is it that much different than just programming via C, just like PIC? I don't know how to use RTOS yet.

FreeRTOS provides tasks and synchronization services. It does not provide eg. hardware device drivers. The RZ demo included in the FreeRTOS distribution is for IAR's compiler, btw.

I want to try ARM-based 32-bit MCUs and found that Renesas is the best. I don't know why you are making it extremely hard to learn as I read many stuff online and in this forum saying that using ARM is not that much hard at all (not implying that it is extremely easy too).

Best by what criteria? This is not a microcontroller. It is a completely different beast from the Cortex-Ms usually discussed on this board, and far more complex. If you want an ARM microcontroller board, get an ST Discovery board or something similar.

[VEGETA]

Can you explain why it is that much more complex than other MCUs? What do I need to learn it btw? Rx is easier?

I have some free time to learn it if it needs a long learning curve. at least for 7 months or so.

[nctnico]

I wouldn't use the RZ/A series without Linux. There is just no point. Also 400MHz is quite low. I'm also not sure how well these devices are supported. If this is for a project with a potential of selling less than 5000 units I'd stick with either TI or Freescale. What counts with these kind of complex processors is good support. Either through a community or paid.

[Howardlong]

I am open to correction, but I don't think Renesas are very receptive to much other than 100ku+ projects. I believe they're still the biggest MCU producer globally.

They have a massive presence, just not in low to medium volume. They're a Japanese company, and yet if you go into the few remaining true electronics stores in Akihabara (still well worth a visit, and distinctly teaming with geeks of all ages none the less!) there's not much in the way of Renesas, I can't remember seeing any in fact, it's all PIC, TI, NXP, Atmel/Arduino. That probably tells you all you need to know.

[ajb]

ARMs are a bit harder to work with than 8 and 16 bit micros

Please stop with this nonsense. Getting an ARM going is just as hard as getting an 8 bit microcontroller going.

If you already sorta know what you're doing, then sure, an ARM isn't any harder than a typical 8-bit micro.  However it IS typically more complicated, and if you're just starting out with embedded devices or programming in general, then the increased complexity of the peripherals, having to deal with clock distribution, power management, and memory timings can present a much steeper barrier to entry.  Couple that with often poorly documented libraries and a relative lack of example code as compared to the popular 8-bit systems, and ARMs on the whole aren't nearly as beginner-friendly.  That will change as more people start using ARMs and releasing example code and beginner guides and such, but for the time being AVRs and PICs are still a good place for beginners to start out.

[nctnico]

So you think an 8 or 16 bit microcontroller doesn't have clock distribution? Even on an 8 bit PIC you need to set the right options during programming for the oscillator to work.

Thinking an ARM controller is more complicated than an 8 bit controller is utter nonsense. Getting an ARM going takes just as much time & learning as getting a PIC going for the first time.

[Howardlong]

For me, the biggest problem in getting up and going with ARM was knowing where to start. There are a whole bunch of marketing hurdles to master before you can even order something. The difference is that you have to understand both ARM marketing and the chip maker's marketing in order to make a reasonable comparative decision.

In the end whether it's ARM or not doesn't make a great deal of difference when developing. There's not really anything particularly special about it when compared with, say, MIPS based platforms.

I would say though that diving in to a complex M4 based device will be a baptism of fire. The clocking regimes are often very complex.

PICs have their own frustrations, even at the bottom end 8 bit devices. Some design decisions such as defaulting to analogue pins on GPIOs I still don't understand, but it becomes a natural reaction to switch them to GPIO as one of the first thing you do. For a beginner this kind of thing is just another barrier. Spending an hour or two just getting the core clock going at the right frequency with a mixture of fuse and functional programming is not unheard of.

PICs do have a simulator integrated into the IDE, so you can do stuff without hardware. Personally speaking, except for the most basic of scenarios, simulators are of pretty limited use, but I guess you can try out for free.

For any platform, though, you'd hope that doing a blinky should be a reasonably painless affair. Once you've got that toolchain working that is...

[Psi]

So you think an 8 or 16 bit microcontroller doesn't have clock distribution? Even on an 8 bit PIC you need to set the right options during programming for the oscillator to work.

Thinking an ARM controller is more complicated than an 8 bit controller is utter nonsense. Getting an ARM going takes just as much time & learning as getting a PIC going for the first time.

Its more complicated in that there are lots more registers you need to set before things work.
In a empty AVR project you can write one line to set a pin to output and another to set it high. Compile and it works
RC clock is active and everything is on

Try doing that on a stm32
You get nothing because you didn't set up the system clock
Then you get nothing because you didn't set the peripheral clock divider
Then you get nothing because you have not enabled the clock for the port your talking too

Need I go on

[andersm]

With no extra configuration, the STM32 will run off its internal 8MHz RC oscillator. You might need an extra line of code to configure the port directions, but that's it.

Also, "8-bit vs 32-bit" is a false dichotomy. The clock distribution diagram of eg. Atmel Xmegas look as complicated as any 32-bit MCU.

[nctnico]

So you think an 8 or 16 bit microcontroller doesn't have clock distribution? Even on an 8 bit PIC you need to set the right options during programming for the oscillator to work.

Thinking an ARM controller is more complicated than an 8 bit controller is utter nonsense. Getting an ARM going takes just as much time & learning as getting a PIC going for the first time.

Its more complicated in that there are lots more registers you need to set before things work.
In a empty AVR project you can write one line to set a pin to output and another to set it high. Compile and it works
RC clock is active and everything is on

The same goes for the ARM Cortex devices. The ones from NXP have an RC clock running by default so even without any clock setup you have a running core. I doubt it will be very different on other ARM Cortex MCUs.

[mikerj]

The same goes for the ARM Cortex devices. The ones from NXP have an RC clock running by default so even without any clock setup you have a running core. I doubt it will be very different on other ARM Cortex MCUs.

Yes the core runs as soon as you power it up, but few if any of the peripherals will.  On a PIC or AVR you can configure a pin for output and start using it as soon as the core is running, on a Cortex device you have to enable the clock to the peripheral before you can even start configuring it.  That clock will also have various dividers that may need to be adjusted for your application. 

They are undeniably more complex devices to use than the older 8 bit micros, and many more traps to fall into.

[nctnico]

On NXP's ARM devices the common peripherals are already on & clocked at startup. On some devices all peripherals which don't need special clocking (like USB or ethernet) are enabled. In NXP's user manuals the description of each peripheral starts with links to the registers which control clock and power for that particular peripheral. How can that be difficult?