You will get nonsense back from SPI until you send the correct commands to the ADC. The datasheet should tell you what bytes need to be sent, e.g. for the 12 bit ADC MCP3202 I'd use pi.spi_xfer(h, [1,128,0]) and get back the 12 bit value in the response.

Thanks, now I can feel the logic. I'll read the datasheet thoroughly and let you know, Joan!

I didn't notice before but you should not set the SPI GPIO to be inputs or outputs, the hardware will set them to SPI mode. Also remember that pigpio only uses Broadcom numbers for the GPIO (i.e. not pin numbers as you seem to be using in the example above).

Clear. So what argument should I put instead of INPUT/OUTPUT?

You shouldn't touch them at all while they are being used for SPI. pigpio will set them to SPI mode.

Ok, so I don't have to set them.. fine. I'm still looking for the starting byte

Reading the datasheet I got in the Register Map page. The answer seems to be hidden here, but I can't really understand how it works. I have a chart with addresses and respective bits, but I don't know how to write this data with pigpio. Is the address the data I have to insert or not? I tried but it says it is an invalid token.

I have not used the ADS1256. Can you find another SPI example for the chip on the www? The bytes needed will be common to all SPI software. What is reporting invalid token?

// define the command bytes (see table 24 on page 32 in the PDS #define CMD_WAKEUP 0x00 #define CMD_RDATA 0x01 #define CMD_RDATAC 0x03 #define CMD_SDATAC 0x0f #define CMD_RREG 0x10 #define CMD_WREG 0x50 #define CMD_SELFCAL 0xf0 #define CMD_SELFOCAL 0xf1 #define CMD_SELFGCAL 0xf2 #define CMD_SYSOCAL 0xf3 #define CMD_SYSGCAL 0xf4 #define CMD_SYNC 0xfc #define CMD_STANDBY 0xfd #define CMD_RESET 0xfe #define CMD_WAKEUP2 0xff

I found this. Even though it's in C I suppose, these should be the command bytes. After using spi_open I used spi_xfer in this way: spi_xfer (h, [0x00]) I tried with and without square brackets, but it returns me the same thing I wrote in the question. Somewhere I read that they used as data the address of the register, so I tried this: spi_xfer(h, [01]) and it returns me "invalid token". I'm sorry for the mess, but I'm trying to do as much tries as possible.

Does the test from waveshare.com/wiki/High-Precision_AD/DA_Board work (udo ./ads1256_test)?

It doesn't. Doesn't even find the file.

The ADS1256 is a peculiar device. It seems to require delays in the middle of SPI transfers. That is not standard. Try opening the device at 50000 bps and see what spi_xfer(h, [0x10, 0x00, 0x00, 0x00]) returns.

(4, bytearray (b'\x00\x00\x00\x00') its the returned message

Did you download and install the test program from waveshare.com/wiki/File:High-Precision-AD-DA-Board-Code.7z

No, I can't install 7zip.

Ok, I've installed the test program and it works.

I'll have a quick look through the C. You may have to use C to access this device because of its non-standard SPI interface (in particular the delays which need to be inserted in the data stream).

Ummh, try spi_xfer(h, [0x10, 0x00]) immediately followed by spi_xfer(h, [0x00]).

Nothing changed. I'm asking at Texas Instruments if it is compatible with Python

Meanwhile I can send to you the test program in C we ran before so that it can give you some hints.

I've run the test program. I was looking at which GPIO it was using for the signal lines. They are standard. I don't think the pigpio Python module will work with this chip. It probably could be made to work but it would need a lot of hands on experimentation. You might have more chance with the standard spidev module and one of the other Python modules such as RPi.GPIO. They don't use the client/server model of the pigpio Python module and for the specific SPI timing needed by that chip they would be better.

Ok thanks, I'll try with spidev.

May I ask you what you mean by "client/server model"? Its just curiosity, if it doesnt take too much time to you for explaining it.

The pigpio Python module talks to the pigpio daemon which is the software which actually talks to the GPIO. That means that pigpio Python scripts do not need to be run as root as the pigpio daemon does all the privileged stuff. The pigpio daemon is a separate process and inter-process calls (IPC) need to be made from the Python script to the daemon. These IPC use TCP/IP sockets and work just like your browser, e.g. a request is sent over the network and a reply is received from the network. That takes time. On the Pi it takes roughly half a millisecond per request.

Clear, thank you very much Joan!

Another question. Whenever I write a byte, for example "0x01", is it like saying bit 0 of register 01?

The SPI protocol assigns no meaning to the data transferred. The meaning of the data is determined by the manufactur of the device you are talking with. All you know when writing 0x01 is the device will receive a series of bits 0, 0, 0, 0, 0, 0, 0, 1. The device datasheet will tell you what that means to the device.

I'm having problems installing spidev. I read some threads on which you personally answered and I followed your installation instructions. It doesn't work though.

But another problem is with spi itself. I changed the options using raspi-config, edited the config.txt, I even tried to paste at /lib/modules the modules bcm_2708, but when I run the command modprobe bcm_2708 spidev it always returns "no such device". Same with lsmod command, spi_bcm2708 is missing.

The Linux SPI driver is now called spi_bcm2835. That should not make any difference to the Python spidev module. You should not be using modprobe any more. Let device tree handle loading the needed SPI modules.

Ok thanks. What do you mean with your last sentence though? I've downloaded the module from github, unzipped, make and installed the setup.py, but as I insert this two last commands two blank python windows appear. To end the process and insert a new command in the terminal I've to close them. Is this normal? Should I write something in those windows?

Let device tree handle loading the needed SPI modules? Just what it says, you should not be using modprobe to load the SPI kernel module.

Ah, clear. Well, if lsmod command returns spi_bcm2835 I suppose there's no problem then, right?

Yes. Perhaps simplest just to ls /dev/spi* and check that the two devices are present.

Yes, they are present. Now the only problem is the installation of spidev module. Do you know why the blank windows appear?

No. I don't remember anything similar. Which instructions are you following? It is probably best to raise a new question as this has nothing to do with pigpio as such.

Ok, I managed to install spidev. Now I try to communicate with ADC