PIC: May be faced with the task of familiarising myself with the PIC

[IconicPCB]

OK.. I am familiar with the Atmel AVR micro controllers but have absolutely no idea familiarity with the PICs.
A very simple issue is how are PICs programed? what programmers are available ?

[jpanhalt]

Try this: http://microchipdeveloper.com/dtda:icsp-considerations

PIC's with which I am familiar use either "high-voltage" or "low-voltage" programming.  The difference is in how one enters programming mode.  For those that can use LV programming, that is the default state.   After that, programming is via CLK and DAT pins.  Each chip will have its own specifications for programming, but as you might expect,  they are quite similar.

Microchip seems to have settled on the term NVM (non-volatile memory) to describe EEPROM and other NVM, i.e., using program space, that can be used during runtime.

[woofy]

If your budget allows, grab yourself a PICKIT4.
It programs every PIC and AVR and along with MPLABX, does in circuit debugging. It also updates itself though MPLABX for new devices as they come along.
There is a stand alone programmer (IPE) tp program devices without firing up MPLABX, that can also program unique serial numbers if required.
A lower cost programmer (SNAP) is available, but I've not used it.

[DavidAlfa]

The Snap model is basically the same, without ability to power the target and probably also lacking on-the-go programming.
Looks good target to clone, hopefully we'll see them soon.

[MikeK]

The Snap programmer only does low-voltage programming, so it cannot program older PIC's that don't have that ability.

[JPortici]

The Snap programmer only does low-voltage programming, so it cannot program older PIC's that don't have that ability.

though "old" actually means 15yo+ parts, basically those that required the PGM pin.
Anything that came out later than, including, PIC16F1823/47 (all the more recente PIC16Fxxxx and the latest PIC16Fxxxxx) doesn't need high voltage programming.
And regarding PIC18, anything PIC18F "K", "Q" and probably "J" is LVP only.

So, it's improbable that you really need a programmer that supports LVP

[slugrustle]

And regarding PIC18, anything PIC18F "K", "Q" and probably "J" is LVP only.

I'm using a PIC18F45Q43, and it definitely supports high voltage programming (datasheet snippet attached).  I actually always use high voltage programming, as I tend to use the MCLR pin as a digital input.

I would second the use of a PICKIT4.  It's not too pricey as far as programmers go, and I've found it to work well.

[brucehoult]

OK.. I am familiar with the Atmel AVR micro controllers but have absolutely no idea familiarity with the PICs.

If you're used to AVR assembly language then be prepared for a shock.

[DrGeoff]

Which model? There's a large range, PIC12, PIC16, PIC17 (now gone), PIC18, PIC24, PIC32, DSPIC.
MPLAB-X is a free dev system with C-compiler. Programming in assembly is rarely needed, depending on the application.
As for programmers, there's PICKIT, which I've never really liked, and ICD, which is much better.

[NorthGuy]

Try to get newer parts. They have lots of good periphery and interconnect options.

For some reason, many people try to use PICs which are 20-year old. This is really really bad idea.

Also, PICs are very diverse - over 2000 different parts. Not all of them are available because of the shortages, but still. Select what meets your goals.

[brucehoult]

For some reason, many people try to use PICs which are 20-year old. This is really really bad idea.

Because they still sell then and they are cheaper maybe? I certainly agree they a bad choice for most people but because of the features not the age.

It doesn't seem to be easy to find out when the ATMega168 & 328 were released. I found that the Arduino Nano was using them in May 2008 -- 14 1/2 years ago -- so I assume it was a year or so before that. Perfectly fine chip still, if the performance and capacity match your needs.

[nigelwright7557]

I use a PICKIT 3 and a Snap programmer.
PICKIT for programming stuff that has no onboard power supply.
Snap is a lot faster and I use that where possible.

PICKIT 4 seems to be sorted now after some teething problems so probably best way to go.

I have been using PIC's since 1985.
Worked for a PIC consultancy for 13 years.
Good cheap powerful micro's.
Not always easy to use but reading datasheet first helps.
First pitfall is ANSEL register is set to i/o analogue on power up, this catches out a lot of people.

[SiliconWizard]

It doesn't seem to be easy to find out when the ATMega168 & 328 were released.

The first AVR MCUs were released in 1997 or so. According to this: https://atmelcorporation.wordpress.com/2014/11/11/introducing-the-next-generation-of-8-bit-megaavr-mcus/
the megaAVR series (which the ATMEGA are part of) was released in 2002. It looks consistent to me. So, that's indeed 20 years ago. (And 25 for the first AVRs.)

Now anything can be good for learning purposes. Engineering a product is something else.
Even the old 8-bit PIC architecture can be interesting to study. Sure it is cumbersome to use, but it's easy to understand, and can be interesting as a learning experience to better understand architectures and MCU history. If you start with ARM-Cortex stuff, which would make a lot more sense these days otherwise, you're going to learn things in a lot more "high-level" way, unless you're ready to dig very deep, which a beginner won't or can't do.

