Talk:PIC microcontrollers/Archive 1 Source: en.wikipedia.org/wiki/Talk:PIC_microcontrollers/Archive_1

This is an archive of past discussions about PIC microcontrollers. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

These architectures bear little resemblance to the 8 bit microcontrollers. I suggest that they be moved to their own article. Choppingmall 22:35, 24 January 2007 (UTC)

I've searched the net and manufacturer's site ([1]) to try to verify or find an objective list of "common" PICs (sales figures or shipped units would be great, for example) but no luck. I'm not seeing the encyclopedic value in this list if it can simply become a list of "hey, I use this chip". Thoughts? --Ds13 19:36, 2005 Feb 28 (UTC)

I think it would be useful as a benchmark for their power and cost-effectiveness... as long as the product is well known. Example: I'm adding the ipod remote (disclaimer - it goes to my website, but I think it's useful and appropriate (plus already highly ranked by google)). Other peoples' thoughts? --Morcheeba 26 Feb 2005

I know that the 16C55 and 16C54 are or were very widely used, mainly because they were some of the first ones to be sold. The 18F452 is a great chip for hobbyist projects, since it has a lot of capabilities while still being easy to use. I'd say it's one of the best microcontrollers you can find that still comes in a DIP package for easy soldering. But commercial products will usually use something cheaper. As for the 18F4550, if you want a low-end controller that supports USB in a commercial product, you'll probably want more power than a PIC18 can provide, so you're more likely to go with something like Atmel's ARM7 offerings (in my opinion). But for a hobbyist it's wonderful. I guess the main thing that needs to be figured out is if "commonly used" means used in commercial products or for hobbyist use, or both. I suspect that there isn't a lot of overlap there, especially because a hobbyist will usually use chips with lots of peripherals that are more powerful than what he needs for a particular project, while a business will usually use the cheapest PIC that will get the job done. -- DImfeld 08:20, 8 June 2006 (UTC)

Well microchip have chips with larger memory (both program and data) and higher permitted clock speed (the USB pics are rated at 48 so you can run the core off the same clock signal as the usb though this may not be a design change but simply a different test procedure) in the 40 pin dil package. Afaict the reason the 452 is well known is that it was the biggest (in terms of memory and pin count) of the early 18 series pics and therefore made it into all the books etc.

As for your commercial comment i think it depends on the volume, if you are making tens of thousands of one product then sure your going to shave off every last penny, though you may leave it to quite late to decide on the exact chip to use in the final product and use chips with more memory for development. If your making custom control equipment of which there will only be a few hundred at most sold then i doubt you will. Plugwash 20:20, 9 June 2006 (UTC)

Actually, the 16F84 is much more popular than the 18 series. The above citation is incorrect. —Preceding unsigned comment added by 68.4.70.65 (talk • contribs)

What citation are you referring to? That's half the problem here -- no citations, just opinions. Each person sees and uses a subset of the PIC family and might be inclined to believe their favorite chip is common or popular. I'm still inclined to remove this section because, while it's well-intentioned, it's not verifiable. Verifiability is job #1. --Ds13 06:47, 11 November 2006 (UTC)

Sorry, i didn't mean to say that the 18F452 is better known than the 16{C|F}84 What i meant to say was that of the 18 series PICs it seems to be by far the best known. A quick google test is quite interesting here (note the results are googles "of about" figures, i'm not going to try and find the last page just to see how many there really are) if we go through the pics listed in the article.

PIC12C508 -- 60,900

PIC12C509 -- 31,800 (borderline)

PIC12F629 -- 62,900

PIC16C84 -- 69,900 (not in the list atm but imo should be)

PIC16F84 -- 372,000

PIC16F628 -- 91,500

PIC16F88 -- 38,400 (borderline)

Next is an entry for the 87x family, which should probablly be either removed or merged with the entry below

PIC16F877 -- 176,000

PIC18F452 -- 76,000

PIC18F4550 -- 39,200 (borderline)

Comparing theese with say the 18F442 or the 18F4455 shows a stark difference in number of results, so it is pretty clear that some particular models (generally the higher powered ones from each series) are favoured at least by those who post thier designs on the internet. Plugwash 17:01, 12 November 2006 (UTC)

I wholy disagree with the asertion that there is a lot of support on the Internet for PIC chips freely available on the Internet because of their uses in hacking copy protection systems. I think that more important reasons start with the massive level of support that Arizona Microchip provided to the Electronics Hobbyist sector in the use of their devices. Further, the repeated articles and designs using them in projects in practical electronics magaizines (EPE, ETI, Etc.) Finally, the devices' inate advantages, high level of integration and ease of programming make these brilliant devices for small projects. All of these factors not only out weigh but predate the devices' use in cracking copy protection systems. Does anyone have any proof of the PIC support communities originating from the wish to crack copy protection systems? Particularly 194.178.209.84 --talkie_tim 09:32, 20 January 2006 (UTC)

I agree with Talkie tim. I also think that the real appeal of the PIC is that it's a great platform. It's cheap, easy to use, and doesn't require a bunch of support circuitry to do anything: the perfect tinkerer's chip. (So as not to inadvertantly start a flame war, I should mention that AVR micros provide all these same benefits). I don't know if it was the cracking efforts that brought PICs into the public eye, but I can certainly say that there are many better reasons for their huge popularity among hobbyists. -- DImfeld 08:20, 8 June 2006 (UTC)

I second that agreement. I started using Microchip PIC chips to automate environmental monitoring sensors in a big way at my university lab in Hong Kong in the mid-1990's. PICs were widely used a long, long time before there was any such thing as copy protection in consumer electronics. There are a number of competing families of microcontrollers around these days and my colleagues who use them swear by them. Microchip is still a major player in the game, though, and stays that way largely by having so many third party compilers and IDE's out there that support them. Plaasjaapie 04:49, 18 March 2007 (UTC)

yeah the minimal support circuitry is a very good thing, you need about 4 caps and a crystal to get it running (even less if you use one with an internal oscilator). The pic is also a CHEAP platform to get started with: the IDE is free (as in beer), the assembler is free, a cut down version of the C compiler is free. Basic programmers can be built extremely cheaply and microchip sell one themselves with a basic demo board for less than £30. The pics themselves can be had in small quantities for free and aren't too expensive to buy. Plugwash 14:03, 9 June 2006 (UTC)

During several automated bot runs the following external link was found to be unavailable. Please check if the link is in fact down and fix or remove it in that case!

• http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1003&mid=10&lang=en&pageId=74
  • In PIC microcontroller on Mon Jul 17 14:24:55 2006, Socket Error: (-2, 'Name or service not known')
  • In PIC microcontroller on Thu Jul 27 00:28:43 2006, Socket Error: (-2, 'Name or service not known')

---

maru (talk) contribs 04:29, 27 July 2006 (UTC)

I removed the whole section of links to the Microchip website. All those links just clutters up the article. Choppingmall 13:34, 12 January 2007 (UTC)

The article incorrectly stated PIC was not an official acronym. I corrected that. PIC stands for "Peripheral Interface Controller". —Preceding unsigned comment added by 68.4.70.65 (talk • contribs)

do you have a reputable source for that assertion? Plugwash 15:06, 16 November 2006 (UTC)

1977 spec sheet mentions Programmable Intelligent Computer for PIC: http://www.rhoent.com/pic16xx.pdf. /Mat-C 12:06, 23 Jan 2005 (UTC)

My 1976 MOS Data Book calls both the PIC1640 and PIC1650 "Programmable Interface Controller". I'd say 1976 beats 1977 for determining "initial meaning." I can post a scan. --Mr z 07:04, 4 December 2007 (UTC)

Also, the databook says specifically: "The Programmable Interface Controller family (PIC1640/1650 and all extensions)..." It seems rather likely by the capitalization that PIC in the part number refers back to the phrase "Programmable Interface Controller." I've put photos (since I can't get my scanner working right now) on my webserver. --Mr z 07:20, 4 December 2007 (UTC)

I'll include a link to a proper scan from the 1976 Databook in the reference if it's necessary. Otherwise, you can verify the specific detail by looking at my (unfortunately blurry) photographs above. Based on this older databook and a presentation I found at Microchip, though, I've edited the text to indicate that PIC1640 started off the family, not PIC1650, and that the initial, short lived name for the family was "Programmable Interface Controller." --Mr z 07:41, 4 December 2007 (UTC)

