Beginner Q: Starting out in embedded systems dev

>Say you want a 24-bit delta-sigma DAC on board.. AFAIK only the 8051
>core is available in production quantity (at least two suppliers),
>with ARM availability (one supplier) projected to be in 3rd quarter
>2K004. There are other similar examples. 
>

I guess there must be a requirement for 24bits somewhere I just can't think of
1.

>More generally, why in the world would you reject a competitively
>priced 8051 from consideration in an application where it would be
>appropriate?  For example, the modern Philips 6mm x 6mm P89LPC932FHN.

Seems ok, but no ADC, so no good for 50% of projects. PIC16F870 would seem a
better choice.

>Or an inexpensive OTP P87LPC760BDH (USD0.87 ea/reel from Avnet)

Biggest problem here is OTP, PIC16F630 seems better.

>
>When you wrote "it has a primitive instruction set not suited to
>running pointer intensive languages like C. It has an architecture
>which is just as unsuited to C as well" I think you expressed your
>real objection, and a fine objection it is - for those who program
>microcontrollers in C.  That's the high end.  Down here where the
>chips cost less than a dime and the programs are less than 100
>bytes long we use assembly language and ponder whether to use an
>8051 with onboard peripherals or a 4-bit processor with external 
>peripherals.

As an assembly language chip the 8051 holds its own alot better but the pics
and avrs still have it beat. You don't need to be very "high end" to use C
these days.

Dave Hansen wrote:

> On Wed, 26 May 2004 16:49:35 +1200, Jim Granville
> <no.spam@designtools.co.nz> wrote:
> 
> [...]
> 
>> I must have missed the release of the 100MHz AVR 
> 
> 
> They're up to 20 now.  And they've always been single-cycle machines.

  I did see they even briefly 'hit 24MHz' until engineering caught up 
with marketing :).
  I still have a 1996 AVR data book that claims they would
all be 24MHz on release... Oh well, maybe 2005 will see it hit the
'marketing target' ? :)

  I've seen an instance where a single sourced uC was 'new versioned' by
the vendor, and the user saw a noticable ADC degrade from the 2002 
model, to the 2004 model. Last I heard, they were looking to use
a small cygnal device, as ADC co-processor, as a short term fix.

<snip>
> Forgive me if I'm skeptical about a microcontroller's ability to
> distinguish 300 nanovolts (or 180 with a 3 volt reference).  If I
> needed that kind of accuracy, I'd want the ADC a little further away
> from the CPU clock...

  I would be too. A key point is these devices are really uC assited 
ADCs, NOT uC with a bolt-on ADC. They also come from the Analog Expert
companies, like Analog Device, Burr Brown, Cygnal....

<snip>
>> Last time I looked at an AVR, the BOOLEAN handling was primitive, and
> 
> 
> AVR has a Load/Store architecture -- most operations take place on
> data in the registers.  Setting or clearing a bit in a register is one
> single-cycle instruction (SBR, CBR).  The compilers I use reserve up
> to 13 general-purpose registers (104 bits) for boolean storage.
> Assigning the value of one boolean to another requires 2 single-cycle
> instructions (BST/BLD).

  But you have to trade off register resource for boolean, and once you 
go outside the register space, the lack of direct opcodes in AVR means
real pointer thrashing.....
  If it's in a HLL, who cares - but make sure there is a bigger code 
version in the package you've chosen.

<snip>
> If the AVR were multiply-sourced, we'd see them at 100 MHz and in the
> automotive temperature grades (though perhaps not in the same
> device...).

Agreed.

> ARMs are overkill for most applications I've worked on the last 4
> years.  The AVR does a really nice job at a low cost, and is
> relatively C-friendly.  The avr-gcc compiler is very good.

ARM maybe a technical overkill, but when they come sub $5, you need to
think what you can do for that $5, and care less about waste-head-room.
In recent 80C51 designs I've done, quite a lot of the resource
is unused - is that a problem ? - not if it essentially comes for free.


> From a software standpoint, the AVR is my first choice for an 8-bit
> microcontroller (If you haven't guessed that by now  ;-).  From a
> hardware standpoint, the only real problem I've had is temperature
> grades.

  For that, you can always cover with the multi-sourced devices, like 
80C51, or ARMs ... :)

