@Kazooie : Hadn't time top check the datasheet in depth, but you should indeed get values up to 4096 if Vin = Vdd (check p.13 of datasheet). What is you Vdd and Vin to wich you get 252 (which is a very strange value by the way). You could connect the analog input to you Vdd. The converter should output 4096.

@rahul2413 looks like you're trying to do a full-duplex SPI transaction. The Omega2 family does not support full-duplex on the hardware SPI bus. Half-duplex transactions will work fine. More details in this FAQ post. If you absolutely need full-duplex, you can try using a software-based SPI bus.

@luz Thank you for detailed explanation. I probably will use soft spi because of parallel usage needs of two devices. it will be too slow but there is no other chance. I will need to make some hardware design changes. But i couldnt understand why hardware spi count is limited in openwrt side. i know MT7688 has two hardware supported spi cs pin but it could be increased by openwrt side as adding gpios as cs with hardware spi. Thanks again @luz

@Jonathan-Jefferies still going strong thanks for the reminder - I've updated the OpenWRT-Packages repo to set the openwrt-18.06 branch as the default!

I compiled a simple spi C program, as per: http://linux-sunxi.org/SPIdev#In_the_user_space PID PPID USER STAT VSZ %VSZ %CPU COMMAND 3768 1816 root R 900 1% 65% ./spi The %VSZ value remains constant. while (1==1){ buffer=(char *)spi_read(0x10,0x0A,11,file); //reading the address 0x100A for (i =0; i < 11; i++) { printf("%X ",buffer[i]); } } I am planning to make a daemon C program that stores reads from the SPI device in a /tmp/buffer file. Then I can read the file with Python.

Hi,everyone. I'm working on a project where I need to connect a chip that works over SPI .I used raspberry pi 4 and Ic ad5422 in my project. now I want to send data throw spidev and xfer that my data is 24 bits. The input shift register is 24 bits wide. Data is loaded into the device MSB first as a 24-bit word under the control of a serial clock input, SCLK. Data is clocked in on the rising edge of SCLK. The input register consists of eight address bits and 16 data bits. The 24-bit word is unconditionally latched on the rising edge of the LATCH pin. Am I using spi.xfer3([0xab, 0xcd,0xef], 3) in my code? Does anyone know what am I doing?

@Jeremy-Shubert To answer my own question...you create a new software based SPI device using insmod spi-gpio-custom, then you can access this device on the bus you created with the standard Python module, just point it to the newly created device. I haven't been able to get the CLK and data signals working but the CS triggers using this method

I seem to have found a solution for this issue, or at least a work around that works for me: YMMV I've merged in the OpenWRT repo (git merge -X theirs openwrt/lede-17.01) into my OnionIoT/source repo. That built flawlessly ! :). So we're running kernel 4.4.153 now. That's nice on its own (always recommended to keep up with LTS kernel versions!). Anyway, the SPI problem persisted. Then I removed the original Onion patch file for the spi-mt7621 module (rm ramips/patches-4.4/9999-spi-mt7621.patch) and rebuilt the image. Now we're using the unpatched mainline SPI driver. Guess what: this seems to work flawlessly! I'm a happy man now. I only did some quick smoke tests, so it could be other SPI stuff breaks because of the missing patch. On the other hand, there have been some commits to the spi-mt7621 module in June, so the mainline might just be the only thing we need.