first let me thanks everybody for the interresting answers.
This call for another question:
Do you know a good and CHEAP programmer for the ATMEL series of MCU ??
one that support the whole series but more certainly the mid-range 
including the AT89C55WD ??
Many thanks again
Andr�

Le 16/08/2012 13:57, Andre a �crit :
> first let me thanks everybody for the interresting answers.
> This call for another question:
> Do you know a good and CHEAP programmer for the ATMEL series of MCU ??
> one that support the whole series but more certainly the mid-range
> including the AT89C55WD ??
> Many thanks again
> Andr�
and BTW wath do you think about the ATAVRISP2 ??
and atmel-studio ??
Andr�

On 16/08/2012 14:04, Andre wrote:
> Le 16/08/2012 13:57, Andre a �crit :
>> first let me thanks everybody for the interresting answers.
>> This call for another question:
>> Do you know a good and CHEAP programmer for the ATMEL series of MCU ??
>> one that support the whole series but more certainly the mid-range
>> including the AT89C55WD ??
>> Many thanks again
>> Andr�

No sane person would move from one brain-dead cpu, the PIC, to another 
brain-dead cpu, the 8051.  The only possible reason why anyone would 
want to buy an AT89xxx or any other 8051-based CPU is because they are 
stuck with two decades of legacy 8051 code, and already have invested in 
Keil tools (which are vastly expensive, but much better than anything 
else for the 8051).

Atmel's AVRs are a different family, and a far better choice in every way.

> and BTW wath do you think about the ATAVRISP2 ??
> and atmel-studio ??
> Andr�

Atmel's AVRISP programmers are simple and reliable, and fairly cheap, 
but they are only for programming the chips - they don't do debugging. 
The AVR JTAG debuggers cost a bit more, but are also fine.  I don't know 
the current prices of these things.  Olimex used to make cheaper clones 
of the JTAG debuggers, but I don't think they do so now.

I have mixed opinions on Atmel Studio.  Up to version 4, it used Atmel's 
own IDE, which okay as an editor, but not as powerful as Eclipse, 
Notepad2, or any good programmers' editor.  The debugger worked well 
enough, as did the simulator and programmer.  Versions 5 and 6, however, 
are based on MS Visual Studio.  In my opinion, MSVS is pure bloatware - 
it is /huge/, even compared to Eclipse, and installs all sorts of bits 
and pieces that can mess up your system (MS software always does).  It 
is inconsistent with the current trend from most tool vendors (which is 
to move to Eclipse), stuck in a old-fashioned windows-only world, and 
generally a bad idea.

Having said that, people do seem to be able to use AS6 as an IDE for 
development.  I have even heard of people who think MSVS is a good IDE. 
  I guess there is no accounting for taste.

Atmel Studio comes with a full gcc toolchain.  You can also download 
command-line versions for the toolchain for Windows or Linux - which is 
great for people like me with a mixed development environment.

Le 16/08/2012 14:20, David Brown a �crit :
> On 16/08/2012 14:04, Andre wrote:
>> Le 16/08/2012 13:57, Andre a �crit :
>>> first let me thanks everybody for the interresting answers.
>>> This call for another question:
>>> Do you know a good and CHEAP programmer for the ATMEL series of MCU ??
>>> one that support the whole series but more certainly the mid-range
>>> including the AT89C55WD ??
>>> Many thanks again
>>> Andr�
>
> No sane person would move from one brain-dead cpu, the PIC, to another
> brain-dead cpu, the 8051. The only possible reason why anyone would want
> to buy an AT89xxx or any other 8051-based CPU is because they are stuck
> with two decades of legacy 8051 code, and already have invested in Keil
> tools (which are vastly expensive, but much better than anything else
> for the 8051).
>
> Atmel's AVRs are a different family, and a far better choice in every way.
>
>> and BTW wath do you think about the ATAVRISP2 ??
>> and atmel-studio ??
>> Andr�
>
> Atmel's AVRISP programmers are simple and reliable, and fairly cheap,
> but they are only for programming the chips - they don't do debugging.
> The AVR JTAG debuggers cost a bit more, but are also fine. I don't know
> the current prices of these things. Olimex used to make cheaper clones
> of the JTAG debuggers, but I don't think they do so now.
>
> I have mixed opinions on Atmel Studio. Up to version 4, it used Atmel's
> own IDE, which okay as an editor, but not as powerful as Eclipse,
> Notepad2, or any good programmers' editor. The debugger worked well
> enough, as did the simulator and programmer. Versions 5 and 6, however,
> are based on MS Visual Studio. In my opinion, MSVS is pure bloatware -
> it is /huge/, even compared to Eclipse, and installs all sorts of bits
> and pieces that can mess up your system (MS software always does). It is
> inconsistent with the current trend from most tool vendors (which is to
> move to Eclipse), stuck in a old-fashioned windows-only world, and
> generally a bad idea.
>
> Having said that, people do seem to be able to use AS6 as an IDE for
> development. I have even heard of people who think MSVS is a good IDE. I
> guess there is no accounting for taste.
>
> Atmel Studio comes with a full gcc toolchain. You can also download
> command-line versions for the toolchain for Windows or Linux - which is
> great for people like me with a mixed development environment.
>
I have no experiences regarding the 8051 architeture in fact I learned 
electronics about 40 years ago, worked on computer all the rest of my 
actve live, repairing them at begining, programing communication ( X25, 
SNA, ..) after, and finaly adminitsrating Unix servers.
And BTW electronic changes a lot since last I touch it.
But now as retaired..
Andr�

