6 Replies Latest reply on Jan 13, 2015 10:24 AM by KurtE

    Edison libmraa: SPI Python interface bulk transfer Issue

    CountBadger

      I am trying to write an small library for communicating with a AT25DF041A flash chip however, when trying to read the Manufacturer and Device ID i realized i cannot seem to do bulk reads without the CS line being asserted/de-asserted.  A simple example:

       

      import mraa

      spi = mraa.Spi(5)

      spi.frequency(20000)

      spi.bitPerWord(8)

       

      data = ''.join([chr(0x9F),chr(0xFF),chr(0xFF),chr(0xFF),chr(0xFF)])

      man_id = spi.write(data)

       

      This should get the Manufacturer and Device ID but requires that the CS line stays low for the duration of spi.write(data). Hooking the above up to an oscilloscope shows:edison_spi.png

      In the above image, channel 1 is the CS line and channel 2 is the clk line. So clearly the CS lin is not staying low for the duration of the write/read. Is there a particular way i should be doing this which will result in the CS line staying low for the duration of the transfer? Also, changing the spi.bitsperword to anything greater than 8 seems to cause the SPI interface to just not work..

        • 1. Re: Edison libmraa: SPI Python interface bulk transfer Issue
          CMata_Intel

          Hi CountBadger

           

          According to the image that you are showing the SPI seems to work fine, the CS has to be low when SCLK is working. Take a look at this code :

          import mraa
          spi = mraa.Spi(5)
          spi.frequency(200000)
          while True:
                  spi.write(0x12)
                  spi.write(0x35)
          
          
          
          

          I took a screenshot of the behavior in MOSI, CS and SCLK, take a look at it I think this will answer your question

           

          SPI.PNG

          About spi.bitsperword it depends on what to you have attached in the system, is the device working with something different than 8 bits per word?

          Also, I recommend you to upgrade your MRAA library with:

           

          root@edison:/# echo "src mraa-upm http://iotdk.intel.com/repos/1.1/intelgalactic" > /etc/opkg/mraa-upm.conf
          root@edison:/# opkg update
          root@edison:/# opkg install libmraa0
          
          
          
          

           

          Regards;

          CMata

          • 2. Re: Edison libmraa: SPI Python interface bulk transfer Issue
            CountBadger

            Hi CMata, thanks for the response.

             

            I was incorrectly interpreting the array version of the mraa spi write as acting something like spidev xfer so thanks for the clarification. I was under the impression CS would be held low until all data had be transmitted. The reason for my enquirery is that is seems necessary for the CS line to not be toggled for certian commands to complete.  As discussed on page 27 of  http://docs-europe.electrocomponents.com/webdocs/0dc4/0900766b80dc4577.pdf

            "

            Deasserting the CS pin will terminate the Manufacturer and Device ID read operation and put

            the SO pin into a high-impedance state. The CS pin can be deasserted at any time and does not

            require that a full byte of data be read.

            "

            And with the CS line being set high after i send the ID request command, the chip immediately discards the request.

            • 3. Re: Edison libmraa: SPI Python interface bulk transfer Issue
              CountBadger

              As an update, i got spidev running on edison and see the exact same pattern. So the spi mraa write is behaving like spidev xfer afterall and ill have to rethink my approach to interfacing with this Flash device. Regardless, thanks for the help

              • 4. Re: Edison libmraa: SPI Python interface bulk transfer Issue
                CountBadger

                One last look, i ran the same code on a raspberry pi for a comparison and the oscilloscope reading shows the CS line being held low for the duration of the transfer before being released. This is the kind of behavior i was hoping to find but looking through the documentation i cannot seem to find a way of replicating the behavior on the Edision SPI interface.

                 

                edison_spi.png

                • 5. Re: Edison libmraa: SPI Python interface bulk transfer Issue
                  CMata_Intel

                  Hi CountBadger

                   

                  What is the reason of getting the CS always low and not with the default behavior of on and off during transitions? One way to do this is using another pin and set it as low before a transfer function and set back to high after the transfer function. We could try with that.

                   

                  Regards;

                  CMata

                  • 6. Re: Edison libmraa: SPI Python interface bulk transfer Issue
                    KurtE

                    Hi CMata_Intel and CountBadger

                     

                    I found earlier on, I could not use the default behavior of the CS pin with the Adafruit display using ILI9341, so I currently control it myself.  You can do that easily by initializing the GPIO object with the CS pin after you init SPI, which will then convert the pin back to Mode0...  I needed to do this anyway to support the Touch screen which has it's own CS pin and you don't want the system to assert the screens CS when you are talking to Touch screen.

                     

                    Note: on some other boards, like currently the ODroid C1, I have found that they do the CS transitions for each IOCTL call for the transfer, which appears to work OK for at least doing outputs to the display.  I have not tried yet to see if reading works.  Found earlier with other boards (Teensy 3.1) that when you read in pixel data you need to keep the CS pin asserted through the transfer.

                     

                    Currently I am pretty sure neither the Edison SPIDEV nor the Odoid SPIDEV support the cs_change field of the IOCTL transfer structure, which I believe is supposed to give you more control over how the CS is asserted or not.  Hopefully will be surprised soon with new release that supports this.  

                     

                    Also currently doing our own CS works OK as the system appears to do the SPI operations synchronously.  Will be interesting if/when Intel allows asynchronous access, actually use the hardware queue and/or DMA...