So, two different approaches, both complementary.

Now if it's for designing a product, the question is entirely different obviously and can't be answered in a single manner in a single post.

[brucehoult]

Now anything can be good for learning purposes. Engineering a product is something else.
Even the old 8-bit PIC architecture can be interesting to study. Sure it is cumbersome to use, but it's easy to understand, and can be interesting as a learning experience to better understand architectures and MCU history.

Sure. Or you could look at PDP-8. But you can buy and use PIC today, so that's an advantage.

Just something as simple as "if (x <= y) goto z" ends up as (if I got it right):

Code: [Select]

movwf x
subwf y,1
btfsc status,c
goto z

While for "if (x <= y) goto z" you'd want:

Code: [Select]

movwf y
subwf x,1
btfss status,c
goto z

If I didn't get confused. That's for unsigned values. Signed is harder.

AVR / ARM / x86 need two very straightforward instructions for this. RISC-V one. (assuming z is reasonably near in all cases)

[NorthGuy]

For some reason, many people try to use PICs which are 20-year old. This is really really bad idea.

Because they still sell then and they are cheaper maybe?

No. They're substantially more expensive than new ones.

[NorthGuy]

AVR / ARM / x86 need two very straightforward instructions for this. RISC-V one. (assuming z is reasonably near in all cases)

load/store architectures need 3 (load x, load y, compare, and branch) or 4 (load x, load y, compare, branch), many will also have a stall if a command uses a register loaded on the previous cycle, which will push cycle count to 4 or 5. "one" is somewhat miscounted.

x86 needs 3 - load x, compare to y, branch

That is largely irrelevant though.

[tabemann]

AVR / ARM / x86 need two very straightforward instructions for this. RISC-V one. (assuming z is reasonably near in all cases)

load/store architectures need 3 (load x, load y, compare, and branch) or 4 (load x, load y, compare, branch), many will also have a stall if a command uses a register loaded on the previous cycle, which will push cycle count to 4 or 5. "one" is somewhat miscounted.

x86 needs 3 - load x, compare to y, branch

That is largely irrelevant though.

Much of the time the values one needs to work with will already be in registers on a load/store architecture, as load/store architectures have greater numbers of general purpose registers to work with. This is my experience from working with Thumb assembly on Cortex-M, and in practice in Thumb-1 in particular one only gets to really work with registers R0-R7 in practice due to the general cumbersomeness of working with registers R8-R12.

[brucehoult]

AVR / ARM / x86 need two very straightforward instructions for this. RISC-V one. (assuming z is reasonably near in all cases)

load/store architectures need 3 (load x, load y, compare, and branch) or 4 (load x, load y, compare, branch), many will also have a stall if a command uses a register loaded on the previous cycle, which will push cycle count to 4 or 5. "one" is somewhat miscounted.

x86 needs 3 - load x, compare to y, branch

That is largely irrelevant though.

No, because the values you are working with will almost always be in registers already, either because you were just using them earlier in the function, or because they were passed to the function as arguments (in registers). Dealing with values from RAM is very much the exceptional case, not the common one, if you are not on a completely register-impoverised ISA such as 6800, 6502, 8080, z80, or even 8051 or 8086.

AVR, RISC-V, 64 bit ARM, MIPS, SPARC etc have 32 registers, so there are virtually always enough. The 16 registers in 32 bit ARM, MSP430, SuperH, 64 bit x86 are usually enough too.

Even 12-bit PIC has 32 "registers" (memory locations that can be directly addressed by an instruction). 14-bit increases that to 128, and 16-bit ("PIC18") to 256.

[jpanhalt]

Just something as simple as "if (x <= y) goto z" ends up as (if I got it right):

Code: [Select]

movwf x
subwf y,1
btfsc status,c
goto z


"movwf   x"  moves whatever was in W to register x, so that code will not provide a comparison of x to y.  You probably meant the instruction "movfw   x" which may still work as an assembler directive.  However, it is more common now simply to use, "movf  x, W" 

It's not clear to me what you are trying to show in the second example.  If you subtract y from x and y is > x, then STATUS  C is cleared (i.e., "borrow"), but if they are equal, then Carry is not cleared.  The enhanced mid-range and later have a couple of new instructions (subwfb and addwfc) that can be useful when doing math rather than comparisons as they take care of checking Carry and  automatically increment or decrement appropriately.

[brucehoult]

Just something as simple as "if (x <= y) goto z" ends up as (if I got it right):

Code: [Select]

movwf x
subwf y,1
btfsc status,c
goto z


"movwf   x"  moves whatever was in W to register x, so that code will not provide a comparison of x to y.  You probably meant the instruction "movfw   x" which may still work as an assembler directive.  However, it is more common now simply to use, "movf  x, W"

