On Feb 19, 1:32 pm, "linnix" <m...@linnix.info-for.us> wrote:
> > * For small projects I look at how familiar I am with the chip,
> >    because it takes time to spin up on a new architecture.  For
> >    large projects I figure that the time to learn the new
> >    architecture and the expense of new tools will be paid back
> >    in efficiency as time goes on -- this is obviously a judgment
> >    call, and one that should be made carefully.
>
> If it's my choice, I pick the micro and ask for additional money for
> different micro.  For example:
>
> 1. Arm (cost)
> 2. Avr (cost + 100)
> 3. Freescale (cost + 300)
> 4. MSP (cost + 500)
> 5. PIC (cost + 1000)
>
> I will do any micro with the right price.  Otherwise, I prefer ARM M3
> Cortex nowaday, except for very low power and code density with AVR.
> ARM M3 is around 30% higher in power and 40% higher in code space than
> AVR, but a non-issue most of the time.
>
> The LMI chips meet most of what I need, except for the relatively new
> company.  TI and ST are coming on-line with M3 soon.  Hopefully, they
> will have parts close enough to LMI.

A lot of people seem to think that the ARM 32 bit MCUs have some power
disadvantage compared to the 8 bit MCUs.  I have not seen it myself.
The CM3 devices from Luminary Micro are not as low power, but then
they are the first generation.

I have looked at the AVRs and many of the other processors and, other
than the sleep mode where some individual parts are highly optimized,
the SAM7 and LPC2xxx parts are neck and neck with nearly all 8 bit
parts.  The SAM7 parts are about 0.5 mA/MHz even while running at full
speed with parallel I/O, UART, SPI and TWI all running.  That is about
the same power consumption as the 8 bit parts.

Another thing I consider a red herring is code density.  I don't care
if one processor uses 40% more Flash space.  I just care that I can
make my app fit in a given part at a given price.  The SAM7 parts are
cheaper than the AVR parts at a given Flash size, so even if I have to
bump up to the next size flash it is still a break even on price.
With the SAM7 parts reaching 512 KB of Flash, I don't see Flash size
being a limitation compared to any of the 8 bit parts.

So why consider a 8 bit MCU at all at this point unless there is some
peculiar need that the ARMs can't satisfy?  For general processing,
including power constrained processing apps, the ARMs are pretty hard
to beat.

Herbert Kleebauer ha scritto:

> ftp://137.193.64.130/pub/assembler/uhr_e.pdf
I found more readable the Atmel.
Anyway seems Atmel AVR assembler v2 will be better.

"Herbert Kleebauer" <klee@unibwm.de> skrev i meddelandet 
news:45DAB907.78C5998F@unibwm.de...
> "[Frank]" wrote:
>>
>> I'm new to microcontrollers world.
>>
>> I have only a little experience with Z80 based systems.
>>
>> I saw some Atmel AVR's sources and I loved it: very clear.
>
> I suppose this wasn't an assembly source. If you choose the
> AVR, you better forget the ATMEL assembler and write your
> own.

Or use the Free IAR Assembler
-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

"steve" <bungalow_steve@yahoo.com> wrote in message
news:1171926117.400805.3150@q2g2000cwa.googlegroups.com...
> On Feb 19, 5:30 pm, "Aly" <,shfskf...@sliuflky4iuhdf.erl> wrote:
> > "larwe" <zwsdot...@gmail.com> wrote in message
> >
> > news:1171910012.299179.171790@m58g2000cwm.googlegroups.com...
> > <SNIP>
> >
<SNIP>
>0nanoseconds!!
>
> 24 bit? divide alone is 18 cycles on a dsPIC.
>
>

You don't use the implemented MUL and DIV style instructions.  You develop
your own through bit manipulation and shifting.  ;-)

"[Frank]" wrote:
> 
> I'm new to microcontrollers world.
> 
> I have only a little experience with Z80 based systems.
> 
> I saw some Atmel AVR's sources and I loved it: very clear.