On Thursday, August 16, 2012 6:06:40 AM UTC-7, Andre wrote:
> Le 16/08/2012 14:20, David Brown a =E9crit :
>=20
> > On 16/08/2012 14:04, Andre wrote:
>=20
> >> Le 16/08/2012 13:57, Andre a =E9crit :
>=20
> >>> first let me thanks everybody for the interresting answers.
>=20
> >>> This call for another question:
>=20
> >>> Do you know a good and CHEAP programmer for the ATMEL series of MCU ?=
?
>=20
> >>> one that support the whole series but more certainly the mid-range
>=20
> >>> including the AT89C55WD ??
>=20
> >>> Many thanks again
>=20
> >>> Andr=E9
>=20
> >
>=20
> > No sane person would move from one brain-dead cpu, the PIC, to another
>=20
> > brain-dead cpu, the 8051. The only possible reason why anyone would wan=
t
>=20
> > to buy an AT89xxx or any other 8051-based CPU is because they are stuck
>=20
> > with two decades of legacy 8051 code, and already have invested in Keil
>=20
> > tools (which are vastly expensive, but much better than anything else
>=20
> > for the 8051).
>=20
> >
>=20
> > Atmel's AVRs are a different family, and a far better choice in every w=
ay.
>=20
> >
>=20
> >> and BTW wath do you think about the ATAVRISP2 ??
>=20
> >> and atmel-studio ??
>=20
> >> Andr=E9
>=20
> >
>=20
> > Atmel's AVRISP programmers are simple and reliable, and fairly cheap,
>=20
> > but they are only for programming the chips - they don't do debugging.
>=20
> > The AVR JTAG debuggers cost a bit more, but are also fine. I don't know
>=20
> > the current prices of these things. Olimex used to make cheaper clones
>=20
> > of the JTAG debuggers, but I don't think they do so now.
>=20
> >
>=20
> > I have mixed opinions on Atmel Studio. Up to version 4, it used Atmel's
>=20
> > own IDE, which okay as an editor, but not as powerful as Eclipse,
>=20
> > Notepad2, or any good programmers' editor. The debugger worked well
>=20
> > enough, as did the simulator and programmer. Versions 5 and 6, however,
>=20
> > are based on MS Visual Studio. In my opinion, MSVS is pure bloatware -
>=20
> > it is /huge/, even compared to Eclipse, and installs all sorts of bits
>=20
> > and pieces that can mess up your system (MS software always does). It i=
s
>=20
> > inconsistent with the current trend from most tool vendors (which is to
>=20
> > move to Eclipse), stuck in a old-fashioned windows-only world, and
>=20
> > generally a bad idea.
>=20
> >
>=20
> > Having said that, people do seem to be able to use AS6 as an IDE for
>=20
> > development. I have even heard of people who think MSVS is a good IDE. =
I
>=20
> > guess there is no accounting for taste.
>=20
> >
>=20
> > Atmel Studio comes with a full gcc toolchain. You can also download
>=20
> > command-line versions for the toolchain for Windows or Linux - which is
>=20
> > great for people like me with a mixed development environment.
>=20
> >
>=20
> I have no experiences regarding the 8051 architeture in fact I learned=20
>=20
> electronics about 40 years ago, worked on computer all the rest of my=20
>=20
> actve live, repairing them at begining, programing communication ( X25,=
=20
>=20
> SNA, ..) after, and finaly adminitsrating Unix servers.
>=20
> And BTW electronic changes a lot since last I touch it.
>=20
> But now as retaired..
>=20
> Andr=E9