With respect to the citation needed for the fact that Microchip Technology does not refer to PIC as an acronym -- it is extremely difficult to prove a negative. Even harder, perhaps, to cite it. Would the following glossary of terms from Microchip's website do it justice? They define PICmicro, but make no mention of any acronym. I wouldn't feel comfortable placing that page as a citation, but perhaps we can remove the "Citation Needed" flag; I'd be surprised if a good source exists. Matt B. 02:12, 7 March 2007 (UTC)

I checked out the external links section on this article and found that many of the links do not meet WP:EL guidelines. Lots of commercial sites, excessive advertising (finanical COI), personal sites (NPOV), etc. In order to cleanup the current warning, I am going ahead and removing many of these links and placing a warning on the EL section to discuss the addition of any new links here. Hopefully that will keep this article a little cleaner and discourage any link spamming. If I've removed any links that you feel are in compliance with WP guidelines, please leave a comment here and if others here agree, we'll add them back. If you placed the links here originally, please don't take my edits personally. Just trying to clean things up. Thanks! Calltech 21:56, 18 December 2006 (UTC)

PIC programmers (Development Tools) section is becoming simply a magnet for links to commercial and personal websites. WP is not a directory of links WP:NOT. See links to avoid WP:EL. Adding dmoz entry to replace these links. Add sites to dmoz directory rather than here. Calltech 12:02, 28 December 2006 (UTC)

I doubt the MIT email list for PIC microcontrollers could be considered a spam link so I just added it. Delete it if you feel that was not appropriate.

I shall start with the Criticisms section today:

I also notice that the PIC 18 article is a mirror of the main PIC article. Many of the shortcomings of the earlier series simply do not apply to the 18 series and should not appear on the 18 page..!

Criticisms

The PIC architecture has been criticised on many important points.

(Weasel word -- criticized by who? when? where?)

   * The few instructions, limited addressing modes, code obfuscations due to the "skip" instruction and accumulator register passing makes it difficult to program in assembly language, and resulting code difficult to comprehend.

