What micros do you actually hate to work with?

Microchip PIC.

The PIC core does not make any sense.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

The PIC core makes perfect sence for the applications it was first designed for. Their a victim of their own success and have tried to drag the core to places it shouldn't really be much like the 8051 and the 8085 before it.

Have you looked at the PIC24 and dsPIC? I have been impressed. It has nowt in common with the PIC18.

Regards, Richard.

• formatting link

• formatting link
  for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & PIC18

I do not understand guys crying about PICs (or any other processors). If you do not like them, do not use them.

I do not particularly love PICs, but I work with them and besides - they sell way better than AVRs. I sold very few AVRs and did not order more, because everybody wants PICs.

Personally I do not like Harward architecture too much. I am also little excited about buggy tools with hundreeds releases, patched-up features, etc.

But they are processors just like others, they have been designed cheap with decent set of peripherals, they did the job and became popular and it's hard to terminate popular product even if it is not designed perfectly. I agree, ARM may be nicer to work with, although how easy is to prototype with them ? I am looking at Richard Collins' comparison table and do not see a single DIP packaged ARM.

--
Roman Ziak, DIPmicro Electronics
Selection of PIC and AVR micros and other electronic parts.
www.dipmicro.com

Hate is maybe too strong, but AVRs - great chips in general, but badly let down by AVR Studio, which can be a real PITA to work with, and there isn't a proper ICE for the newer parts. Debugwire is OK but annoyingly slow and klunky. I now budget a couple of hours extra on any significant AVR project to cover devtools playing silly buggers for no apparent reason at some point, which they do without fail.

Atmel really need to invest more in their devtools, which have always lagged seriously behind a minimal acceptable standard for serious development. Their assembler only got conditionals a couple of years ago, and still doesn't do looped assembly FFS! And don't get me started on it not embedding config fuses in the .hex file - this is total insanity,

Please don't assume that my info is complete or accurate. I have asked several times for people to review the info in those tables and have only received a few responses. One vendor I know I have missed is Micronas which has DIP packaged parts or if not DIP, they offer easy to solder QFPs. They target the automotive market where size is not as important as ease of assembly and low cost. Partly I did make an effort to include them because in the past when I evaluated their product it was very hard to cover all their ARM parts because of the way they market them, much more by application than by functionality. I will add them some day when I have nothing better to do than download their data sheets and read all the details.

Also, the real volumes are not in the sort of users who want 0.1" spaced DIPs. So that will be a dying breed if not already.

Frankly I don't care about the core. I do my programming in C. The core is transparent to me. I just select the PIC that fits my project and for it. So far, so good.

Al

PICs are OK for some things, and AVR good for other things. I tend to prefer AVR (and as I design the hardare as well, that's what typically goes in) for small jobs, or (as in one product) as a system supervisor. PICs are a little easier to do ISP with, but with appropriate interfacing, either one is suitable. The TI MSP430 series is very nice for certain things.

As far as price is concerned, there's not much to choose between AVR and PIC once you normalise the variables (number of IO, onboard resources etc) and one chooses the part with the required features.

For higher end, I usually use ARM or MIPS, but much depends on _what_ I am doing. I've used some Broadcom parts with quad MIPS cores (and a lot of other stuff), and they were very nice (if a little power hungry). I have one current product that uses an Intel PXA processor (ARM core) and it does the job well and at reasonable power consumption. Now though, we're getting into the arena of sizeable chunks of memory and IO hanging off the outside of the core.

I can't honestly say I _hate_ any particular architecture; I'll drop in the appropriate part for the task. That's often a tradeoff between electrical power, previous use (so we are already up to speed with the tools, for instance), interface rqeuirements and overall task requirement.

I dropped in a 6502 variant (within an FPGA) fairly recently, which was a blast from the past :)

As in all decisions like this, I pull out the watchwords of engineering 'It depends' ;)

Cheers

PeteS

Your comparison table is a nice overview, but I always check datasheet if available. If you received few responses that means that your info is sufficient, thank you for that.

Beside schools and hobbyists, robotics and home automation enthusiasts, there is a whole market of system integrators, who have volumes from single quantity to few 100s and many of them prefer to work with DIP. Personally I do not think DIP package is going to die anytime soon.

--
Roman Ziak, DIPmicro Electronics
Selection of PIC and AVR micros and other electronic parts.
www.dipmicro.com

What exactly is a "system integrator" in this context? I always thought that was someone who combined boards and/or boxes and possibly wrote software. What sort of hardware design do they do?

No DIPs will not die, but there are any number of new products that will never be made in DIP. In fact, I can't think of a single part, of the hundreds I have seen introduced just this year, that is available in DIP. If you are limited to DIPs you are mostly using technology of the 90's and older. Older technology, higher costs and less performance...

Have you looked at the Imagecraft product for the AVR?