If you are already familiar with PIC and running into code size limitation.=
  I suggest you go directly into PIC32.  The development environment is a b=
it more consistent across PIC, than to AVR, MSP or ARM.  PIC32 with 512K fl=
ash should have plenty of speed and memory to ignore optimizations.

On 16/08/12 16:02, me@linnix.info-for.us wrote:
> On Thursday, August 16, 2012 6:06:40 AM UTC-7, Andre wrote:
>> Le 16/08/2012 14:20, David Brown a �crit :
>>
>>> On 16/08/2012 14:04, Andre wrote:
>>
>>>> Le 16/08/2012 13:57, Andre a �crit :
>>
>>>>> first let me thanks everybody for the interresting answers.
>>
>>>>> This call for another question:
>>
>>>>> Do you know a good and CHEAP programmer for the ATMEL series of MCU ??
>>
>>>>> one that support the whole series but more certainly the mid-range
>>
>>>>> including the AT89C55WD ??
>>
>>>>> Many thanks again
>>
>>>>> Andr�
>>
>>>
>>
>>> No sane person would move from one brain-dead cpu, the PIC, to another
>>
>>> brain-dead cpu, the 8051. The only possible reason why anyone would want
>>
>>> to buy an AT89xxx or any other 8051-based CPU is because they are stuck
>>
>>> with two decades of legacy 8051 code, and already have invested in Keil
>>
>>> tools (which are vastly expensive, but much better than anything else
>>
>>> for the 8051).
>>
>>>
>>
>>> Atmel's AVRs are a different family, and a far better choice in every way.
>>
>>>
>>>
>>
>> I have no experiences regarding the 8051 architeture in fact I learned
>>
>> electronics about 40 years ago, worked on computer all the rest of my
>>
>> actve live, repairing them at begining, programing communication ( X25,
>>
>> SNA, ..) after, and finaly adminitsrating Unix servers.
>>
>> And BTW electronic changes a lot since last I touch it.
>>
>> But now as retaired..
>>
>> Andr�
>
 > If you are already familiar with PIC and running into code size
 > limitation.  I suggest you go directly into PIC32.  The development
 > environment is a bit more consistent across PIC, than to AVR, MSP or
 >  ARM.  PIC32 with 512K flash should have plenty of speed and memory
 > to ignore optimizations.

OT - what kind of hideous newsreader did you use to make such a mess of 
the quoting in that post, "me@linnix.info-for.us" ?   You've added lots 
of extra lines, breaking automatic re-formatting.


Anyway, Andr� - if you have never used an 8051, then don't go there now. 
  Make sure you only look at AVR chips from Atmel and not their 8051 series.

I don't think I would look at the PIC32.  Yes, it is a Microchip family 
with a solid CPU (being a MIPS cpu rather than one of their own 
designs).  But it is totally different from the PIC, and there is little 
to be gained here from the slight similarities in the design 
environment.  The AVR is going to be a lot easier to learn and work 
with, being a small microcontroller with a lot lower "getting started" 
barrier.

On Thu, 16 Aug 2012 20:09:56 +0200, David Brown
<david.brown@removethis.hesbynett.no> wrote:

><snip>
>Anyway, Andr=E9 - if you have never used an 8051, then don't go there =
now.=20
><snip>

I think this is good advice, broadly speaking. The 8051 was
incredible in its day. Seriously - a nice chip. But it is
seriously hampered in accessing external memory as data. Just
take a look at what is involved in something as basic as a
memcpy() for example.

It is very powerful in bit manipulation, though. So if you
don't need much memory for the application and you will be
mostly doing single-bit stuff in memory AND on the port pins,
then it's not so bad a chip. But in general it has fallen
behind what is now readily available.

The ONLY reason I used it was that the Cygnal (oh, yes,
SiLabs) C8051F061 provided the only 1Msps 16-bit ADC choice.
And the cost of the chip was less than a separate ADC would
be for any other processor. And it met my needs. But what a
pain pulling the rest of the chip along with that data rate!

Jon

