Arduino User looking to move to PIC

[charliehorse55]

I have used an atmel arduino as my microcontroller of choice for a few years now and I am looking to move to using PIC micros. For my first project I am trying to make a bridge between DMX512 and three PWM signals. I want three PWM channels with at least 12 bits of resolution at 200 Hz (I know it might not exactly be 200 Hz because of prescaler values). Which PIC should I use for this? There are so many to choose from.

I will be developing on OSX and linux, is there an IDE to use or will I just be stuck with a command line compiler/debugger?

Can you program a PIC in C? Everyone seems to talk assembler for PIC.

[mariush]

I'm using MPLAB-X on Windows : http://www.microchip.com/pagehandler/en-us/family/mplabx/

As it's based on netbeans ide code, it runs on Linux and Mac.. in fact you can select the distro from the download page (left corner).

It can work with several compilers, they can be added like plugins... and I'm using Hi-Tech C compiler.  So I guess that answers your question about programming in C.

They have some new batch of compilers called XC ... not sure what they are  as i didn't test them yet, but I suspect it's just a rebranding of the hi-tech c compiler with maybe some different compiler for what hi-tech didn't support.

Not sure what micro to recommend for 3 pwm signals, so far I had no use for so many. Maybe others can chip in.

[xquercus]

I'm not familiar with your specific application though the microchip web site has a product selection tool.  That might help you narrow things down.  The only PWM I've done has been in software.  At most, I've used a timer to generate an interrupt.  If the 16F and 18Fs have any additional on chip PWM hardware to assist with the task I've not used it, though I'm just a hobbyist.

If you are looking at the PIC18F family, there are two main C compiler options.  The first is Microchip's C18 compiler.  This is what I've used and it's going away.  The second option is HI-Tech.  My understanding from reading the MC forums is that the upcoming XC compiler is based on Hi-Tech.

In either case, both compilers have free unoptimized compilers available.  The MPLAB IDE interfaces well with both of them.  Just this week I upgraded to MPLAB X and it works well on Windows.  I've heard a number of minor complaints about using it on Linux (mandatory reboot after install/root required for install), but in general, it seems to be functional.

I'm not personally familiar with anything other than the 16F and 18F families so I can't comment further.  If you are moving over from an Arduino, take a look at the 18F line and see if that meets you needs in terms of general capabilities and performance.

Though (my understanding is that) C18 is going away, see if you can get a copy of "Applying PIC18 Microcontrollers" by Barry B. Brey.  It has a great deal of example code dealing specifically with C18 and the PIC18F family.  Of course, if you delve into Hi-Tec C, another book might be more appropriate.

Good luck!

[Jon Chandler]

Quite a bit of DMX work has been done in Swordfish Basic on PIC18F-series controllers.

You can see the details here: PIC based DMX Dimmer

[Rufus]

I want three PWM channels with at least 12 bits of resolution at 200 Hz (I know it might not exactly be 200 Hz because of prescaler values). Which PIC should I use for this? There are so many to choose from.

I would likely go for one of the PIC24Fs

http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8181&mid=14&lang=en&pageId=75

They have up to 9 16bit output compare/PWM generators.

I can't recommend PIC18s, klunky architecture and hard to find applications where they have an advantage over the 16 bit parts. PIC10/12/16s are useful for smaller applications. PIC32 if you want 32 bits but they are not hugely faster or have much more memory than the 16 bit parts.

MPLABX is the new cross platform IDE but being new it is not without issues.

There are C compilers for all parts. They are free to use with optimisation restrictions. The 16 and 32 bit compilers (C30 and C32) are GCC based and generate quite respectable code with the optimization limits. Generated code from the free 8 bit compilers (previously Hi-Tech) is pretty bad.

They are in the process of rationalizing the compiler range down XC8, XC16, and XC32. The free version of XC16 and XC32 might be a bit more crippled than the free versions of the current C30 and C32.

[nctnico]

I agree. I'd stay away from the 8 bit PICs (those are a step back from the position the TS is in). Programming C for 8 bit PICs can be done but it is seriously crippled. For instance: using pointers gets you a severe speed penalty. IMHO a PIC32 or ARM Cortex controller would be a much better choice. None of the professional designers I've been talking to uses 8 bit PICs.

