[time-nuts] favorite microcontroller module?

[Chuck Harris]

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