Can somebody explain why anybody would want to put up with PIC in 2020 when ARMs are so cheap and energy efficient and development tools got to a point where you get working toolchain with no time or money expense (for example with stm32cubeide and st-link)?
I was about to say that only PIC chips come in 8- and 6-pin packages, but I see that I'm wrong about that. Microchip's patent must have run out fairly recently.
I gave up on the PIC platform quite some time ago.
There is no good commercial reason to go with a pic, there are cheaper 8bit MCU s like 0.01$ cheap or even less, or as you said arm ones that are much faster, with free tooling and good JTAG/swd debugging. However there are millions of PICs that are still used so it is useful to know these things.
I haven’t looked into the ultra cheap stuff in a while, are you talking about other 8 but mcus from major manufacturers or the ultra cheap no name alibaba stuff? PICs historically have good data sheets which is worth a non trivial amount of money
PIC extreme low power (xlp) is ridiculously low - at least an order of magnitude lower sleep current (9nA) than ARM equivalents. They also have very low uA/Mhz, but some ARM chips are approaching or exceeding that (eg SAM L).
There's also something to be said for simplicity and ease of hardware development, as opposed to a race to the bottom on price. Do you necessarily need all that ARM grunt? 8 bit micros tend to need very little support circuitry and can have very low pin counts - eg the PIC10F322 is 6 pin, 20nA sleep current and comes in a DFN package.
There are also applications where having a DIP package chip is useful (easy replacement, for example).
RISC-V will probably be more of a competitor to PIC once suppliers really get going. There's even a standard RV32E spec that's limited to 16 registers, which should make for tiny area footprint even in old process nodes.
That's the mentality that leads to toasters running Linux. For many applications there's absolutely no need for ARM MCUs and all their added complexity.
Plus for the hobbyist at home, PIC still comes in DIP formats which is handy for breadboarding or soldering without the added difficulty of SMT.
> The idea that ARM should be used in any/all situations is naive.
I mean, sure, this is true. MSP430s are great when you need the lowest power, and AVRs are tiny and cheap for lowest cost. But... I do this for a living, and there's a reason our go-to is the Cortex-M series. M3 or M4 if you need a lot of CPU power, or M0/M0+ if you need small. They're just so, so much easier to program that the trivial additional cost of the microcontroller washes away in the noise.
And it's not like this leads to Linux toasters; the M0 is not a microprocessor, it's a microcontroller. It's got a two-stage "pipeline" and absolutely no memory protection! There are tricks to get the larger M3s to run Linux, but it's hacky and not something you'd want to ship.
PICs are essentially obsolete, and none of us would ever consider them for new development. They're annoyingly constrained hoary old beasts.
I never said you should use ARM for everything. I just asked why anybody wants to put up with PIC which is quirky and offers nothing over other chip families.
But even then, why bother with PICs which need assembly programming and their paging?
There are ton of other 8-bitters which have no need for paging -- Atmel AVR, MSP430, even modern 8051 clones and higher end PICs.
They all come in variety of DIP shapes and memory sizes, too. And great C-based toolchains.
I think that for the last ten or so years, there is no excuse for someone to use low-end PIC, the ones where you need to write "pagesel" my hand, at all. There is no niche where they are good.
Capable C compilers have been around for a long time on PICs. I’ve only seen people using assembly for legacy systems that were already written that way.
That said I wouldn’t use one for a new product. I think they could still have a place in education because of the quality of their data sheets and their robustness. In grad school we had a graveyard of ARM chips but the PICs put up with a really surprising amount of abuse.
I guess your kind of mentality would be writing everything in assembly. Yes, it is possible to write a website in C or assembly and would probably be more efficient with resources.
No, it doesn't make any sense.
If you calculate you can learn one platform and use the knowledge and toolchain to produce wide variety of projects with less hassle it is difficult to defend using PIC for new projects when the only argument would be that maybe it uses less current in standby mode. The price is that you need to live with with essentially obsolete development environment with no future that you can use only for relatively simple projects.
We prefer to use PIC microcontrollers because they come in a DIP package.
Our products are mainly sold as PCBs that a customer assembles in their own home, appealing to the DIY electronics market.
For many, SMD is challenging, so having a DIP package makes us more available.
Additionally, the ability to use less power is useful because our products do not have an onboard power supply, instead relying on the rack's supply that may be shared between many products.
I only know ST ARM chips (aside from AVR I used before I started with ARM), but some low power ones go down to 1.8V and can sleep for years on two AAAs. I see no issue soldering LQFP packages even though I have very little experience (my domain is software) but I can see how DIP is much less assuming.
legacy momentum is still a factor too for sure. its easier to move an old, industrially in use 16F84 to eg 16F18xxx or pic18F or smaller faster modern low power pics with minimal code changes. and MCC is pretty good
ive seen a lot of critical timing code down to using the 4 clock instruction timing have to stay on similar devices to save rewrite effort etc
Technically, the second block of code is not 100% equivalent.
Why? Well, it uses more instructions (so more memory and
also takes longer to execute) but it also sets ALL bits of
the Program Counter, not just the ones that a goto or call
can.
We could use the second block of code to goto to a correct
page, but it would be annoying to use in practice because it
would mangle the W register.
Does the code even work at all? I don't know anything about PIC microcontrollers, but I would have expected that writing to PCLACH would cause a jump immediately, meaning that the write to the low bits in PCL would never even happen.
PCLATH stands for Program Counter LATch High (byte).
In this case latch refers to the digital design technique where you have a register that holds bit(s) until some other event happens. The event in this case is a write to PCL. Once the event occurs, PCLATH is transferred to PCH synchronously/atomically with the write to PCL.
33 comments
[ 4.6 ms ] story [ 67.9 ms ] threadI gave up on the PIC platform quite some time ago.
https://patents.google.com/patent/US5847450A/en
https://www.eetimes.com/microchip-sues-zilog-over-8-pin-micr...
However, it would not shock me if someone were to take a critical look at the validity of Microchip's patents.
https://electronics.stackexchange.com/questions/144005/wlcsp...
There's also something to be said for simplicity and ease of hardware development, as opposed to a race to the bottom on price. Do you necessarily need all that ARM grunt? 8 bit micros tend to need very little support circuitry and can have very low pin counts - eg the PIC10F322 is 6 pin, 20nA sleep current and comes in a DFN package.
There are also applications where having a DIP package chip is useful (easy replacement, for example).
Plus for the hobbyist at home, PIC still comes in DIP formats which is handy for breadboarding or soldering without the added difficulty of SMT.
ARMs from ST can run for years on a single AA battery and have nowadays very easy tools.
Probably you are missing understanding of whole range of ARM chips, these start from couple kB of flash and hundreds of bytes of memory.
Further, PIC isn’t the only “non-ARM” in this space. Your average RainBird type water timer likely uses an MSP430, for example.
The idea that ARM should be used in any/all situations is naive.
I mean, sure, this is true. MSP430s are great when you need the lowest power, and AVRs are tiny and cheap for lowest cost. But... I do this for a living, and there's a reason our go-to is the Cortex-M series. M3 or M4 if you need a lot of CPU power, or M0/M0+ if you need small. They're just so, so much easier to program that the trivial additional cost of the microcontroller washes away in the noise.
And it's not like this leads to Linux toasters; the M0 is not a microprocessor, it's a microcontroller. It's got a two-stage "pipeline" and absolutely no memory protection! There are tricks to get the larger M3s to run Linux, but it's hacky and not something you'd want to ship.
PICs are essentially obsolete, and none of us would ever consider them for new development. They're annoyingly constrained hoary old beasts.
No argument there.
There are ton of other 8-bitters which have no need for paging -- Atmel AVR, MSP430, even modern 8051 clones and higher end PICs.
They all come in variety of DIP shapes and memory sizes, too. And great C-based toolchains.
I think that for the last ten or so years, there is no excuse for someone to use low-end PIC, the ones where you need to write "pagesel" my hand, at all. There is no niche where they are good.
That said I wouldn’t use one for a new product. I think they could still have a place in education because of the quality of their data sheets and their robustness. In grad school we had a graveyard of ARM chips but the PICs put up with a really surprising amount of abuse.
https://www.mikroe.com/mikroc-pic
https://www.mikroe.com/mikropascal-pic
https://www.mikroe.com/mikrobasic-pic
No, it doesn't make any sense.
If you calculate you can learn one platform and use the knowledge and toolchain to produce wide variety of projects with less hassle it is difficult to defend using PIC for new projects when the only argument would be that maybe it uses less current in standby mode. The price is that you need to live with with essentially obsolete development environment with no future that you can use only for relatively simple projects.
We prefer to use PIC microcontrollers because they come in a DIP package.
Our products are mainly sold as PCBs that a customer assembles in their own home, appealing to the DIY electronics market.
For many, SMD is challenging, so having a DIP package makes us more available.
Additionally, the ability to use less power is useful because our products do not have an onboard power supply, instead relying on the rack's supply that may be shared between many products.
ive seen a lot of critical timing code down to using the 4 clock instruction timing have to stay on similar devices to save rewrite effort etc
-legacy designs
-expertise
-corporate politics
Very low power consumption.
Aggressive pricing (if you've got the volume).
Ace technical support. (Again - if you've got the volume.)
In this case latch refers to the digital design technique where you have a register that holds bit(s) until some other event happens. The event in this case is a write to PCL. Once the event occurs, PCLATH is transferred to PCH synchronously/atomically with the write to PCL.