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
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
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.
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
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.
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.
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...