If you want to use Linux or OSX there is Eclipse which can be used as an IDE. For programming and debugging you can use OpenOCD in combination with a simple parallel port JTAG programmer. A cross-compiler can be downloaded from: http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ (formerly Codesourcery).

[free_electron]

Why would you want to move from AVR to PIC ?
That is like a step backwards, unless you go for pic32.
Pic 18f is sort of ok. The problem with pic is the hardware stacks and the banking. They are kludges to extend a broken architecture.
Pic32 is a real core (actually a MIPS based machine )

But, why not bite the bullet and switch to a Cortex based machine ? This is very fast becoming the new standard.
Problem with pic and avr is that you are stuck to 1 manufacturer... Only microschip makes pic, only atmel makes avr.
As for cortex based machines , ti , st , nxp , and many others have chips with that core. And every day new devices are released.

[A Hellene]

Charliehorse55, I will absolutely agree with Free_electron.

If you need to know the reasons why not to move from AVR to PIC, please take the time to read the quoted passage at this message.

Quoting someone competent in both architectures:
- The AVR has thirty-two target registers, sixteen of which can be an 'accumulator'; the PIC has one.
- The AVR can perform conditional jumps; the PIC can only skip one instruction conditionally.
- The AVR has individual vectors for each interrupt; the PIC has a single interrupt for all.
- The AVR has a contiguous RAM memory space; the RAM on the PIC is accessed either by setting one or two bits in the status register to select the required bank or by using an indirection register (and potentially another selector bit).
- AVR registers are accessible through specialised instructions or as direct memory addressing; PIC registers are available only through the paged memory system.
- AVR completes one instruction per clock cycle; the PIC requires four cycles.
- The AVR has a stack available to the program and potentially as large as the internal RAM; the PIC has eight levels, with no user stack.
- The PIC peripherals are generally not as useful as those of the AVR, in particular the timers (though the PIC can offer interrupts on more pins (I think) than the AVR).
In general, on the AVR you generate code which targets the 'accumulator' registers; on the PIC most operations target memory directly.


-George

[T4P]

Go with STM32F1 or STM32F4 you can also go for NXP's cortex M3/M4 or TI's Stellaris Cortex M3 but the highest clock belongs to STM32F4
God i love the STM32F4 so much i am a sucker for ST's micros now.

One thing very big about ARM is once you learn ARM you can do nearly all ARM without difficulties because device to device only change in terms of device specific.
In AVR/PIC it's about assembly and the C is a little bit different so if you can, make the move to ARM although ARM is only available in LQFP.

OR you can use the MSP430, low power high performance for a 16bit chip.

AVR is a hell lot more advanced than a PIC, even calculating in the extra cost

[Psi]

AVR is a hell lot more advanced than a PIC, even calculating in the extra cost

That's mainly because the AVR instruction set was designed to be used by a C compiler efficiently.
Where as the PIC instruction set was designed for writing programs in ASM. 

[alm]

I don't think that it's useful to have another PIC vs. AVR debate here. The point remains that moving from AVR to another 8/16-bit architecture like PIC or MSP430 is mostly a horizontal move: you gain some improvements, and lose some other things. If moving to another MCU family represents a significant investment in time and equipment for you, than it may make more sense to either stick to AVR (you can use an Arduino to program any AVR, and you can program them in C), or move up to some 32-bit architecture (eg. PIC32, ARM Cortex) if you need more performance/peripherals.

[nctnico]

Googling a bit for 'arduino arm' came up with this website:
http://www.xduino.com/hardware/

[bxs]

So people already started a PIC vs AVR, why?
I also think that for 99% of the jobs doesn't matter, the 2 will do the job and if you know well one brand, the only reason for change is because you want to simple taste other things, witch is good thing if you have time for it.

About PIC on OSX and Linux, the way to go is MPLAB X, and yes, you have C compilers 

[Galenbo]

@charlieHorse:

I use a Mikroelektronica board with Pic 18F4520, language MikroC.
Some will (for their reasons and background) not think this is the optimal choice.

For me, it is. I'm a newbie in microcontrollers, with a large expierience in PLC, LabView and Drives.
MikroC gives me a big jumpstart, with more predevelopment and examples than something else.

So I can only advise to take a look at it, and determine if it's any good for your situation.
Customer service is excellent and the quality of the boards is very fine.

