> Paul,
>
> You're quite right. The large RAM area is to be used for buffering data
> received through one comms medium, checking it for integrity, then passing
> on via another comms medium. The app that controls all this will, it is
> hoped, fit in the on-chip SRAM. Still, if the data is larger than 64k then
> the page switching will still be a nuisance.
>
> I quite like Ulf's suggestion of an AT91R40008 which has 256k SRAM
on-board,
> this saves the cost of the SRAM devices. The question is will the device
> come in under the total budget? I'll have to see...
>
> CTW

Drop me an email (remove the hyphens) and I'll talk to some guys
to find out whats possible.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
"Clive Wilson" <clive@nowhere.invalid> skrev i meddelandet
>
>

What about Dallas DS89C440 or 450?
They have 2 UART with sufficinet (x)RAM.

"Paul Burke" <paul@scazon.com> wrote in message 
news:35ucfbF4qpd1gU1@individual.net...
> Tauno Voipio wrote:
>>
>> An 8 bit micro will have only 16 address lines -> maximum addressable
>> range = 0 to 65535 (0x0 to 0xffff) without page switching or similar
>> tricks. The paging is a nightmare, regardless whether it's done by
>> the compiler/linker/run-time combination or the programmer.
>>
>
> I've missed the start of this, but a lot depends on how the OP wants to 
> use the RAM. It's easy enough to set up a paged access scheme for any 
> amount of RAM with an external latch for the high-order addresses. Of 
> course, there is a performance hit, and the compiler can't deal with it 
> directly. But I can't imagine that his app is using that much RAM in the 
> ordinary way anyway, not in an 8 bit system.

Paul,

You're quite right. The large RAM area is to be used for buffering data 
received through one comms medium, checking it for integrity, then passing 
on via another comms medium. The app that controls all this will, it is 
hoped, fit in the on-chip SRAM. Still, if the data is larger than 64k then 
the page switching will still be a nuisance.

I quite like Ulf's suggestion of an AT91R40008 which has 256k SRAM on-board, 
this saves the cost of the SRAM devices. The question is will the device 
come in under the total budget? I'll have to see...

CTW 

On Thu, 27 Jan 2005 19:54:52 GMT, Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> wrote:

>Clive Wilson wrote:
>> "Grzegorz Mazur" <easy2find@the.net> wrote in message 
>> news:ctalfl$ja4$1@julia.coi.pw.edu.pl...
>> 
>>>Clive Wilson wrote:
>>>
>>>>Dear All,
>>>>
>>>>I'm looking for a cheap 8/16 bit uP/uC that has an external bus 
>>>>interface, so that about 256k of SRAM can be addressed. It needs to have 
>>>>on-board Flash, around 32k would be good. The device doesn't need many 
>>>>GPIO pins, perhaps 5 or so just in case. It doesn't need ADC/DACs, USB 
>>>>etc like all the manfs seem to throw in them these days. It will be 
>>>>running a TCP/IP stack with link layer to connect to modem, so the 
>>>>processor also needs a UART. Price needs to be <$1.50 or so, in 100k 
>>>>quantities.
>>>>
>>>>Any ideas? To recap:
>>>
>>>And what's the problem with 32-bit ones? Too easy memory addressing or too 
>>>high processing speed?
>>>
>>>Seriously, at that price you could probably dream of not-too-fast '51 and 
>>>using external memory above 64K is a nighmare on 8/bit MPUs. Your specs 
>>>can be easily met by almost any ARM and many Renesas H8 chips at a 
>>>slightly higher price. Anyway I don't believe you will get a contemporary 
>>>'51 chip with 2 UARTS at $1.5.
>> 
>> 
>> Grzegorz,
>> 
>> Thanks for your reply. Two points I'd like to discuss a little more:
>> 
>> 1. You mention that using external memory above 64K is a nighmare on 8 bit 
>> MPUs. Why is this? As long as the data is treated as 'far' by the C compiler 
>> (no asm please!), then the compiler will take care of the paging. Admittedly 
>> it takes processor cycles to achieve this. Is this the angle you were coming 
>> from, or did you have other reservations?
>
>An 8 bit micro will have only 16 address lines -> maximum addressable
>range = 0 to 65535 (0x0 to 0xffff) without page switching or similar
>tricks. The paging is a nightmare, regardless whether it's done by
>the compiler/linker/run-time combination or the programmer.
>
>> 2. You seem to suggest that I could get a sufficiently-spec'ed ARM for less 
>> than an H8? Really? Which vendor(s) did you have in mind?
>
>My vote to an Atmel AT91.

