Emulating a SD or xD card with a PIC or other microcontroller

[NiHaoMike]

I have a digital picture frame that accepts SD or xD cards. I would like to wire a microcontroller to the SD or xD data lines and program it to load a (changing) JPEG file from a server on the network using an Ethernet interface. (A few seconds of delay is no problem and locally buffering it is OK.)

How would I go about having a microcontroller behave like a SD or xD card?

[free_electron]

Never going to be fast enough....

[Psi]

I think SD cards have two separate interfaces you can use (a serial and a parallel).
First you probably need to figure out which one the picture frame is using.


But really, i suspect you will spend more time/money trying to get this to work than just buying a new picture frame with wifi access.

[senso]

Google FatFS, it as examples for PIC's, its almost download, include lib, read example, adapt and use.

[MikeK]

What free_electron said.  The clock is controlled by the master (the device in the picture frame), and there is a minimum expected speed that is faster than a PIC can handle.

If you wanted to verify this, you could plug in an SD card and scope the clock pin.

[senso]

No, you can use it even on an 8Mhz Atmega!

[johnnyfp]

FatFS is for reading and writting to SD cards.

What NiHaoMike wants is the ability to read from a PIC simulating a SD card. So that way he can put a Serial to Wifi on the other side of the PIC to connect to a server or something.

However a PIC32 or Cortex or similar could do it. There are SD cards out there that are slow reading or fast reading from and the SD reader would have to adapt. So the Frame should be able to adapt, it will just have to wait until the PIC is ready to send data back. This can be achieved by the PIC sending a busy.

[DavidDLC]

Use a SD card with Wi-fi on it, and then on the computer side make a program to store the files on it.

http://www.amazon.com/s/ref=nb_sb_noss_1/188-6501036-4531800?url=search-alias%3Daps&field-keywords=wireless+sd+card

David.

[johnnyfp]

That looks cool. But from the descriptions it only does uploads from the card, Not too the card.

Wonder what MCU is uses? Could there be a option to reprogram it to do other things.

Saying that look what I found. Perfect! http://www.engadget.com/2011/09/02/toshiba-flashair-wifi-sd-card-will-make-your-eye-fis-water/

[MikeK]

No, you can use it even on an 8Mhz Atmega!

senso, you're missing the intent of the project.  Yes, you can use nearly any microcontroller with a SD card.  But that's not what NiHaoMike wants to do.

[MikeK]

However a PIC32 or Cortex or similar could do it. There are SD cards out there that are slow reading or fast reading from and the SD reader would have to adapt. So the Frame should be able to adapt, it will just have to wait until the PIC is ready to send data back. This can be achieved by the PIC sending a busy.

The master still controls the clock, though.  So any SD card (or imitator) has to be able to respond, bit-wise, to the clock.  Sending a "busy" would be impossible if the PIC can't send it at the master's clock speed.

I just glanced through the SD spec and there is a "max speed" field in the CSD register.  And I know that the card initializing routine is supposed to be low speed.  So if the CSD is being read to check the "max speed" it's possible to tell the master to use a 100kb/s transfer rate.

[DavidDLC]

That looks cool. But from the descriptions it only does uploads from the card, Not too the card.

Wonder what MCU is uses? Could there be a option to reprogram it to do other things.

Saying that look what I found. Perfect! http://www.engadget.com/2011/09/02/toshiba-flashair-wifi-sd-card-will-make-your-eye-fis-water/

Cool ! Good finding

[NiHaoMike]

But really, i suspect you will spend more time/money trying to get this to work than just buying a new picture frame with wifi access.

It's more about the fun. Why would anyone bother building 8 bit CPUs from discrete logic when they can buy a far superior microcontroller for under $1?

I taped over the outer two pins of the card and it still worked, so it's using SPI. (Not surprising when digital picture frames don't need speed and SPI is so cheap to implement.) I haven't checked the clock yet, but I think they'll just use whatever frequency that happens to be convenient.

The xD interface could possibly be easier to interface, since it's just a bare Flash device.

[Psi]

Yeah, if it's just for fun then go for it

One issue you may run into is that the picture frame may only read the FAT table at startup.
It will read the file contents every time it loads a picture but the location of the file may be cached

So if you change an image on the sd/xd card while the picture frame is running it may not be aware of it.
The new file may have to be the same size as the old file so it occupies the same blocks.

That maybe why those WiFi SD cards only read the data and can't write.
Any device that takes a memory card doesn't expect the contents to change while it's using it, so results might be a bit unpredictable with some products handling it fine and others crashing etc..

[NiHaoMike]

I remember reading that JPEGs have a certain sequence for denoting the end of file, so anything after it is ignored. (I recall something about some "popular" JPEG file that had the source code of DeCSS appended to the end as a way of distributing it.) If that's true, I could just define the file size in the table as being much larger than any JPEG I want to load and then just pad extra bytes. (I'll actually try that by concatenating some extra bytes to the end of a few JPEGs.)

[free_electron]

Again, you are never going to be fast enough.
You need to emulate the spi protocol as a SLAVE. You need to emulate the file system as a DEVICE. Both are undoable on a processor. The reason is simple. The read clock on an sd card can go as high as 80MHz... You don't stand a chance following that with a 8MHz cpu... Even with a 300MHz cpu you don't stand a chance ! You would only have 4 clockticks to process a clockcycle...

Your only option is to build this in an FPGA.

[Erwin Ried]

That looks cool. But from the descriptions it only does uploads from the card, Not too the card.

Wonder what MCU is uses? Could there be a option to reprogram it to do other things.

Saying that look what I found. Perfect! http://www.engadget.com/2011/09/02/toshiba-flashair-wifi-sd-card-will-make-your-eye-fis-water/

I used a Eye-Fi card to send the panorama photos to a remote pc:


Eye-Fi card works in a very "closed" way but in my tests I can say that you can transfer anything with the jpeg extension, it is just a dumb filter on those cards, your uC can write a txt with jpeg and it is syncronized properly. I think comunication is bidirectional but I am not 100% sure (it was a lot of time ago and  I only needed one directional). Also comunication, at least in this low end model (4g photo if I recall correctly) is not fast, it is like the sd card tries to save a lot of power and only do some periodic syncs.

I opened it (I needed to cut some plastic parts to make the CHDK firmware to work) and inside there was a memory chip, like samsung and an Arm chip.

[free_electron]

there is no such thing as an 'arm' chip. arm does not make chips themselves ... they produce IP.
one fo the requirements is that you clearly place the ARM logo on any chip that has an arm core in it. there may be tons more stuff in it.
the only way to omit the arm logo is to pay more royalties....