SPI setup problem

[JohnBeardmore]

I'm trying to use the Gertboard dtoa.c code to acess a MCP4812 DAC.

I appreciate this isn't the 8 bit version of this chip that's normally used with the Gertboard, and I was expecting to have to make a few mods to use the device.

Before I can do this though, I have an initialisation problem.

The function setup_spi() never returns.

I'm using Raspbian
I have a /boot/config.txt file containing dtparam=spi=on
I can see /dev/spidev0.0 and /dev/spidev0.1

What else go wrong with setting up SPI ?

Cheers, J/.

[JohnBeardmore]

Sorry ! Meant to say:

What else COULD go wrong with setting up SPI ?


Can't type in the middle of the night !

Cheers, J/.

[fsr]

you can test the linux side of things by running spidev_test.c which is distributed with the kernel
https://github.com/raspberrypi/linux/bl ... dev_test.c
(download, compile, run with --help)

Then connect miso to mosi and run the test with -D /dev/spidevX.Y (configure to suit)
if you get a response then the config.txt / kernel models / permissions is all ok and working
if you do not get a response check everything and try again till you do.

if you code still hangs then it is almost certainly a problem with the code. isolate and examine...
repeat what the code is doing with spidev_test - e.g. clock speed, flags etc to see if spidev is throwing up an error the code isn't catching.

(spi doesn't have any sense of an acknowledgement from clients and so cannot 'hang' waiting for a response. it'll quite happily speak to nothing)

[JohnBeardmore]

Thanks.

So when I get to the github page, what do I do to download spidev_test.c ?

I can't see an obvious 'download this file' buttoin, and if I try to cut and paste, it only gives me screen sized chunks.

Cheers, J/.

[fsr]

can't see an obvious 'download this file' buttoin

there is a button then gets the 'raw' file then I wget this raw url straight onto the PI

Code: Select all

wget https://raw.githubusercontent.com/raspberrypi/linux/rpi-4.1.y/Documentation/spi/spidev_test.c

and build

Code: Select all

gcc -o spidev_test spidev_test.c

[JohnBeardmore]

Thanks. I tried compiling it, but I get a bunch of errors which refer to SPI_TX_DUAL, SPI_RX_QUAD, SPI_RX_QUAD, SPI_IOC_WR_MODEE32 and SPI_IOC_WR_MODEE32 as undeclaired.

Have I missed something obvious ?

Thanks, J/.

[fsr]

Thanks. I tried compiling it, but I get a bunch of errors which refer to SPI_TX_DUAL, SPI_RX_QUAD, SPI_RX_QUAD, SPI_IOC_WR_MODEE32 and SPI_IOC_WR_MODEE32 as undeclaired.

Have I missed something obvious ?

Thanks, J/.

you are running an older kernel?
spidev was enhanced at some point and your header (/usr/inlcude/linux/spi/spidev.h) doesn't have these new features in it thats all.

easy to correct, we just need to know your kernel version: uname -a

[JohnBeardmore]

uname -a says:

4.1.6-v7+ #810 SMP PREEMPT

I assume those are the kernel version bits ?

Many thanks, J/.

[fsr]

ok

lets try this one then
https://raw.githubusercontent.com/raspb ... dev_test.c

[joan]

Bare metal?

It might be helpful if you posted the code you are using (dtoa.c?). If it's written for the Gertboard there may be obvious changes needed for use on the Pi.

[JohnBeardmore]

fsr:

Thanks ! That version compiled without problem.

I've got a MCP3008 on 0.0 and an MCP4802 on 0.1

With the -D /dev/spidev0.0 or 0.1 options I get a result, and the hex dumps are a little different which seems right if data is being shifted through two different devices.

The interesing detail is that this refers to spi mode 0, 8 bits per word, and 500kHz maximum speed. Does this all seem right ? I'd got the impression somewhere that 1Mhz operation was normal for SPI on a Pi, and this is a Pi2.

Any thoughts ?

More to follow shortly.

Many thanks, J/.

[JohnBeardmore]

I'm still going through my A to D and D to A chips rather than connecting miso to mosi, but if I try the -l option for loopback, I get a "can't set spi mode: invalid argument" error. Is this normal for the Pi ?

Thanks, J/.

[JohnBeardmore]

Joan wrote:

>Bare metal?

Hi Joan,

You mean I'm off topic here ? Sorry, I probably am. If so, which would be the more appropriate forum? I must admit that I tend to keep coming back here with hardware related questions, because generally I get useful answers. In other groups my questions frequently sink without trace.

>It might be helpful if you posted the code you are using (dtoa.c?). If it's written
>for the Gertboard there may be obvious changes needed for use on the Pi

Yes, it is dtoa.c - I had the impression that all the Gertbord did with SPI was let you patch it to whichever chips you wanted to use, so I expected Gertboard code to drive an MCP4802 (number of bits aside) connected directly to the Pi. Have I misunderstood something fundamental here ? I can upload atod.c if you like though it doesn't seem to have changed for a few years, so if you have an old copy hanging around, it's probably the same code that I'm using.

Many thanks, J/.

Thanks, J/.

[JohnBeardmore]

OK, a bit more progress.

Having added a bunch of printf()s and fflsuh( stdout )s it seems to be not returning from write_dac() in gb_spi.c

It seems to be failing between the 'Values sent' printf, and the following 'Done bit cleared' printf, so presumably the do{}while loop is never terminating ?

Thoughts anyone ?

I did try changing the SPI clock speed to 500kHz by setting SPI0_CLKSPEED = 500 in setup_spi() in gb_spi.c but this didn't seem to change the behaviour.

Help !

Cheers, J/.

[fsr]

[quote="JohnBeardmore"invalid argument" error. Is this normal for the Pi ?[/quote]

yes.
the broadcom spi hardware / driver doesn't support all of the possible features that linux implements.
invalid argument just means 'I don't support that feature'

[fsr]

spi mode 0, 8 bits per word, and 500kHz maximum speed.

spidev_test is just using safe values

spi mode -> this is device specific. the data sheet of the devices will tell you which mode to use
bits per word -> current driver only supports 8bpw so you have no options here! its a pity as lcd screens commonly use 9 bpw
500khz max speed -> crank this up as far as your device can take. at some point the device will stop responding properly

this is where spidev_test is useful.
it lets you experiment with different options quickly.

[fsr]

'Done bit cleared'.

This sounds to me like the code is not using linux driver at all but rather accessing the hardware direct?
If you I assume you have stopped the linux driver loading? (take out spi=on from config.txt)


Poking hardware directly is not my realm.
All I can suggest it to look at the various libraries round that use spi and see how the registers are being initilised.

[joan]

Unless the code you are using is massive why not post it or at least a link to where others can find it.