what's wrong with a pic ?

It's certainly not the democratisation for me - there are plenty of good 8 bitters in that category. For me its two things principally.

1. Fixed size inaccessible hardware stack - a really serious limitation IMHO.
2. The really weird names for various elements of the architecture (for which perfectly good already well known names already exist) e.g. register files, working register.

There are plenty of good, just as cheap, just as easy to use but much better (from the point of view of learning about 'normal' micros) devices out there. And they all have good/free support tools.

Ian

In my case - my dislike comes largely from its unfriendliness towards high-level languages, but that's because I used to work on a codebase that had to run on everything from PIC18 up to 64-bit RISCS. Yes, you can make a PIC18 behave like a "normal" micro; but no, it's not elegant.

I was also somewhat disgruntled by Microchip's attitude to development tools - their development software and hardware was buggy through most of my exposure to PICs and their attitude seemed to be to "release early; release often" rather than actually thinking about the problems and fixing things properly.

If you think of the PIC as a bunch of peripherals and I/O lines glued together with just enough logic to make it programmable in assembly-language or very simple C, it's fine.

If you think of it as a microcontroller like any other, you'll be profoundly disappointed by anything up to the PIC17 and puzzled by that and the 18.

PIC30 and PIC24 have what it takes from a packaging and features point of view; unfortunately they're too expensive and too late. I first saw the dsPIC (Roadrunner, back then) architecture back in

2000 and if a decent $2-$3 part had existed then, Microchip could've eaten into a lot of the market that's been taken up by ARM licensees. As it is, they've missed the boat, I think, and are backed further and further into their niche markets.

pete

--
pete@fenelon.com "That is enigmatic. That is textbook enigmatic..." - Dr Who
                 "There's no room for enigmas in built-up areas." - N Blackwell

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.

I use them, but don't like them much for the same reasons as the other people have stated. The new 16 bit ones (dsPIC and PIC24) are OK, they have a decent architecture which supports high-level languages well. Their only real drawback is the power consumption.

Leon

i think the answer is obvious. some computer keyboard devices are implemented in pics. and, in such applications, there is a well known bug that changes upper case key input to lower case. your post seems to be victim to that bug. as you can see, my keyboard is broken too. that damn pic!

why would anybody want to use a device that does that?

jjs

I evaluated the PIC family for a small project, several years ago. The stack "idiotsyncrasies" did it for me. I am aware that newer devices are coming out all the time, and that their features and architecture are slowly evolving, but the initial "bad-taste" left by that encounter has put the PICs at the bottom of my list.

Nothing wrong with pics, if you use them in the way and for the jobs they were designed for. Most problems seem to stem from people insisting on programming in C for which they are not well suited, especially the earlier ones. The other problem is the inability of engineers to use different processor families for different jobs, they would rather struggle with the one they used "last time" and complain about how bad it is.

I am no defender of PIC architecture and was put off by other factors when the first parts were introduced many moons ago but I feel the need to address the prevailing opinion about the 'strangeness' of various architectural features expressed by many here. It reminds me of Kirk and Spock's reaction in the episode "A Piece of the Action" to encountering a 'flivver' that they intend to drive and how very odd to them is the concept of an internal combustion engine, geared transmission, control linkages and pedals. The concepts of a fixed size hardware stack inaccessible to the program, separate 'register file' scratchpad memory area, table lookups by performing jumps and retrieving literals, harvard architecture separations and so on were a familiar part of many mainframe, minicomputer and several generations of micro architecture and surely are not strange or bizarre from a historical perspective (maybe wrongheaded in some instances). The introduction in microcomputer architecture of a general purpose register file in the main memory space was novel and promoted as such by the likes of the TI 9900 for example. Most of the PIC features mentioned could possibly be justified by design decisions involving gate count, power consumption or in some cases code entropy and are possibly reflective of design constraints set forth many many years ago. One can disparage the elderliness of a design but that does not make it bizarre.

I respectfully suggest that published descriptions of the validity of technology would benefit from the widest possible historical perspective so that a reader could form an opinion informed by the consequences of past design decisions lest we fall prey to repeating or ignoring for our benefit the lessons of history.

Michael Grigoni Cybertheque Museum

I've also seen plenty of cases where the processor choice is imposed upon the engineer by management or the customer.

I remember one case where the customer's technical people completely agreed that a different processor would be better, faster, cheaper and easier to design in. But, the customer's procurement people had standardized on a slower, more expensive, _extremely_ difficult to use processor. So we used the slow, expensive, crappy one. And complained a lot about how bad it was.