On Thu, 16 Aug 2012 20:09:56 +0200, David Brown
<david.brown@removethis.hesbynett.no> wrote:

>Anyway, Andr� - if you have never used an 8051, then don't go there now. 
>  Make sure you only look at AVR chips from Atmel and not their 8051 series.
>
>I don't think I would look at the PIC32.  Yes, it is a Microchip family 
>with a solid CPU (being a MIPS cpu rather than one of their own 
>designs).  But it is totally different from the PIC, and there is little 
>to be gained here from the slight similarities in the design 
>environment.  The AVR is going to be a lot easier to learn and work 
>with, being a small microcontroller with a lot lower "getting started" 
>barrier.

While I agree that Atmel's AVRs are the go-to chips for 8-bitters with a
nice deep register set and all (no more single #%!$& WREG!), the OP
should be aware that they do use a Harvard architecture (separate
address spaces for code and data). Not a huge hurdle, and the compilers
make it mostly transparent, but something for him to keep in mind.

-- 
Rich Webb     Norfolk, VA

On 16/08/12 20:38, Jon Kirwan wrote:
> On Thu, 16 Aug 2012 20:09:56 +0200, David Brown
> <david.brown@removethis.hesbynett.no>  wrote:
>
>> <snip>
>> Anyway, Andr� - if you have never used an 8051, then don't go there now.
>> <snip>
>
> I think this is good advice, broadly speaking. The 8051 was
> incredible in its day. Seriously - a nice chip. But it is
> seriously hampered in accessing external memory as data. Just
> take a look at what is involved in something as basic as a
> memcpy() for example.

Yes, it was powerful in its day - but its day was some 30 years ago! 
For the last 15 years at least, it has only existed because it is 
popular, and it is only popular because it is popular, not because it is 
a technically or economically good choice (somewhat like the x86 
architecture, or most MS software).

>
> It is very powerful in bit manipulation, though. So if you
> don't need much memory for the application and you will be
> mostly doing single-bit stuff in memory AND on the port pins,
> then it's not so bad a chip. But in general it has fallen
> behind what is now readily available.

It has a few powerful bit manipulation instructions - that's true 
enough.  But how often do you /really/ need single-instruction bit 
manipulation?  Most alternatives can do the same function in a maximum 
of three instructions - and they run at least 3 times as quickly.  So in 
its day, features like the bit manipulation instructions were special - 
but they have long since ceased to be exciting.

>
> The ONLY reason I used it was that the Cygnal (oh, yes,
> SiLabs) C8051F061 provided the only 1Msps 16-bit ADC choice.
> And the cost of the chip was less than a separate ADC would
> be for any other processor. And it met my needs. But what a
> pain pulling the rest of the chip along with that data rate!
>
> Jon

Yes, that is the one good reason for using an 8051 - there are some 
manufacturers who want to take a good chip (typically an analogue chip 
or a wireless chip) and add a processor core.  In those cases, 8051 
cores are an easy and cheap solution for the manufacturer - despite the 
frustration it causes for potential customers - because it is "industry 
standard".  The lowest possible common denominator.

Fortunately, many manufacturers are moving on to the new "industry 
standard", Cortex-M cores, which are vastly better in every way.

Of course, in 30 years time I'll be complaining about manufacturers that 
are still using ancient brain-dead Cortex-M3 cores :-)