System integrator is someone who integrates a solution from off-the-shelf products. My employer is a Test & Measurement integrator. We integrate PC, UPS, measurement instruments like DMM, scope, communication controllers, loads etc. into the rack. Sometimes a special fixturing may be necessary, depends on the applications.

Every test solution is somewhat different so our PCB volumes are small, depending on number of test heads and number of relay boards per test head. That can go from single test head up to whatever (maximum I integrated was 50 in single system).

We try to use existing products wherever possible, but some off-shelf products need extra conditioning, some are prohibitively expensive, so we design our circuitry here and there. The competition is high, so overpriced products are eliminated. Agilent or NI boards are thousands dolars, our PIC/ARM/FPGA controlled relay boards cost us fraction of that.

Customers ask us to interface their own protocols, so we have to design converters to be able to do that. Everything low volume.

You see, not everybody is making volumes of 10,000 products in batch. We have an in-house assembly, but maybe someone can recommend an SMT shop close-by Toronto with reasonable prices and we may consider dropping some of DIP technologies we are using.

--
Roman Ziak, DIPmicro Electronics
Selection of PIC and AVR micros and other electronic parts.
www.dipmicro.com

Whatever they pay least for.

pete

-- snipped-for-privacy@fenelon.com "he just stuck to buying beer and pointing at other stuff"

It may be better to think of "socketable", rather than DIP. DIP is pretty much off the radar now, for anything > 40 pins.

DIP still exists, in high volumes, on smaller uC, where they may end up on punched phenolic PCBs, with other thru-hole devices.

Shrink-Dips I have seen added to recent uC releases, and most uC vendors have some DIP choices, if not across all variants.

PLCC packages are another way to get a socketable/thru hole device (that can also be SMD mounted). The new Zilog ZNEO is in a similar space to ARM, and I note they offer that in PLCC68. Microchip's smaller dsPICs are also avialable in DIP, so you can get quite powerful uC in socketable variants.

-jg

But we have no choice, I use alot of PICs, I hate them, but they are the best solution for the customer, even though the PICs causes me great pains.

Chips that are hardest to work with generally are the best solution for a particular product, the 8051's are another example.

Well, I am pretty much in the same position at my full time job. Most of my grievances can be attributed to bad tools. MPLAB acts-up, downgrade

0.01 down and works. CCS C I used before got confused with array access and was calculating MyArray+i instead of MyArray[i]. Upgraded to newer version and fixed. I refuse to use Hi-tech C since 2004.

When I program in assembly, there is generally few grievances, but my boss believes that I should be more productive in C :)

Just few weeks ago I had a micro bug on 18F2515: I used B5 as SPI CS, if PORTB.5 was used, SDO output worked few bytes and then slowly degraded to 0.5V for high as if it was open collector. If LATB.5 (0xF8A) was used, the SDO was ok. According to datasheet writing to PORTx and LATx registers should be identical. Weird that port B is not even related to SPI since that is on port C. I dislike the micro during bugs like these, but architecture is not bothering me as much.

Since you mention 8051, I used one from Atmel few years back and do not recall any issues. If the micro behaves according to datasheet, I am generally happy with it.

--
Roman Ziak, DIPmicro Electronics
Selection of PIC and AVR micros and other electronic parts.
www.dipmicro.com

That seems to be common situation, move from assembler to C and management believes all the software costs should drop significantly, but it doesn't happen. Our software quotes are increasing.

The loss of productivity just seems to be caused by other reasons (the toolset as in your case, toolset training, toolset costs, toolset bugs). Everyone needs 2 Gig of RAM now on their PC to run the darn tool. Another of the problems with C is that it's too low level for a "high level language".

We moved to a higher level language (graphical) but the learning curve was so long and the tools so expensive, that it was abandoned.

We also keep moving to better cheaper processors, but the interface to all the peripherals is different, so all the C interface code has to be rewritten, which kills our reusability. We attempted to use C++ classes to handle the new interfaces, but they always failed, either the class wasn't sophisticated enough to accommodate the new interface or they became too overly complex to handle all the different type of interface variations.

A floating point processor is one of the few things I can definitely say is a big software productivity aid.

... snip ...

For something like a PIC, I think C advantages are a chimera. For a good assembly programmer productivity will improve with time as the library of tested routines and techniques improves. With an incomplete C system you are always fighting the restrictions of the compiler port.

--
"The mere formulation of a problem is far more often essential
 than its solution, which may be merely a matter of mathematical
 or experimental skill. To raise new questions, new possibilities,
 to regard old problems from a new angle requires creative
 imagination and and marks real advances in science."
                                               -- Albert Einstein

Hi,

And why don't you try FREESCALE controlers ?

8 bits : 68HC908 / 9S08 16 bits : 9S12 / 912X

Yvan

--

********************** YBDesign **********************

"steve" a écrit dans le message de news: snipped-for-privacy@m73g2000cwd.googlegroups.com...