parallel eeproms and 8051

Hi..

Im new to embedded systems, iv started with the 89c51 uC. Ive never
used a parallel eeprom with the 89c51, thought iv used a serial one
with the i2c protocol (and had a tough time in getting the thing to
work, using sdcc :-( ).

My question is..can only a parallel eeprom be used to extend the RAM??
seems logical, or else how would the uC generate the address on its
own??

Also, can some part of the code be in the on-chip flash and the
remaining in an external serial eeprom?? again, how then would the uC
know the address to find the remaining lines of code?

Finally, could u point me to some good places where i can find info on
interfacing the 8051 types to a serial eeprom. How about bus arch too..

Im googling for this info too, in case u plan to flame me for not doing
that :-)

Thanx in anticipation

Mayank

funkymunky wrote:

> Hi..
> 
> Im new to embedded systems, iv started with the 89c51 uC. Ive never
> used a parallel eeprom with the 89c51, thought iv used a serial one
> with the i2c protocol (and had a tough time in getting the thing to
> work, using sdcc :-( ).
> 
> My question is..can only a parallel eeprom be used to extend the RAM??
> seems logical, or else how would the uC generate the address on its
> own??

Only parallel EEPROMs can be used to extend the "native" RAM.  Serial 
EEPROMs are pretty much just nonvolatile storage devices.
> 
> Also, can some part of the code be in the on-chip flash and the
> remaining in an external serial eeprom?? again, how then would the uC
> know the address to find the remaining lines of code?

Not in a serial EEPROM, unless you load the code out of the EEPROM and 
into RAM for execution.
> 
> Finally, could u point me to some good places where i can find info on
> interfacing the 8051 types to a serial eeprom. How about bus arch too..

Your brain.  Just study the serial EEPROM data sheet and think about how 
to bit-bang it (or get an 8051 with an SPI port and use a compatible 
EEPROM).
> 
> Im googling for this info too, in case u plan to flame me for not doing
> that :-)
> 
> Thanx in anticipation
> 
> Mayank
> 


-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

okay okay...i got that..another question:

out of i2c and spi, which standard is more popular? any specific
reasons for it?

Okay, got that..one more thing: out of spi and i2c, is any one of them
more popular...if yes, why?

funkymunky wrote:

> okay okay...i got that..another question:
> 
> out of i2c and spi, which standard is more popular? any specific
> reasons for it?
> 
No, because they address different concerns.  Depending on the project 
one may have occasion to use SPI, I2C or both.

If you want to hook up a small, fixed number of peripherals to a 
microprocessor then SPI is much simpler to use.  If you want to hook up 
a large number, or an unknown number, of peripherals to a microprocessor 
then I2C can't be beat.

Of course sometimes you have a peripheral that you must use that only 
comes with one interface, and then you're stuck.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

funkymunky wrote:
> Okay, got that..one more thing: out of spi and i2c, is any one of them
> more popular...if yes, why?

Look at the vendors web sites [Atmel, Ramtron etc ] and you get
an idea of what is available( and thus consumed ).
i2c uses fewer pins, so you can get SOT23 i2c memories, but i2c
tops out at 400KHz/1MHz/3.4MHz, with very few devices around
that work to the latest 3.4MHz ( I have not seen a uC yet that specs
to 3.4Mhz i2c)

SPI is much faster, so can go to 50MHz on newest devices.
So, for the largest memories, that need wider pipes, SPI is more
common than i2c.

Sometimes, you can find both: the AT17F FPGA loader devices from Atmel, 
pgm like i2c, but read like SPI...
-jg