On 16/08/12 21:19, Rich Webb wrote:
> On Thu, 16 Aug 2012 20:09:56 +0200, David Brown
> <david.brown@removethis.hesbynett.no>  wrote:
>
>> Anyway, Andr� - if you have never used an 8051, then don't go there now.
>>   Make sure you only look at AVR chips from Atmel and not their 8051 series.
>>
>> I don't think I would look at the PIC32.  Yes, it is a Microchip family
>> with a solid CPU (being a MIPS cpu rather than one of their own
>> designs).  But it is totally different from the PIC, and there is little
>> to be gained here from the slight similarities in the design
>> environment.  The AVR is going to be a lot easier to learn and work
>> with, being a small microcontroller with a lot lower "getting started"
>> barrier.
>
> While I agree that Atmel's AVRs are the go-to chips for 8-bitters with a
> nice deep register set and all (no more single #%!$&  WREG!), the OP
> should be aware that they do use a Harvard architecture (separate
> address spaces for code and data). Not a huge hurdle, and the compilers
> make it mostly transparent, but something for him to keep in mind.
>

Yes indeed - the AVR core has a few serious design flaws that make it 
more annoying that it need be.  The separate address spaces is one of 
them, and the limited pointer registers is another (though that is 
completely hidden by the compiler).  Like any 8-bit or 16-bit device, 
you run into inconveniences whenever you have to deal with greater than 
64K address spaces.  All these points you can avoid by jumping to 32-bit 
Cortex cores.

However, in comparison to a PIC (or 8051), the limitations of the AVR 
core are very minor - and they are otherwise nice chips.

On 2012-08-16, David Brown <david.brown@removethis.hesbynett.no> wrote:
> On 16/08/12 20:38, Jon Kirwan wrote:
>> On Thu, 16 Aug 2012 20:09:56 +0200, David Brown
>> <david.brown@removethis.hesbynett.no>  wrote:
>>
>>> <snip>
>>> Anyway, Andr? - if you have never used an 8051, then don't go there now.
>>> <snip>
>>
>> I think this is good advice, broadly speaking. The 8051 was
>> incredible in its day. Seriously - a nice chip. But it is
>> seriously hampered in accessing external memory as data. Just
>> take a look at what is involved in something as basic as a
>> memcpy() for example.
>
> Yes, it was powerful in its day - but its day was some 30 years ago! 
> For the last 15 years at least, it has only existed because it is 
> popular, and it is only popular because it is popular, not because it is 
> a technically or economically good choice (somewhat like the x86 
> architecture, or most MS software).

Well said.


If you're starting out right now,  I'd recommend:

 * Atmel AVR for cheap 8-bit.

 * TI MSP430 for cheap 16-bit.

There are dozens and dozens of cheap eval/demo boards for both of the
above. [Don't bother with the MSP430 'X' parts which try to be 20-bit
processors -- if you want more than 64K of address space, jump to an
ARM part.]

Do not, under any conditions, touch a PIC part the CPU architecture is
_amazingly_ awful.  8051 is slightly less painful, but it's still bad
compared to an AVR or MSP430.  Personally, I think the MSP430 is
easier to use than the AVR (especially if you end up doing any
assembly language stuff), but the AVR is still good.

 * ARM Cortex-M for cheap 32-bit.

There are about a half-dozen uC vendors to choose from (NXP, 
TI/Stellaris, Motorola, Samsung, Toshiba, and so on.).

The above are all available as single-chip solutions (on-chip SRAM and
flash).  If you want to use external flash and SDRAM (e.g. to run
Linux), then I'd go with:
  
 * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)

GCC is avaialable for all the above.  Once you've learned how to use
gcc and gnu binutils, those skills apply to everything from an AVR/MSP
with 8K of flash and 256 bytes of RAM to an IBM system Z "mainframe".

-- 
Grant Edwards               grant.b.edwards        Yow! My haircut is totally
                                  at               traditional!
                              gmail.com            

In article <k0jm3k$mmc$1@reader1.panix.com>, invalid@invalid.invalid 
says...
> 
> On 2012-08-16, David Brown <david.brown@removethis.hesbynett.no> wrote:
> > On 16/08/12 20:38, Jon Kirwan wrote:
> >> On Thu, 16 Aug 2012 20:09:56 +0200, David Brown
> >> <david.brown@removethis.hesbynett.no>  wrote:
> >>
> >>> <snip>
> >>> Anyway, Andr? - if you have never used an 8051, then don't go there now.
> >>> <snip>
> >>
> >> I think this is good advice, broadly speaking. The 8051 was
> >> incredible in its day. Seriously - a nice chip. But it is
> >> seriously hampered in accessing external memory as data. Just
> >> take a look at what is involved in something as basic as a
> >> memcpy() for example.
> >
> > Yes, it was powerful in its day - but its day was some 30 years ago! 
> > For the last 15 years at least, it has only existed because it is 
> > popular, and it is only popular because it is popular, not because it is 
> > a technically or economically good choice (somewhat like the x86 
> > architecture, or most MS software).
> 
> Well said.
> 
> 
> If you're starting out right now,  I'd recommend:
> 
>  * Atmel AVR for cheap 8-bit.
> 
>  * TI MSP430 for cheap 16-bit.
> 
> There are dozens and dozens of cheap eval/demo boards for both of the
> above. [Don't bother with the MSP430 'X' parts which try to be 20-bit
> processors -- if you want more than 64K of address space, jump to an
> ARM part.]
> 
> Do not, under any conditions, touch a PIC part the CPU architecture is
> _amazingly_ awful.  8051 is slightly less painful, but it's still bad
> compared to an AVR or MSP430.  Personally, I think the MSP430 is
> easier to use than the AVR (especially if you end up doing any
> assembly language stuff), but the AVR is still good

