from Pic18f to Pic32, new problems

[Galenbo]

I found this quote online:

"One real problem with PIC32 is the semi-failed attempt to replace 8 bit in the hobbistic world. Most hobbists still use a PIC16, even if cost more and gives much less. The fact is ALL 32 bit architectures failed in this effort because all brands understimated the "friendly-factor". It's true a 32 bit is 10 times better then a 8 bit ... but also small packages impossible to solder, complicates programming languages and rather expensive debugging tools makes it 10 times more complicated to use."

I do not doubt it is true, but please give your personal problems you ran into.
Basic things that do work immediately in pic16f/pic18f, an costed days in pic32f.

[hans]

I cannot familiarize myself in this quote, well not regarding PIC32.

In my experience PIC32 (and PIC24 for that matters) feels like programming an 8-bit PIC on steroids. The peripherals are simple for a 32-bit chip, "what you see if what you get" and pretty straight forward. I wrote my own ethernet DMA mac driver in like 2 hours, bare metal. All procedures regarding init and maintaining the TX/RX frame chains were documented in nicely in the datasheet. I basically just implemented these in C and it worked.

Contrary to most ARM chips.. these often do not contain said procedures in whole. They require setting clock enable, clock reset and power enable registers before anything happens. Each peripheral typically has many more bits and modes to set. etc. In other words; they assume you will be using their CMSIS libraries anyway.
When starting out this can be quite frustrating, but once going and familiarized it's probably nice to have that granularity at times. However for someone who doesn't have 40+ hours a week to burn on this stuff, I am sure it can be daunting.

I think the most dicky aspects of any chip family and architecture are init codes (clock, PLL, etc.), interrupts and debugging exceptions. This will never go away until you spend time to learn it.

Additionally I would like to point out that IMHO some part of the PIC16 programmers are quite scared of change it seems. They are still trying to program these antique PIC16F877A 628A or even 84A chips in 2016. In obscure languages like Basic, Proton or even assembler. And then complain that [insert X protocol] is hard, takes a lot of time to figure out or there is bad support (code examples, projects, etc.) for new chips/peripherals, or an external chip is hard to interface with.
I think these people will complain if a STM32F4 is not available in DIP. Come on, I can imagine BGA is hard to solder.. but QFP is very manageable with a decent solder iron, fine solder and some practice.

[batteksystem]

I found this quote online:

"One real problem with PIC32 is the semi-failed attempt to replace 8 bit in the hobbistic world. Most hobbists still use a PIC16, even if cost more and gives much less. The fact is ALL 32 bit architectures failed in this effort because all brands understimated the "friendly-factor". It's true a 32 bit is 10 times better then a 8 bit ... but also small packages impossible to solder, complicates programming languages and rather expensive debugging tools makes it 10 times more complicated to use."

I do not doubt it is true, but please give your personal problems you ran into.
Basic things that do work immediately in pic16f/pic18f, an costed days in pic32f.

I would say most of the hobbyists do not need a 32-bit architecture unless they need to do heavy codec like MP3, or JPEG compression. However, the original PIC32 is not very good in RAM support which also make these applications not easy to do. I remember there was a MP3 codec for PIC32 and a lot of that had to be done in assembly for speed. I personally also worked in a project using PIC24F which is fully done in assembly as well.

So from my point of view, if in these days they still need these kind of things to be done, it is better on a rasberry pi or something more easy and powerful. As the cost of these are not that expensive, comparing to like, ten years ago when we first starting coding.

[andersm]

In my opinion, the PIC32 carries around a lot of MIPS legacy baggage that makes them harder to learn than it could be. Microchip's tools tries very hard to hide most of it, but it's still far from the elegance of the Cortex-M architecture. "PIC32" is also a large (and growing) family of devices with significant architectural differences.

[Bruce Abbott]

In my opinion, the PIC32 carries around a lot of MIPS legacy baggage that makes them harder to learn than it could be. Microchip's tools tries very hard to hide most of it, but it's still far from the elegance of the Cortex-M architecture.

'Elegance' of Cortex-M? Please  explain. And how are Microchip's tools 'hiding' MIPS baggage?

[andersm]

'Elegance' of Cortex-M? Please  explain. And how are Microchip's tools 'hiding' MIPS baggage?

