Slightly OT: PIC vs ARM

[bkamen]

Hey PIC Veterans,

I've been playing with an ARM M0 from STmicro and it's kinda funny how everyone is running to 32bit for the simplest of tasks.

but when I look at the machine code, all those extra instructions to do byte-sized or word-sized work that don't exist even for 16bit PICs (I didn't compare to PIC32 -- since I know it's kinda messy like ARM)..

But the inefficiency of the instruction sets for ARM vs. PIC 8/16bit.

Kinda interesting to observe.

Anyone else jump into these other venues recently for a PIC Comparison?

-Ben

p.s. I'm so unhappy with XC8. OMG that's another thread entirely.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[Ttelmah]

In terms of sheer chip quantity the small processors still win. When you are putting together things like a smart card that is supplied in 6digit numbers you don't want the power use/cost of anything bigger.

However it is sad that Microchip haven't produced a really 'enhanced' mid end PIC family. Kept the same basic architecture, but with all the peripherals re-mappable (some are getting close on this), and then had single cycle save of all the main registers (this was on the Z-80, something like 30 years ago - a swap instruction that switched between two register sets). Suddenly for the cost of a very few bytes of RAM, you have tiny interrupt latency. Add a hardware divide, and you'd have a single chip that could be used to replace just about all the existing PIC18's, and some of the PIC24's etc., without having to have the 'plethora' of models, which perhaps tends to put people off the PIC.
The 'PIC-18X', would be a dream for so many things.....

[jeremiah]

Unless I am misunderstanding yall, the PIC24 family has some of that:
1. Byte, word, and double modes for some instructions (not all, but MOV off the top of my head has this option).
2. Remappable pins (at least on the main family lines I have used)
3. PUSH.S, POP.S for single instruction context save
4. Hardware divide (and multiply)

Am I misunderstanding?

[ELCouz]

[RF_Developer]

[Ttelmah]

Some of the PIC24's are moving that way, but there are major shortfalls.

First, push, and pop don't help much with the register saving. They only save _one_ register at a time. Want to save twenty registers, and it is twenty push's, and twenty pop's to get them back. The PIC24, takes as long as a PIC16 or 18, to get into or out of the interrupt handler. The point about quite few older processors, was they had single cycle operations, that saved all the critical registers, either by moving a memory pointer, to relocate the working registers, or by having ghost copies of the registers, and switching. Really fast responses to interrupts are critical for an embedded processors and it is an area where the PIC does increasingly badly. Increasingly, because each chip generation has more and more registers....

For ElCouz, I have to say 3.3v, is honestly easier than 5v now.

The PIC18's only have 8*8 hardware multiply. The multiplication/division on the PIC24's, not that much better. Really slow by modern standards.

Yes, the family has some parts of this, but I find myself wanting to have a single slightly 'upmarket' PIC, without having to choose from a hundred models, so I can have a smaller part bin. Imagine something in the PIC24 family, with the pin layout/peripherals of the 18FxxK22, an improved ALU, and a single instruction response to interrupts at a couple of priority levels, and all the peripherals re-mappable.

I'm a great believer in using more powerful chips for more complex tasks (ranging from Arduino's through embedded PC's), but love the PIC for simpler tasks, but want something that just fills the gap a little more above the current models.

[jeremiah]

I've really enjoyed using the PIC24 family, specifically variants of the PIC24FJ64GA004.

1. Single Instruction multiply
2. Majority of the pins and peripherals are remappable, which makes it very flexible.
3. Single Instruction context save for interrupts using the Shadow Register hardware. Makes interrupts faster, which I like.
4. Decent RAM (8+k) and ROM
5. Multiple interrupt levels
6. Low power variants (10s of nA in sleep mode)
7. Small package options

I've been working with them for over 7 years now and aside from the occasional errata issue, I have really enjoyed them. I'm still looking for an ARM that is 16bit bit or higher with good low power options and size all at the same time. I would like to branch out some.

[guy]

I never worked with anything other than PICs so I am amazed over and over again at what they squeeze into those tiny parts at a ridiculous price (for example take a look at the peripherals on the PIC16F1704 at $0.67 ! There's a whole PCB full of parts inside). I also enjoy the DIP packages for those early prototyping stages. As a freelance you pay for your design mistakes

Recently I did a project with the PIC24. Again I was dazzled - user-friendly DMA, high MIPS, plenty of resources but at the end of the day, also due to CCS compiler's bugs I didn't quite enjoy working with it.
Another downside was that there is no mentioning of protection diodes for the pins (to VSS and VDD). This adds A LOT of parts to the BOM + placement costs. I think they forgot about the concept of a microCONTROLLER rather than a uProcessor.

Altogether I'm very happy with the combination of PICs + CCS and option of [rarely] inserting a few lines of assembly in the code. Can't seem to let go of MPLAB

[bkamen]

[guy]

Microchip doesn't know know software... Never did.
A friend had saved my life by recommending CCS. Other compilers have registers and addresses #DEFINEd in the code which makes the code non-migrateable - out of the question.

[bkamen]

Their compiler would be ok if it just WORKED...

I get it that bugs happen.

but their model of designing in a "crappy compiler mode" which now distracts from just focusing on writing the best compiler they can coupled with their new pay-to-get-stuffed licensing model...

And their incompetent tech support.

Ugh.

Microchip should just hire the Gurus here (if they didn't already have full time jobs, I'm sure.)

Sorry - I didn't mean to turn this into a Microchip rant.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[ELCouz]

I just wished that the microchip supported open source compiler such as GCC from the beginning like Atmel.... we would have PICduino instead of arduinos now...

I completed the 2015 CCS survey....

I asked for PIC32 (Good thing to do if they want to survive in long term)
And more drivers (less time we spent doing drivers is better for us)


PS: I know the PIC32 is a very different beast but they should support it ... the minimum at least so they could continue to compete with Microchip XC32 compiler...
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!

[ELCouz]

I wonder if the effort is so great and worth it to switch to the PIC32 family than learn any other better ARM platform?

If I understand at this point PIC32 is no more a microcontroller (more like a processor)

Do anyone here tried the PIC32 platform since it's launch in 2007?
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!

[bkamen]

I've done a couple designs for customers based on the PIC32 with built-in ethernet.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[ELCouz]