Emulating a SD or xD card with a PIC or other microcontroller - Page 1
Forum section: electronics / general

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 27, 2012, 02:54:40 am
content: 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?

author: free_electron
author_rank: Super Contributor
timestamp: June 27, 2012, 03:03:53 am
content: Never going to be fast enough....

author: Psi
author_rank: Super Contributor
timestamp: June 27, 2012, 03:47:08 am
content: 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.

author: senso
author_rank: Frequent Contributor
timestamp: June 27, 2012, 07:23:13 pm
content: Google FatFS, it as examples for PIC's, its almost download, include lib, read example, adapt and use.

author: MikeK
author_rank: Super Contributor
timestamp: June 27, 2012, 10:17:59 pm
content: 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.

author: senso
author_rank: Frequent Contributor
timestamp: June 27, 2012, 10:44:34 pm
content: No, you can use it even on an 8Mhz Atmega!

author: johnnyfp
author_rank: Frequent Contributor
timestamp: June 27, 2012, 11:07:02 pm
content: 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.

author: DavidDLC
author_rank: Frequent Contributor
timestamp: June 27, 2012, 11:10:04 pm
content: 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+cardDavid.

author: johnnyfp
author_rank: Frequent Contributor
timestamp: June 27, 2012, 11:20:56 pm
content: 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/

author: MikeK
author_rank: Super Contributor
timestamp: June 27, 2012, 11:40:42 pm
content: Quote from: senso on June 27, 2012, 10:44:34 pmsenso, 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.

author: MikeK
author_rank: Super Contributor
timestamp: June 27, 2012, 11:53:36 pm
content: Quote from: johnnyfp on June 27, 2012, 11:07:02 pmThe 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.

author: DavidDLC
author_rank: Frequent Contributor
timestamp: June 27, 2012, 11:55:21 pm
content: Quote from: johnnyfp on June 27, 2012, 11:20:56 pmCool ! Good finding

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 28, 2012, 02:26:33 am
content: Quote from: Psi on June 27, 2012, 03:47:08 amIt'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.

author: Psi
author_rank: Super Contributor
timestamp: June 28, 2012, 02:52:19 am
content: Yeah, if it's just for fun then go for itOne 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 cachedSo 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..

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 28, 2012, 04:41:31 am
content: 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.)

author: free_electron
author_rank: Super Contributor
timestamp: June 28, 2012, 12:14:22 pm
content: 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.

author: Erwin Ried
author_rank: Regular Contributor
timestamp: June 28, 2012, 07:31:56 pm
content: Quote from: johnnyfp on June 27, 2012, 11:20:56 pmI 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.

author: free_electron
author_rank: Super Contributor
timestamp: June 28, 2012, 07:45:01 pm
content: 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....