.

[ColinB]

Googling a bit for 'arduino arm' came up with this website:
http://www.xduino.com/hardware/

If you're looking for an Arduino-like platform with a more powerful ARM Cortex micro, look at the LeafLabs Maple.  There is even a Maple clone from Olimex now, called OLIMEXINO-STM32.

[EEVblog]

So people already started a PIC vs AVR, why?
I also think that for 99% of the jobs doesn't matter, the 2 will do the job and if you know well one brand, the only reason for change is because you want to simple taste other things, witch is good thing if you have time for it.

I chop and change between PIC and AVR based on the project requirements. Usually features vs package vs price vs availability. Whichever is the most suitable gets the job.
All the arguments about which is best is pretty pointless unless you have direct requirements context.

Dave.

[nctnico]

A controller may look good price and feature wise but you'll need to look at a much bigger picture to make the best choice. Unless you are running >50k quantities of each product the biggest cost of a product is software. Using multiple incompatible platforms means you'll need to write and maintain more software than strictly necessary which means wasting money.

The most succesfull and profitable companies I've worked for didn't care much about cost of a controller as long as it was easy to write software for the platform (series), could be used in every product and had an upgrade path into the future. Nowadays controllers can run more and more software so the choice for a future proof platform becomes even more important. NXP's ARM controllers are a good example of such a path. Most software written for their LPC2000 ARM7 controllers can be reused on their Cortex controllers because the peripherals are (almost) identical.

I vividly recall a meeting I attended many years ago. My employer at that time was interested in purchasing some DSP algorithms so they invited some peope over who already created cards with DSPs and software. It quickly turned out they wrote everything in assembly language and the DSPs they where using where about to become obsolete. They had to rewrite c.q. sift through many human years worth of code to get it working on different DSPs. This basically means putting a company on hold regarding new products and/or adapting to a changing market. In the end my employer opted for doing the processing on PCs and use C as the programming language because that solution would never have problems with getting obsolete while providing lots of processing power.

[xquercus]

The OP commented about having a background with the Arduino and an interest in PICs.  My assumption, which may be incorrect, is that the OP is interested int PICs for hobby use.  His post seemed to allude to this.  I'm an electronics hobbyist and have no professional experience.  Are some of the comments in this thread a bit less critical for us part timers to consider?

[alm]

I would say the issue of learning and tools cost is far more important for the hobbyist than even small business. If you don't mind the costs and time investment, then I see no harm in switching. Just don't expect huge advantages for any of the popular 8/16-bit micros. As Dave has stated repeatedly, it's pretty much a wash, all have some advantages and issues.

[nctnico]

The OP commented about having a background with the Arduino and an interest in PICs.  My assumption, which may be incorrect, is that the OP is interested int PICs for hobby use.  His post seemed to allude to this.  I'm an electronics hobbyist and have no professional experience.  Are some of the comments in this thread a bit less critical for us part timers to consider?

That depends on what you want to do. Get to know as many microcontrollers or just build cool stuff. If you choose one very versatile platform which you get to know inside out over time and collect a big library of routines you can build the most amazing stuff in one evening.
I started with 8051 controllers. At one point I found myself spending more time armwrestling with the controller than getting actual work done for a project. That made me move to TI's MSP430 and from there to ARM.

[free_electron]

I typically don't care about the core used. I am after the built in peripherals. i'll select a chip in functions of the on board stuff...
I do try to stick as much as possible to vendorless cores like 8051 , cortex et al ...
i don't like processor cores that can only be gotten from one vendor .. ( like PIC , AVR ) they are not bad and sometimes i do use them , but the advantage of a vendorless core is that you have a bigger pond to fish in ... there are at least 50 companies making chips with a 8051 core. and there are at least 10 companies making chips with cortex cores...

Heck , even analog devices has an 8051 based cpu with a 24 bit a/d converter !
Zilog just release an 8051 base machine.
And as for silabs ... they have the 8051F120... that beast screams at 100 mips ... has hardware mulitply and devide.
silabs also has 8051 that can run off 0.9 volts ...

