8 Replies Latest reply on Jan 14, 2015 7:26 PM by w2r

    Edison spidev for CS0




      I made circuit board that has 2 of MAX14830 (quad UARTs), one connect to CS0, other one connect to CS1.


      I would like to access them via spidev (actually mraa library). but if I use latest yocto image, only /dev/spidev5.1 is available.

      I could access some register for CS1 chip using mraa.


      I would like to know correct way to add /dev/spidev5.0 that control CS0 line.




      Long time ago, I had experience that  I added spidev to Gumstix board.


      I tried to hack kernel for Edison, I found





      I think I have to modify these files.


      I just change  from

      {"ads7955", SFI_DEV_TYPE_SPI, 0, &ads7955_platform_data, NULL},

        • 1. Re: Edison spidev for CS0

          sorry post is devided...


          I just change  from

          {"ads7955", SFI_DEV_TYPE_SPI, 0, &ads7955_platform_data, NULL},


          {"spidev", SFI_DEV_TYPE_SPI, 0, &ads7955_platform_data, NULL},


          for quick test, I build virtual/kernel, edison-image, and flash it, but no /dev/spidev5.0 is appered.


          Please let me correct way to add spidev device.





          • 2. Re: Edison spidev for CS0

            Hello w2r,


            Let me see if I can find out something about this, I will get back to as soon as I find out something about it



            • 3. Re: Edison spidev for CS0

              Hello w2r,


              I'm not sure, but is this what you are looking for?

              In the Intel® Edison Compute Module Hardware Guide, in Table 5, you will find that in pin 53 is CS0, you could call it directly using mraa_gpio_context mraa_gpio_init_raw you can learn how to use this command in: mraa: /var/lib/jenkins/workspace/mraa-doc/api/mraa/gpio.h File Reference



              • 4. Re: Edison spidev for CS0

                Hi Peter,


                Thank you for your reply.


                Yes, I think I can change CS0 line as GPIO manually. But it is not expected method for me.


                My problem is,


                when I use mraa_spi_init(1) to get spi bus context, I saw CS1 was driven as expected during mraa_spi_transfer_buf etc.


                But when I use mraa_spi_init(0) to access other chip I connected CS0, CS0 was not driven during mraa_spi_transfer_buf.

                But SCK/MOSI lines were driven. I feel it looks strange. ( I used oscilloscope to check lines )


                I can not find /dev/spidev5.0, so I think mraa_spi_init(0) should be failed.

                I saw mraa source code, mraa_spi is just wrapped spidev access.


                Arduino breakout uses CS0 line for ADC.

                So I think I have to detach(unbind?) CS0 driver from ADC, and re-attach CS0 driver to spidev.

                I would like to know how to do this. May be I have to re-build kernel with modification, or may be I can unbind/bind from command line.






                • 5. Re: Edison spidev for CS0

                  As far as I can tell, looking at MRAA sources, there is only one SPI buss (5), which if you call the init with (0), will use default (only buss)


                  Currently the MRAA sources look pretty much like the CS pin is hard coded to use the one specific Pin for CS.  that is in the intel_edison_fab_c.c file as part of the board definition you have:


                     b->spi_bus_count = 1;
                      b->def_spi_bus = 0;
                      b->spi_bus[0].bus_id = 5;
                      b->spi_bus[0].slave_s = 1;
                      b->spi_bus[0].cs = 23;
                      b->spi_bus[0].mosi = 11;
                      b->spi_bus[0].miso = 24;
                      b->spi_bus[0].sclk = 10;


                  When you do the spi init call it will initialize the pins to SPI mode...   Note in my code I then actually convert the CS pin back to GPIO pin as I need higher control over the CS pin then the SPIDEV library supports.   As reading data back Pixel data required holding CS pin asserted...  You potentially could do the same here.


                  Also you might raise an issue with the MRAA library suggesting that maybe there should be some api to allow you to choose other valid CS pins.



                  • 6. Re: Edison spidev for CS0

                    Hi KurtE,


                    Thanks, I did not look intel_edison_fab_c.c.


                    I understand the problem, I found if b->spi_bus_count==1, then mraa_spi_init always success with any argument,

                    and returned context is always for CS1.


                    I have to learn more about mraa framework.


                    Thanks again,



                    • 7. Re: Edison spidev for CS0

                      Hi @w2r. Really when we say spi bus in mraa we mean bus + cs. We always pick CS1 because that's the only one available from linux on edison images (that's probably a bug). Basically CS0 is used by the ADC on the arduino board with an IIO module, if that was loaded at runtime on detection of an arduino board then another /dev/spidev5.0 or w/e device could be created which could then be described in mraa. At this time however default images don't do that so short of unloading the ADC module and hacking up the kernel configs a bit you can't access CS0 from userspace.


                      On the miniboard it is 'safe' to use any random gpio as a CS however. Note that the HW CS pin will still get toggled so should be left unwired.

                      • 8. Re: Edison spidev for CS0

                        I tried to investigate who control cs line.


                        in this file,



                        tng_ssp_spi_cs_control() looks toggling CS pin by software, so I replace .cs_control and

                        .platform_pinmux to NULL in struct intel_mid_ssp_spi_chip.


                        static struct intel_mid_ssp_spi_chip chip = {

                                .burst_size = DFLT_FIFO_BURST_SIZE,

                                .timeout = DFLT_TIMEOUT_VAL,

                                /* SPI DMA is currently not usable on Tangier */

                                .dma_enabled = false,

                                .cs_control = NULL,//tng_ssp_spi_cs_control,

                                .platform_pinmux = NULL,//tng_ssp_spi_platform_pinmux,



                        But spidev still toggling CS1 line, so I guess CS line is controlled by peripheral.

                        I can't understand purpose of tng_ssp_spi_cs_control()/tng_ssp_spi_platform_pinmux().



                        I tried manual control by mraa_gpio. I think this is the same way as KurtE's method.

                        I initialized gpio after mraa_spi_init().

                        I could control both cs1 and cs0 from my user-space code, I could communicate both chip individually.


                        I agree with arfoll, this is not safe way. I have to prevent other task


                        Now I have to solve long dummy wait between two spi transactions.

                        At least, I could confirm my circuit board is correct using manual control method.


                        Thank you Peter, KurtE, arfoll.