-jg

Jim Granville <no.spam@designtools.co.nz> says...

>ARM maybe a technical overkill, but when they come sub $5, you need to
>think what you can do for that $5, and care less about waste-head-room.
>In recent 80C51 designs I've done, quite a lot of the resource
>is unused - is that a problem ? - not if it essentially comes for free.

You and your $5 supercomputers... Why not just design in a Cray? <grin>

I pay less than a dime for the processors I use.


-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/ 

CBarn24050 wrote:

>>Say you want a 24-bit delta-sigma DAC on board.. AFAIK only the 8051
>>core is available in production quantity (at least two suppliers),
>>with ARM availability (one supplier) projected to be in 3rd quarter
>>2K004. There are other similar examples. 
>>
> 
> 
> I guess there must be a requirement for 24bits somewhere I just can't think of
> 1.

Weighing systems and metering are a couple of large segments.
Vendors don't make multiple variant families for no customers....

> 
>>More generally, why in the world would you reject a competitively
>>priced 8051 from consideration in an application where it would be
>>appropriate?  For example, the modern Philips 6mm x 6mm P89LPC932FHN.
> 
> 
> Seems ok, but no ADC, so no good for 50% of projects. PIC16F870 would seem a
> better choice.

Small Package+ADC flash is one sector where the 80C51 is a relative 
new-commer, but Philips now show ~9 members of their LPC9xx family with 
ADCs.

> 
> 
>>Or an inexpensive OTP P87LPC760BDH (USD0.87 ea/reel from Avnet)
> 
> 
> Biggest problem here is OTP, PIC16F630 seems better.

  I like the look of the P89LPC912FDH-S, in a nice TSSOP14 package -
FLASH and US0.86/reel (but new).
( I always ran out of pins, when ever I looked at 8 pin uC ! )

-jg

>> I guess there must be a requirement for 24bits somewhere I just can't think
>of
>> 1.
>
>Weighing systems and metering are a couple of large segments.
>Vendors don't make multiple variant families for no customers....
>

how would you use a 24bit dac in a weighing system?

On Thu, 27 May 2004 10:05:53 +1200, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Dave Hansen wrote:
>
>> On Wed, 26 May 2004 16:49:35 +1200, Jim Granville
>> <no.spam@designtools.co.nz> wrote:
>> 
>> [...]
>> 
>>> I must have missed the release of the 100MHz AVR 
>> 
>> 
>> They're up to 20 now.  And they've always been single-cycle machines.
>
>  I did see they even briefly 'hit 24MHz' until engineering caught up 
>with marketing :).

IIRC, that was when they were first introduced (and before I used
them).  The earliest databook I have is 1999.  The highest speed it
promises for any AVR is 12 MHz, and that only for the AT90S1200.  

>  I still have a 1996 AVR data book that claims they would
>all be 24MHz on release... Oh well, maybe 2005 will see it hit the
>'marketing target' ? :)
>
Most of the chips I use (ATmega16, ATmega32, ATmega8535) go up to 16
MHz.  20 MHz is available only on the newest parts (ATmega48/88/168),
but progress is being made.

[...]
><snip>
>>> Last time I looked at an AVR, the BOOLEAN handling was primitive, and
>> 
>> 
>> AVR has a Load/Store architecture -- most operations take place on
>> data in the registers.  Setting or clearing a bit in a register is one
>> single-cycle instruction (SBR, CBR).  The compilers I use reserve up
>> to 13 general-purpose registers (104 bits) for boolean storage.
>> Assigning the value of one boolean to another requires 2 single-cycle
>> instructions (BST/BLD).
>
>  But you have to trade off register resource for boolean, and once you 
>go outside the register space, the lack of direct opcodes in AVR means
>real pointer thrashing.....

Remember the AVR has almost as much register space as the 8051 has
data space.  OK, I'm exaggerating, but just a little.  The smallest
AVRs have no RAM other than the registers.  

I could reserve 24 registers for boolean variables (192 bits) and
still have as many general-purpose registers left as does the 8051.  I
wouldn't do that (well, never say never...), but I could.

