Atmel ATmega128 - would you use it in a new design?

I recently picked up H8/300H again after a decade or so. Depending on your volume, Renesas are very hungry at the moment. The tools just work and whatever we need just arrives.

We have run TCP/IP on both H8/300H and H8S. IF you want to stay with Renesas, there'a always the new RX core. Otherwise, there's a vast number of ARM/Cortex parts to play with or Coldfire or any number of other 32 bit cores.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

They fund the people in India to support the GNU tools for H8/H/S/HS/HSX/LX.

I have had a few dealings with H8 families (see sig), never used H8/300 always used H8/300H or above.

Other than long ago debacles of 3048 and eventually 3048B, most of the time the silicon and tools work, just as much as most companies.

Most H8/300H and above can easily handle that with 16MB plus address space as well.

There have been various TCP/IP stacks ported to H8/300H and H8/300HS. See links pages from sig page.

Unless of course you want Gigabit then you will need much larger CPU and RAM, with higher bus bandwidth.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

The TINY2313 should be a virtual 'drop in'.

Chose one of the XMega chips.....

Am 01.06.2010 18:56, schrieb Peter:

I'd go for a Cortex M3 device - powerful, cheap, and parts available from at least half a dozen vendors: Atmel, TI, STM, NXP, Toshiba, EFM, ... If you consider how long the ARM7 is in use, it is a safe bet that the ARM Cortex family will still be alive in 10 to 15 years. Plus you won't depend on a single vendor.

Downside: All Cortex devices share the core, which contains the CPU, Interrupt Controller, Systick Timer, Debug Unit. The peripherials and the pinouts are different from vendor to vendor and from product line to product line. For the ARM7 controllers only the CPU core was common, everything else was vendor specific, so you don't want to start with them now. You might have to face a board redesign in 10 years (or even want one in order to use newer, cheaper parts with lower power consumption), but the overall impact to the product and the firmware is going to be rather low.

--
Mit freundlichen Grüßen

Frank-Christian Krügel

Peter skrev: > I have a product which has been running for 16 years, based on a > Hitachi H8/323 (16k PROM, 48k external address space). >

I think that if you need to have a 20 pin packages, there are plenty of AVR options.

ATtiny2313. ATtiny4313 ATtiny26 (although I dont recommend this) ATtiny261 ATtiny461 ATtiny861

As long as the marketshare is growing, at the expense of Microchip and others, I guess Atmel plans to stay alive.

The preferred chip today, is not the ATmega128. You would go either with the ATmega1281 (with extra power management) or with the ATmega128A which is lower cost, lower power and same functionality.

The XMEGA would be an even better choice due to internal DMA which will offload the UART. It is a much nicer chip.

Not true from where I am standing.

If you need ethernet, they you better look at a 32 bit chip. Typically you need to have large amount of SRAM for a TCP/IP stack which is not so cheap in the typical 8 bit micro process. The 32 bit machines have more memory, but also higher sleep currents. The AT32UC3A (32 bit AVR), AT91SAM7X (ARM7) and soon the AT91SAM3X (Cortex-M3) chips would be the Atmel alternatives.

The AT32UC3A comes with an free of charge Eclipse/gcc environment with wizards to support the inclusion of drivers and goodies like lwIP TCP/IP stack and FreeRTOS.

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

**Cough** leadtimes **Cough ** ATMEGA328....

PIC32 may be worth a look - free TCPIP libraries with full source.

Sounds like you should drop Hitachi. If you don't like dealing with the company, don't buy their chips.

Atmel seem to be reasonably good at replacing old parts with new ones that are mostly compatible, but it's not always clear-cut. I don't know if they are much better or worse than other suppliers. The 90S1200 is ancient - I think it was the first AVR available to general customers.

I've seen nothing to indicate that Atmel are a bad choice. Microchip tried to buy them out not long ago, and Atmel laughed at them.

As Ulf said, there are newer variants on the Mega128 theme, so check the latest devices before deciding.

AVRs are a good choice for small microcontrollers - they are robust, low power, fast (for an 8-bit micro), easy to work with, and have cheap development tools. But they are inefficient at memory access - as 8-bit devices, it's inconvenient to deal with more than 64K code space, you have limited ram, and heavy pointer work is slow.

When you start talking about TCP/IP stacks, I would go for a Cortex M3 device (or possibly a Coldfire if you prefer). You certainly /can/ use TCP/IP on an AVR, but with the current size and price of M3 devices, there is little point - a 32-bit devices is much better suited. There are plenty available with inbuild Ethernet - far more convenient than an external Ethernet MAC.

If you can extend the address space (e.g., bankswitching, overlays, etc.) you can get a full stack running on an "8 bit processor" *and* an application :> Depending on the NIC you choose, performance may be dodgy (e.g., checksums will eat your lunch).

Do you really need TCP? E.g., if you can live with just UDP (and trim down the "other" services that you might not require) this can be done for very little CODE/DATA. It would change the way you talk to other things and the way *they* talk to you -- but, if your application can live with those constraints...

[you can also build simple protocols atop UDP to give you "reliable" communications without the overhead of TCP]