There ya go, I got it wrong. I think that illustrates my point that it's not easy to understand and use. I've written a lot of assembly language on a lot of different ISAs and PIC is just nuts. THe subtraction seems backwards too. I mean .. I can accomplish anything I need to using any set of primitives (assuming they are Turing complete), but some primitives are just a lot more convenient than others. 

It's not clear to me what you are trying to show in the second example.  If you subtract y from x and y is > x, then STATUS  C is cleared (i.e., "borrow"), but if they are equal, then Carry is not cleared.  The enhanced mid-range and later have a couple of new instructions (subwfb and addwfc) that can be useful when doing math rather than comparisons as they take care of checking Carry and  automatically increment or decrement appropriately.

The difference is whether you want to do the goto on equal or not.

If you want to do the goto on <= or >= then you need to NOT do the skip on = so you need to do the skip on C clear since = sets C. Then you need to do the subtract in the order which sets C i.e. gives a positive result when the operands are such that you want to do the goto (and not the skip).

If you want to do the goto on < or > comparisons then you need to do the skip on C set since = sets C and you want to skip on =. So you need to reverse the order of the subtraction. Either that or use two skips (one on Z then one on C) and two GOTO. But that's extra code size.

Perhaps people working with low end PIC a lot have a set of macros to make this easier to get right, I don't know. GOTO{EQ,NE,LT,LE,GT,GE,LO,LS,HS,HI} x,y,z That could cut out a lot of error.

[westfw]

For some reason, many people try to use PICs which are 20-year old. This is really really bad idea.

Because they still sell then and they are cheaper maybe?

Hobbyists get stuck using processors specified in the projects published in books and magazines, back when those were "current" processors (and pretty much all that was available.) (You can occasionally find people trying to find PIC16C84 processors, not even realizing that the PIC12F84 is pin and code compatible.)

If you're used to AVR assembly language then be prepared for a shock.

Yeah, I was going to say that.
The 8bit bit PIC processors are essentially "Accumulator/Memory" architecture.   That means that most "normal" math operations require that you move one operand into the "Work register" ("W"), do an operation between W and a memory location, and move the result back to memory.  Then you add the fact that the "memory" you can access on those instructions can only be accessed in relatively small "banks", and accessing more memory means doing some sort of bank switching.  Oh, and code memory is banked as well.  And no stack.

On the bright side, a bunch of "less normal" operations that are useful in many embedded scenarios can operate directly on "memory", and the peripherals are memory-mapped.  So you can set and clear bits in peripherals (like IO pins) with a single instruction, without going through W.  (if the right bank is selected.)

So it's sort-of opposite to an ARM.  On an ARM, you can do lots of math directly between registers, and you have lots of registers.  But setting a port PIN is going to take at least three ARM instructions and probably an additional 32bits of program memory space.  On the PIC, the math will involve a lot more moving of operands into and out of the W register, but you can set those port pins in one instruction (as long as pin and port are constants.)

Also beware that CPUs vary somewhat significantly.  Size of memory banks and "call stack", "base", "midrange", "enhanced midrange" instruction sets, etc.  PIC18 is more obviously enhanced (and I think more consistent.)

PIC24/PIC30/PIC33 and PIC32 are completely different architectures, and so would need to be discussed separately.

[jpanhalt]

Perhaps people working with low end PIC a lot have a set of macros to make this easier to get right, I don't know. GOTO{EQ,NE,LT,LE,GT,GE,LO,LS,HS,HI} x,y,z That could cut out a lot of error.

Here's a link to a "quick chart". 

http://ww1.microchip.com/downloads/en/devicedoc/30400g.pdf

On page 5 are pseudo-instructions, e.g, sknz = skip not zero, which many coders use.  I don't as they simply act as macros and don't same space.

[NorthGuy]

No, because the values you are working with will almost always be in registers already, either because you were just using them earlier in the function, or because they were passed to the function as arguments (in registers). Dealing with values from RAM is very much the exceptional case, not the common one

Quite opposite. Memory operations dominate. For example signal processing, such as FIR, FFT, convolutions etc. These operations are performed on arrays stored in memory. Parsing is very common - UART, ethernet frames, or whatnot. Dealing with hardware registers. Simple graphics. The list goes on and on ...

Load/store architecture simplifies CPU design, reduces the transistor count, and hence power consumption per MHz, perhaps simplifies writing compilers. All this comes at a cost - the number of instructions you need to execute to accomplish something increases because memory access becomes costly.

It is conceivable that load/store architectures could have been beneficial in high end out-of-order CPUs, but in practice we see the opposite - Windows on most advanced Arm processors, Apple's M1 and M2 - they all are way behind Intel CPUs in terms of performance.

[IconicPCB]

Thank You all for Your comments.

The processor in question is likely to be an 18F1220 part.
I am still waiting on the nod to grapple with the new material.

[NorthGuy]

The processor in question is likely to be an 18F1220 part.

Really? One of the first PIC18F. Released in 2002. 20 years old.