I have a special embedded device which has an SD card slot and reads data files from an inserted SD card. These data files are validated only once (because validating them on every access would take too long), but the files are being accesses periodically.

But sadly, they are also being re-validated when I remove the SD (to manipulate the files) and re-insert it.

One possible way that came into my mind to "hack" this would be an SD card with WiFi (the Transcend WiFi SD runs Linux and can be hacked to also allow write access over WiFi) and use that to edit the file on the fly. But I don't really feel like buying a 40 € "wifi" SD card when I'm not even sure if this will work.

My idea was now, would it be possible to "emulate" an SD card using the PIs GPIO pins? I mean, like, I open a Micro-SD-to-SD-Adapter, solder some wires to the MicroSD pins and connect them to the GPIO, and then start some program / driver / whatever that emulates a FAT32 filesystem / image / whatever over these pins.

I could then connect the SD slot of my device with the Pi and change the files / file contents on the fly without the device recognizing an SD card change (and, hopefully, without the device re-validating the contents).

Is this possible? What speed can the GPIOs achieve? Longer loading times would be no problem, although I don't know if the device wouldn't crash when the loading times happen to be awfully slow.

  • I strongly advise against trying to solder a SD card to the GPIO - it is not going to work. If you want to even begin going down that crazy path I suggest looking up how the GPIO is actually connected to the rest of the Pi. Yes you can transfer data using the GPIO but it is going to be slow. Why can you not just put a SD card in the SD card slot like everyone else?
    – Darth Vader
    May 15, 2016 at 18:59
  • 1
    You misunderstood my question - I do not want to connect a SD card to the GPIO pins, I'd like the Pi to behave as if it was an SD card - i.e., connecting the GPIO pins to an SD card reader. May 15, 2016 at 19:42

1 Answer 1


Not impossible, but here are the obstacles to overcome:

First, the SD card knows nothing about FAT, ext4fs, or any other file system. What it does is accept commands from the host interface and either store the data given to it, or retrieve data and send them back to the host. The filesystem interface is implemented at a higher layer. Whatever you create will not (should not, cannot) know anything about filesystems. You need to create something that serves blocks.

Second, there are two modes to communicate with the SD card: SPI mode and SDIO mode (there is actually a somewhat-newer physical interface involving an additional row of pins, but I think this extends the SDIO mode, it does not involve a third mode. I could be wrong. SDIO mode is a lot more complex to implement; if you look at the Arduino (and other such systems) libraries for how they access SD cards, they use the simpler, but a lot slower, SPI mode.

Your question now can be rephrased as: "Is it possible to implement either the SDIO or the SPI sdcard interface on the Pi?". If this is true, you can then have a chunk of storage (on a USB-connected drive, or even on the on the on-board sdcard) that you are exporting over the sdcard interface as if it were the flash chip that sdcards use. (In fact, sd cards have their own tiny embedded OS that does exactly that -- Bunnie Huang from MIT has written about it, and how to hack it). What you put on that chunk is up to you; you can rely on the other side to store/retrieve data, or you can put a filesystem on it, mount it, store stuff from the Pi side, unmount it, and then let the other side play with it. Obviously, you should have the chunk mounted as a filesystem both from the Pi and the outside at the same time (OK, obvious to me; the reason is that some metadata is not written synchronously, and what's on the chunk of storage that you are exporting may not be a consistent filesystem).

Already it's a tremendous amount of work to implement this; you'd have to implement the SD card specification (start at www.sdcard.org; they have the simplified specs available, but you need to be a member to get the full spec).

Add to all this the complication that, while sd cards have to support the SPI interface, the host controller may not be implementing it, so you could end up implementing all this complexity to export an SPI-interface-only card, which cannot then be read from the particular machine you may have. There aren't too many sdcard controller chips out there, and you may be able to figure this out by reading the corresponding linux device drivers.

You are still not done. Even assuming the simplest (but still not simple) case, where you will be implementing the SPI interface, you are stuck with the fact that the Pi does not support SPI slave mode. So you'd be back to having to bit-bang the SPI (or, worse, the SDIO) protocol on the GPIO pins, which would have to be done inside the kernel with interrupts disabled so as not to mess with the timing. Even if you are implementing a very slow sd card (which you could tell the host when it asks what kind of card you are), that would be about a megabyte per second, or eight megabits, and when you are running at 800MHz, you'll have about 100 clock cycles for each bit in which to read the status of signalling pins, decide what to send out, and send it. Not impossible, esp. if you can take an interrupt at the rising edge of the clock pin and can have some stuff precomputed, but that's a rather tight timing budget, and you'd have to do a fair amount of assembly coding.

You are still reading?! :)

Now for the good news: you may still fail, but you'll have learned more than most people about sd cards, spi/sdio, file systems, interrupt/real-time programming, and kernel device drivers :)

  • 1
    Uuuh.. That sounds a bit too complicated for me. I hoped that someone already did this on a Pi and the needed tools were available somewhere ... -> "you should have the chunk mounted as a filesystem both from the Pi and the outside at the same time" - I guess this should mean I should NOT mount it the same time? But that was the whole point of this idea - changing the contents without unmounting on the other side, because unmounting and remounting would trigger the validation again. The device does not write to the SD at all anyway. Guess I'll just spend the 40€ on a WiFi SD card and try that. May 16, 2016 at 7:14
  • yeah, there is a reason why those cards exist :) "not mounted at the same time" was a simplistic way of saying "be very careful with locking/synchronization/chache consistency".
    – JayEye
    May 16, 2016 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.