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.