Change SPI word size not work

[pasifus]

Hi,
I'm use wiringPi library and I'm try to change SPI word size.
I change in wiringPiSPI.c variable spiBPW from 8 to 4,12 and 16 but when i try change it SPI device don't generate output signals (sckl, miso, mosi). only when SPI word size 8 it's work.

What i do wrong?
Thanks.

[pasifus]

Someone tried to change spi word size?

[gordon@drogon.net]

I'm not sure the hardware actually supports it...

So it's multiples of 8 bits only.

You can only write 8, 16, 24, 32, ... bits in a single transaction though, as long as its a multiple of 8.

(that I'm aware of)

What are you trying to interface to that only need 4 bits? (or 12, etc.)

-Gordon

[pasifus]

i have 12 bit adc and i was thinking that send only 12 bit it more easy.

[Gert van Loo]

No, that is not supported by that SPI interface.
There are two other SPI interfaces which do not have that problem**,
but the pins are not brought out so that does not help you.

** Sorry could not help pointing that out as I designed the other SPI interface type.

[gordon@drogon.net]

i have 12 bit adc and i was thinking that send only 12 bit it more easy.

Probably not.... Because what you might find is that to set the ADC you need to send it 16 bits. e.g. 4 bits of 'command' data (select channel, mode maybe?) then keep the clock going for another 12 bits to clock out the data, so needing 16 bits in-all.

At least that's how the ones I've used & seen so-far work.

-Gordon

[pasifus]

ok. if i send 16bit and generate CS with some GPIO. if it possible to generate CS. (SPI_CLK=1MHz)


here is the adc http://www.ti.com/lit/ds/symlink/ads7863.pdf

[gordon@drogon.net]

ok. if i send 16bit and generate CS with some GPIO. if it possible to generate CS. (SPI_CLK=1MHz)


here is the adc http://www.ti.com/lit/ds/symlink/ads7863.pdf

So it's 16 clocks per sample. You need to output the command byte at the same time as reading in the first reply byte, then output a 2nd byte (zeros) to force anothe 8 bits of clock to read in the 2nd data byte.

Look at my gertboard.c driver in wiringPi - it's fairly similar to how that works. (the one in the wiringPi directory, not the one in the examples)

You can only read one converter though - the Pi only has one SPI port. (So you can read 2 inputs on one convertor, but not the inputs on the 2nd convertor), so connect up, Clock, serial in/serial out and one of the Pi's enable pins to the chip (CS) and I think that's all you'll need (other than the usual power, ground, decoupling,etc.) Connect RD to CONVST by the looks of it too.

You could read the 2nd convertor, but you'll need a couple of tristate buffers to enable one at a time to the Pi's MISO pin.

Simples

-Gordon

[TTT]

Hi Gordon,
So if I wanted to connect my RPi to a slave device which communicates with 24 bits. How would I go about that? I tried changing the bits per word but I keep getting an error. I'm using the example that most people on the internet spidev_test.c but it only sends 8 bit words.
Any help would be greatly appreciated.
Thanks

[pasifus]

simple try to send 8 bit three time

[gordon@drogon.net]

Hi Gordon,
So if I wanted to connect my RPi to a slave device which communicates with 24 bits. How would I go about that? I tried changing the bits per word but I keep getting an error. I'm using the example that most people on the internet spidev_test.c but it only sends 8 bit words.
Any help would be greatly appreciated.
Thanks

Just write 3 bytes at once. The enable line will stay low for the entire transaction which is all you need, really.

In my world:

Code: Select all

#include <wiringPiSPI.h>
// stuff

  unsigned char buf [3] ;

  if ((fd = wiringPiSPISetup (chan, speed)) < 0)
    return -1 ;

// You can then simply use write() or read() to write or read 3 bytes at a time, to the fd, or do a
//  simultaneous read/write operation:

// write only:

  write (fd, buf, 3) ;

// or simultaneous w/r transaction

  wiringPiSPIDataRW (chan, buf, 3) ;

// buf updated with the 3 bytes returned at the same time

If you're just writing data (e.g. to those LED strings), then write() is marginally faster than the read/write operation.

-Gordon

[gordon@drogon.net]

simple try to send 8 bit three time

you have to make sure you do it in one transaction - otherwise the enable line will toggle on each transction and some devices use this to reset their input bit counter, etc.

-Gordon

[pasifus]

simple try to send 8 bit three time

you have to make sure you do it in one transaction - otherwise the enable line will toggle on each transction and some devices use this to reset their input bit counter, etc.

-Gordon

yes you right, must to send then by one transaction, also i thin you need to order bytes before sending (Big-Endian/Little-Endian)

[pasifus]

ok. if i send 16bit and generate CS with some GPIO. if it possible to generate CS. (SPI_CLK=1MHz)


here is the adc http://www.ti.com/lit/ds/symlink/ads7863.pdf

So it's 16 clocks per sample. You need to output the command byte at the same time as reading in the first reply byte, then output a 2nd byte (zeros) to force anothe 8 bits of clock to read in the 2nd data byte.

Look at my gertboard.c driver in wiringPi - it's fairly similar to how that works. (the one in the wiringPi directory, not the one in the examples)

You can only read one converter though - the Pi only has one SPI port. (So you can read 2 inputs on one convertor, but not the inputs on the 2nd convertor), so connect up, Clock, serial in/serial out and one of the Pi's enable pins to the chip (CS) and I think that's all you'll need (other than the usual power, ground, decoupling,etc.) Connect RD to CONVST by the looks of it too.

You could read the 2nd convertor, but you'll need a couple of tristate buffers to enable one at a time to the Pi's MISO pin.

Simples

-Gordon

thanks for trick to send 16 bit by one session (4bit zeros and 12bit control data )
but i confuse about RD/CONVST. it's needs to see a clock edge.
if i can to generate gpio in first 4bites(zeros) of spi transmit or maybe you now better solution?

i really need read only from one convertor

[gordon@drogon.net]

thanks for trick to send 16 bit by one session (4bit zeros and 12bit control data )
but i confuse about RD/CONVST. it's needs to see a clock edge.
if i can to generate gpio in first 4bites(zeros) of spi transmit or maybe you now better solution?

i really need read only from one convertor

I read the data sheet. It seemed to suggest you can connect the RD (output) to CONVST (input).

-Gordon

[pasifus]

thanks for trick to send 16 bit by one session (4bit zeros and 12bit control data )
but i confuse about RD/CONVST. it's needs to see a clock edge.
if i can to generate gpio in first 4bites(zeros) of spi transmit or maybe you now better solution?

i really need read only from one convertor

I read the data sheet. It seemed to suggest you can connect the RD (output) to CONVST (input).

-Gordon

uuups it's my fault i thought that RD it also input.

Thanks a lot of. I will try your solution.

[gordon@drogon.net]

yes you right, must to send then by one transaction, also i thin you need to order bytes before sending (Big-Endian/Little-Endian)

Left as an excercise to the user ...

-Gordon

[pasifus]

ok. if i send 16bit and generate CS with some GPIO. if it possible to generate CS. (SPI_CLK=1MHz)


here is the adc http://www.ti.com/lit/ds/symlink/ads7863.pdf

So it's 16 clocks per sample. You need to output the command byte at the same time as reading in the first reply byte, then output a 2nd byte (zeros) to force anothe 8 bits of clock to read in the 2nd data byte.

Look at my gertboard.c driver in wiringPi - it's fairly similar to how that works. (the one in the wiringPi directory, not the one in the examples)

You can only read one converter though - the Pi only has one SPI port. (So you can read 2 inputs on one convertor, but not the inputs on the 2nd convertor), so connect up, Clock, serial in/serial out and one of the Pi's enable pins to the chip (CS) and I think that's all you'll need (other than the usual power, ground, decoupling,etc.) Connect RD to CONVST by the looks of it too.

You could read the 2nd convertor, but you'll need a couple of tristate buffers to enable one at a time to the Pi's MISO pin.

Simples

-Gordon

thanks for trick to send 16 bit by one session (4bit zeros and 12bit control data )
but i confuse about RD/CONVST. it's needs to see a clock edge.
if i can to generate gpio in first 4bites(zeros) of spi transmit or maybe you now better solution?

i really need read only from one convertor

i tested today spi and find that spi delay between write sessions it very long

Code: Select all

while(TRUE)
        {
                buff[0] = 0x32;
                buff[1] = 0x10;

                // send data to SPI
                wiringPiSPIDataRW(0, buff, 2);
        }

spi_speed = 1MHz
kernel: Linux raspberrypi 3.2.27+ #307 PREEMPT Mon Nov 26 23:22:29 GMT 2012 armv6l
WiringPi from: https://github.com/WiringPi/WiringPi

How to reduce the delay?

[gordon@drogon.net]

i tested today spi and find that spi delay between write sessions it very long

Code: Select all

while(TRUE)
        {
                buff[0] = 0x32;
                buff[1] = 0x10;

                // send data to SPI
                wiringPiSPIDataRW(0, buff, 2);
        }

spi_speed = 1MHz
kernel: Linux raspberrypi 3.2.27+ #307 PREEMPT Mon Nov 26 23:22:29 GMT 2012 armv6l
WiringPi from: https://github.com/WiringPi/WiringPi

How to reduce the delay?

Firstly, please get wiringPi from https://git.drogon.net/ and not github. The github version is not maintained by me, but rather Gadgetoid who maintans the wrappers for wiringPython, etc. It's sometimes a few revisions behind my own released version. However that's not going to help you here..

But yes, there is a gap of about 1 clock cycle between bytes. It's like a stretched clock pulse. I've observed this too. I'm fairly sure this is a limitation of the hardware and nothing in software. (there are other latency issues in the current kernel SPI drivers, but I'm fairly sure this isn't part of that) Something you will have to live with in this $35 device. It's not given me any issues with the few devices I've used it with so-far.

-Gordon

[pasifus]

i tested today spi and find that spi delay between write sessions it very long

Code: Select all

while(TRUE)
        {
                buff[0] = 0x32;
                buff[1] = 0x10;

                // send data to SPI
                wiringPiSPIDataRW(0, buff, 2);
        }

spi_speed = 1MHz
kernel: Linux raspberrypi 3.2.27+ #307 PREEMPT Mon Nov 26 23:22:29 GMT 2012 armv6l
WiringPi from: https://github.com/WiringPi/WiringPi

How to reduce the delay?

Firstly, please get wiringPi from https://git.drogon.net/ and not github. The github version is not maintained by me, but rather Gadgetoid who maintans the wrappers for wiringPython, etc. It's sometimes a few revisions behind my own released version. However that's not going to help you here..

But yes, there is a gap of about 1 clock cycle between bytes. It's like a stretched clock pulse. I've observed this too. I'm fairly sure this is a limitation of the hardware and nothing in software. (there are other latency issues in the current kernel SPI drivers, but I'm fairly sure this isn't part of that) Something you will have to live with in this $35 device. It's not given me any issues with the few devices I've used it with so-far.

-Gordon

You right it not problem of WiringPi version (in your repository i see same gap). I thinks it device problem, too.
Maybe you now projects that try to reduce delay between segment transmuting. (changes in spi driver)
To example http://www.open.com.au/mikem/bcm2835/ if can to help me? (or that same driver that use in this kernel)

[gordon@drogon.net]

You right it not problem of WiringPi version (in your repository i see same gap). I thinks it device problem, too.
Maybe you now projects that try to reduce delay between segment transmuting. (changes in spi driver)
To example http://www.open.com.au/mikem/bcm2835/ if can to help me? (or that same driver that use in this kernel)

That library pokes the SPI hardare directly rather than use the kernel driver. I'm of the opinion that it would suffer the same problems because the problem is with the hardware on the SoC and not the software driving it. I do not recommend using anything other than the standard supplied kernel drivers to drive the SPI and I2C (and serial) hardware on the Pi. My SPI acces code in wiringPi is just trivial wrappers round the kernel stuff to make it easier to use.

-Gordon

[sr447011]

If you got this to work could you please post the code? I am trying to get the ADS7863 to connect to my Raspberry Pi B+ as well with no luck. I am having a bit of trouble following the conversation. I thing that seeing the code might help.

Also, Gordon, are you saying to physically just connect CONVST directly to RD without either of them connected to anything else?

Sorry for all the stupid questions.
Thanks!