I would imagine that in most case, if you need >64K, the bulk of it is not for general storage but
for some particular data, that could easily be accessed via a special routine that handles the
paging etc. 

Tauno Voipio wrote:
> 
> An 8 bit micro will have only 16 address lines -> maximum addressable
> range = 0 to 65535 (0x0 to 0xffff) without page switching or similar
> tricks. The paging is a nightmare, regardless whether it's done by
> the compiler/linker/run-time combination or the programmer.
> 

I've missed the start of this, but a lot depends on how the OP wants to 
use the RAM. It's easy enough to set up a paged access scheme for any 
amount of RAM with an external latch for the high-order addresses. Of 
course, there is a performance hit, and the compiler can't deal with it 
directly. But I can't imagine that his app is using that much RAM in the 
  ordinary way anyway, not in an 8 bit system.

Paul Burke

>
> I'm looking for a cheap 8/16 bit uP/uC that has an external bus interface,
> so that about 256k of SRAM can be addressed. It needs to have on-board
> Flash, around 32k would be good. The device doesn't need many GPIO pins,
> perhaps 5 or so just in case. It doesn't need ADC/DACs, USB etc like all
the
> manfs seem to throw in them these days. It will be running a TCP/IP stack
> with link layer to connect to modem, so the processor also needs a UART.
> Price needs to be <$1.50 or so, in 100k quantities.
>
> Any ideas? To recap:
>
> <$1.50 for 100k+
> 8/16-bit
> 32k onboard Flash
> External bus interface
> Handful of GPIO
> UART
>

Some calculation:

256kB ext SRAM
------------------
18 address pins
8 data pins
3 control: /RD,/WR,/CS
4 UART pins RXD*2, TXD*2
5 I/Os
VCC*2,GND*2,XIN,XOUT,RESET
Anything else?
I think you are going to end up with a 64 pin package.
With a mux bus, and an external latch you will fit into a 44 pin package.

I think you get a 16 kB Flash, no external memory at that price, not 32 kB
The ATmega162 is the lowest cost AVR that has a chance to fit.
Since different architectures generate different amount of
code, it is strange that you specify the code size without
a reference to the CPU architecture.

If the ATmega162 doesnt fit, then the ATmega64
is the next obvious choice but will have a problem pricewise

Maybe you could consider instead the AT91R40008?
This is an 32 bit ARM7TDMI with 256 kB of
internal 32 bit zero waitstate SRAM.
Runs at 66 MHZ, providing 60 MIPS at very low power.

You would use the cheapest external 8 bit flash
you could find, and load it into the SRAM at boot
if you need performance/low power or keep it external
if low performance is acceptable. Loading the code into SRAM of course measn
that
you haev less avaialble for data.

It will be more expensive than $1,50 but you do not need to buy the SRAM
since this is on chip.
How much will that cost?




> I would really appreciate it if anyone has any suggestions. I've tried
> Renesas and they can't even come close price-wise.
> Very many thanks in anticipation,
>
> Clive Wilson
>
>

Tauno Voipio wrote:

> Clive Wilson wrote:
>> Thanks for your reply. Two points I'd like to discuss a little more:
>>
>> 1. You mention that using external memory above 64K is a nighmare on 8 
>> bit MPUs. Why is this? As long as the data is treated as 'far' by the 
>> C compiler (no asm please!), then the compiler will take care of the 
>> paging. Admittedly it takes processor cycles to achieve this. Is this 
>> the angle you were coming from, or did you have other reservations?
> 
> 
> An 8 bit micro will have only 16 address lines -> maximum addressable
> range = 0 to 65535 (0x0 to 0xffff) without page switching or similar
> tricks. The paging is a nightmare, regardless whether it's done by
> the compiler/linker/run-time combination or the programmer.
> 
>> 2. You seem to suggest that I could get a sufficiently-spec'ed ARM for 
>> less than an H8? Really? Which vendor(s) did you have in mind?
> 
> 
> My vote to an Atmel AT91.