I've only looked briefly at the AVR, but I've done a dozen designs with 
various MSP430 variants.  I've used some of the larger flash versions, 
but never had to use more than about 36K of that program memory.  I used 
the larger chips mostly because the later versions have faster clock 
rates.  The one limitation that I think about most is the limited RAM---
about 10K in the versions I've used.  If you need a big buffer to accept 
interrupt-driven input while you handle the vagaries of SD card write 
timing, that 10K can seem a bit limited.

If you need big buffers (such as for a camera), it's time to move up to
a Cortex M3 or M4.  You can start at 64K  RAM and go up to 160K without
much searching.
> 
>  * ARM Cortex-M for cheap 32-bit.
> 
> There are about a half-dozen uC vendors to choose from (NXP, 
> TI/Stellaris, Motorola, Samsung, Toshiba, and so on.).

And ST.  I've been pretty happy with the peripherals and supporting
libraries for the STM32 chips.
> 
> The above are all available as single-chip solutions (on-chip SRAM and
> flash).  If you want to use external flash and SDRAM (e.g. to run
> Linux), then I'd go with:
>   
>  * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)

Yup.  160K RAM hardly gets you started on an OS which wants lots of
buffers for ethernet stacks, file system, video and USB drivers.  
Beagleboards and their kin are good place to start here.  I worked in 
that area for half a year----but I'm really happier down in the Cortex 
and MSP430 environment.
> 
> GCC is avaialable for all the above.  Once you've learned how to use
> gcc and gnu binutils, those skills apply to everything from an AVR/MSP
> with 8K of flash and 256 bytes of RAM to an IBM system Z "mainframe".


Mark Borgerson

On 2012-08-17, Mark Borgerson <mborgerson@comcast.net> wrote:

> I've only looked briefly at the AVR, but I've done a dozen designs with 
> various MSP430 variants.

The main annoyance in the AVR is that it's strictly an 8-bit CPU.  It
can't really do any 16-bit operations.  That would be fine if it had
an 8 bit address space, but it's got two different 16-bit address
spaces.  So, if you need to do anything at all with pointers (and C is
designed to use pointers quite a bit) the AVR falls down badly
compared to the MSP430 -- which has sixteen 16-bit registers, a single
16-bit address space, and a very elegent, orthogonal instructions set
(rather reminiscent of the PDP-11) where any register can be used as a
pointer, accumulator, index, whatever.

The old "8-bit" 8080/Z80 and 6800/6502 processors had a 1 or 2 16-bit
registers and a couple 16-bit operations specifically to deal with the
pointer issue.  Unfortuantely, the AVR failed to learn from them and
is missing those features -- and it hurts.

>> The above are all available as single-chip solutions (on-chip SRAM and
>> flash).  If you want to use external flash and SDRAM (e.g. to run
>> Linux), then I'd go with:
>>   
>>  * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)
>
> Yup.  160K RAM hardly gets you started on an OS which wants lots of
> buffers for ethernet stacks, file system, video and USB drivers.

I should add that there are a _few_ (very few) Cortex-M parts that
have external busses and include SDRAM controllers (NXP has one
family), so it is possible to do large-memory stuff with Cortex-M.
But, it's far more common to move up to the Cortex-A or the slightly
older ARM9 families if you need memory measured in MB rather than KB.

> Beagleboards and their kin are good place to start here.  I worked in
> that area for half a year----but I'm really happier down in the
> Cortex and MSP430 environment.

-- 
Grant Edwards               grant.b.edwards        Yow! I joined scientology
                                  at               at a garage sale!!
                              gmail.com            

