MMC over SDIO

[ianmga]

Has there been any attempt to duplicate the MMC interface over the SDIO lines instead of SPI? I want to run FATFS using SDIO.

ian

[Giovanni]

Hi Ian,

Not yet but it is something I am looking into, there are two possible solutions:

The first one is to create an abstraction layer within the MMC driver and SD/SPI would become the transport layers.

The other possible solution is to create an abstract MMC interface much like the Serial driver interface and then have multiple implementations of the abstract interface.

On top of this there is also the need to extend the MMC/SD support for devices above 2GB.

I think this will go after finishing the USB support, I am doing the Mass Storage now, it is related to the MMC too.

Giovanni

[ianmga]

Hi Giovanni,

I'm now starting to work on this on earnest. What I want to do at least to get it working in a hurry is to duplicate the MMC/SPI functionality. I will use the STMicro code as a reference, but my main worry is to be able to make the read/write calls blocking, so that the rest of the threads can go on. That will be the trickiest part (for me, anyway).

Ian

[Giovanni]

Hi Ian,

This thing should not be complicated but currently I don't have any hardware supporting SDIO so it can't go ahead.

Note that you don't need to make calls blocking, you could simply use the ST code as-is and use it from a thread with lower priority than other treads. If you need to access it from multiple threads you may consider creating a "server thread" using messages. Client threads would send messages in order to read/write from the card.

Giovanni

[ianmga]

Ooohhh. I'll start with that.

[ianmga]

Alright I got SDIO working on ChibiOS without threads. I'll clean it up, put it on a server thread, and post it here.

Actually, do you have an example on how to best do the server thread? I know there's a description on the documentation but maybe there was an example in code already.

ian

[Giovanni]

Hi Ian,

Encapsulating into server threads is a good method for reusing code not meant for a RTOS. The structure of a server thread is very simple:

Let's assume your message is encoded into a structure of type mymsg_t (you could put there a message code, pointer to a buffer, number of bytes to transfer etc).

Code: Select all

/* Server thread.*/
static msg_t thread1(void *p) {

  /* Init SD code here.*/
  do {
    msg_t status;
    Thread *tp = chMsgWait();
    mymsg_t *msgp = (mymsg *)chMsgGet(tp);

    switch (msg->command) {
    case CMD_READ:
      /* Perform read.*/
      status = TRANSFER_OK; /* The operation status, you define this.*/
      break;
    case CMD_WRITE:
      /* Perform write.*/
      status = TRANSFER_OK; /* The operation status, you define this.*/
      break;
    default:
      status = UNKNOWN; /* The operation status, you define this.*/
    }
    chMsgRelease(tp, status);
  } while (msg);
  return 0;
}

Note, the example is for version 2.3.0, in 2.2.x the messages functions are a bit different, see the function "thread1" in testbmk.c for another example.

Giovanni

[ianmga]

This works on STEVAL-10E (using keil). I found the original in some STMicro forum and replaced some of the files by the STM32 peripheral library files, fixed a bug on fprintf, etc. It just copies a file on the same disk. I added writing the time in ticks to a third file.

[Giovanni]

Thread moved into the contributed code forum.

Thanks,
Giovanni

[ianmga]

And finally got it working and tested as a server as well. Phew. Thanks for your suggestion.