I meant that he was NOT using the SPI port OR the RAMTRON, although he
MIGHT be using the SPI port to provide I2C, wasn't sure.

In any case, the SPI port needs to drive the MMC. You can set up the FRAM,
pull a byte with I2C, send it with the SPI, pull another byte by I2C, send
it out the SPI. Much faster than what it looked like he was doing... That's
what I was referring to.

But his overall approach looks OK.

--Bob


At 06:14 AM 7/14/2003 -1000, you wrote:
>Not sure what you mean. The workbench guy IS buffering in the fram.  But if
>you use a pic18f252, then you have enough memory so you don't need the fram
>either.
>
>You can get both the dos file access software (CCS C) and the mmc buffering
>into the 18f252
>
>Jay
>
> >The problem with this approach is that he's bit-banging the
> >MMC. Better to bit-bang the RAMTRON. Not the way I'm doing it..
> >--Bob
> >
> >http://www.compsys1.com/workbench/On_top_of_the_Bench/MMC_Project/MMC_to_PI
>C
> >_3_3v_Schematic/mmc_to_pic_3_3v_schematic.html
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email listserv@mitvma.mit.edu with SET PICList DIGEST in the body

---------------
NOTICE

1. This account can accept email & attachments up to 10M in size.
2. Federal Monitors: At request of client, some attachments are encrypted.
Please DO NOT delay traffic; please reply with credentials for password.
--------------

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body