I suppose this wasn't an assembly source. If you choose the
AVR, you better forget the ATMEL assembler and write your
own. I can tolerate crippled hardware (you have to make 
compromises if you want small and cheap chips) but there
is no reason to use a confusing assembly syntax. Here a
example of a simple program, once written with the Atmel
assembler and once written with a clean syntax for the
AVR:

ftp://137.193.64.130/pub/assembler/uhr_e.pdf

Jim Granville wrote:
> [Frank] wrote:
>> I'm new to microcontrollers world.
>> 
>> I have only a little experience with Z80 based systems.
>> 
>> I saw some Atmel AVR's sources and I loved it: very clear.
>> 
>> Someone suggest me to start with PIC, someone else with AVR.
>> 
>> The net is full of doc/projects about PIC and give me a bit of 
>> confusione; AVR much less...instead.
>> 
>> What do you think about? What's the best approach for a beginner?
> 
> Download the tool sets and try them. Find one you like.
> 
> Or choose an application, and work backwards from there.
> 
> I suggest you also look at SiLabs C8051F family, and their ToolSticks TI
> MSP 430 family, Similar toolsticks, but no 5V parts Zilog's devices,
> since you already have some background there eZ80, Z8F, ZENO etc 
> Freescale, who are having a push on their smaller parts.
> 
> -jg

I second JG on his Zilog mention. They have a few different families, and
quite a lot of different parts in the Z8 Encore! (XP or not) one.

The main Z8 Encore! advantages I see are:
- very low cost dev kits, including USB probes
- free development environment: asm, unlimited C compiler, debugger, ...
- good documentation
- not a choice of peripherals as wide as Microchip's, but good ones (one of
Zilog's historical strengths)
- low cost chips, and they're available in DIP packages! (Someone with more
experience and buying budget might give you a more accurate picture when it
comes to large-quantity prices.)

I must say I'm biased, as for some reason I'm very much at home with the
Zilog chips, much more than with other architectures. I like their assembly,
the way they're set up and so on, but of course you would have to check for
yourself, Z80 background or not.

The ZNEOs, the new 16-bitters in the family, seem to be very very nice
chips. Well I say 16-bitters, but actually they're 32-bit chips with a
24-bit address space and a 16-bit bus width... Their design is clean, and
although I have not yet taken the time to do a proper systematic analysis,
they seem to be close to a Z80000 running in Z8000 mode (ie with the 24 bits
address space, just like the Z8001). That would make them very much like the
Motorola 68000, with the possibility of evolution to a full 32-bit chip.
They're fairly orthogonal, and with 16 general-purpose registers they're
much more modern designs than the Z80/eZ80.

As with the Z8s, some low-cost dev kits are available, with free tools. Not
many parts yet though, basically variants of the same one with different
Flash and RAM sizes and with/without the external bus. This core's first
silicon errata also shows an annoying bug in the stack frame handling, so
you might want to wait for a new revision to bypass this issue.


OK, enough of the shameless plug. Zilog, you owe me on this one. :)

If you're planning on learning and experimenting with those chips, low-cost
kits and tools and DIP packages are pretty useful. But if you want to do
this for a living, at any rate follow all advice given to you by the wise
people of this NG: play with the tools, design you application and go
backwards from there. Best way to get the right part for the job.

Regards,
D.

Terran Melconian wrote:
> On 2007-02-19, Tim Wescott <tim@seemywebsite.com> wrote:
> 
>>* Do the pins have enough oomph to do what I want?  A circuit with
>>   a processor and a bunch of drivers is much larger than a circuit
>>   with just a processor.  IIRC the PIC and the TI MPS430 excel at
>>   this.
> 
> 
> AVRs certainly do not, anyway.  In fact, Atmel is taking the AVRs in the
> opposite direction, and has halved the specified source and sink current
> recently in some newer parts (e.g. TinyX61).  Very disappointing for us!
> I hope they reconsider.