Things like being able to do (almost) anything in C, ISRs being normal functions and the automated interrupt prologue in general, lazy FP register stacking and so on. On the PIC32 you have eg. the legacy single-vector interrupt modes, the split between the core's interrupt handling and the external interrupt controller, the fixed-offset vector tables, register banks, CP0 registers, the whole KSEG/USEG split and so on. Just look at the number of CP0.Config registers that hold information that may be relevant if you're trying to distribute portable binary Unix kernels, but that none of Microchip's customers will ever need. MIPS is also saddled with one of the most inefficient calling conventions (O32) that they haven't been able to replace, despite trying for probably decades by now.

[rstofer]

I find programming the PIC16 to be quite a chore.  All the paging and banking nonsense is just ugly.  Move to C and the problem is hidden - right up until you look at the assembly code.  A very high percentage of the executable instructions deal with nonsense dictated by the architecture.

The early ARM-7TDMI chips had some restrictions on interrupt handler code but newer versions can just use normal functions.

I can sling assembly code around as well as the next guy but, really, I prefer to just write generic C.  I like the ARM chips and I particularly like the 'stamp' form factor of boards like the mbed.  I can just stuff the entire board onto a daughter card and call it good.  The fact that I don't need a special programming device is pretty nice.  Of course, one result of that is that I don't get JTAG debugging.  I get around that with printf().

There's no way I would start a new project with a PIC device unless it was somehow a requirement and that's not likely because I set the requirements.

To the original quote:  Somebody has an agenda and I disagree with every aspect of the statement.  PICs were great 10 or 15 years ago and they have a place yet today.  But for the hobbyist, I'm not so sure they are a good place to start. 

As to CSMIS:  I'm not a fan.  Every time something gets hidden in a library, I have less control over my project.  I would rather do the work myself.

[dannyf]

"Every time something gets hidden in a library, I have less control over my project.  I would rather do the work myself."

There are countless things in your life that you depend on others to get right. As a matter of fact, there is no way you can live a modern lfe without depending on others.

To me, this "I have to do everything" approach is quite limiting.

[Sal Ammoniac]

Others have already covered some of the MIPS baggage the PIC32 carries around, but one issue that I didn't see mentioned is interrupt and context switching latency.

The PIC32 has twice as many general purpose registers as the Cortex-M parts. Many of these must be saved on an interrupt and all of them on a context switch. This is time consuming and it's compounded by the fact that there aren't any "store multiple" instructions--each save requires a separate instruction, unlike the Cortex-M which has store multiple instructions that can save the entire register set in one instruction.

[jnz]

mentioned is interrupt and context switching latency.

At least on the PIC32 it's long but not ridiculous. PIC18 was just stupid.


I look at it like this... I was on 8bit bits for years, had one project on the 33F/16bit. Then needed to get with the times... I had the choice of PIC32 and being locked into MCHP for everything or ARM... It wasn't even a question.

[hans]

Others have already covered some of the MIPS baggage the PIC32 carries around, but one issue that I didn't see mentioned is interrupt and context switching latency.

The PIC32 has twice as many general purpose registers as the Cortex-M parts. Many of these must be saved on an interrupt and all of them on a context switch. This is time consuming and it's compounded by the fact that there aren't any "store multiple" instructions--each save requires a separate instruction, unlike the Cortex-M which has store multiple instructions that can save the entire register set in one instruction.

I agree that interrupt latency can be painful if the CPU has to save many registers.
However I would argue that the store-multiple instructions is a purely a FLASH saver, not much of a time saver.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/BABBCJII.html
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CIHJJEIH.html

The store-multiple instruction takes more cycles the more registers it has to store or load.

In my experience the code density on MIPS is not as good as on ARM. However I have never found 256K or 512K of FLASH to be scarce, well unless dealing with static assets of course.

[Sal Ammoniac]

In my experience the code density on MIPS is not as good as on ARM. However I have never found 256K or 512K of FLASH to be scarce, well unless dealing with static assets of course.

The PIC32MZ has variants with up to 2M of FLASH, which helps. In addition, the new M14K CPU core in the PIC32MZ supports microMIPS, which is similar to Thumb2 on the Cortex-M and allows for more compact code.

[andersm]

The store-multiple instruction takes more cycles the more registers it has to store or load.

That's expected, the core can only issue so many memory writes per clock cycle. However, with more store instructions you're more likely to run into flash wait states or prefetch stalls. The microMIPS32 instruction set has load/store multiple instructions, but they're designed for function call prologues and epilogues, and can only operate on the callee-saved registers.

