Are you using any level translator? (for the 1.8V on Edison to 3.3V for your SPI device)
I suppose you saw this example : mraa/spi.py at master · intel-iot-devkit/mraa · GitHub
Is it possible for you to test shorting MISO and MOSI for tests? (maybe hard if everything is soldered on your board)
I am using an ADG3304 to level translate between the 1.8V and the drivers 3.3V. Also since I forgot to mention it in my first post I am running mraa v0.6.1
The test code I wrote was based on the SPI example in the github repo.
I removed the level shifter and installed a jumper between the MISO and MOSI lines on the 1.8V side coming from the Edison and the mraa/spi.py example generates the "We have an error captain!" message.
Also just out of curiosity I thought I would try bitbanging the SPI however I can't seem to access GPIOs 109-111, 114, or 115 via mraa so I'm wondering if that is a symptom of a configuration issue somewhere?
I have an Arduino breakout and a custom board, I'll do tests on both tonight and tell you what I got.
If you get nothing on spi likely the muxes aren't set correctly or the pinmode is incorrect. Why that would be is interesting, is your custom breakout very special? Can you try on the standard miniboard or arduino breakout just to confirm first?
If you want to bitbang (not a good idea) you need to use either gpio_raw in mraa or better use the mraa numbers eg 114 -> mraa 24 - handy conversion table here - https://github.com/intel-iot-devkit/mraa/blob/master/docs/edison.md.
There is nothing particularly special about the board we are using, the SPI pins on the Edison go straight through the level shifter to the driver.
I set the Edison up to treat CS0 pin as a Gpio pin and toggle it on and off and it looks like there may be an issue with my level translator. On the +1.8V side CS0 flips between 1.4V and 1.8V which suggests the Edison is having trouble driving the pin low. On the +3.3V side I am seeing a constant 0V.
I am going to read through the datasheet for the level translator and see if I am missing something.
I managed to get the spi.py test working with my Arduino board by shorting MISO and MOSI. I'm also running version 0.6.1. I had 0.5.2 at first but it did not work with that version.
spi = mraa.Spi(x)
x is supposed to be the bus number. However I can put any number there and it still works.
I also have a custom breakout board with only VSYS and GND connected. MISO and MOSI are shorted at 1.8V straight out of the DF40 connector and it works too. I think that your problem is not related to SPI. Do you have the Arduino or Mini breakout to test your Edison module?
Yup there's only one CS/bus on edison so we basically chuck the argument out of the window. There should be a small INFO message in syslog telling you that you asked for an invalid bus num.
EasyAs314159 just don't do that on the arduino breakout and then do an Aio read... hardware CS is there for a reason!
Have the same issue, logic Analyzer shows that CS0 is inactive when transaction are running. If I init CS as GPIO and control it manually it works but in this case SCK have one addition clock, some long paused period. I think that hardware CS will pulled down after this clock, but how to make hardware CS0 work?
I tried init with mraa.Spi(0), mraa.Spi(1), mraa.Spi(2) - nothing help CS still not works.
My SPI init is:
spi = mraa.Spi(0)
Ok, I digged into sources of mraa and understood that for controlling CS0 should be file /dev/spidev5.0, but I have only /dev/spidev5.1 , but I routed only CS0 on my board =( because I thought default should be 0
Ok I soldered FS0 and FS1 to solve issue. Please write somebody when CS0 will be supported