what's wrong with a pic ?

Not actually hate at all but it is *single source*.

I also like the many flavours of 8051 too much

Graham

Anyone here care to write the lyrics for the potentially Academy Award winning song "It's Hard Out Here For a PIC"? ;-))

~Dave~

The Hi-tech C Compiler works fine with it. The code size is reason able enough (PIC16). (It does not make the stack bigger). I would not even try to program ASM on it.

Why does everyone always say you can not run C on 8 bitters.

The pin count, wide voltage range, cost, and the number of built in peripherals make it the right chip for many jobs. Whether I like it or not. I can not pick a more expensive solution becuase I "like it" better.

I have to say in their defence that their documentation is very thorough.

... snip ...

Don't believe it. That pic is incapable of providing the elementary requirements of the C language, such as recursion. That compiler may handle a language with superficial resemblance to C, however.

Some of these "quirks" (to those accustomed to modern micros) are less capricious "reintroductions" than design decisions/compromises inspired (as Michael implies) by cost/complexity constraints. Hence the resemblance to past generations of mainstream processor.

That seems to ignore or dismiss Michael's point, I'm afraid.

Be prepared for the rednecks to throw stones at it. And if it's not already illegal to import fuel efficient vehicles, the Politburo will soon make it so...

Which is no panacea really. While the compiler does the best it can, the architecture of PIC18 and smaller is a indisputably a bad fit for C. It helps a great deal to tailor the instruction set to the needs of a particular HLL (PIC18 extended is somewhat improved), and C on PIC is clearly an afterthought - market driven no doubt.

Acquired taste?

the

Risks equal to assembler. Problems with pointers are problems with pointers, not problems with C; if you wish to eliminate pointers, then you're probably not doing embedded programming, or you're in an enviable domain and making some pleasant design decisions (embedded Forth, Smalltalk, JOP, :-)

After 20 years of C, I didn't have too much trouble adjusting to PIC18 (assembler, then C), so you may be right.

I thought it addressed it head on.

Ian

Ive heard from Hi tech users that it's full of bugs and wont perform some of the more advanced C programs. Ive yet to see a compiler that meets the ANSI standard. For the kind of jobs a pic was made for assembly is a far better option. As far as code size is concerned it depends what you regard as reasonable, it may well be that your program fits into the device but if that meant you could have used a smaller device then that would be a big problem if you were mass producing.

I didn't mean C, there are other languages, like JAL ;-)

Stef

I recently benchmarked PIC18 vs. MSP430 for codesize and cycle count for typical (for me) C code doing mostly integer stuff (decoding and constructing DeviceNet frames). MSP430 code size was less than 50% of PIC code size. MSP430 cycle count was about 60% that of the PIC.

I'd hate to imagine using something even more crippled...

I liked reading Jim G's comment, because it is a segue:

: I have to smile :) : : First you say "i don't see anything wrong with it" : : then you add : : "i don't like the banked memory in most of the parts" : "the risc is a little "too risc" : "add with carry" would have been nice : : so that's three things wrong, even before anyone replies..post. : I'll leave others to add to this list...

It's hard to deal your kind of question, where you've already laid a foundation that has to first be undone before responding or else where it must be somehow dealt with. But in any case, I agree with the banked memory point where it applies (not a concern on the PIC18, for example.) I take the "too risc" to mean that its internal operation is "too exposed to view." In that sense, I agree. For teaching CPU design, this can actually be an advantage -- as the student really gets to see more of the details that are otherwise somewhat hidden. The lack of an "add with carry" is annoying, but the bit test/skip works and is helpful elsewhere. PIC18, which I'm using now, includes an add with carry, though.

Why do I like Microchip for designs?

I just recently had a problem with an old production tool from Microchip. The power switch wasn't working quite right and I needed to wobble it into the middle in order to turn it on. Now, keep in mind that Microchip doesn't sell this unit, anymore. It's old. But it is a production tool. So they support it.

Microchip only said: "We're sending you out a new unit. When you get the box, put the old one in there and send it back to us." I received it the next day.

Same thing for an old module for that old unit, which also seemed to be showing 'weak drivers,' by way of a message at powerup. I was shipped another one of those under the same circumstances. They do still sell those modules and other ones, as well, because they support their old production tools even after they don't sell the main units anymore.

This production programmer was purchased in 1991, by the way. 15 years ago.

I should also mention that their support staff never once gave me the "it's not currently supported" message.

By comparison, I have a similar circumstance with Analog Devices, using an old tool I also bought in and around 1991 for their ADSP-21xx line. I was told that the tool was no longer supported, that I couldn't get replacements, and that they couldn't help me with problems except to suggest a couple of places where I visit their web pages.

This is just one such example. Although I also don't like many aspects of the PIC chips, as viewed as a programmer, when thinking about designing with a product where I want and may need support for a product or product line a decade or two into the future, their actual demonstrated support tells me a lot.

As far as code size issues go related to C compilation, a point I see elsewhere mentioned, it's not terribly important so long as their is a part which has _enough_ program space for the application at hand. Of course, all the other usual culprits in deciding appropriateness for an application apply -- price of the program space vs competing products; power consumption and heating; packaging; etc. But assuming there are some matches within that territory, Microchip support for their production tools is unparalleled and they don't ask for the size of the company when they do that -- so this is probably more important for small and midsized designs and embedded companies like those I'm more exposed to.

On the other hand, I'm also using other microcontrollers for products. So I'm not married to Microchip. But if part of the consideration for the design is a long life and support for older tools as the future unfolds is important to the project, then Microchip with have at least one leg-up on it in that regard.

Jon

Support from Microchip is very good. I had difficulties installing their dsPIC C30 compiler on one of my PCs and they went to a lot of trouble to sort it out for me. I'm quite sure it was an obscure bug in their installation software, as no-one else seems to have had the problem. One of their support people even phoned me from the USA to check that everything was OK, and to discuss another problem I'm having with the software - something to with me using a dual-core Athlon 64 system. They don't have a similar system to test it on, unfortunately.

Leon

By calling it "retrograde" do you intend to imply some kind of misdesign by contemporary standards (which I think Michael was challenging) - or were you agreeing with Michael that it merely recapitulates familiar design compromises forced by cost/complexity?

I guess there will never be agreement on the best way to use N gates...

I thought what I said was quite clear:

That, IMHO, was a retrograde step.

Ian

Neither is true. It's just a very, very old design and wasn't intended to be general purpose microcontroller.

Except the PIC is ancient -- it was desined over 30 years ago.

It's not retrograde, it's just plain _old_. The PIC was designed to be a periphal interface controller chip for a "real" CPU by General Instruments. The PIC was based on an even older Signetics design.

No, it was introduced in 1985 but it was based on a design over 10 years old which is precisely my point, it was a retrograde step.

Ian