(Above: It's a reduced instruction set computer chip! It's supposed to have few instructions. And the "skip" method is in some ways better then the branch-if-equal style because you can not only have conditional branches, but any other opcode can also be conditional! It's a feature with a benefit -- why bash it? )

   * The PIC architecture has historically been unfriendly to high level language compilation, although these issues have been addressed in the 18 and subsequent series.

(This line should not show up on the PIC 18 specific page.)

         o Stack implementation (for parameters and locals) has been dreadfully inefficient.

(Again -- it's a reduced instruction set computer chip! It's for when you need to do little things. If you need a bigger chip, use a bigger chip..!(And no reference..!))

         o Lack of indexed addressing.

(No references -- and even the lowly 18C84, my first ever PIC, had the FSR which was sort of like indexed addressing, and besides the 18 series have 3 FSRs with auto PreDec, PostDec, PreInc, and PostDec -- which make copying memory blocks or running fifos just as painless in Assembly as in C. What's the point here?)

         o Most PIC C compilers do not generate re-entrant code.

(Reference? is this someone's original unnamed research? who tried most C compilers and determined this?)

   * The call stack is so small that program structure must be flattened.

(It's a tiny micro! Why does this need to be here? And it's not even true of all PIC series..)

   * The call stack is not addressable, so interruptible task switching cannot be implemented.

(Reference? I don't know for sure since I've never done it, but I'm sure I've seen websites over the years of people who are doing some fancy RTOS multitasking scheme with PICs. Are you sure that interruptable task switching cannot be done on any PIC series?)

   * Writing non-trivial interrupt handlers is very difficult because processor state and used registers must be explicitly saved.

(References? Besides, the processor state is super east to save. You do it once on entry to ISR, and restore it just before return. How do you define non-trivial? I've done multiple fifos, Rs232 drivers, realtime clock routine, and many many other stuff all at once in the same ISR in assembly for a 18F252 and I did not find it very difficult -- not even difficult. See my project and read me code, flowcharts, and the whole bit at http://bookcracker.com/projects/ -- my very first 16C84 project is there as well. It has a bitbanged 1200 baud RS232 driver as well as two motor controllers all controlled in the ISR.)

   * Data stored in program memory is space inefficient and/or time consuming to access.

(Reference? It is true that the PICs with program words of a length other then an even multiple of 8 may not have allowed the user to store data in the bits in the fractional upper byte. But this simply does not apply to the 18 series and many others. A more current project of mine was an 18F4420 which controlled the 6 windings in 3 stepper motors microstepping each one of them, and sending them PWM at 20Khz! I used two 256 byte long lookup tables in program memory -- one for sine and one for cosine (Had plenty of free space and was feeling lazy that day.) -- there are NO wasted bytes in my lookup table, and they sure seem fast enough for me.)

---

So why is there even a criticisms section? What is to be gained...?

A bunch of incorrect or misleading stuff, zero references, and the most absurd idea that the PIC is somehow trying to compete with an arm32 or something.....!

Many thanks,

-Jesse —The preceding unsigned comment was added by 64.146.180.232 (talk) 03:58, 26 January 2007 (UTC).

I would think the section does have function: it does give a rather correct image of what kind of issues one has to deal with these devices. I don't see the arcticle as bashing PICs at the expense of other microcontrollers; rather having implicit justified comparision to modern highend processors. Although wording might be a bit better; don't see term 'criticisms' used on arcticles about other (RISC) processors. lav 18:11, 26 January 2007 (UTC)

But is it helpful or even honest to list a limitation specific to a 16F part as a general critisism on the page for all PIC series? Does it not falsely lead the reader to believe that "All PICs have this limitation?" Can you show that a single item in the Criticisms section is helpful and why? Let's talk about that one.

You say that it gives a rather correct image. What is correct about saying:

• Writing non-trivial interrupt handlers is very difficult because processor state and used registers must be explicitly saved.?

I have written many highly non-trivial interrupt handlers, in both C and assembly for the PIC, in several 16 and 18F series parts and even a 12F part. I found nothing difficult about it. Maybe your idea of "very difficult" is different than mine, but now we're discussing opinions. Is WP a place for people's opinions to be listed off without reference?

Thus I would counter that a statement that is not true does not (in this case anyway) serve any useful purpose.

And the criticism about the 'Skip Next Instruction' should be a feature that reads like "Has powerful 'Skip Next Instruction' branching method which, while challanging to code in assembly, provides a powerful conditional branching support because any opcode can be conditional as well as regular branches, increasing code speed and size efficiency."

There are many times in assembly coding where you only need to conditionally execute a single instruction -- and it is real handy to be able to conditionally skip next instruction without having to branch someplace and then return from there just to skip a single instruction...!

And I just don't understand the criticisms along the lines of "It too few instructions, too small of a stack, etc., etc.." -- it is not a high-end micro!

You say "rather having implicit justified comparision to modern highend processors." But why compare it to high-end processors? It's not a high-end processor. It does not compete with high-end processors. A PIC is one thing: A PIC. And there are a million things it is not. A dog, a tree, a car, and a high-end processor it is not. Why compare it to a high end processor any more then a dog, a tree, or a car? Conversely, one would not expect "Draws too much power to run for any length of time on a watch battery to be of any use" to be found in the Pentium4 CPU article. The P4 isn't made to run for a year on a watch battery. A PIC is.

And in who's mind is the comparision justified? Not mine.

And to refer to the "Skip next instruction" method as "code obfuscations" is also wrong: It is a powerful feature. Sometimes powerful tools are more complicated to use. The word "Obfuscation" is generally used to imply that something has been intentionally made cryptic to make it harder to understand.

When the only part of a feature that is mentioned is the fact that it is more complex to use and described using a word which means "Intentionally made hard to understand" one must suspect slantism.

Is the 'criticisms' section someone's pet project who will be offended to changes thereto? I mean, if it's someone's personal webpage, fine, I'll leave it alone. I wouldn't want someone messing with my personal webpage either. But if it's supposed to be helpful accurate information, then really it should be both accurate and to the point.

And yet, somebody insists on displaying information without any reference to show that it's accurate, nor that it's to the point -- and I'm telling you that I've worked with PICs enough to know a little about them and nothing in the criticisms section is accurate or to the point. (Think I'm wrong on that point? Pick one! pick one line, any line, from the Criticisms section, and explain how it's both to the point as well as accurate!)

Another reason these comparisons are useless is because they don't show what they are comparing to. For example, I'm sure some pics are far more powerful the some other micros. And some other micros are more powerful then some pics. But just to say that the stack is inefficient without saying compared to what serves no purpose! And especially since different PIC chips have different stack sizes, some very small and some very large, how is it not slanted to just complain about the limitations on the most limited versions, as if all series of PICs had the same limitations?

By the way, PIC's don't support 32bit DMA transfers to SD ram either. And connecting up a little 6 pin PIC chip to 168pin SDRAM chip is just about impossible! those PICs aren't good for anything. (They don't support MMX, either. Who could work with a micro that doesn't support MMX anyway!)

(I did actually once implement an simplified ISA bus (electrical only) with a 44pin PIC chip so I could use an ISA modem with it..!)

I propose that somebody besides me remove the portions of the criticisms section that don't have references or for which a logical case cannot be made regarding the pertinence. (Or if others think it's a good idea I'll be glad to as well.)

Am I the only one that sees a problem here? To me, my logic seems fine. Does it not seem fine to someone else? How so? (i.e. which specific part in particular?)

Thanks very much,

-Jesse

Well... I removed some days ago the claim that PICs lack MMX! This is indeed nonsense. IMO, the "critism" section should be removed, and we should give a clear description of what a PIC is (a microcontroller designed to run with as few peripheral as possible) at the beginning of the article. As it is at the moment, the article gives a lot of technical details in no real order (for example an internal diagram would be helpful to understand the architecture or the controller), but does not give a general idea of the uses of a PIC. Furthermore, such "general" section would remove the need for a critism section, as the latter only exists to compare the PIC with a high-end processor.

In the whole list, I think the only critism that makes sense is the use of internal program memory for data use, which can actually be a limitation in some cases (using an external memory is slower as you have to manage it yourself).

Also, the article beginning gives the impression that PICs are mainly used to crack playstations. While I know this is an application, I used quite a lot of PICs in various projects, none of them involved any cracking, and I belive I'm not the only one. And I don't think microchip sold 5 billion devices to crackers. Maybe this claim should be moved to the body of the article? CyrilB 12:03, 27 January 2007 (UTC)

Well, I'm sorry. I was the one who added the line about MMX because the whole critisisms section seemed to be copmaring the PIC with the type of CPU that does have MMX. I also agree with you on the point of PICs being used to crack playstations -- I've done several PIC projects on my own as well as quite a few for the company I work for and have never done anything involved with cracking anything with pics or any other micro. They are used in industry for lots of stuff (and often when I take apart some electronic gizmo to fix it for a friend, I'll see a PIC micro in it.) There are lots of shady misuses of things. As to using program memory for data being "slow", this is as far as I know a property of all Harvard_architecture micros (Including avrs(http://home.wanadoo.nl/electro1/avr/scroll3.htm)). The Harvard_architecture article nicely describes the difference between Havard and von Neumann. The benefit of Harvard is that since there are seperate data and program busses/memories, both can be read or written to at the same time for great increases in speed. As to accessing program memory being "slow", I have not found that to be the case. Sure, it takes a couple extra instructions to fetch each byte of data from program memory, but they really don't take very long. I guess my point is that there are differences between Harvard and Von Neumann -- but there are lots of micros that are harvard and the PIC page isn't the place to compare Von Neumann and Harvard.

There are also many differences between high-end micros like arm32 and low end micros like PIC and AVR. Both types have their advantages; One is power savings, the other is high performance. Sometimes we need mostly to save power, other times we need mostly to run fast. A great article could be written which compares all the features/performances/costs of all ranges of micros from the cheap 6 pin PIC or AVR all the way up to the Multi-Ghz P4 or whatever -- but the PIC article is not the place.

It's not like someone would be deterred from using a PIC or AVR just because accessing program memory requires a couple extra instructions -- I would say that besides noting up fron that it's a Harvard based micro, any mention of technical details on how to implement the varius hardware (such as reading program memory) should be in a "How-to" section. (And besides, a lot of PIC programmers write in C which makes using program memory for constants transparent. So then it's a non-issue.)

I agree that the whole Critisisms section shuold be removed.

I also think a section along the lines of the following might be useful: (Of course I'm not suggesting this exact wording -- just this general thought!)

"Range of performance:"

PIC Micros range all the way from a tiny sot23-6 pin device that runs at 4Mhz (1mips), has 256 words of program memory and 16 bytes of ram, drawing very low current( <350uA (typ 170uA) @ 2V, 4Mhz, and even less at 32Khz) and selling for about a dollar (PIC10F200T-I/OT), to 80 pin Quad Flat Pack with external memory buss, built in UARTS, PWM, up to 128K bytes of program memory (144K for some dsPIC), several K bytes of data ram, built in EEPROM for data storage (A K or two), running at 40Mhz (64Mhz for some of the DSP series) with watchdog timers, multiple on the fly changable run speeds, dual crystal support, LCD drivers, RF transmitters/receivers (rfPIC series) USB/CAN bus support, self programming, 16 channel 10-BIT AD (12 BIT on some dsPIC)(Insert part number and price of example high-end PIC here) -- this is just an incomplete prototype of what I propose. If someone thinks it's good, I'll go ahead and fill it out and polish it off.

Anyway, I'm sure I missed some noteworthy features, but a statement along the lines of the above would allow someone at a glance to know whether their need was covered by a PIC micro. Any comments? Thanks, -Jesse

---

I am really surprised at the meticulous attacks that the "criticisms" section has generated. My feeling is that the section is both balanced and justified, and that Jesse's submission and critique is mostly misguided. His assertion that there is a lack of source reference is very valid, however almost every statement is a verifiable statement of fact -- although not necessarily applicable across all PIC architectures (but it doesn't claim that).

Too many contributors to the PIC article are advocates, and the "criticisms" section represents a refreshing counterpoint, the net effect of which is to increase the neutrality of the article as a whole, and to present up-front the drawbacks of the PIC architecture.

If there is a slant to the article, I submit the following as major problematic trends which we must guard against:

• An exposition of PIC supposed features -- which are just a rehash of Microchip marketing-speak, but are in fact very controversial claims. For example:
  • claims that it is easy to program because it has such few instructions and/or addressing modes
  • claims that it is faster, has higher code density, etc.
  • claims that it is related to RISC architecture CPUs
• repetitiousnous
• A "promotional" or "advocacy" tone.
• An innapropriate focus on details of dubious relevance, rather than appreciable architectural differences. I would include almost all of Jesse's "Range of Performance" submission above as an example of this. That level of detail is needed by the designer, and is readily available in the databooks. The article also needs regular "weeding" to remove references to PIC18F677 or what-have-you model. There are dozens of models and sub-features, the minutiae of which are not encyclopedic content.
• A tendency to excessively expound and link to related tools, compilers, devices, and projects.
• repetitiousnous

Choppingmall 16:52, 10 February 2007 (UTC)

As to whether my(Jesse's) critique is misguided or whether the criticisms section is balanced and justified, my constant plea has been "If you think I'm wrong, just pick one -- pick any one Criticism section item and explain specifically how it's accurate and justified!" Anybody can very easily say "Oh, Jesse's critique is misguided.." but of course that means absolutely nothing unless at least one point in said critique is demonstrated to be misguided. -Jesse

I have not programmed any of the PIC processors, but I have studied them. I think that the whole criticism section should be eliminated with the relevant criticisms placed in the appropriate sections. For comparison, the x86 architecture does not have a criticism section. If it did, and was treated like the criticism section in this article is, it would look somewhat like this:

• Is not available for as low as 10 cents per unit (in quantities)
• It is necessary to use specific "general purpose" registers for certain operations
• Has a large register set that must be saved on a context switch
• Must have additional support chips to provide even a minimal, working computer system
• Even more support chips must be added to provide analog and digital input/output
• Its clock speed is so high that exceptional care must be used to reduce the induction of errors on the data and address busses.

See what I mean? Every CPU architecture and implementation has its advantages and disadvantages. So you should integrate these pluses and minuses in the appropriate sections. Remove the criticism sections and rewrite the sections appropriately. Val42 05:23, 11 February 2007 (UTC)

Jesse says: Right on, Val42 That's exactly how it would look if whoever wrote the PIC criticisms section had used the same logic when writing a similar section for the x86 page. -Jesse

Uhh.. You have your tongue firmly planted in cheek, right? Because your criticism of the x86 is either vague (the one about general purpose registers), is wrong or out of context (that it has a large register set), or doesn't actually address the CPU architecture (everything else). Why do you even bring up the x86? it doesn't play in the same ballpark as the PIC. Compare the PIC with HC11, AVR, Z80, etc. architectures you will see that the "criticisms" section is very valid and useful information for someone who has to choose between them. It doesn't try to prove a position or say that the CPU is bad because of those qualities -- it just presents pertinent drawbacks to the architecture which anyone planning to use it should know about. By the way, all CPUs architectures are trade-offs, and why shouldn't it be discussed? The articles for all CPUs would benefit from a criticisms section. Choppingmall 21:19, 11 February 2007 (UTC)

Jesse says:Could you provide a single case as to how and why even one of the criticisms is accurate and pertinent? What Val42 and I are saying is that the PIC Criticisms section is wrong or out of context or vague. As to comparing the PIC to the AVR, the PIC Criticisms section doesn't -- it's comparing to CPUs in another realm. For example, it criticizes PICs about program memory access being slow and inefficient. I would wager (having used that method) that neither is true always true. But in any case, that exact same criticism applies to AVR -- they too, being a Harvard architecture, require a couple extra instructions to read program memory. So my plea still stands: If I'm wrong, if the criticisms section is accurate and on-topic, show me where and how! There is just such a difference between saying something is so and demonstrating that it is so. It means so much more to say "Jesse's misguided because ..." and provide references to demonsrate one's point. (And by the way, I have been in the past misguided, and in all likelihood will again in the future, and well may be misguided on this issue. But I've "Done my homework" the best I can and am willing to be shown that I'm wrong and willing to learn what is right.) -Jesse

I cleaned up the criticisms section to make it more clear and to soften the tone so it is more balanced. Does it help? Choppingmall 22:21, 11 February 2007 (UTC)

Jesse says: Well, I guess if it was 98% inaccurate and now it's only 95% inaccurate, yeah, I guess that helps. But my original plea still stands: Pick one -- any one (or more) of the criticisms and demonstrate that it is both accurate and pertinent. Just one! But please be specific and provide data sources so we can all see that you're right. Thanks very much! -Jesse

Hi,

I would like to make two changes to the PIC Microcontroller article, and would like comment here first, if I may.

The two changes are independent and I don't necessarily have to do both just because I do one.

The first change is that I would like to remove the criticisms section. I think I've clearly shown in my previous posts to the discussion page that the criticisms section serves no true purpose and nobody has provided any specific input to the contrary in a couple of weeks.

The second change I would like to make, if I may, is to add the following paragraph near the top (but below the contents). My goal with the following paragraph is to provide the reader with a quick painless understanding of the range of meaning of "PIC" without them having to read through a bunch of specific sections, trying to read between the lines. I'm certainly open to suggestions and modifications as I'm certainly no great wordsmith. Thanks, -Jesse

PICs come in a wide range of sizes and functionalities from as small as a tiny 6 pin sot23-6 with 256 words of program flash memory (256 opcodes), 8-bit data path, 16 bytes of ram, and 4 IO pins and runs at 1 MIPS max for about $1 each in low quantities or less then 50 cents each in quantities over 3k (Based on PIC10F200T-I/OT from digikey.com 2/6/07) to as large as a 100 pin TQFP with 256K of program flash memory (128K opcodes), 30K onboard ram, 10Mips max speed, 85 IO pins, Many built in special functions like UARTS, Timers, Interrupts, dual crystal clock oscillators, analog to digital converters, power management, and much much more as well as 16 bit data path, with a cost of about $19 each in low quantities, or about $9.50 each in quantities over a hundred. (Based on DSPIC33FJ256MC710-I/PT from digikey.com, 2/6/07). Some models can also run up to 16 MIPS. —The preceding unsigned comment was added by 64.146.180.232 (talk) 04:12, 7 February 2007 (UTC).

I think that these are both good ideas. Val42 06:01, 8 February 2007 (UTC)

I think what you suggest is inappropriate -- see my explanation in the prior section. Choppingmall 16:57, 10 February 2007 (UTC)

Jesse replies: Ahh, I guess I missed your explanation in the prior section. Thanks. But now that I've read it (and commented on it in prior section)the criticisms section still appears to me to not be accurate and pertinent in pretty much all the same ways as I verbosely specified in my original critique. My criticisms have gone unanswered.

I feel that just removing the section is not good idea; changing it towards 'Limitations' tone would be better. Due PIC's popularity I would like to see some major limitations mentioned; this arcticle has good chances to be the first about microcontrollers for fellows from PC world (like me). The suggested additional paragraph looks like a good start for more techinal details, although far from "quick painless understanding". lav 12:16, 12 February 2007 (UTC)

Jesse replies: Is there a specific reason that removing the section is not a good idea even if it's pure lunchmeat?? I know some people do have a hard time understanding their feelings. That's okay. As to the suggested paragraph, I agree that it mentions some technical issues. I'm certainly open to suggestions on how to make it better. The point is that someone who's never heard of Microchip just learns about this version of CPU called a PIC Microcontroller. He'll go and put "PIC Microcontroller" into google and be at wikipedia.org. His first questions will be "Well how big is it? what color is it? how fast is it? and if he's wanting to program it, he'll also want to ask How much does it cost?" so my goal is that the reader who knows what a microcontroller is would be quickly informed to exactly what a PIC is. -Jesse

Jesse Asks: If I do my proposed changes, how likely am I to get reverted? I certainly am not trying to start a revert war. I'm just trying to make WP better (as in more accurate and pertinent.) That's why when I first started discussions here I asked "Is this someone's pet project? Because if it is I'll go away and not bother it." While nobody claimed it as their pet project, some folk seem to strongly insist that the criticisms section stay -- even though nobody will demonstrate that even a single line -- much less the whole section -- are pertinent and accurate. I'm beginning to suspect that accuracy and pertinence just aren't factors of interest here. If someone had just said "it's my pet project" outright, I would have gone happily on my way. I had long wondered why I saw so many instances of irrelevance, slant, or inaccuracy on WP. I had always assumed that it was for a lack of research and efforts. But now that I try to reason about factual matters and find that they are besides the point I now understand much better. -Jesse

As you wish, I will choose one statement in the criticisms section to support:

The stack did not become addressable until the 18 series. That fact is readily verifiable in databooks published by the manufacturer. Because of this, preemptive (interruptible) task switching is not possible. RTOS is claimed, but are based on some variant of "super loop" or "cooperative" methods and are not preemptive. An example of this is "Salvo" by Pumpkin Real Time Software or Calvin http://fse.bc.ca/Calvin.html.

Quote from http://www.picos18.com/Projects/RTOS/PICOS18/Projects_RTOS_PICOS18_us.htm

Before PIC18xxx family it was not possible to develop a such real-time kernel for PIC...

Supporting reference: http://www.sxlist.com/techref/microchip/multitasking.htm

None of the statements in the "criticisms" section are controversial (most of the statements are facts plainly stated in the data books). But your refutations are full of fallacies:

• give references! (valid point, but not a counterargument)
• but it is supposed to be that way! ( umm.. isn't it supposed to be better rather than worse?)
• but that's also a feature! (one might also claim sickle cell condition as a "feature" as it protects against malaria)
• who says that? (ignore the argument, just question the authority)

It would greatly help if you gave reasons, or counter-examples. Do you know of a C compiler that produces re-entrant code for PIC16? Please name it.

Okay, I checked the data books of 5 other MCUs. Z80, 8051, HC11, AVR, and COP8. Of them, only the HC11 saves state on interrupt. I think that the statement "writing interrupt handlers is difficult..." is valid, but not fair with respect to the majority of the PICs peers. I'll remove the statement. Choppingmall 19:43, 13 February 2007 (UTC)

Jesse replies:Thanks for your post. Remember that I asked that each criticism line be not only true, but pertinent as well. Personally I have not found the lack of re-entrant code or preemptive multitasking to be any problem on PICs. Have you? Just why is this pertinent?. There are many things that a PIC12F just can't do. Running windows and linux or other multi-user multi-tasking operating systems well is not one of them. But then they aren't designed, sold, or priced for that.

You have shown that (for some pics) preemptive multitasking isn't possible. But can you also show that such a statement is pertinent? Can you show that someone is actually likely to want to do re-entrant code or preemptive multitasking on a 12F with 63 bytes of ram? ha ha ha. And besides, that information should be down with the sections to which it applies.

As to whether I know of any C compiler that produces re-entrant code -- I don't. I've never wanted one. I've only used one PIC C compiler, and it doesn't produce re-entrant code for PICs. But that is entirely besides the point -- when we criticize, we run the risk of tarnishing someone's or somethings reputation. Thus, when we criticize, we should really make sure that we're right and that everybody can see that we're right. Thus criticisms really should have references.

Only on WP would a critical statement be posted without references, then defended by the poster with the attitude of "Everybody knows it. It's not controversial." "You prove it wrong." Normally for encyclopedic content, it's the other way -- only after it's proved to be pertinent and accurate is it posted. It is very bazaar indeed to post something as true without references, then put the burden of proof on others to show that it's not true. The burden of proof that something is true should be on the person first claiming it to be true.

(But alas; shifting the burden of proof onto someone as a burden to disprove something that was never known to be proved in the first place is an exceedingly common method to 'win arguments at all cost' these days.)

So I suggest that the criticism about Re-entrant code and preemptive multitasking are, while perhaps in some cases true, not pertinent and should not be there. And I also suggest that they burden of proving that they are pertinent lay on the person who insists on them being there. "This is true because choppingmall says so" just isn't WP Quality. Especially when it's a criticism! Thanks,

-Jesse

You may not have found multitasking (or lack thereof) pertinent, but apparently some sxlist contributors would disagree (visit the link I posted above). For heaven's sake! it lists several RTOSs, some are commercial products -- companies are built around solving the problems which you casually dismiss. Next, the re-entrant code limitation is a consideration to C developers writing interrupt handlers -- I would assume that catches quite a lot of people.

Next, you exposit your personal interpretation of Wikipedia guidelines, then argue (in a remarkable turn-about) that I have tried to shift the burden of proof to yourself, when it was you who so stridently insisted that I prove one "Just one!" of those statements. Now that I have done so, you simply deny its significance. How kind.

Verifiable Facts:

• data in program memory is space and time inefficient (all 8 bit MCUs) --
  • RETLW for early cores 12/14 bit encoding storing 8 bits of data
  • need to synthesize computed jumps to access RETLW tables, possibly across bank boundary
  • need to load address registers for table reads
• data stack is inefficient (base/mid cores)
  • push a constant onto the stack: movlw, movwf INDF, incf FSR
  • ensure correct bank + register pressure on W + FSR reserved for stack pointer
• most PIC C compilers (base/mid cores) produce non-reentrant code
  • survey the C compilers, you will find this to be correct. (Do ANY produce reentrant?)
• instruction lacks indexed addressing (baseline/mid cores)
  • effectively has "register indirect" through FSR (whether it's an "addressing mode" is debatable)
  • PLUSW not introduced until PIC18
• call stack is small (baseline/mid cores)
  • 2 depth for baseline
  • 8 depth for mid (remember it's needed for interrupt handling too)
• call stack is not addressable (base/mid cores)
  • already shown

Leaving us with the only two statements which are opinions (I agree these do need references, why don't you find some?) but which are also well supported by the FACTS presented.

• PIC assembly code is difficult to follow
• PIC architecture is somewhat unfriendly to high level language compilation

Is the community best served by suppressing these problems?

And a final word, I take issue with your assertion that I argue with "because I say so". You ascribe the importance of avoiding tarnishing reputations, but have no problem painting me as ego-centric. That's not fair or justified. Search comp.arch.embedded and piclist and you'll find I've asserted nothing hasn't been known and debated for years, including the RISC controversy. I don't feel obligated to prove these points at your pleasure. And I'll not be baited into a flame war in this forum, so I am going to back off and I suggest you do the same.

Choppingmall 13:55, 17 February 2007 (UTC)

Jesse reponds: Choppingmall, I certainly did not intend to exposit my personal interpretation of WP guidelines. I did and do argue, however, that according to WP Policy on Original research,[2](paragraph 2) the burden of proof that a statement is true quite clearly lay upon whoever adds or restores said statement. And if you insist that a certain statement stay against my logical wish to remove it then I would say that according to WP Policy, the burden to reference it would fall on you.

I will here replicate paragraph 2 from the NOR page:[3]

Wikipedia is not the place for original research. Citing sources and avoiding original research are inextricably linked: the only way to demonstrate that you are not presenting original research is to cite reliable sources that provide information directly related to the topic of the article, and to adhere to what those sources say.

So even if a statement would otherwise not be Original Research, if it does not have a valid source, it is considered Original Research anyway.

As to me having "so stridently insisted that you prove just one" of those statements -- that wasn't quite my request -- but rather to prove that it was accurate and pertinent. It is certainly true that (and I choose an extreme case here for ease of demonstration,) one simply cannot run windows XP on a 12F PIC part. But that's not really pertinent information -- true but not pertinent. Remember, this is an encyclopedia -- all content needs to be accurate and pertinent or it shouldn't be shown! (And, according to WP Policy, it must be referenced as well.[4]

As to me ignoring the argument and questioning the authority, yes, in some cases, that is absolutely the correct response! Like on WP, which requires statements to be sourced with valid sources: If no source is given, then it doesn't really matter what or who's the argument is, in the context of a WP article.

Re: give references! (valid point, but not a counterargument) you say that my request for references is not a counterargument -- but in the case of statements on WP, it certainly is[5] a perfectly valid argument that a statement is OR and should not exist.

You say 'None of the statements in the "criticisms" section are controversial..." but I(Jesse) and at least a couple other folk have posted here saying that the criticisms section should be removed. And I(Jesse) have certainly found the statements themselves to each be individually controversial -- either on grounds of lack of pertinence or lack of accuracy. Isn't saying "None of them are controversial" basically the same thing as saying "Everybody knows they are true?"

You say to me "You ascribe the importance of avoiding tarnishing reputations, but have no problem..." I did not ascribe any importance in the tarnishing reputations per-se but more specifically without references or sources. If something is true about a PIC chip, be it good or bad, by all means -- put the statement in the appropriate place on the WP article but with references. When referring to you as arguing with "Because I say so" I was referring only to things you said on this page and figured others would read those as well. I was not intending to paint you as an ego-centric. I'm sorry if that's how it looked. I was referring to the way you seem to be asserting so many things as true without references, and insisting that criticisms remain without references because you know they are true: "None of the statements in the "criticisms" section are controversial" - This is very like the old "Everybody knows it's true" argument used in lack of actual evidence.

You say "I don't feel obligated to prove these points at your pleasure." That's fine -- but it's not my pleasure that obligates these points to be proved. It is WP Policy which obligates whoever adds or restores "these points" to prove them -- and provide references! Remember, I have expressed desire and intent to remove the criticisms section and you told me that I shouldn't. Thus, out of honor, even if not technically, you are on who falls the burden to reference/source the statements in the criticisms section, because if not for your objection, I would have removed them. Had I removed them, you quite likely would have in one way or another restored them, at which point the burden would have been technically yours as well.

I certainly have no interest in a flame war either! That's what I appreciate about this conversation that even though we have some differing opinions we can both think logically and support our views with references and sources! I certainly have learned a lot that I didn't know before! (I never knew about the load/store part of RISC. Imagine, me, thinking of myself as a RISC programmer, and not knowing what load/store was..! grin)

Here are a few points I've summarized/paraphrased/shortened from WP Policy/Guideline pages along with sources:

1. An edit counts as original research if it intorduces an argument without citing reputable sources for that argument.[6]
2. The burden of evidence lies with the editor who adds or restores material. Any material that is challenged or likely to be challenged needs a reliable source.[7] Paragraph 1
3. Any edit lacking a source may be removed or moved to the talk page, but it's nice to give editors a chance to provide sources.[8] Paragraph 2
4. sources considered reliable are usually not self-published blogs, websites, papers, or books.[9]
5. The only way to show that a statement is not original research is to cite reliable sources that provide information directly related to the topic, and to adhere to what those sources say.[10] Paragraph 2
6. Writer of the source must write about the same claims or must advance the same argument as the statement which cites it.[11] End of paragraph 1.

The criticisms section clearly has no sources and has been challanged, and therefore should have sources if it is to exist.

So I guess according to WP policy, the criticisms section should be moved to the talk page until it's authors or anyone else can provide reliable sources for each one.

In a while I may stop by and move to the talk page those criticisms which are, at that time, still lacking valid sources. If someone moves them back without references, then that's their problem and at least I'll know I did my best.

I still see them all as unpertinent or inaccurate, but in the process of finding references for them may help that problem. Either they will need to be changed to an accurate state to comply with their newfound reference, or I will be able to see their reference and then I'll know that they're accurate. That'll leave just pertinence, but I think references will help with that greatly as well, as it will give a context.

1. Data stored in program memory is space inefficient and/or time consuming to access, as it is not directly addressable. To be fair, this is also true of other harvard architecture microcontrollers.

To be fair, this is not the harvard vs non-harvard page. It's already noted at top of article that PIC is harvard based. Why even bother having that criticism? I mean, really. It is in the same spirit of criticisms along the lines of "PIC May be zapped by high voltage. To be fair, this is true of most CMOS. PIC may not operate over 100C. To be fair, this is true of most micros." They're all true, but sure don't seem like encyclopedic quality to me.

Sincerely, -Jesse

If you think that pointing out, as I have done, a few drawbacks of the PIC architecture is biased or wrong-headed or factually wrong or whatever -- then act accordingly. Stop clogging up this page with your meandering and pedantic rationale -- act boldly and make the changes you feel will improve the article. Choppingmall 18:40, 24 April 2007 (UTC)

Unless you can find citations, "drawbacks" are "original research". It would be better to describe the features of the architecture (of which there is plenty of documentation) and let the reader come to his own conclusion. Val42 17:13, 4 May 2007 (UTC)

We need to add citations to the content on these pages. Almost everything here is original research. I added citations for Open Source section of this article. Items in the pages should be cited using the <ref> and </ref/> tags placing the proper Wikipedia:Citation_templates in between.

Gfutia 06:22, 10 February 2007 (UTC)

I strongly refute the claim that any content in this article is original research. Look up the definition on the link that you posted. Does anything in this article present new knowledge or advance a position? I think not.

Almost none of the citations you made in the Open Source section were necessary, as each development tool was clearly linked to a separate Wikipedia article on the topic. None of the statements in that section needed a citation, your over zealous changes added no value but to clutter up the wiki-markup.

Choppingmall 21:33, 11 February 2007 (UTC)

Wikipedia states, as I referenced, that Original Research is, "not exclusively based on a summary, review or synthesis of earlier publications on the subject of research." The key point here are the words earlier publications. When somethings is stated in a reference article, like a Wikipedia article, it must be referenced.

Wikipedia is not a place to post personal experiences or findings. It a place to restate, summarize, and consolidate existing published information. This should be done with a reference. Not doing so would be called plagiarism in the academic community.

Let's look at some examples where there is no citation, leading to what appears to be original research in this article.

Paragraph #1, "PIC is a family of Harvard architecture microcontrollers made by Microchip Technology, derived from the PIC1650 originally developed by General Instrument's Microelectronics Division." Where is this information published? If it can not be found it is original research. Now, I know from reading the PIC18 reference manuals, that is is documented, but this documentation must be cited.

Paragraph #2, "PICs are popular with developers due to their low cost, wide availability, large user base, extensive collection of application notes, availability of low cost or free development tools, and serial programming (and re-programming with flash memory) capability." Where is it published that PICs are popular with developers? Where can it be proven that they can be programed serially? Who says that PICs have flash memory? What is the source of this statement.

A more important example that has also be discussed previously is the Criticism section. The statement, "The PIC architecture may be criticised on a few important points." Where has it be criticized. There should be a reference to the magazine or publication that made each and every criticism if they are to appear in this article. Without citation, that entire section constitutes original research. This section seems to me to also be "Advancing a Position".

I will not continue any further with examples, although they are numerous. My point can be made repeatedly.

In regards to Choppingmall's idea of linking other articles to avoid citation. I feel that that is a proper way to do to things, if that article is where the information was found. Referencing articles that do not exist and calling that a citation is not useful for the reader, and I can't see how they could be used as a reference.

If a counter point exists to what I have stated here about Original Research and lack of citation, reference it. Also, I don't understand what Choppingmall is trying to accomplish by stating my edits were, "over zealous changes added no value but to clutter up the wiki-markup." I disagree with this and this is an option. Slandering others contributions to wikipedia articles is no good way to encourage others to be come editors. As Choppingmall should have noted before making these comments, is that this was my first Wikipedia edit. I welcome constructive criticism and articulated debate, but I don't feel constructive criticism normally includes words such as, "over zealous".

Gfutia 00:48, 23 February 2007 (UTC)

Jesse chimes in:Gfutia, I agree there is a lot of unreferenced content on the PIC article. I just happened to be reading over the "no original researach" page,[12] and found that one of the Official English Wikipedia policies is as follows(Paragraph 2):

Wikipedia is not the place for original research. Citing sources and avoiding original research are inextricably linked:

the only way to demonstrate that you are not presenting original research is to cite reliable sources that provide information directly related to the topic of the article, and to adhere to what those sources say.[13]

So quite clearly, even if a statement is not otherwise original research, if it is unreferenced, it is considered by default to be original research.

Thanks for making WP better! -Jesse

The broad definition of original research which you propound is totally over the top. Do you seriously think that such statements as, "it is serially programmable" and "it has flash memory" are likely to be challenged or represent an original thought? I am sorry, but I find that ridiculous. The statement "The PIC may be critized..." introduces a list of criticisms. You have a problem with that? That you see a pointed technical critique as "advancing a position", the bias appears to be solely your own. To say that every statement of fact is OR is your slanted interpretation of the guideline, and is unworkable in practise. Choppingmall 18:03, 24 April 2007 (UTC)

Whether the PIC can be considered RISC is a contentious issue. Please read the wikipedia article RISC before you post your opinion here.

I took the liberty of moving Jesse's post to this section.

Jesse responds: Is it really controversial to claim that PICs are RISC based..? What about them would even possibly call that into question? See http://cse.stanford.edu/class/sophomore-college/projects-00/risc/whatis/index.html for a mention of RISC. Pretty much describes a PIC even though it's talking about the early RISC concepts.

It is like RISC because:

• it has few instructions
• fixed length instructions
• single "cycle" execution

Not like RISC because:

• it is not designed with compilers in mind
• it is not highly pipelined
• it does not have a large register set or a load-store architecture
• it is not in the same class as RISC CPUs, nor should it benefit by association

Remember, the distinguishing feature of RISC is a load-store architecture with a large register set, design being largely dictated by the great difference in speed between main memory and the CPU.

Let's say for example that we consider the PIC register file as main memory. Then, the PIC has a miniscule register set (a singleton W) and a mix of load-store (eg. addlw) and direct to memory (eg. bsf) instructions.

On the other hand, if you consider the PIC RAM as "registers", you certainly don't have a load-store architecture, because main memory doesn't exist.

Despite some similarities, the PIC is not in the same class of processors as MIPS and SPARC. The RISC architecture had different design goals and constraints from its conceptual genesis. RISC was to leverage compiler technology, acknowledging the rise of high level languages -- and the assembly programmer be damned. No denying that PIC is almost as assembly hostile, but high level language support wasn't a design consideration for a long time.

Characterizing PIC as RISC was a convenient marketing ploy to associate a lowly 8 bit workhorse with screaming fast cutting edge 32 and 64 bit CPUs. It's frankly misleading.

Choppingmall 05:32, 14 February 2007 (UTC)

It would have perhaps been better to copy my short statement down here for rebuttal since no one will now be able to see to what it was a reply. But never mind that.

It is also like RISC because it does pipeline -- it is always fetching the next instruction while executing the current -- see doc page 45 in [[14]] Just who/what defines heavily pipelined, and who says that it has to be heavily pipelined in order to have a reduced instruction set?

So basically, you're saying it's unquestionably a reduced instruction set micro, but it's not exactly the same (even though it can serve the same purpose, scaled down) in some other areas as the chips made by the first company who coined the term RISC, so it can't be called RISC..?

What would you call it? A cisc? Do not your rules of exclusion for PIC as RISC also exclused AVR (who, by the way, also market their micros as RISC [[15]]) ?

You say it's not in the same class -- and if you mean horse power-wise, then I agree. My little fractional HP chainsaw is not even in the same class as my dad's nice 9HP chainsaw -- but they do about the same thing, using the same types of mechanisms, and they go about it about the same way -- one just takes longer to do it -- but they are both chainsaws. (But they are of different brands.) Are you saying that it is not possible to have a true RISC CPU that's as low-power as a PIC because the early RISC CPUs were all high-powered...?! What if a company produced a RISC CPU that was 100 times faster then the current fastest real RISC -- would you say that since it wasn't even in the same class of performance it couldn't be called a RISC? I'll bet the first RISC CPU didn't use CMOS technology either. Does that mean that nothing that uses CMOS can be a RISC?

I just don't see any logical reason that a micro which is unquestionably a reduced instruction set part that has single cycle instructions, pipelines -- regardless of whether they are CMOS or bigger or smaller then the first RISC micro -- I just don't see why they can't be called RISC -- what would you call them?

You mention that if we consider the PIC RAM as "registers" then we don't have a load-store architecture because main memory doesn't exist. The only reason it doesn't exist in some cases is because it's not needed; why add main memory when your registers do what you need? Main memory can exist if it's needed! Nobody connects memory to their CPU if they don't need it. Besides, many PICs have internal EEPROM -- or even program memory can be used as the "slow" memory. Did all of the "real" RISC parts (MIPS, SPARC, etc) have ALL of their slow memory on-die or at least in-chip?

Anyway, it sure looks like any objection to PIC being RISC is just a strong opinionism. I find no coherent logical reason that describing them as RISC is a problem, and I can't think of a better way to describe them Can you?

-Jesse —The preceding unsigned comment was added by 64.146.180.232 (talk) 18:45, 14 February 2007 (UTC).

Firstly, let's make it clear here that I am talking about the 8 bit PICs, not the 16 bit PICs (dsPIC and PIC24) which are significantly different.

I accede that my "heavily" pipelined comment is somewhat vague. But let's agree, you cannot claim pipelining as a distinguishing feature of RISC, after all the 6502 can be considered pipelined by the same criterion as PIC.

You seem to be taking the acronym RISC at its literal meaning, and ignoring the fact that it is a design concept, it has a strong connotative meaning going beyond "fewer instructions", and has a distinct lineage -- totally unrelated to PIC. And no, I would not call the PIC a CISC either.

Is your argument that the PIC is RISC because it is like AVR? Let's talk about how AVR is distinct from the PIC:

• the designers were explicitly influenced by RISC
• its design favours compilation of C code
• it has single clock cycle execution (compare to PIC's 4 cycle execution)
• it has 32 working registers (compare to PIC's singleton) which are distinct from memory
• and most importantly, it has a load-store architecture

You bring up EEPROM and other memory, but these are not mapped into the data address space and are irrelevant to a discussion of the core architecture. Regarding the memory, my point was: On the PIC, there is no clear distinction between what is a "register" and what is "memory". Contrast this with the AVR (or any RISC chip) where it is unambiguous.

You have ignored the significance of load-store architecture, which most distinguishes RISC. Look at the AVR instruction set -- no arithmetic instruction operates on memory. If you claim similarity with the PIC architecture, am I not then correct to point out that the PIC's analogous "register set" is a singleton? that it has read-modify-write instructions? and combines arithmetic with load and store? Do these characteristics not make the PIC markedly distinct from RISC architectures?

Choppingmall 22:57, 14 February 2007 (UTC)

Jesse replies: It is true that the first RISC systems had a main memory and a register set. The register set was for doing mathematical operations on, and the main memory was because there wasn't enough register set to be useful by itself. But a PIC also has a memory that is for mathematical operations, and a memory that's big enough to be useful -- they just happen to be the same one..! If both purposes can be served by a single memory then I just don't see the problem. If the original RISC designers could have used a single memory, they just may have. But register memory was much bigger and more expensive back then. (By the way, the PIC performs mathematical operations on all onchip sram, and there's enough onboard sram that no external ram is needed. Thus the sram on a PIC truly serves the purpose of both register ram and main ram.)

Thus, if some clever engineer someplace figures out how to make a single memory serve the purposes of both register memory and main memory, even if it eliminates the need for load and store instructions, No, I would not say that such a characteristic makes the PIC markedly distinct from RISC.

Yes, I am taking the meaning of "RISC" to its literal meaning. Nobody as of yet has provided a good reason not to (besides, of course, "Chopping mall says so" :-)

No, I'm not saying that PIC are RISC because they are like AVR. I'm just looking for coherence here.

You say that "PIC is not in the same class of processors as MIPS and SPARC." and that "Characterizing PIC as RISC was a convenient marketing ploy to associate a lowly 8 bit workhorse with screaming fast cutting edge 32 and 64 bit CPUs. It's frankly misleading."

But you do seem to indicated that AVR is true RISC. But AVRs are not even in the same class as MIPS or SPARC, nor are they anything like a cutting edge 32 and 64 bit CPU...

So which is it? are PICs not RISC because they aren't even in the same class as a 32 or 64 but cutting edge CPU? then AVRs aren't even in the same class either, and therefore aren't RISC. I say they are both RISC.

Anyway, I have no reason to believe that there's anything wrong with calling a PIC a RISC. You seem to believe that it's not right. Maybe I'm just ignorant. Maybe there is a well known definition of RISC that clearly excludes PICs. But I haven't found it yet. Perhaps you could provide such a reference -- like a paper written by a PhD in CS -- a paper which wasn't written in response to our discussion here..

But since as of yet the "Criticisms section" does not yet talk about the 'RISC' issue, I'm not too interested in growing this RISC thread. You clearly know something to be authoritative (i.e. that PICs are not RISC) but haven't shown me that it's true -- besides you saying so. I'm just a little leery of "Everybody knows it!" when it's followed by zero (independent) evidence. -Jesse

PS: Choppingmall, I finally got around to replying to your post supporting the Re-entrant code and preemptive multitasking criticism. -Jesse

According to my text book the PIC micro controller pipelines instructions. Shouldn't this be mentioned in the article? --Weedrat 11:21, 3 December 2007 (UTC)

If I may quote Choppingmall in part: (from this discussion page) ".... act boldly and make the changes you feel will improve the article. Choppingmall 18:40, 24 April 2007 (UTC)"

And so I shall act boldly!

The Criticisms section is clearly in violation of WP Policy. [16] It was only after much discussion and waiting for someone to fix this that I moved them here. I have (As my many posts to this discussion page show) challenged the Criticisms section -- and to date absolutely zero of them have even one reference! This was not a sudden action taken without talking about it first.

"Any material that is challenged or likely to be challenged must be supported by a reliable source. "Original research" is a claim for which no reliable source can be found. Producing a reliable published source that advances the same claim taken in context is the only way to disprove an assertion that a claim constitutes original research. If there is a source, but the source or claim is disputed, that is not original research but rather of a question of reliable sourcing or undue weight. However, using information from references out-of-context or to forward claims not directly supported by the sources is original research." [17]

Make them compliant and by all means return the ones that are compliant (That is to say, have a reference, are accurate, and pertinent.)

Each of the following points completely qualifies for Original Research. Many of them are not pertinent. Many are absurd. I have addressed the specifics for most of them on previous posts to this page -- see the list at top and find the ones on the Criticisms section.

Thanks, -Jesse

'=== Criticisms ==='

PIC microcontrollers have a very small set of instructions, leading some to consider them RISC devices. However, the PIC architecture does not reflect many of the advantages of RISC design. For example:

• PIC does not have a load-store architecture, as memory is directly referenced in arithmetic and logic operations
• it has a single working register, while RISC designs typically include 16 or more general purpose registers
• its addressing modes are not orthogonal, since some instructions can address RAM or immediate data, while others can only use the working register
• register-bank switching is required to access the entire RAM of many PIC devices, making the development of libraries of position-independent code complex and inefficient
• a stack cannot be implemented efficiently, so it is difficult to generate reentrant code

These properties have made it difficult to develop compilers that target PIC microcontrollers. While several commercial compilers are available, the Free software Small Device C Compiler has not yet completed support for PIC as of 2007. By contrast, Atmel's AVR microcontrollers—which are competitive with PIC in terms of hardware capabilities and price, but feature a RISC instruction set—have long been supported by the GNU C Compiler.

PIC assembly language code can be difficult to comprehend due to the limited addressing modes, code obfuscation via the "skip" instruction, and register juggling through the accumulator.

However, it should be noted that judicious use of simple macros can make PIC assembly language much more palatable, but at the cost of a reduction in performance. For example, the original Parallax PIC assembler "pasm" has macros which hide W and make the PIC look like a two-address machine. It has macroinstructions like "mov b,a" (move the data from address a to address b) and "add b,a" (add data from address a to data in address b). It also hides the skip instructions by providing three operand branch macroinstructions such as "cjne a,b,dest" (compare a with b and jump to dest if they are not equal).

Other drawbacks have been addressed in the PIC18 and PIC24/dsPIC series, but still apply to earlier cores:

• Data stored in program memory is space inefficient and/or time consuming to access, as it is not directly addressable. This is true of most Harvard architecture microcontrollers.
• The PIC architecture is somewhat unfriendly to high level language compilation.
  • A data stack implementation (for parameters and locals) would be dreadfully inefficient, leading to compilers storing these values at fixed memory locations. Thus, most C compilers do not generate re-entrant code.
  • The instruction set lacks an indexed addressing mode.
• The call stack is so small that program structure must often be flattened.
• The call stack is not addressable, so pre-emptive task switching cannot be implemented.
• Program memory is paged on PIC16 and older devices with large program memory. There are two page sizes to worry about: one for CALL and GOTO and another for computed GOTO (typically used for table lookups). For example, on PIC16, CALL and GOTO have 11 bits of addressing, so the page size is 2KB. For computed GOTOs, where you add to PCL, the page size is 256 bytes. In both cases, the upper address bits are provided by the PCLATH register. This register must be changed every time control transfers between pages. A non-obvious case of this includes after when a CALL to a different page returns, since RETURN itself does not restore the current page number. PCLATH must also be preserved by any interrupt handler. —Preceding unsigned comment added by 64.146.180.232 (talk) 05:43, 7 December 2007 (UTC)

Well, despite my best efforts, KnowledgeOfSelf immediately reverted my edit.

So what do we know? We know that the people running WP intentionally knowingly put unreferenced slanted, POV and original research information onto WP.

I always wondered why WP had so much bad information - I had assumed it was because nobody-type users (like me) just put junk in there. But no, it's actual sysops putting it in there, in direct violation of WP Policy!

Several people in this page, have, over the last several months, all agreed that the Criticisms section was out of WP policy compliance and needed reference and qualified as OR. And yet none of them were allowed to do anything about it.

Speaking of WP Policy, the NOR policy page used to state:

  1. An edit counts as original research if it intorduces an argument without citing reputable sources for that argument.
  2. The burden of evidence lies with the editor who adds or restores material. Any material that is challenged or likely to be challenged needs a reliable source.
  3. Any edit lacking a source may be removed or moved to the talk page, but it's nice to give editors a chance to provide sources.
  4. sources considered reliable are usually not self-published blogs, websites, papers, or books.
  5. The only way to show that a statement is not original research is to cite reliable sources that provide information directly related to the topic, and to adhere to what those sources say.
  6. Writer of the source must write about the same claims or must advance the same argument as the statement which cites it.

And it currently says: [18] "Any material that is challenged or likely to be challenged must be supported by a reliable source. "Original research" is a claim for which no reliable source can be found. Producing a reliable published source that advances the same claim taken in context is the only way to disprove an assertion that a claim constitutes original research. If there is a source, but the source or claim is disputed, that is not original research but rather of a question of reliable sourcing or undue weight. However, using information from references out-of-context or to forward claims not directly supported by the sources is original research."

And it says much much more.

I did give editors months and pages of reasons to fix it. I argued for accuracy, pertinence, and WP Policy. And even having gotten the Go-ahead from Choppingmall, my edit was reverted.

At least I now know why bad material lives so long -- Sysops guard it and revert it the instant it gets fixed.

So I guess WP is becoming, by and by, (Or maybe it was always this way) a POV Machine.

Thanks, -Jesse —Preceding unsigned comment added by 64.146.180.232 (talk) 06:05, 7 December 2007 (UTC)

I see it as you removed an entire section and replaced with a single ungramatical fragment. O.K., so this section has problems and could use a clean up. But I look at it and ask: Is the artical better with the criticisims section or with the sentence fragment "are being fixed up"? The artical is clearly beter with the section in place. It would be even better with the section improved. That is the direction in which you should proceed. I've read the discussion, you do make some valid points. You should do somthing constructive rather than destructive. Include the counterpoints to invalid criticisms: "The PIC has been criticised for inadequately saving processor state on interrupts, but other competing processors also do not save complete interrupt state". You can probably phrase that better than I just did. You can make this artical better, by making this section better. Ferritecore (talk) 02:15, 8 December 2007 (UTC)

Moving entire sections of slanted/POV unreferenced material to the discussion page is perfectly inline with WP policy. Ideally, I would have just moved it without leaving any comment in it's place, but I wanted other editors to know that I hadn't deleted all their work, but just moved it. My sentence was not fragmented: In whole it read "Criticisms are being fixed up" and to be more verbose would have been uncalled for. My comment left there was only to calm the nerves of the sys ops who tend to shoot then ask questions -- if they indeed get around to asking questions. "Criticisms are being fixed up" was not intended to contribute to the article.

You suggest I make the Criticisms section better. I'm contending that every single line in the criticisms section is inherently un-fixable. Every line is unreferenced, and every line is either not pertinent or not true. WP policy is so clear that "Any material that is challenged or likely to be challenged must be supported by a reliable source." [19] (Emph. Mine.)

In answer to your question, No, the article is not better off due to having a bunch of slanted unreferenced POV material on it. Note that WP Policy does not say that any challenged material should or might or may but must be supported by a reliable source. So then why do people keep adding to the criticisms section without making it WP compliant? I don't know. If I were to violate any WP policy or guideline with an edit, I would have my edit reverted with no questions asked. But sys ops routinely add stuff that is in clear violation of not only WP guidelines but Policy as well -- and anyone who comes along and tries to fix it just gets reverted -- Even when I went through all the procedure of discussing it on the discussion page, getting a go-ahead from the author of the section, and in all manor doing it in the best possible way.

The fact is that WP is running by some secret rules which are different then the official WP policy available to normal users such as myself. In order for people to trust and find useful WP, it must have an "Official Policy" that assures it's readers that only properly referenced material is present. But I'm beginning to wonder if the official policy is really nothing more then something to throw at honest folk such as I. The sysops are clearly regularly and blatantly violating WP Policy.

I will leave you with one simple question, and two comments. I've shown that the criticisms section is clearly in violation of WP Policy. By Policy, it simply MUST have valid sources, or must not exist. Considering it is in violation of WP Policy, why should it exist in the first place?

When I first read the criticisms section and commented on the talk page about it and found I was meeting resistance, I said "Is the 'criticisms' section someone's pet project who will be offended to changes thereto? I mean, if it's someone's personal webpage, fine, I'll leave it alone. I wouldn't want someone messing with my personal webpage either." -- Nobody claimed it as their pet project, but it is becoming clear that it is someone's pet project. Otherwise I would not have hit so many brick walls from so many registered users while simply trying to make the article more compliant with WP Policy. If the article's author had simply been honest and said "Oh, yeah, that's my project, I'd just assume you don't mess with it. I don't care about Policy or your view of accuracy." it would have saved all of us a lot of trouble.

Like I said before, WP is definitely broke when the sys ops routinely post and protect bad unreferenced information in violation of WP Policy. There are simply no two ways about it! Thanks, -Jesse —Preceding unsigned comment added by 75.165.44.143 (talk) 10:16, 8 December 2007 (UTC)

AFAIK, the origins of the PIC is a Scientific Microsystems/Signetics 8X300 microcontroller.

http://www.trash.net/~luethi/microchip/faq/faq.html

The first MPU using Harward architecture was the
Signetics 8X300, and this was adapted by General Instruments
in the mid 1970s for use as a Peripheral Interface Controller
(PIC) which was designed to be a programmable I/O port
for their 16-bit CP1600 MPU.

General Instruments sold their microelectronics division
in 1988 to a startup company called Arizona Microchip Technology.
Microchip's main product was, and is still, a series
of microcontroller families based on this PIC architecture.
Their first family was introduced in 1989 with the PIC16C5X series.

http://www.cpushack.net/CPU/cpu2.html

http://www.cap-lore.com/stories/LLNL_history/john_fletcher_2p1.html

http://www.satyam.com.ar/comphist.htm

Can someone translate Spanish version ?

http://es.wikipedia.orghttps://demo.azizisearch.com/lite/wikipedia/page/8X300 —Preceding unsigned comment added by Alecv (talk • contribs) 10:32, 5 January 2008 (UTC)

This is an archive of past discussions about PIC microcontrollers. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1