Very unlikely.
There is a general trend downwards in drive ability in uC, as they push 
the die sizes down. 8-10mA is now a common spec point, with PIN maxs
in the region of 25mA, and package Max's 100-200mA.

If you want more on one pin, add a transistor.

If you want to push many-pin drive, you are better with CPLDs, where the
package limits are 500mA @ 44pin or 1000mA @ 100pin

-jg

Aly wrote:
> "larwe" <zwsdotcom@gmail.com> wrote in message 
> news:1171910012.299179.171790@m58g2000cwm.googlegroups.com... <SNIP>
>> but it's simply less weird than PIC
>> 
> 
> Now that bit definitely is true.  The PIC achitecture sure is weird.  But
>  I've been coding PICs in assembler for what must be about 2-years now so
> am almost used to it.
> 
> The PIC makes you think, ALOT.  But I find there are things you can do
> with them that are just mind boggling amazing.  Being able to multiply
> and divide a 24-bit number in 4 clock cycles on a 40 MIPS dsPIC makes you
> wonder where you'd been all your life.  That's like 100nanoseconds!!
> 
> But PICs sure are weird.  As I have become programming them.
> 
> Also, each PIC release architecture is almost drastically different from
> the next, ie. 12F, 16F, 18F, 30F.  Things like getting used to having the
> target register on the left, is now on the right.  Perculiar stuff like
> that.
> 
> The PICs though I find a joy to program.

 From what I've read of the specs, the dsPIC is a whole new beast, very
different from its little PIC siblings. I also remember reading something
about an engineer at Microchip saying that basically the dsPIC was a new
core with just a bit of PIC likeliness bolted on.

YMMV as usual, but while I tend to seriously dislike the PICs, I'm quite
neutral regarding the dsPIC. It seems to be a clean and nice design; I'll
wait until I'll actually work with it to make up my mind.

Regards,
D.

On Feb 19, 5:30 pm, "Aly" <,shfskf...@sliuflky4iuhdf.erl> wrote:
> "larwe" <zwsdot...@gmail.com> wrote in message
>
> news:1171910012.299179.171790@m58g2000cwm.googlegroups.com...
> <SNIP>
>
>
>
> > but it's simply less weird than PIC
>
> Now that bit definitely is true.  The PIC achitecture sure is weird.  But
> I've been coding PICs in assembler for what must be about 2-years now so am
> almost used to it.
>
> The PIC makes you think, ALOT.  But I find there are things you can do with
> them that are just mind boggling amazing.  Being able to multiply and divide
> a 24-bit number in 4 clock cycles on a 40 MIPS dsPIC makes you wonder where
> you'd been all your life.  That's like 100nanoseconds!!

24 bit? divide alone is 18 cycles on a dsPIC.

On Feb 19, 2:30 pm, "Aly" <,shfskf...@sliuflky4iuhdf.erl> wrote:
> "larwe" <zwsdot...@gmail.com> wrote in message
>
> news:1171910012.299179.171790@m58g2000cwm.googlegroups.com...
> <SNIP>
>
>
>
> > but it's simply less weird than PIC
>
> Now that bit definitely is true.  The PIC achitecture sure is weird.  But
> I've been coding PICs in assembler for what must be about 2-years now so am
> almost used to it.
>
> The PIC makes you think, ALOT.  But I find there are things you can do with
> them that are just mind boggling amazing.  Being able to multiply and divide
> a 24-bit number in 4 clock cycles on a 40 MIPS dsPIC makes you wonder where
> you'd been all your life.  That's like 100nanoseconds!!

Not bad for 10M 24 bits.

I haven't check it yet, so not sure about /.
Arm M3 core claims to have single cycle 32 bits at 50 MHz.
20 nanoseconds 32 bits multipler for $3 is simply amazing.

>
> But PICs sure are weird.  As I have become programming them.
>
> Also, each PIC release architecture is almost drastically different from the
> next, ie. 12F, 16F, 18F, 30F.  Things like getting used to having the target
> register on the left, is now on the right.  Perculiar stuff like that.
>
> The PICs though I find a joy to program.