8 Replies Latest reply on Oct 11, 2014 2:31 PM by KurtE

    Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures

    742002

      In order to get started with using SPI on the Edison, I have wired up one of Adafruit's OLED boards (Monochrome 128x32 SPI OLED graphic display ID: 661 - $17.50 : Adafruit Industries, Unique & fun DIY electronics and kits) to my edison on the Intel Arduino breakout board.

       

      I am using the linux 64 bit weekly 68 SDK (http://downloadmirror.intel.com/24271/eng/edison-sdk-linux64-weekly-68.zip)

       

      I am using http://downloadmirror.intel.com/24271/eng/arduino-linux64-1.0.3.tgz for my IDE.

       

      I have attached a log of my boot sequence output; it shows what versions of the kernel, etc I am using.  I am just using the Yocto image from http://downloadmirror.intel.com/24271/eng/edison-image-ww36-14.zip.

       

      I started with Adafruit's arduino sample code for the oled (adafruit/Adafruit_SSD1306 · GitHub) and Adafruit_SSD1306/ssd1306_128x32_spi.ino at master · adafruit/Adafruit_SSD1306 · GitHub.

       

      Depending on which  Adafruit_SSD1306 constructor is used, one can choose from software SPI (where CLK and MOSI are twiddled as GPIOs) or hardware SPI (where the Arduino SPI object is used).

       

      When I use the software SPI constructor, all is good.  Basically, this version just uses pins 13 (clk), 11 (mosi), 10 (slave select), plus a couple of oled-specific lines as gpios.

       

      When I use the hardware SPI constructor, I have no success.

       

      In the process of debugging my problem I have determined that the current version of arduino-1.5.3-Intel.1.0.3//hardware/arduino/edison/variants/edison_fab_c/variants.cpp has problems in the mux structures with respect to SPI.

       

      First of all, MuxDesc13's entry for the SPI MODE gpio is:

      { 109, PIN_MODE_1, FN_GPIO }, // SPI mode

      instead of

      { 109, PIN_MODE_1, FN_SPI }, // SPI mode

       

      Next,  g_APinDescription[] does not contain any entries for the GPIOs (109, 114, 115) referenced in MuxDesc11, MuxDesc12, and MuxDesc13.

       

      I fixed these issues in my local version of variant.cpp, and that still did not get hardware SPI working.

       

      I am watching pins 13, 11, and 10 (with LEDs) to see if they ever go high  when I run my oled sketch mentioned above, and I see that the clk (13) does go high, the slave select seems to be working, but that's just a plain old gpio, and most importantly, pin 11 (mosi) never goes high, indicating no data is being sent over the wire.

       

      By the way, with the same hardware configuration, if I switch to "software spi" and just use pins 13 and 11 as gpio pins, I see these pins go high as expected.

       

      So my question is, has anybody gotten hardware spi working on the Edison using the Arduino breakout board?

       

      If so, how?

        • 1. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
          DiegoV_Intel

          Hi 742002,

           

          That sounds interesting. Let me investigate about your question to give you a more accurate response.

           

          Regards,

          Diego.

          • 2. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
            MPayne

            Some Adafruit shields are too aggressive with their pull-up resistors and can exhibit behavior like this (in our experience) - I'd start in that direction, Diego.

            • 3. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
              DiegoV_Intel

              Hi 742002,

               

              I did some tests, however I don't have the Adafruit's OLED board you have, or another SPI board, so what I did was to use the SPI.transfer() function of the SPI.h library and connect a LED, as you did, in the pin 11 (MOSI pin) and start sending data. The first time I used the DigitalPotControl example but I couldn't see anything on the LED. I supposed that was happening because the bits are sent very fast to can see them in the LED. Since I don't have access to an oscilloscope I started sending only high bits (SPI.transfer(0xFF)) into a while loop. With this way I could see the pin goes high through the LED. So the MOSI pin is working.

               

              Another thing I noticed in the example you are using is the following:

               

              // If using software SPI (the default case):
              #define OLED_MOSI  9
              #define OLED_CLK  10
              #define OLED_DC    11
              #define OLED_CS    12
              #define OLED_RESET 13
              Adafruit_SSD1306 display(OLED_MOSI, OLED_CLK, OLED_DC, OLED_RESET, OLED_CS);
              
              
              /* Uncomment this block to use hardware SPI
              #define OLED_DC    6
              #define OLED_CS    7
              #define OLED_RESET  8
              Adafruit_SSD1306 display(OLED_DC, OLED_RESET, OLED_CS);
              */
              
              

               

              According to this, when you use the software SPI, the pin 13 is for RESET, the pin 11 is for DC and the pin 10 is for CLK, but you said the pin 13 is for CLK, the pin 11 for MOSI and the pin 10 for CS.

               

              When I use the software SPI constructor, all is good.  Basically, this version just uses pins 13 (clk), 11 (mosi), 10 (slave select), plus a couple of oled-specific lines as gpios.

               

              I'm a little confused with that because when you use the hardware SPI instead the software SPI, the pins for CLK and MOSI are 13 and 11, just like you said, but you was referring to the software SPI. So if you can provide a detailed explanation of the pins you are using for both cases would be nice. Have a nice day.

               

              Regards,

              Diego.

              • 4. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
                KurtE

                Hi, I am new to the Intel Edison, so I will probably miss a few obvious things.

                 

                I thought I would try out SPI using the Adafruit_ILI9341 library (used with their 2.8" tft display, works also with their 2.2" TFT display as well as several other displays.  I thought I would try it as I have working versions on Atmega 8 boards, Teensy 3.1 and a little testing on Arduino Due...

                 

                So I modified my fork of the Adafruit_ILI9341 to compile for the Edison, and plugged in the display, downloaded the graphic test program and saw nothing... I have not yet tried using software SPI.

                 

                So I removed the shield and brought out my Saleae Logic 8 (one of their new ones) logic Analyzer and connected up to pins 8-13.  I then did a capture and I see data coming in on the IO pins 9 and 10, which correspond to the CS and DE lines, but IO pins 11-13 are flat line (low).  So not getting anything on the spi lines.

                 

                I am running the current version of the 1.3 release (as of yesterday).

                Configure_edison --version  shows 68 as as does --latest-version

                 

                Kurt

                • 5. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
                  David_J_Hunt

                  Kurt, have you set up the GPIO mixing to configure the GPIO pins to enable the SPI functionality?

                     Example 5 at the link here: EmutexLabs should get it set up.

                  I had that issue before and I got nothing on SPI until I got the mixing right.

                  Regards,

                  Dave.

                  • 6. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
                    KurtE

                    Forgot to ask: Is there a good document or thread that details more of the capabilities of the SPI of the Edison?  Does it have some form of fifo queue like the Teensy 3.1 processor?  Support DMA? 16 bit transfers? 

                     

                    Likewise good document to describe the MUX capabilities, like what pin does what, how to change...

                     

                    Thanks

                    • 7. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
                      742002

                      I changed the #defines for SW spi to use the same pins as hw.

                       

                      FYI, I have been in the hospital, and may not be able to respond for a few days.

                      • 8. Re: Unable to get any signals on SPI MOSI, variant.cpp has bugs in data structures
                        KurtE

                        FYI - I now have my Adafruit 2.8" tft display that uses the ILI9341 display chip over SPI working.  Still not fast as lets say compared to the Teensy 3.1, but at least it is getting usable.

                        I believe I needed the fixes you mentioned in the first posting of this thread.

                         

                        I created a new branch for it on my fork of the Adafruit_ILI9341 tree.  If anyone is interested, it is up at: KurtE/Adafruit_ILI9341 at Intel-Edison · GitHub

                         

                        Daivd_J_Hunt - Thaks for the link to EmulexLabs, it has lots of good information up there.

                         

                        My first pass the display was real real slow, when I was only transfering one byte at a time: SPI.transfer.  It was helped quite a bit when I made some use of:

                        SPI.transferBuffer

                         

                        So far I have only tried this out using the Example program graphictest that is an example for this library.