Robert Vassar wrote: ... > Not at all. Embedded products generally have higher quality needs > than general purpose computing as we've come to know it today. Let's > face it, when a traffic light controller or a military device wanders > off the end of a null pointer people die. You're a pro, you > understand these problems. Engineering is compromise. Use the tools > you feel comfortable with that allow you to do your job. > > > As a software professional that plays with uC's for fun, not work, > I'm going to choose something that doesn't use oddball word lengths, > and has a nice orthogonal instruction set with a rich set of > addressing modes.
Which you probably will never see from your C compiler. I really enjoyed programming in 68020 assembler. It was just like programming in C, without the compiler. The 68020, and its ilk, has truly is a lot of baggage for an embedded processor to carry around and feed power to. I prefer to make the compiler sweat, and keep the processor lean and cheap. I only develop the code once, but many many copies of the hardware get made. I learned the '51 back in high school 20+ years > ago. If someone else was going to pick up a uC arch from scratch for > hobby purposes, I would probably recommend the AVR. I was progrmming '51's about 20 years ago too, and I never particularly cared for them. But back then, compilers for such tiny processors weren't readily available... Sure, Intel had some MCS crap that would do the job, but tied you down to one of their overly large, overly noisy, and overly slow development stations. >> And I assume they have them in 6 or 8 pin surface mount with 4 or 5 >> ADC >> channels, and a built in clock oscillator that has a better than >> 1% accuracy over the full military/industrial temperature range? > > SiLabs makes some very remarkable derivatives, which I've not had the > pleasure to play with. I'm not sure they get down to the 6 or 8 pin > point. > >> Oh, and I forgot, a uart on every pin? > > Why on earth? No... I don't want to know. :-) When you are trying to develop a part, and you don't want to use an emulator, or simulator, it can be handy to wire up a 1 wire TTL RS-232 port to let you know what is going on. With the CCS C compiler, I can put a very tiny software UART on any pin. So, for instance, I can use a pin that ordinarily would run an LED as a diagnostic port. > >> PIC's are the greatest little problem solvers in existence. >> > > s/PIC\'s/uC\'s/ and we agree.... Many would say this is a religious issue, but I would disagree. The 6 and 8 pin PICS are simply awesome in what they can do in virtually no space. The tools are cheap, or free. The PIC's are cheap too. A recently I had a customer that needed to augment a single RS442 command that came from a black box, and went to another black box. I put a little 8 pin PIC in a connector shell, and the problem was solved. In another project, I replaced a circuit that used an opamp comparator, and a 555 timer with a single 8 pin PIC, and was able to gain better functionality, and keep the adjustment pots that the customer loved. The neat part was the PIC only cost 1/2 the price of the opamp and 555, drew less power, was more reliable, covered full industrial temperature range, and didn't need all of the resistors and capacitors the analog timer needed. The program was written in C, and took about 50 lines of code. I made a series of intelligent, rapid battery chargers using one of the 18 pin PIC's. It handled the charging algorithm, and housekeeping chores, and produced the PWM used by the power supply, and by a variable current load used in the charging process. One PIC did it all. The only other components on board were a few FET's and resistors. Oh, did I mention, it auto detected the charge adapter, and was capable of charging every small rechargeable battery the Army used for the last 40 years? I've done hundreds of little things like this. >>> and have an arch better suited to C. >> Who cares? > > Anyone trying to make a C compiler for the chip? Anyone concerned > about the quality of the compiler, mixed language use ala C with > assembly, or code portability? The PIC being a very simple RISC processor actually makes life pretty easy for the compiler writer. The CCS compiler I have been using for years is tiny in size, and generates better code than I can do in assembler. It has only 32 commands to juggle, and only a couple of registers. GCC is a monster, and is way overkill for such a tiny processor, yet it is used on many of the 8 bit uC's. ... > I have to confess, I'm rather surprised at your passion for the PIC. > But hey... I spend all day working on Solaris and Linux, and use a > Mac everywhere else just to be 100% Microsoft free. So while I'm > surprised, I can understand it. I to spend my days using Linux. There isn't a Microsoft product anywhere around here, though that will have to change for income tax time, because I cannot seem to get TaxCut to work under wine this year. PIC's get the job done. When the job is done, I get paid. I do embedded work, but my definition of embedded is something I can code up in a couple of days and ship. The largest PIC I use generally is the 16F690. It is a 20 pin package. I use it for the pin count, and the gizmo's inside, not the code size. Some consider embedded work to be stuffing a mainframe computer in a 1/4 ATR chassis... and I have done that too... but I don't consider it to be embedded. -Chuck Harris _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