On 17/08/2012 15:17, Grant Edwards wrote:
> On 2012-08-17, Mark Borgerson <mborgerson@comcast.net> wrote:
>
>> I've only looked briefly at the AVR, but I've done a dozen designs with
>> various MSP430 variants.
>
> The main annoyance in the AVR is that it's strictly an 8-bit CPU.  It
> can't really do any 16-bit operations.  That would be fine if it had
> an 8 bit address space, but it's got two different 16-bit address
> spaces.  So, if you need to do anything at all with pointers (and C is
> designed to use pointers quite a bit) the AVR falls down badly
> compared to the MSP430 -- which has sixteen 16-bit registers, a single
> 16-bit address space, and a very elegent, orthogonal instructions set
> (rather reminiscent of the PDP-11) where any register can be used as a
> pointer, accumulator, index, whatever.
>
> The old "8-bit" 8080/Z80 and 6800/6502 processors had a 1 or 2 16-bit
> registers and a couple 16-bit operations specifically to deal with the
> pointer issue.  Unfortuantely, the AVR failed to learn from them and
> is missing those features -- and it hurts.

Strictly speaking, the AVR also has 16-bit registers (X, Y and Z) made 
from pairs of 8-bit registers, and it has a few 16-bit operations (such 
as addiw, subiw and movw).  But it would have benefited enormously from 
a forth pointer register, better addressing modes with these registers, 
and a few extra instructions (such as 16-bit atomic moves between the SP 
and a pointer register).

>
>>> The above are all available as single-chip solutions (on-chip SRAM and
>>> flash).  If you want to use external flash and SDRAM (e.g. to run
>>> Linux), then I'd go with:
>>>
>>>   * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)
>>
>> Yup.  160K RAM hardly gets you started on an OS which wants lots of
>> buffers for ethernet stacks, file system, video and USB drivers.
>
> I should add that there are a _few_ (very few) Cortex-M parts that
> have external busses and include SDRAM controllers (NXP has one
> family), so it is possible to do large-memory stuff with Cortex-M.

Some Freescale Kinetis (Cortex-M4) parts have external memory buses, IIRC.

> But, it's far more common to move up to the Cortex-A or the slightly
> older ARM9 families if you need memory measured in MB rather than KB.
>
>> Beagleboards and their kin are good place to start here.  I worked in
>> that area for half a year----but I'm really happier down in the
>> Cortex and MSP430 environment.
>

David Brown wrote:

> "But it would have benefited enormously from > a forth pointer register,"

Not you, too! :)

> On 17/08/2012 15:17, Grant Edwards wrote:
[ ... ]
>> The old "8-bit" 8080/Z80 and 6800/6502 processors had a 1 or 2 16-bit
>> registers and a couple 16-bit operations specifically to deal with the
>> pointer issue.  Unfortuantely, the AVR failed to learn from them and
>> is missing those features -- and it hurts.
> 
> Strictly speaking, the AVR also has 16-bit registers (X, Y and Z) made
> from pairs of 8-bit registers, and it has a few 16-bit operations (such
> as addiw, subiw and movw).  But it would have benefited enormously from
> a forth pointer register, better addressing modes with these registers,
> and a few extra instructions (such as 16-bit atomic moves between the SP
> and a pointer register).

Grant Edwards was more dramatic than I would have been, but the 8-bit roots 
show in all the doubled-up instructions below.  A lot of potential pointer 
problems go away because gcc has inlined the heck out of the code, and much 
of the parameter passing has vanished (less obvious here than in other 
snippets, I guess):

	unsigned char led, i, w;
	int mask, val, pwm;
	
	// randomize time to next interrupt ..
	for (i=0, w=0; i < (127/32); i++)	// randomly pick a number 
[31/32 .. 1+1/32) scaled into 8 bits
		w = w * 2 + random_bit();
  a2:	33 0f       	add	r19, r19