On fast processors with deep pipelines, load/store multiple causes lots of implementation headaches, which is why those instructions were removed from the ARMv8-A instruction set.

In my experience the code density on MIPS is not as good as on ARM.

microMIPS32 should be about as compact as Thumb-2.

[rstofer]

"Every time something gets hidden in a library, I have less control over my project.  I would rather do the work myself."

There are countless things in your life that you depend on others to get right. As a matter of fact, there is no way you can live a modern lfe without depending on others.

To me, this "I have to do everything" approach is quite limiting.

If I use CMSIS, I first have to read the datasheet to figure out what needs to be done.  Then I have to struggle to find the CMSIS documentation and the code to see if they did it properly.  Everybody makes assumptions, do I and the author agree on how I would use the hardware?  Any reserved pins?  Any clocks that can't be changed because other stuff breaks?  Timer usage?  NVIC limitations?  And on and on...

If I write to the registers directly, I know exactly what will happen.  It will be just like the datasheet!  Mostly...

Now, that idea doesn't necessarily carry over into complex communications protocols.  I certainly don't want to write a TCP/IP stack or USB stack. But I absolutely want control over every aspect of the standard peripherals like SPI, I2C, UARTS, Timers, NVIC (including priorities) and so on.  I don't need bloatware getting in the middle of everything.

[dannyf]

"
If I use CMSIS, I first have to read the datasheet to figure out what needs to be done. "

I don't know which elements of cmsis you are talking about but forr DSP, dap, rtoss, etc, there is no point of register access.

If you are talking about cmsis startup, well, they don't provide any framework to the chips peripherals, like spi or timer. You are on your own and can do whatever you want.

Not to mention that those startup files are simply used during start-up. So why would anyone make a decision on whether to use. A chip based on how the chip starts up is beyond me.

Btw, you don't have to use cmsis startup. There are plenty of chips that start up without such - as AA matter of fact if you object to cmsis start up, you can write your own startup files.

[karpouzi]

one issue that I didn't see mentioned is interrupt and context switching latency.

I heard that the MZ was improved in this aspect. How does the MZ compare to the MX (and ARM) for running an RTOS? Are we talking small differences or something more significant.

[andersm]

I heard that the MZ was improved in this aspect.

The MZ series have the MIPS MCU ASE (application-specific extension) that has some features for decreasing the interrupt latency, but (at least AFAIK) Microchip's tools doesn't take advantage of them. The MZ also adds the DSP extensions, and the MZ EF the FPU, both of which add registers that aren't included in the shadow register banks and have to be saved by hand. IIRC newer versions of XC32 have added some flags to disable saving the FPU registers in ISRs.

