SD library

has anyone done any work to implement SD cards as a file store?
I know similar work is available for the Arduino
wondered if it’s been implemented for a Wixel?

alternatively, what do the committee think about using an Arduino/SD card as a file store?


Sorry for not responding to your post sooner. We would like to develop a Wixel library to work with SD cards eventually, but we don’t have an estimate for when it might be available. (We have done some early work on an SPI library, which would be used to communicate with the SD card.)

- Kevin

hello Kevin
thanks for the update
I’ve started work on this
if you can share what you have for the SPI interface I’d be delighted!

After getting the SPI stuff working, I would try to get the Petit FAT File System Module to compile for the Wixel. Currently, it is written in a way that causes very inefficient use of memory in SDCC, so it fails at the linking step because there isn’t enough memory.


I was looking at that as a start point :slight_smile:!
any idea where I can find the SPI work done so far?

ok looks like I have a working SPI library :smiley:
is it worth publishing?

now moving on to annoying the SD card
watch this space :open_mouth: [ ]


Sorry for the delay in responding. We would be interested to see your SPI library if you want to publish it somewhere. In addition, I’m working on getting our own SPI library available for download.

- Kevin

I think I have it working, but I am struggling to talk to the SD card
the hardware is ok as I have tested it with an Arduino

any chance of a sneak peak at yours?

I’ll upload mine so you have a larf and tell me where I went wrong! (4.39 KB)

I’ve created a fork of the Wixel SDK on github and published our SPI library here in the dev/kevin/spi_master branch. You can pull my changes with git, download (my version of) the entire SDK, or just grab the new files; they are:


This is still a work in progress, so it is not well-documented yet, and some of the function names might change before we merge it into the official Wixel SDK. Please let me know if you have any trouble understanding it.

The CC2511 datasheet recommends using a software-controlled GPIO pin to drive a SS (slave select) signal, if it is required. I did not implement any functions to do this in our library (yet), though we might reconsider this later.

I have not taken a close look at your library yet, but I will go through it and let you know if I see anything unusual.

- Kevin

mmcp42, I was able to get your library working by changing two things in spiWriteData.

First, I changed the for loops from

for (i = 0; i <= size; i++)


for (i = 0; i < size; i++)

(unless you intended “size” to mean “the number of bytes to write - 1”, but I’m not sure why you would want that.)

Second, I removed this:

// need to send a final 0xFF to let card complete
U0DBUF = 0xFF;

I am not sure what that comment means, but if your SPI slave actually does expect an extra 0xFF byte to be written, I suggest that you add that byte to the end of the buffer you pass to spiWriteData instead of hard-coding it into the function (which makes it less generally useful).

- Kevin

hello Kevin
thanks for taking the time
you picked up a couple of schoolboy errors there for me :blush:
I’ve made all the changes suggested, now glaring at code and 'scope!

I’ll take a look at what you’ve done - compare and contrast
thanks again for your help


some observations on your library:
I notice that you are setting SCK and MOSI to peripheral, but not MISO

very neat speed calculation I may (ahem) “borrow” that

your set speed routine writes to UxBAUD and UxGCR
I supect you may need to mask to only set the lower 5 bits of UxGCR
else you will lose the CPOL, CPHA and ORDER bit settings

your code is so much smaller than mine
guess the interrupts help


thought I’d post an update
looks like my SPI library is working :smiley:
looks like my SD card interface is working :smiley:

thanks to Kevin for some pointers to the errors of my ways

seems I was not checking for received/sent data correctly
the trick seems to be to clear the flags first
then look for the flag being set

I did need the “dummy” extra writes as the SD card spec says to allow an extra 8 clocks (conveniently one byte) after most commands to allow the command to finish

I can now reliably read data from the SD card

next steps:
write to the card :open_mouth:
look at implementing a FAT system (PROB90 based on pfs)

happy bunny - moi!?! :laughing: (3.66 KB) (4.9 KB)

I’m glad you got it working! To respond to your observations:

I think David thought about this and concluded that setting the MISO pin to its peripheral function seems to have no benefits other than disabling the internal pull-up. It doesn’t seem to matter too much either way, but we might change this in the future.

The code in spiNMasterSetFrequency is a slightly improved version of the uartNSetBaudRate function in our UART library (we will probably add the same improvements to uartNSetBaudRate too). You are right about the upper bits in UNGCR being clobbered; they didn’t matter in the UART function, but I forgot to change the code when I copied it to the SPI function. Thanks for pointing it out.

I think this is mostly because we use a “template” to compile the library for USART 0 and USART 1 separately, instead of using conditionals to handle both like you are doing, which essentially doubles the length of your code. At the top of spi_master.c, you can see that (for example) spiNMasterInit is #define’d as either spi0MasterInit or spi1MasterInit depending on whether SPI0 or SPI1 are defined. Then, sets things up so that when you compile the library, it makes two copies of the source and compiles it once with SPI0 defined and once with SPI1 defined.

- Kevin

ok - onwards and spiralling downwards
how do you actaully make a library?

I tried just copying files around and got knickers in a very bad twist

is there an iijit’s guide “make a library 101” or some such?

For a simple library with just one .c file and one .h file, all you should need to do is move your .c file into libraries/src/library_name/ (for example, libraries/src/spi/spi.c). Then move the .h file into libraries/include/. When you compile again, your new library should automatically be created and placed in libraries/lib/.

To use your library in an app, make sure to angle brackets instead of double quotes in the #include statement in your app (replace #include “spi.h” with #include <spi.h>). You will also need to add the library to your file to allow your app to be linked with it, since it is not in the list of default libraries. If you do not already have an, just create a new file in your app’s directory with the following content:

APP_LIBS += spi.lib

- Kevin

thanks for that
tried it
works a treat
you, sir, are a star!

now pressing on with the SD library
can open and read a card, but not reliably…

ok more progress
I think that’s what I mean - stumble forwards, graze knees, curse, goto 1

anyway attached are two libraries

spi - a few updates now that I have things working
sd - I can finally insert a card, initialise it and read blocks of data

still a way to go, but, one small stumble for hacker-kind! :open_mouth: (2.83 KB) (4.91 KB)

bit of a breakthrough today :smiley:
can now insert a card, initialise it, read and write sectors!!!
library and test program attached for your amusement

next up FAT filing system!

typical timings:
initialise card 150 mS
read sector (512 bytes) 12 mS
write sector (512 bytes) 12 mS (3.29 KB) (4.73 KB) (2.21 KB)

Congratulations, and good luck getting the file system to work!

Have you considered using git to keep track of the development history of your library? You could make a fork of the wixel-sdk on github. Git makes it really easy to keep track of all your changes (line by line) and save copies (commits) whenever you want to.