--
Grant Edwards                   grante             Yow!  I have a TINY BOWL in
                                  at               my HEAD
                               visi.com

I am very new to PICs. I have been using Atmel uCs for all my project. For my current project I was considering dsPIC. But after reading all the post, I am a bit hesitant. Is dsPIC also bad like its 8-bitters? Actually my current project involves some signal processing, thats why I am considering dsPIC. Any guidance?

I am commiting a mistake considering dsPIC? Is there any other good DSP uC?

regards

--Himanshu

I like PICs very much, main reasons:

- the availability, also in small quantities is very good

- a released component will be available for many, many years

- and last but not least, I've people in my surrounding using them

all the reported negative arguments (limited stack, banking, paging) don't yield for me,... ... simply because I use a good HLL ;-)

Stef Mientki

Precisely and that is very limited. In 25 years developing microcontroller high volume products we used a PIC once and I strongly suspect they bought into that design.

I don't think so. Some problems do but most problems stem from the limitations of the architecture and the bugginess of the tools. It is only recently that HLL compilers have become commonplace for small 8 bit micros.

Rubbish. We always chose the best processor for the job no matter what it was. Learning a new assembly language was just part of the job, the same as learning a new register set of peripheral set.

Ian

There are other good processors for doing DSP. Depending on the speed you need you could look at:

• 'real' DSP processors, with the dsPIC clinging to the bottom of the set. This group is separated into 'fixed point' and 'floating point'. Examples of fixed point DSP chips would be the dsPIC, the Freescale

56xxx, the TI DSPs, Analog Devices 21xx (which seem to be getting phased out), and the Analog Devices Blackfin series.

• ARM, or other 32-bit RISC processors. The ARMs are getting really cheap these days and the core at least is second sourced which is way more than you can say for any dedicated DSP chip. For some DSP tasks a

32-bit RISC machine will be just as good as any of the 'real' DSP chips, and way better at the 'regular software' tasks that you always seem to need to tack onto your DSP application.

• Just a plain old processor. If your signals go by slowly enough sometimes you don't need a DSP at all -- sometimes you can do just fine with a regular processor with a good fast multiply instruction (which is kind of what the ARM is).

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

dsPIC is very different to earlier PICs. It's almost a new micro with some PIC compatibility bolted on as a sop to backwards compatibility, and having spoken with some of the architects I think that's how they want people who aren't already locked into Microchip to think about it. Yes, it's still Harvard, but it's relatively painless Harvard (you can map a page of code space into data space so you can actually have "constants in ROM" without hacks like TBLRD or RETLW), it's got a decent set of general-purpose registers, and some pretty good addressing modes.

The GCC code generator for the PIC30 is clean and relatively 'vanilla' - there's nothing particularly awkward once you get your head round the limitations enforced by Harvardness.

PIC24 is essentially dsPIC (PIC30) without the DSP functionality; from what I recall, the DSP stuff is effectively almost disjoint from the rest of the chip, operating on different clock phases and exchanging data through a subset of the W registers, so it's relatively easy to factor into or out of the design.

ADI Blackfins are *very* cheap....

pete

--
pete@fenelon.com "That is enigmatic. That is textbook enigmatic..." - Dr Who
                 "There's no room for enigmas in built-up areas." - N Blackwell

I,ve been around since the 8080 so I've seen quite a few microprocessors and microcontrollers. While it is true that the architecture of some early types carried across many concepts from mainframes and minicomputers, those that were inappropriate to embedded applications got dropped - the1802 for example had no return instruction.

The PIC was a relatively late comer on the scene and I think its biggest mistake was to re-introduce some of the these old concepts and terminology

- basically its architecture is a retrograde step IMHO.

Ian

Although (Arizona) Microchip is a new-ish company (just past its 20th birthday, IIRC), the PIC architecture is a relatively straightforward development of a design that started off at Signetics and migrated to General Insturments... I think the architecture of the smaller PICs is well into its 30s now!

pete

--
pete@fenelon.com "That is enigmatic. That is textbook enigmatic..." - Dr Who
                 "There's no room for enigmas in built-up areas." - N Blackwell

The context of this section of the book is to describe to "newbies" what to choose, and why to choose it, in the modern era. Historical information is very nice but these oddities are out of place in the modern age.

What would you say if Ford announced a new 2008 8-cylinder "Retrostar", with a carburetor, four-wheel drum brakes, and points ignition?

And that's if you don't count the resemblance to a PDP-8, which would put it into the 40's.

What type of applications do you work on? I like PICs for some things, but prefer other microcontrollers for others. It would certainly add perspective to the discussion if you said what you have tried to do with them and where they fell short.