Without an FPU, the Cortex-M has a fixed interrupt latency of 12 cycles. That includes enabling nested interrupts and saving enough register context allowing ISRs to be normal C functions, and is handled in hardware. The FPU can double that (ballpark, don't remember the exact figure), but with the lazy stacking feature that only applies if the ISR touches the floating-point registers. I don't have numbers for the PIC32, but IIRC for an XC32-generated ISR it's on the order of 30 cycles for a PIC32MX (no DSP or FPU). It depends on the number of registers the ISR has to save and whether or not shadow registers are in use.

Here's some PIC32MX interrupt wrappers I wrote. A Cortex-M would do all of that (except pending the context switch interrupt) in hardware, the MIPS MCU ASE would hande setting up nested interrupts and the stack pointer swapping.

[mikeselectricstuff]

We seem to have diverted into a detailed discussion on architectural things  that just don't matter for most users writing in C.
The OP was asking about transitioning from PIC18 to PIC32(MX)....

Unlike most other manufacturers, Microchip do 16 and 32 bit parts in DIP and SO packages.
To get a bare-minimum program running, about the only difference is you need to figure out the config bits to set up the PLL.
Once you start to use peripherals, you need to do the pin mapping stuff.
For interrupts there's a small amount of additional setup, deciding on priorities etc.
Like any other part, once you start needing high performance, you may need to start getting into DMA etc. 

For parts that don't need the power of 32 bit, PIC24 has some advantages, including lower active & sleep power, and the super-flexible pin mapping. 

If you can do something comfortably on a PIC16/18, then do that. 8 bit is never, ever going to go away.
I still regularly use 8, 16 and 32 bit PICs, depending on the requirements.
One of Microchip's advantages over everyone else is you can use the same tools, and very familiar peripherals across the whole range, from a 6 pin SOT23 part with 256 words of flash to a 144 pin 200MHz part with 2Mbytes of flash.

[JPortici]

One of Microchip's advantages over everyone else is you can use the same tools, and very familiar peripherals across the whole range, from a 6 pin SOT23 part with 256 words of flash to a 144 pin 200MHz part with 2Mbytes of flash.

and they are easy to find and set up, at least compared to everything else i've used

We seem to have diverted into a detailed discussion on architectural things  that just don't matter for most users writing in C.
The OP was asking about transitioning from PIC18 to PIC32(MX)....

i don't mind that, most of these discussions are from 2010-2012 and many many things have changed both in the arm and microchip world

[Galenbo]

Move to C and the problem is hidden - right up until you look at the assembly code. ..., I prefer to just write generic C.
I like the ARM chips ...  The fact that I don't need a special programming device is pretty nice...

There's no way I would start a new project with a PIC device unless...

To the original quote:  Somebody has an agenda and I disagree with every aspect of the statement.  PICs were great 10 or 15 years ago and they have a place yet today.  But for the hobbyist, I'm not so sure they are a good place to start.

Maybe I could ask my questions differently: from pic18f to ARM_M0/M4, Pic32, STM32,...
What are the personal "new" problems you found. Things that are easy out-of-the box for PIC-8bit, but complicated on the advanced ones?

[Galenbo]

...I look at it like this... I was on 8bit bits for years, had one project on the 33F/16bit. Then needed to get with the times... I had the choice of PIC32 and being locked into MCHP for everything or ARM... It wasn't even a question.

Can you explain why this was/is so?

[Galenbo]

We seem to have diverted into a detailed discussion on architectural things  that just don't matter for most users writing in C.
The OP was asking about transitioning from PIC18 to PIC32(MX)....

I indeed only write code in C, the underlying architecture differences are unimportant to me, on the condition they don't cause trouble or necessary workarounds.

Once you start to use peripherals, you need to do the pin mapping stuff.

I guess that's on the same difficulcy level as writing control registers for the PIC18f peripherals?

once you start needing high performance, you may need to start getting into DMA etc. 

At the moment, I'm happy with the performance of 8-bit, sure 32-bit will bring more potential, for me it's about not getting too much extra trouble running my "limited" pic18f tasks on the 32-bit processors.

If you can do something comfortably on a PIC16/18, then do that. 8 bit is never, ever going to go away.
I still regularly use 8, 16 and 32 bit PICs, depending on the requirements.

In a one-off project, where price of the PIC doesn't matter (7euro=4euro=20euro=2euro compared to the total cost)
what are your personal reasons to use a 8-bit instead of a 32-bit?

[mikeselectricstuff]

We seem to have diverted into a detailed discussion on architectural things  that just don't matter for most users writing in C.
The OP was asking about transitioning from PIC18 to PIC32(MX)....

I indeed only write code in C, the underlying architecture differences are unimportant to me, on the condition they don't cause trouble or necessary workarounds.

Once you start to use peripherals, you need to do the pin mapping stuff.

I guess that's on the same difficulcy level as writing control registers for the PIC18f peripherals?

It's an extra layer you need to do before a peripheral can be used. The PIC32 is fiddlier than the PIC24 as there are more constraints on which pins can be used for which peripherals. Unlike the PINSEL stuff on the lower end PICs there are no default mappings.
Having said that many higher-end parts have similar pin-mapping capabilities.

If you can do something comfortably on a PIC16/18, then do that. 8 bit is never, ever going to go away.
I still regularly use 8, 16 and 32 bit PICs, depending on the requirements.

In a one-off project, where price of the PIC doesn't matter (7euro=4euro=20euro=2euro compared to the total cost)
what are your personal reasons to use a 8-bit instead of a 32-bit?

Some possible reasons could be:
Lower pin counts /smaller packages available, wide supply voltage so external regulator may not be needed, faster programming/debug cycle, lower powerdown & run current.

[Galenbo]

In a one-off project, where price of the PIC doesn't matter (7euro=4euro=20euro=2euro compared to the total cost)
what are your personal reasons to use a 8-bit instead of a 32-bit?

Some possible reasons could be:
Lower pin counts /smaller packages available, wide supply voltage so external regulator may not be needed, faster programming/debug cycle, lower powerdown & run current.

I'll do some "google research" on this aspects, thanks for mentioning them.