If you do want to use RAM for boolean variables, remember that AVR
don' need no stinkin' DPTR.  To set bit 3 in variable (call it
"mask"), use

   lds   r3, mask
   sbr   r3, 08h
   sts   mask, r3

No pointer thrashing involved.  The worst that can be said is that it
is no longer atomic -- beware ISRs.  To set bit 1 of "mask" to the
value of bit 5 in "status,"

   lds   r3, status
   bst   r3, 5
   lds   r3, mask
   bld   r3, 1
   sts   mask, r3

But if "mask" and "status" are r4 and r5 respectively,

   bst   r5, 5
   bld   r4, 1

Still not atomic...  Dusting off my rusty 8051, that would be
(assuming "status" is at 0x20 and mask is at 0x21)

   jnb   5, clrbit
   setb  9
   jmp   done
clrbit:
   clr   9     ; why isn't it clrb?
done:
   

I forgot to mention the SBRC and SBRS instructions to test if a bit is
set or clear and branch (well, skip anyways) appropriately.

>  If it's in a HLL, who cares - but make sure there is a bigger code 
>version in the package you've chosen.

Atmel has been really good about that.  The AT90S8535, ATmega16,
ATmega32, and ATmega8535 (in the order in which I've used them) have
identical pinouts, with 8, 16, 32, and 8k flash, respectively.  There
may be others that will fit in the footprint, but I haven't looked
into it yet.  Haven't needed to.

And the AVR is quite C-friendly.  As I said before, avr-gcc works very
well (and in some cases generates better code than another commercial
compiler I use).

[...]
>> ARMs are overkill for most applications I've worked on the last 4
>> years.  The AVR does a really nice job at a low cost, and is
>> relatively C-friendly.  The avr-gcc compiler is very good.
>
>ARM maybe a technical overkill, but when they come sub $5, you need to
>think what you can do for that $5, and care less about waste-head-room.

Digikey's price for the industrial-temperature ATmega32 is sub $5 for
100.  I get them quite a bit less than that.  The only application I
have that feels pinched in a mega32 is I/O locked -- I'm using about
70% of the flash and 50% of the RAM.  Nothing else requires more than
14k of flash.

Most of my applications don't need a lot of fancy processor power.
They need I/O.

>In recent 80C51 designs I've done, quite a lot of the resource
>is unused - is that a problem ? - not if it essentially comes for free.

Oh, you paid for it.  ;-)  You're just not using it.  It's only a
problem if you are making large volumes, and a $0.10 cheaper micro
would swamp the NRE you would invest to get it to fit.

>
>
>> From a software standpoint, the AVR is my first choice for an 8-bit
>> microcontroller (If you haven't guessed that by now  ;-).  From a
>> hardware standpoint, the only real problem I've had is temperature
>> grades.
>
>  For that, you can always cover with the multi-sourced devices, like 
>80C51, or ARMs ... :)

We tend to go with PICs and Motorola (Freescale?) HC908 parts.
Because we have used them before, and we have the tools.  Also,
Microchip is almost prescient about what kind of micro we require --
they almost always have a micro with exactly the I/O we need in the
smallest possible package.  They came up just short with the 12F675 --
We needed one more I/O pin.  That project is going to an HC908QY4.
Which at 16 pins is quite a bit more than required, but comes in a
TSSOP package that is actually smaller than the PIC's 8-pin SOIC.

There's a real resistance here (from upper managament) to try a
different micro architecture unless we have a "motivated" vendor or
our customer has a list of "approved" micros that doesn't include the
ones we use.  Certainly not the most senseless edict to come down from
on high...

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Dave Hansen wrote:
> On Thu, 27 May 2004 10:05:53 +1200, Jim Granville
>>Dave Hansen wrote:
>>>On Wed, 26 May 2004 16:49:35 +1200, Jim Granville
>>>>I must have missed the release of the 100MHz AVR 
>>>
>>>They're up to 20 now.  And they've always been single-cycle machines.
>>
>> I did see they even briefly 'hit 24MHz' until engineering caught up 
>>with marketing :).
> IIRC, that was when they were first introduced (and before I used
> them).  

  Not quite: besides the 1996 Marketing MHz, the newest shrink
