# If one has used PIC uC, how different is it to migrate to using a different uC like say Arduino or ARM?

There seem to be quite many vendors making uC and some uC are more popular than others say for example Arduino and PIC because of their low cost and abundant features and ARM because of its high performance. What I wish to know is, how different is it to move to ARM uC after one has used a PIC and has understood its peripherals and the language/compiler (C++ with CCS C Compiler for example).

Do ARM, Arduino or other uC from TI and other perhaps less known names have big difference in what they can do compared with a PIC?

Let me make the question more simple. Suppose I have done a project using PIC that makes use of its timer, ADC, comparator, SPI and I2C peripherals. Now suppose that I wish to move to a new microcontroller altogether, lets say ARM or Arduino. I understand that the toolset (IDE) used with these other microcontrollers to compile code shall be different, but in what are the things one shall have to learn before being able to migrate such a project to other microcontrollers? I am not sure if ARM and Arduino microcontrollers have such peripherals or if they have more peripherals not found in PIC. I read somewhere that ARM has some graphics engine as well, it sure looked like a wierd block diagram of the processor.

I suspect that one shall have to learn a new plethora of functions and method to write ISR e.t.c, but I am not sure of the full list which I think is not very long.

• It is unfair to compare a microcontroller like PIC or ARM to Arduino. Arduino is an entire ecosystem including hardware, software (libraries) and an IDE. It would be better to compare it with AVR, the bare microcontroller that is used on Arduino. Also you have to compare with the ARM microcontroller, not the ARM SoC (system on chip). The SoC indeed implements things like a GPU, in fact it is an entire computer often running Linux. – jippie Oct 9 '13 at 10:53
• I found moving from PIC to ARM a little unsettling at first, because I was intimately familiar with PIC architecture and naming convention. Once I immersed myself in ARM, I found it really quite comparable, and I am now very comfortable with both. The difference becomes transparent very quickly, IMHO. – Bob Oct 9 '13 at 12:30

All microcontrollers can be programmed in a C-like language, all of them have the same basic peripheral types and comparable cores as far as features go. When you stay within the realm of real-time MCUs, they are pretty easy to jump between.

Probably the biggest differences are simply in the idiosyncracies of the tools. If you are accustomed to the ease of having preprogrammed bootloaders in your AVRs (down to pre-programmed USB bootloaders in the -U parts), you may have some trouble with having to buy a compatible JTAG programmer for certain ARM chips. If you're accustomed to the rich debugging features of JTAG-enabled chips, it may be a bit of a culture shock to go back to in-bound debugging in low-end PICs and AVRs. But that's something you get used to after using a toolchain for a while. Also, with some chips there is quite a significant cost associated with using their tools, e.g. Freescale and Renesas.

Don't be afraid to choose a different chip once in a while and learn to work with it. It will broaden your view and enable you to use more optimal MCUs in the future

Addendum: this doesn't really apply when you go to non-realtime processors like the ARM A-series, x86 and Cell. These are very difficult to program for on a low level, tools are expensive and the chips are hard to get and implement.

• What does non-realtime processor mean here? I do know about hard-real time soft-real time and non-realtime OS but not processors. – quantum231 Oct 9 '13 at 9:13
• It's a processor that is used exclusively with a non-realtime OS. Real-time processors by contrast are often used without an operating system entirely, or possibly with a very bare-metal realtime OS. – user36129 Oct 9 '13 at 9:14

First to clean up a few terms.

Arduino is a line of development boards mostly centered around a Atmel AVR microcontroller (Typically the ATMega328). It does not produce the microcontroller. Consider Arduino is like Dell, they take various parts and produce a full product. Comparable PIC development boards are the Parallax Basic Stamps, and even PICAxe (PIC chips with a proprietary basic emulator)

ARM is a type of architecture, not a specific line of microcontrollers. It is like x86 processors. And ARM based microcontrollers are usually 32-bit or higher, and can barely be called a microcontroller, any more than a x86 based ic would be. With ARM, you are getting into microprocessors, SBCs and full blown computing.

Multiple companies produce ARM chips, including Atmel, TI, NXP (Phillips), Freescale (Motorola), Broadcom, AMD, Samsung, etc.

Microchip does not have ARM based chips, but they have PIC32s (MIPS based), which technically compete against ARM, but not really. Its hard to ever find a consumer product with one inside.

When you say you are used to PICs, most people will assume you mean PIC16/18 and smaller. Comparable (and consumer/hobbyist known) popular chips to PICs would be TI's various MSP430 lines, Atmel's ATtiny/ATMega lines, and Intel 8051 compatible mcus.

As an analogy, All of those are toy cars compared to ARM's full sized sports cars.

• (small addendum) PIC32 is based on the MIPS core from the MIPS company, which is technically what you could call a competitor to ARM. – user36129 Oct 9 '13 at 9:16
• There are ARM chips that are definitely microcontrollers. Take the low-end an LPC1114: 4k RAM, 32k Flash, no external address/data bus. – Wouter van Ooijen Oct 9 '13 at 17:08

Most of the differences between the PIC and the ARM represent nuisances that the ARM does away with, but there are a few exceptions.

On the 18xx PICs, one may safely read and write LATxx and TRISxx bits in main-line code and also write other bits of the same port in an interrupt. On ARM processors that is generally not safe. An statement like: LATC |= 2; would translate as a single instruction.A typical ARM's direct equivalent PTC->PODR |= 2; would become an instruction sequence equivalent to uint32_t temp = PTC->PDOR; temp |= 2; PTC->PDOR = temp;. If an interrupt which occurs between the first and third statement of that sequence modifies the PORTC output register, such modification will be undone by the third instruction of the sequence above.

To mitigate this problem, most ARM variants have special "port bit set" and "port bit clear" addresses. For example, one could use PTC->PSOR=2; to force one bit of PORTC high without affecting anything else, or PTC->PCOR=2;` to force one bit low. This approach will be safe even if an interrupt routine tries to write some other bit on the port. Unfortunately, while most parts provide such logic for the main data output register, they are inconsistent in their support for setting or clearing individual bits of other I/O registers.

Another detail to watch out for is sleeping. Sleep mode on the PIC is pretty straightforward; while the ARM core supports a sleep mode in standard fashion among all ARM parts, most vendors offer additional modes that offer substantial additional current savings, but they don't all do so the same way. Further, while the PIC can generally be awoken using any of its asynchronous interrupt inputs, many ARM devices seem to use separate hardware for handling interrupts than for wakeup from low-power sleep modes. Expect sleep mode to be much more difficult with the ARM than with the PIC.