Re: what's wrong with a pic ?


purple_stars wrote:

i keep hearing, "i hate the pics", everytime i turn around. someone is

From my latest book:

So, what oddities does PIC exhibit, you ask? There's quite a list. To
begin with, most of the "8-bit" PIC variants, including this one,
actually have a 14-bit instruction word. (There are several 8-bit cores
available; a 12-bit-word core, a 14-bit-word core, and two 16-bit-word
cores, the PIC17 and PIC18 series. The idiosyncrasies are different
amongst these families). Microchip always quotes their code size in
words, so a 1K 14-bit PIC is actually 1.75 kilobytes of actual flash
space. This isn't really a big deal unless you're trying to parse the
raw HEX file, but it is slightly unusual and can lead to confusion,
particularly because a lot of documentation (mostly from third parties)
is horrifically sloppy about "bytes" vs. "words", to the point
where you often can't tell what they are talking about.

There are a couple of immediate limitations we can get out of the way
now: This PIC variant has only one 8-bit general-purpose register,
referred to as W (the Working register). Every byte of data you will
ever process on the micro has to be funneled through this register.
Also, the instruction set doesn't, strictly speaking, have any
conditional jump instructions; it only has "skip next instruction if
condition" instructions. While not exactly unprecedented - the AVR
family has these instructions too, for example - this is a
significant source of bugs from programmers who are not experienced
with this style of programming, because the logic is backwards from the
way most people are accustomed to think of binary decisions.

The PIC is a blindingly Harvard-architecture microcontroller, with four
distinct address spaces: program memory, data memory and peripheral
registers (Microchip refers to the on-chip RAM as the "register
file", implying that it's really just a special case of on-chip
registers), EEPROM and stack.

[...]

Implementing lookup tables in code memory is also significantly unusual
in this family of microcontrollers. There is no instruction or
addressing mode that permits you to read data directly out of code
memory. Instead, the PIC16F84A offers an alternative version of the
RETURN [from subroutine] instruction called RETLW (Return and Load W).
This single-word instruction loads an 8-bit literal into the W register
and returns to the caller. Any data table you need to have in ROM is
thus actually a long string of RETLW instructions. In order to access
the table, you have to calculate and load PCLATH, then calculate the
low-order 8 bits of the address of the desired entry, and write this
into PCL to perform a long jump into the data table. This is quite
bizarre, not to mention terribly inefficient.

Next on the list of unusual behaviors, we come to the PIC's stack. I
have almost nothing good to say about this system. In pretty nearly
every other microprocessor architecture you will ever encounter, the
stack pointer, if any, is a register that through some mechanism or
other (occasionally quite convoluted), points into the device's general
scratch RAM area. Often there are special rules about where the stack
can reside and how large it can grow, usually caused by limits on the
number of bits available for the pointer register, but nevertheless the
actual data on the stack almost always reside in normal data memory.

The PIC16F84 is completely different from the norm - it has an
8-level x 13-bit hardware stack (13 bits are necessary because this is
the size of the program counter), and the stack pointer is completely
inaccessible to your code. All you can do is push and pop data using
call and return instructions - interrupts also use the stack, of
course. Since there is no exception thrown or flag set if you try to
grow the stack below the hardware limit (it simply wraps around from
location 8 to location 1), and there is no way to read the current
stack pointer in software, it is impossible for your code to avoid,
detect or trap stack overflow problems. The one "advantage" of this
highly unusual system, if I can call it such, is that it is impossible
for a runaway stack to blow away your data or program space, but this
is something of a moot point if your program jumps off into hyperspace
as a result of trying to pop a bogus return address.

While the larger PICs aren't quite as bizarre as the small parts, there
is nevertheless a pervading feeling, even in the larger parts, that
you're working on a really tiny micro that has had big RAM and flash
grafted onto it through horrific quasi-Frankensteinian operations. I
can't help but think that somewhere in Microchip's design labs is an
engineer who spent a few days too many packing ten-pound loads of
product into five-pound bags, and went a little insane as a result.
While it is perfectly possible to implement robust applications on a
PIC, it's sufficiently annoying that I would greatly prefer to work on
a different core unless there are significant factors (price, algorithm
licensing, application-specific suitability or something else) that
pull me towards a specific PIC device.

As I'm griping about the parts, let me raise another complaint -
Relatively few of the PIC family have an on-chip debugging interface.
(Some of the very recent parts do have JTAG, and other parts support a
sort of bond-out debugging feature using the MPLAB ICD 2 in-circuit
debug module). This means that usually the only available methods for
code development are burn-and-pray or the purchase of a full in-circuit
emulator. This might not be a huge burden to the home hobbyist (except
for the expense of a full ICE), but it can be very irksome to use these
parts in commercial applications where development time is money. Some
applications - particularly radio devices, which is where I work at
the moment - are very difficult to debug when you have to attach an
enormous emulator spewing RF interference. JTAG is bad enough, but it's
easier to mitigate this noise somewhat. Your ICE, on the other hand,
needs to be physically close to the board to avoid undesirable
parasitic effects from long cables stretched from the ICE into the
location where the microcontroller should be.

.

Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... represented in the stack itself on systems that have a TOS register separate ... system's memory has a "tag" field associated with it. ... in the instruction and pushes it onto TOS; ... increments within the current code segment. ...
    (comp.lang.cobol)
  • Re: Calculating checksums...
    ... - it's a word memory reference using a register address ... lods - it's the lods instruction ... parens are a memory reference. ... programming and why, with the end of the 68k, teaching assembly ...
    (alt.lang.asm)
  • Re: Writing an Emulator
    ... > next instruction to be executed), ... Most modern computers have "registers" and "memory." ... Computer A has one 1-bit instruction register, ... Let opcode '0' be HALT. ...
    (comp.lang.c)
  • Re: Writing an Emulator
    ... > next instruction to be executed), ... Most modern computers have "registers" and "memory." ... Computer A has one 1-bit instruction register, ... Let opcode '0' be HALT. ...
    (comp.programming)
  • Re: Designing my own architecture to be simulated in software - need help with the ISA
    ... > memory address range is limited to 16 bits. ... > I'm reserving the HO byte of the word for the instruction type, ... The register operands are half-bytes in length, ... > sub - store the difference of two registers in a register ...
    (comp.arch)
Loading