devices in 2004 were briefly spec'd at 24MHz, then revised
to 20MHz. ( eg ATtiny13 Data Sheet: 2535D Page 163 )
  Seems a classic case of Marketing vs engineering :)

<snip>
>> But you have to trade off register resource for boolean, and once you 
>>go outside the register space, the lack of direct opcodes in AVR means
>>real pointer thrashing.....
> 
> 
> Remember the AVR has almost as much register space as the 8051 has
> data space.  OK, I'm exaggerating, but just a little.  The smallest
> AVRs have no RAM other than the registers.  
> 
> I could reserve 24 registers for boolean variables (192 bits) and
> still have as many general-purpose registers left as does the 8051.  I
> wouldn't do that (well, never say never...), but I could.

..but remember, some AVR opcodes only work on half the registers...
(You have just turned your AVR into an 8048, not an 8051.)
Besides register opcodes, the 80C51 has many direct-memory opcodes.

<snip>
> No pointer thrashing involved.  The worst that can be said is that it
> is no longer atomic -- beware ISRs.  To set bit 1 of "mask" to the
> value of bit 5 in "status,"
> 
>    lds   r3, status
>    bst   r3, 5
>    lds   r3, mask
>    bld   r3, 1
>    sts   mask, r3
> 
> But if "mask" and "status" are r4 and r5 respectively,
> 
>    bst   r5, 5
>    bld   r4, 1
> 
> Still not atomic...  Dusting off my rusty 8051, that would be
> (assuming "status" is at 0x20 and mask is at 0x21)
> 
>    jnb   5, clrbit
>    setb  9
>    jmp   done
> clrbit:
>    clr   9     ; why isn't it clrb?

  clrb?, yes, good question - ask intel ?

In HLL Code of :  Mask := Status; would produce this code :
      MOV   C,Status
      MOV   Mask,C	
Smaller, clearer code, and no registers consumed.
Also works on 128 SFR Bits, including port pins.


<snip>
> 
> We tend to go with PICs and Motorola (Freescale?) HC908 parts.
> Because we have used them before, and we have the tools.  Also,
> Microchip is almost prescient about what kind of micro we require --
> they almost always have a micro with exactly the I/O we need in the
> smallest possible package.  They came up just short with the 12F675 --
> We needed one more I/O pin.  That project is going to an HC908QY4.
> Which at 16 pins is quite a bit more than required, but comes in a
> TSSOP package that is actually smaller than the PIC's 8-pin SOIC.

IIRC Microchip have some 14/16 pin models comming ?.
Seems to be a growth area, as vendors realise the size is 
similar/smaller than SO8, and you avoid being pin-bound.

-jg

On Thu, 27 May 2004 14:42:35 +1200, the renowned Jim Granville
<no.spam@designtools.co.nz> wrote:

>IIRC Microchip have some 14/16 pin models comming ?.
>Seems to be a growth area, as vendors realise the size is 
>similar/smaller than SO8, and you avoid being pin-bound.

Yes, available now, and quite competitively priced- just a bit more
than the 8-pin parts. But to hedge their bets they also are dangling a
"future product" 6-pin series available in SOT-23-6

http://ww1.microchip.com/downloads/en/DeviceDoc/41210B.pdf  


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Spehro Pefhany wrote:
> On Thu, 27 May 2004 14:42:35 +1200, the renowned Jim Granville
> <no.spam@designtools.co.nz> wrote:
>>IIRC Microchip have some 14/16 pin models comming ?.
>>Seems to be a growth area, as vendors realise the size is 
>>similar/smaller than SO8, and you avoid being pin-bound.
> 
> Yes, available now, and quite competitively priced- just a bit more
> than the 8-pin parts. But to hedge their bets they also are dangling a
> "future product" 6-pin series available in SOT-23-6
> 
> http://ww1.microchip.com/downloads/en/DeviceDoc/41210B.pdf  

I have to say, that's impressive.

So impressive, I'll give it a name : A PicoPIC :)

Price/delivery anyone ?

Their next logical product would be a SerialEE / PicoPIC combo :
looks like serial EE with HW SPI.i2c interface, but has a PicoPIC
on some dual-port basis.

-jg