
A Guide to Pic Microcontroller Paging - Jetroid
https://jetholt.com/micro/a-guide-to-pic-paging/
======
lmilcin
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)?

~~~
joefourier
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.

~~~
bitbckt
I couldn’t agree more with the parent.

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.

~~~
exmadscientist
> 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.

~~~
bitbckt
> 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.

------
indigo945

        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.

~~~
roamingryan
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.

