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.)
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’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.
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).
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, lib_options.mk 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.
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 options.mk 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 options.mk, just create a new file in your app’s directory with the following content:
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.