4 Replies Latest reply on May 13, 2014 9:47 AM by SpiderKenny

    SPI from Linux, not Arduino - strange results.


      I am investigating accessing SPI deices from Linux natively.

      So far I have had some success but it's not quite right.


      First of all, I use this script to switch all the muxes to allow the Quark native SPI1 signals through to the header, and to switch on the voltage level convertor:

      This script first makes the GPIO Lines available from /sys/class/gpio and then sets them to OUTPUTS, sets STRONG DRIVE on them all and then sets '0' as their values. This has the effect of selecting the MUXES such that the Quark native SPI1 lines are routed through to the Shield pin headers on pins 10 to 13. It also enables the bidirectional level shifter.


      echo -n "4" > /sys/class/gpio/unexport

      echo -n "42" > /sys/class/gpio/unexport

      echo -n "43" > /sys/class/gpio/unexport

      echo -n "54" > /sys/class/gpio/unexport

      echo -n "55" > /sys/class/gpio/unexport


      echo -n "4" > /sys/class/gpio/export

      echo -n "42" > /sys/class/gpio/export

      echo -n "43" > /sys/class/gpio/export

      echo -n "54" > /sys/class/gpio/export

      echo -n "55" > /sys/class/gpio/export


      echo -n "out" > /sys/class/gpio/gpio4/direction

      echo -n "out" > /sys/class/gpio/gpio42/direction

      echo -n "out" > /sys/class/gpio/gpio43/direction

      echo -n "out" > /sys/class/gpio/gpio54/direction

      echo -n "out" > /sys/class/gpio/gpio55/direction


      echo -n "strong" > /sys/class/gpio/gpio4/drive

      echo -n "strong" > /sys/class/gpio/gpio42/drive

      echo -n "strong" > /sys/class/gpio/gpio43/drive

      echo -n "strong" > /sys/class/gpio/gpio54/drive

      echo -n "strong" > /sys/class/gpio/gpio55/drive


      echo -n "0" > /sys/class/gpio/gpio42/value

      echo -n "0" > /sys/class/gpio/gpio43/value

      echo -n "0" > /sys/class/gpio/gpio54/value

      echo -n "0" > /sys/class/gpio/gpio55/value  

      And then I compiled this code, as 'spiread' to access SPI from C Code.

      This code is based on the code at Using SPI with Linux | armbedded.eu

      #include <stdio.h>

      #include <fcntl.h>

      #include <stdlib.h>

      #define ARRAY_SIZE(array) sizeof(array)/sizeof(array[0])

      int main(int argc, char **argv)


        int i,fd;

        char wr_buf[]={0x03,0x00,0x00,0x00};

        char rd_buf[32];


        if (argc<2) {

        printf("Usage:\n%s [device]\n", argv[0]);




        fd = open(argv[1], O_RDWR);

        if (fd<=0) {

           printf("%s: Device %s not found\n", argv[0], argv[1]);




        if (write(fd, wr_buf, ARRAY_SIZE(wr_buf)) != ARRAY_SIZE(wr_buf))

           perror("Write Error");


        if (read(fd, rd_buf, ARRAY_SIZE(rd_buf)) != ARRAY_SIZE(rd_buf))

           perror("Read Error");


           for (i=0;i<ARRAY_SIZE(rd_buf);i++) {

              printf("0x%02X ", rd_buf[i]);

              if (i%2)





        return 0;


      And then from the terminal I run the code, giving the device as /dev/spidev1.0:

      spiread /dev/spidev1.0


      I have my Logic analyser hooked up to Pins 10 to 13 and GND. The pins are:

      10 - CS / ENABLE

      11 - MOSI

      12 - MISO

      13 - CLOCK


      I do see some activity when I run spiread, and it is kinda OK. I see the CS signal going low, and some clocking. I don't expect to see anything on MISO since there is no device connected. I see some activity on MOSI, but it doesn't look right.


      Here's what my Logic analyser sees for the write and read operations:

      Screen Shot 2014-05-13 at 14.28.45.png

      And here is the same capture, zoomed into the first block, the WRITE operations:

      Screen Shot 2014-05-13 at 14.29.01.png


      As you can see, there are only 4 clock pulses, and not enough activity on MOSI.


      Finally, here is what my Oscilloscope sees on the CLOCK signal alone, during the same WRITE operation:

      Screen Shot 2014-05-13 at 14.27.59.png


      It's almost there, it does something but the signals are not clean, that might just mean they need a pull-up, but there is definitely not the correct pattern of clock pulses and data signals.


      Any ideas?