Bare Metal SPI

[TheRTmiller]

Hello Pi-Community!

I have the following problem:
I'm trying to use the Pi in combination with the PiFace Digital extension board (to run some servos and let some LEDs blink),
and i just can't get the freakin' SPI-communication between the two up and running.

Programming in C on bare-metal makes this a lot more complicated than i had hoped it would be.
I found exactly TWO code-examples on the internet, both of which i can't decrypt...
https://bitbucket.org/ggkinuthia/bare-metal-spi/src
https://github.com/dwelch67/raspberrypi ... ster/spi01

I took the spi-functions from the first repository and tried to fit them into my code:

main program structure

Screen Shot 2015-01-02 at 19.51.01 copy.jpg (56.84 KiB) Viewed 3897 times

as a result, the PiFace does absolutely nothing (I have a couple of LEDs hooked onto it).
I have (partially) read the data sheets for the MCP23S17 and the BCM2835, but I must have overlooked something.
I am not even sure that the way I communicate to the PiFace [opcode-byte (0100 0000), adress-byte, data-byte, opcode, AB, DB,...] is correct.

Maybe some of you have some constructive input for me, I am officially stuck.
My main problem is that i just can't find any decent documentation regarding this issue....

Thanx!

[bulletmark]

Is there any reason you want to avoiding using the python interface to the PiFace board?

[rpdom]

Is there any reason you want to avoiding using the python interface to the PiFace board?

Bare metal implies no Linux OS, so therefore no Python.

[DougieLawson]

Is there any reason you want to avoiding using the python interface to the PiFace board?

Leave him alone, this topic on getting SPI & an MCP23S17 with an LCD running without an OS is very interesting.

[JacobL]

I don't know the particular peripheral unfortunately, but here are some general pointers on SPI debugging:

The datasheet should mention a SPI mode. There are multiple names for the same, look at http://en.wikipedia.org/wiki/Serial_Per ... de_numbers to translate between various formats.

You should get a logic analyzer so you can look at the actual signal. You can get a USBee clone at dx.com pretty cheap. Otherwise there are the real USBee and Salae, but they can get a bit pricey.

When you get the logic analyzer on, check that the signal looks as you expect. Pay attention to the clock frequency that is actually generated. And of course check if there is actually something there when you write data to SPI. Once you have the write direction (AKA MOSI) handled, you can start looking into the read direction (AKA MISO). Check to see if the chip responds as expected, otherwise something would need to be clarified in the datasheet. Lastly, check that the chip response is also the one seen in your driver.

This method does not get you out of reading datasheets, however it lets you focus on a single one at a time. Getting data out on MOSI is all about the BCM2835, responses are about MCP23S17 and the response seen in the driver is about the BCM2835 once again, but this time it is the read side of it all.

[joan]

pigpio implements SPI in C using direct calls to the SPI hardware (the standard and the auxiliary SPI peripherals).

As it doesn't use the Linux driver it will be close to a bare metal implementation.

The relevant functions in pigpio.c are spiInit, spiGo, spiGoA (auxiliary SPI), and spiGoS (standard SPI) with some ancillary functions.

[dwelch67]

maybe we can dig deeper into what part you dont understand of my code or the others.

For everyone, note that spi debugging be it bare metal or an api on top of an operating system takes experience and sometimes a logic analyzer or scope or other tricks to figure out what is going on.

I often talk about "dividing the problem in half" is the problem you are having here a problem with the spi peripheral, are you making the right signals...OR...is the problem with getting the right combination of commands and data on top of the spi bus to/from the peripheral, sometimes your timing is right you are just sending the wrong commands or wrong amount of bytes to/from the peripheral....OR...is it a combination of the two.

One way to help although it creates its own new problems is to bit bang the spi rather than try to use the spi peripheral. use the same pins or choose others and big bang your way through a simple read id register or something if that is possible, go really slow, lots of time between transitions for settling, etc. If you can talk to the device that way but not with the spi peripheral then you have a problem with using the spi perhipheral and not your knowledge of the payloads going to/from the peripheral. if that doesnt work then well you have replaced one unknown with another unknown, but you are in more control of this unknown than the spi peripheral.

folks have seen my experience and work here and github and spi peripherals scare me a bit, have melted down chips trying to get them to work. spi and i2c I almost always get out the scope, but I have access to nice equipment like that. I have done things like take other boards, and make my own logic analyzer by making a few pins inputs, polling for state changes and logging those then printing them out over a uart, then constructing the waveforms from that to see what roughly is being generated without having a scope...but that adds another board and layer of unknowns to build that logic analyzer...

[tekim]

Writing code for driving SPI or I2C hardware can be trouble some if no diagnostic hardware is available and as I have only produced such code for PIC devices the following hints may not be of use. If so please ignore this post.

I found the most useful fact in both SPI and I2C specifications was the speed parameter. Both are specified as a minimum=0 which means you can run the clock as slow as required and effectively stop the clock. Only an LED connected to clock and data lines (buffered with a transistor in my case) are required to see what the code is producing.

In a similar way using your own low level code to drive the SPI connecting an SD card means data does not have to be read/written to/from a buffer. Single bytes can be read/written, SPI clock stopped, processed, clock started for next byte. The SD card just waits till 512bytes of data have been transfered.

This latter hint is most likely not of use when using a Pi with its megabytes of RAM but on a PIC device its was very useful.

Cheers