From: Mike Harrison on

> >
> > The obvious choice today is Microchip. They seem to be getting most
> > new designs.
>
>Not true from where I am standing.

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

>
> > The code would be written wholly in C anyway (the present
> > H8 is largely assembler but functionally it is nothing complicated;
> > just some intricate ISRs).
> >
> > Performance is not an issue - two UARTs capable of 115200 baud
> > concurrently... easy. Plus the ability to run a TCP/IP stack for an
> > ethernet port would be nice (which the H8 cannot do due to its
> > 64k-byte codespace limit).
> >
>
>If you need ethernet, they you better look at a 32 bit chip.

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

From: David Brown on
On 01/06/2010 18:56, Peter wrote:
> I have a product which has been running for 16 years, based on a
> Hitachi H8/323 (16k PROM, 48k external address space).
>
> This CPU is end of life though we can still buy it from Hitachi
> (Renesas) and countless secondhand chip dealers in the USA :)
>
> We are looking at re-doing the whole thing to get rid of the
> processor.
>
> One option is to stick with the H8 family, which still exists, with
> the downside of Hitachi being the #1 most arrogant and useless-support
> company; a distinction they have managed to maintain for the 20 years
> I have been dealing with them. Clearly they have ISO9000 approval -
> consistent!!
>

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

> I have also been using the Atmel 90S1200-4YC in a volume product; this
> was EOLd a few years ago but we had huge stocks and can still buy them
> around the place. I have just heard that Atmel have (stupidly) dropped
> the 20-pin package, which means a PCB redesign...
>

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.

> We started on work to replace the H8 ~ 3 years ago and bought the
> Mega128 development kit (Atmel being THE embedded company a few years
> ago) then this had to be postponed due to other work. Now we are
> re-opening it but looking at Atmel's dropping of the very popular
> AT-Tiny package, and other comments around the place, I wonder whether
> Atmel are going to be a player in this market for much longer.........
>

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.

> The obvious choice today is Microchip. They seem to be getting most
> new designs. The code would be written wholly in C anyway (the present
> H8 is largely assembler but functionally it is nothing complicated;
> just some intricate ISRs).
>
> Performance is not an issue - two UARTs capable of 115200 baud
> concurrently... easy. Plus the ability to run a TCP/IP stack for an
> ethernet port would be nice (which the H8 cannot do due to its
> 64k-byte codespace limit).
>
> I'd think that a Hitachi chip which is current today may well outlast
> Atmel - as well as myself (aged 53 :)). So that is a plus for Hitachi.
> Which Hitachi H8s are still really common? (2 UARTs, some I/O)?
>
> We use the old Hitech (Australia) compiler, but they have now sold out
> to Microchip, but that doesn't matter. A binary-compatible Hitachi
> processor would potentially save a lot of work.
>
> Any comments?
>

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.

From: D Yuniskis on
Hi Peter,

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

> The obvious choice today is Microchip. They seem to be getting most
> new designs. The code would be written wholly in C anyway (the present
> H8 is largely assembler but functionally it is nothing complicated;
> just some intricate ISRs).
>
> Performance is not an issue - two UARTs capable of 115200 baud
> concurrently... easy. Plus the ability to run a TCP/IP stack for an
> ethernet port would be nice (which the H8 cannot do due to its
> 64k-byte codespace limit).

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]

> I'd think that a Hitachi chip which is current today may well outlast
> Atmel - as well as myself (aged 53 :)). So that is a plus for Hitachi.
> Which Hitachi H8s are still really common? (2 UARTs, some I/O)?
>
> We use the old Hitech (Australia) compiler, but they have now sold out
> to Microchip, but that doesn't matter. A binary-compatible Hitachi
> processor would potentially save a lot of work.
>
> Any comments?