SPI use under Linux/Pascalio [SOLVED]

[MadMike]

Hi folks,

Trying to get to grips with the SPI interface on a Raspberry.

I have to read a 10 bit a/d converter but the best I can resolve is no more than the lower 8 bits!

I had no luck with the included MCPxxxx demo programs, they just didn't work at all.

I got better results when I modified the SPI demo, which I include here.

Code: Pascal  [Select][+][-]

1. (* SPI Linux demo program
2.  *
3.  * This simple program demonstrates how to use the class TSPILinuxDevice to
4.  * access a SPI bus on a Linux published in the file system by the spidev
5.  * driver.
6.  *
7.  * )
8.  
9. program Project1;
10. {$mode objfpc}
11. uses
12.   fpspi;
13.  
14. var
15.   spi: TSPILinuxDevice;
16.   rbuf, wbuf, smallrbuf: LongWord;
17. begin
18.   // SPI Bus 0
19.   // 2nd ChipSelect
20.   // The numbers are directly mapped to the file name /dev/spidevB.C
21.   // with B = Bus and C = Chipselect
22.   // see https://www.kernel.org/doc/Documentation/spi/spidev
23.   spi := TSPILinuxDevice.Create(0, 1);
24.   // set a SPI mode
25.   spi.Mode := SPI_MODE_0;
26.   spi.MaxFrequency:= 500;
27.   spi.LSBfirst:= false;
28.   try
29.     // data sent to device
30.     wbuf := $01800;
31.     // The read and write buffers don't need to be of the same size
32.     // the larger one will determine the total bytes sent
33.     // If length(wbuf) < length(rbuf), the remaining bytes will be sent as 0
34.     spi.ReadAndWrite(wbuf, sizeof(wbuf), rbuf, sizeof(rbuf));
35.     // handle result
36.     rbufsmall:= rbu shr 24;
37.       WriteLn('Rbuf ='+ IntToStr(rbuf));
38.       WriteLn('Shifted Rbuf ='+IntToStr(rbufsmall));
39.       WriteLn('');
40.       Sleep(100);
41.   finally
42.     spi.Destroy;
43.   end;
44. end.

As I've said before, a complete noob here.

All comments invited.

mike

[MarkMLl]

Mike, tell us more about what's going wrong: are you not seeing the data back you'd expect or is it coming back but rubbish?

I think I prodded a bit at SPI a couple of years ago, but went direct to the kernel and was talking some something vaguely Arduino-like rather than a specific hardware device.

MarkMLl

[MadMike]

Hi Mark,

The 'raw' rbuf value is 4 bytes long. Only the MSByte has any value in it: 0 to 255. As its the MSB there's no where for the 'carry' to go so it just rolls over.

When I hang a 'scope on the returned data stream I can see its incrementing past the 255, so I know the  A/D converter is returning data properly.

Mike

[MarkMLl]

I've been looking through my notes and surviving sources. I definitely had I2C running between an RPi and directly-connected Raspi-Duino, I'm not entirely sure where I got to with SPI... I might have had something running at one point but lost the sources due to media problems.

I was looking at a CH340 board a few weeks ago in conjunction with out-of-tree Linux modules, GPIO bits work but don't think that I currently have an SPI device I could use to exercise it.

MarkMLl

[MadMike]

Every time the MSByte rolled over I noticed the raw rbuf value was different.

It seems the bits 9 & 10 end up half way down this raw rbuf.

Maybe some bit manipulation can get me out of trouble.

Thanks

Mike

[MarkMLl]

Are you sure this isn't something silly like an endianness issue? Are you parsing the input as a sequence of bytes or "being clever" and overlaying a 32-bit integer on top of them?

MarkMLl

[jamie]

Every time the MSByte rolled over I noticed the raw rbuf value was different.

It seems the bits 9 & 10 end up half way down this raw rbuf.

Maybe some bit manipulation can get me out of trouble.

Thanks

Mike

sounds like standard com to me...

They are received in Byte format, the first byte is the MSB, the next one third, next second and then finally the LSB

If went receiving each byte you first SHL 8 of the accumulator then Add the new value to the ACC.
so you shift SHL 8  three times and the last one you just do a ADD.

 basically you can ADD first to the ACC and then loop back to read another incoming until you reach a total of four and you stop SHL 8..

SO the unit is sending the MSB first down to the LSB..

[MadMike]

@Jamie

It turns out you're right. I just had to 're-arrange' the bytes in the right order.

Thanks