unsigned short lfsr = 0xACE1u;
static int random_bit ()
{
	// taps: 16 14 13 11; characteristic polynomial: x^16 + x^14 + 
x^13 + x^11 + 1
	lfsr = (lfsr >> 1) ^ (-(lfsr & 1u) & 0xB400u);
  a4:	ca 01       	movw	r24, r20
  a6:	96 95       	lsr	r25
  a8:	87 95       	ror	r24
  aa:	44 27       	eor	r20, r20
  ac:	55 27       	eor	r21, r21
  ae:	46 1b       	sub	r20, r22
  b0:	57 0b       	sbc	r21, r23
  b2:	40 70       	andi	r20, 0x00	; 0
  b4:	54 7b       	andi	r21, 0xB4	; 180
  b6:	48 27       	eor	r20, r24
  b8:	59 27       	eor	r21, r25
	unsigned char led, i, w;
	int mask, val, pwm;
	
	// randomize time to next interrupt ..
	for (i=0, w=0; i < (127/32); i++)	// randomly pick a number 
[31/32 .. 1+1/32) scaled into 8 bits
		w = w * 2 + random_bit();
  ba:	ba 01       	movw	r22, r20
  bc:	61 70       	andi	r22, 0x01	; 1
  be:	70 70       	andi	r23, 0x00	; 0
  c0:	36 0f       	add	r19, r22

On Fri, 17 Aug 2012 13:17:16 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2012-08-17, Mark Borgerson <mborgerson@comcast.net> wrote:
>
>> I've only looked briefly at the AVR, but I've done a dozen designs with 
>> various MSP430 variants.
>
>The main annoyance in the AVR is that it's strictly an 8-bit CPU.  It
>can't really do any 16-bit operations.  That would be fine if it had
>an 8 bit address space, but it's got two different 16-bit address
>spaces.  So, if you need to do anything at all with pointers (and C is
>designed to use pointers quite a bit) the AVR falls down badly
>compared to the MSP430 -- which has sixteen 16-bit registers, a single
>16-bit address space, and a very elegent, orthogonal instructions set
>(rather reminiscent of the PDP-11) where any register can be used as a
>pointer, accumulator, index, whatever.
>
>The old "8-bit" 8080/Z80 and 6800/6502 processors had a 1 or 2 16-bit
>registers and a couple 16-bit operations specifically to deal with the
>pointer issue.  Unfortuantely, the AVR failed to learn from them and
>is missing those features -- and it hurts.


The 6800 had a couple of 16-bit registers (the stack pointer and index
register, plus, of course the PC), and you do some limited operations
on X (load, store, compare, increment, decrement).

On the 6502, OTOH, neither the stack pointer*, or either of the index
registers, X and Y, were 16 bit.  But 6502 had a few very useful
zero-page indirect addressing modes, which allowed using most of the
first 256 bytes of memory as a collection of 16-bit index registers.


*The 8-bit stack pointer was possibly the single biggest annoyance on
the 6502.  Or maybe the lack of a zero-page indirect addressing mode
that *didn't* also use X or Y�

On Thursday, August 16, 2012 11:57:44 PM UTC+12, Andre wrote:
> Do you know a good and CHEAP programmer for the ATMEL series of MCU ??
> 
> one that support the whole series but more certainly the mid-range 
> 
> including the AT89C55WD ??

Do you have a dusty drawer full of AT89C55WD ?

 If you want low cost, easy to use, the new Atmel AT89LP series are supported by Atmel web programmers.

 Or, look at SiLabs C8051F5xx series tool sticks, programming AND Debug for around $20-$30.
 Or the Zilog Z51F series, you can get going for ~$29, again programming AND debug.

 The parts above are all wide Supply, which is rather harder to find in 32 bit variants.

-jg

On Aug 17, 9:13=A0pm, Robert Wessel <robertwess...@yahoo.com> wrote:
> ...
> The 6800 had a couple of 16-bit registers (the stack pointer and index
> register, plus, of course the PC), and you do some limited operations
> on X (load, store, compare, increment, decrement).

And TSX/TXS... whoever has written lots of SWI handlers will
remember those well (including the +1/-1 ...). They lived on the HC11,
probably on the 12 (whatever they call that today) to this day.

The 6809 was a huge step forward but did not make it into the future,
it came too late (although I learned the trade mostly on it), the 68k
came out and changed the game entirely.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

Grant Edwards <invalid@invalid.invalid> wrote:
> The above are all available as single-chip solutions (on-chip SRAM and
> flash).  If you want to use external flash and SDRAM (e.g. to run
> Linux), then I'd go with:
>  
> * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)

If you just need the memory, at least ST, TI and Fujitsu have Cortex-M3s 
with external memory buses and built-in SDRAM/flash memory controllers.

-a

On Friday, August 24, 2012 11:25:40 AM UTC-7, (unknown) wrote:
> Grant Edwards <invalid@invalid.invalid> wrote:
> 
> > The above are all available as single-chip solutions (on-chip SRAM and
> 
> > flash).  If you want to use external flash and SDRAM (e.g. to run
> 
> > Linux), then I'd go with:
> 
> >  
> 
> > * ARM9 or Cortex-A (Atmel, TI, Motorla, etc.)
> 
> 
> 
> If you just need the memory, at least ST, TI and Fujitsu have Cortex-M3s 
> 
> with external memory buses and built-in SDRAM/flash memory controllers.
 
Also NXP.