but nowhere near $1.50, esp with external bus...

This is a high volume (100K) app, so 50c = $50K.
This is also DATA, not Code in the 256K.

Thus yes, the access is not invisible, but it is also
not a nightmare. Simply equates to a little more nous, and
engineering time, which saves on the BOM.

-jg

Clive Wilson wrote:
> Dear All,
>><$1.50 for 100k+
>>8/16-bit
>>32k onboard Flash
>>External bus interface
>>Handful of GPIO
>>UART

Sounds like a vanilla C51: these I have recorded from SST

SST89E52RD2-40-C-NJ $1.20/10K   8KF+8KF  1KR   IAP  SPI  PCA  WDOG  P4
SST89E54RD2-40-C-NJ $1.38/10K  16KF+8KF  1KR   IAP  SPI  PCA  WDOG  P4
SST89E58RD2-40-C-NJ $1.55/10K  32KF+8KF  1KR   IAP  SPI  PCA  WDOG  P4

 >
 > On reflection, it needs two UARTs. The rest's the same.

the above devices have SPI and UART, so might do ?
Or do one UART in SW ?, the PCA can help that.

Two HW uarts tends to move into the 'other extras', so the price
moves up. Look at Winbond's C51's and Dallas's C51's

-jg

Paging over 64k with a 8 bit processor is a pain in the bum with C,you
can try it with sdcc for free and see how badly it copes.
If it wasnt for the cost issue I would recommend one of the many
extended 32 bit variants of the standard '52.

Clive Wilson wrote:
> "Grzegorz Mazur" <easy2find@the.net> wrote in message 
> news:ctalfl$ja4$1@julia.coi.pw.edu.pl...
> 
>>Clive Wilson wrote:
>>
>>>Dear All,
>>>
>>>I'm looking for a cheap 8/16 bit uP/uC that has an external bus 
>>>interface, so that about 256k of SRAM can be addressed. It needs to have 
>>>on-board Flash, around 32k would be good. The device doesn't need many 
>>>GPIO pins, perhaps 5 or so just in case. It doesn't need ADC/DACs, USB 
>>>etc like all the manfs seem to throw in them these days. It will be 
>>>running a TCP/IP stack with link layer to connect to modem, so the 
>>>processor also needs a UART. Price needs to be <$1.50 or so, in 100k 
>>>quantities.
>>>
>>>Any ideas? To recap:
>>
>>And what's the problem with 32-bit ones? Too easy memory addressing or too 
>>high processing speed?
>>
>>Seriously, at that price you could probably dream of not-too-fast '51 and 
>>using external memory above 64K is a nighmare on 8/bit MPUs. Your specs 
>>can be easily met by almost any ARM and many Renesas H8 chips at a 
>>slightly higher price. Anyway I don't believe you will get a contemporary 
>>'51 chip with 2 UARTS at $1.5.
> 
> 
> Grzegorz,
> 
> Thanks for your reply. Two points I'd like to discuss a little more:
> 
> 1. You mention that using external memory above 64K is a nighmare on 8 bit 
> MPUs. Why is this? As long as the data is treated as 'far' by the C compiler 
> (no asm please!), then the compiler will take care of the paging. Admittedly 
> it takes processor cycles to achieve this. Is this the angle you were coming 
> from, or did you have other reservations?

An 8 bit micro will have only 16 address lines -> maximum addressable
range = 0 to 65535 (0x0 to 0xffff) without page switching or similar
tricks. The paging is a nightmare, regardless whether it's done by
the compiler/linker/run-time combination or the programmer.

> 2. You seem to suggest that I could get a sufficiently-spec'ed ARM for less 
> than an H8? Really? Which vendor(s) did you have in mind?

My vote to an Atmel AT91.

-- 

Tauno Voipio
tauno voipio (at) iki fi