I personally like harvard machines over von neumann , simply becasue memory is partitioned. no problems with 'data' overwriting 'code' because of a pointer problem...
The 8051 has long been my favorite although now i am rolling bit by bit into the cortex machines.
i like the 8051 because of the 4 register banks. it is extremely easy to make code that runs in threads. you can assign a routine to one bank and don't need to do 'contect swaps' , something that on other architectures takes time because you need to push and pop stuff on the stack to get in and out... it also allows very very fast interrupt response. you don't need to save anything or restore anything , just switch bank. On an Arm7 context swap is horrible... you waste sometimes 50 instructions just popping in and out ....

cortex fixes that by having special switch instructions. ( cortex is also a harvard machine where a regular arm is a flat von neumann machine )

[nctnico]

I personally like harvard machines over von neumann , simply becasue memory is partitioned. no problems with 'data' overwriting 'code' because of a pointer problem...

Wait until you start programming C on a pure Harvard CPU. Because of 2 or more seperate memories pointers need an extra 'tag' to tell which memory they are pointing to. This needs to be handled at runtime and makes the code extremely slow. There is a good reason you don't see new pure Harvard CPUs anymore...

On an Arm7 context swap is horrible... you waste sometimes 50 instructions just popping in and out ....

Really? ARM7 has seperate register banks for use during interrupts. If you are carefull with the registers you can write IRQ handlers without the need for pushing and popping. And even if you need to push or pop you only need one instruction to push or pop a selection of registers on the stack (the time this takes depends on the number of selected registers). Its all very efficient.

cortex fixes that by having special switch instructions. ( cortex is also a harvard machine where a regular arm is a flat von neumann machine )

You are mistaken seperate code fetch, memory access and system buses for Harvard. Those have nothing to do with a Harvard architecture! The Cortex devices have (simply put) multiple busses in parallel to gain performance. The larger LPC2000 ARM7 devices from NXP also have a similar bus matrix which allows to have multiple devices access memory devices in parallel as long as there are no conflicts. For example: at the same time the CPU can fetch the next instruction from flash while the DMA controller is transferring data from the ethernet MAC into SRAM.

Actually the CortexM cpus are much simpler than the ARM7 cpus. No more register banks and many seperate stacks for different IRQ levels. I also can't find your magic switch instruction. There is no difference between the way it is handled on ARM7 or CortexM. Both have kernel and user space stacks. OTOH CortexM cpus do much of the interrupt handling in hardware. Which is nice because it allows interrupt handlers to be plain C functions. Even better: you don't need a single line of assembly code to get a CortexM controller going.

[yanir]

I would likely go for one of the PIC24Fs

I agree, I've been using the pic24f series for a few years and although they are not perfect they are a good balance between power and ease of use. I've made a few products with them and the
Main problems they have are usually compiler / IDE bugs (which are infuriating). But the chip is a solid micro. I code in C and there are plenty of app notes and sample projects to get you going.

[jerry507]

"Vendorless cores" like arm sound great in theory, but in reality there is nothing vendorless about them. Different IDE's, different debuggers, different libraries. It's all different and requires just as much transition time unless you just forgo all the vendor provided support.

I use many different processors, but I LIKE PICs so I try to use them. I recently used a TI cortex for it's USB host capability. Having gone through that experience, I'll go with Microchip next time, likely a pic24. Peripherals do largely guide my choices, but a huge area for me is documentation. TI documentation sucks and there aren't a lot of people on their forums, but Microchip has considerably better app notes, better technical support and though their forum sucks mechanically it's got users.

That ranting aside, I would recommend the same as other posts, go with a pic24. It's newer, there are better packages of peripherals IMO and the prices aren't even that bad. 18 series pics are generally left to the serious penny pinchers now, though when they came out they were much better than the 16 and 17 series. I don't go for the 32 bit MIPS ones, but that's purely because they are always too big for my requirements.

[Rufus]

I'll go with Microchip next time, likely a pic24. Peripherals do largely guide my choices, but a huge area for me is documentation. TI documentation sucks and there aren't a lot of people on their forums, but Microchip has considerably better app notes, better technical support and though their forum sucks mechanically it's got users.

People (including me) complain that Microchip documentation sucks but I haven't recently needed to look at other vendor parts to establish the current industry standard level of sucking .

Also good to see some people understanding that there are at least 4 families of processor called PIC and statements like PICs suck or PICs are worse than x are just ignorant.