This may sound arkward, but I'm currently trying to connect Edison with a custom made board that uses SPI interface to connect with an ADC, and then connect these together with Arduino Breakout board. The plan is to use the SPI that connect directly with the SOC (not the SHIELD PIN), and use the Arduino breakout board to control shield-pin-compatible i2c sensor. Using mraa, it always failed to initiate any SPI transfer with my custom board, e.g. reading and writing always result in 0x00. The surprising thing is I'm able to get the SPI interface working when connecting Edison with just the custom board. So I suspect that mraa multiplex the pins using Arduino breakout pins and route the SPI pins to the SHIELD pin instead.
By default, mraa will automatically mux the pin according to the carrier board that it is currently connected to, e.g. Mini breakout board or Arduino board. I've even modify the mraa so that it always multiplex using mini breakout board pinouts, but to no avail. SPI transfer still return 0x00 whenever I connect these boards with Arduino Breakout board. I've even remove the sketch and disable clloader service to prevent any pin muxing done by Edison using Arduino breakout board pinouts.
Not sure whether there could be any solution to this.
In other words,
Is it possible to bypass the Edison Compute Module to connect its SPI pinout to my custom board SPI instead of the SPI pins on the Arduino breakout board shield pins. I've tried to revert all shield pins to non-SPI function but to no avail as well.
echo 111 > /sys/class/gpio/export
echo 115 > /sys/class/gpio/export
echo 114 > /sys/class/gpio/export
echo 109 > /sys/class/gpio/export
echo 263 > /sys/class/gpio/export
echo 240 > /sys/class/gpio/export
echo 262 > /sys/class/gpio/export
echo 241 > /sys/class/gpio/export
echo 242 > /sys/class/gpio/export
echo 243 > /sys/class/gpio/export
echo 258 > /sys/class/gpio/export
echo 259 > /sys/class/gpio/export
echo 260 > /sys/class/gpio/export
echo 261 > /sys/class/gpio/export
echo 226 > /sys/class/gpio/export
echo 227 > /sys/class/gpio/export
echo 228 > /sys/class/gpio/export
echo 229 > /sys/class/gpio/export
echo 214 > /sys/class/gpio/export
echo low > /sys/class/gpio/gpio214/direction
echo low > /sys/class/gpio/gpio263/direction
echo low > /sys/class/gpio/gpio240/direction
echo low > /sys/class/gpio/gpio262/direction
echo low > /sys/class/gpio/gpio241/direction
echo low > /sys/class/gpio/gpio242/direction
echo low > /sys/class/gpio/gpio243/direction
echo low > /sys/class/gpio/gpio258/direction
echo low > /sys/class/gpio/gpio259/direction
echo low > /sys/class/gpio/gpio260/direction
echo low > /sys/class/gpio/gpio261/direction
echo out > /sys/class/gpio/gpio226/direction
echo out > /sys/class/gpio/gpio227/direction
echo out > /sys/class/gpio/gpio228/direction
echo out > /sys/class/gpio/gpio229/direction
echo mode0 > /sys/kernel/debug/gpio_debug/gpio111/current_pinmux
echo mode0 > /sys/kernel/debug/gpio_debug/gpio115/current_pinmux
echo mode0 > /sys/kernel/debug/gpio_debug/gpio114/current_pinmux
echo mode0 > /sys/kernel/debug/gpio_debug/gpio109/current_pinmux
echo mode0 > /sys/kernel/debug/gpio_debug/gpio41/current_pinmux
echo mode0 > /sys/kernel/debug/gpio_debug/gpio43/current_pinmux
echo mode0 > /sys/kernel/debug/gpio_debug/gpio42/current_pinmux
echo mode0 > /sys/kernel/debug/gpio_debug/gpio40/current_pinmux
echo high > /sys/class/gpio/gpio214/direction
Thank you for your interest in the Intel Edison module.
Could you please provide me the hardware specifications of your custom made board?
Hi Eliza, it's a board that housed a ADS1299 from Texas Instrument. By design it uses GP44, GP45, GP46, GP47 and GP110 of the Edison SoC and uses spidev5.1. It really puzzles me as to why it only works when not connected to the Arduino expansion board.
I think I finally have some idea on why this is happening after spending some time looking at the Edison-Arduino schematics.
Since our custom board uses GP109, GP115, and GP114 (as highlighted), and these are also used by the Arduino board, so I'm guessing that the signal is routed to the Arduino board instead to my custom board. So what's next is really to finding a way to cut off these GP's programatically. https://emutex.com/educational/76-intel-edison-gpio-pin-multiplexing-guide https://emutex.com/educational/76-intel-edison-gpio-pin-multiplexing-guide
https://emutex.com/educational/76-intel-edison-gpio-pin-multiplexing-guide Emutex - Intel® Edison GPIO Pin Multiplexing Guide has a pretty good multiplexer guide but I just couldn't find a way to properly use it to disable these GP's...
There are a couple of libraries that could be of help getting the SPI setup going: mraa and upm (links listed below). When using the mraa library, this sets up the SPI interface without having to worry about any muxing. Usually the muxing is needed for the Arduino Kit or the Breakout Board.
I also found a guide online that provides an example using the SPI interface, hope this also helps you with your project https://lasr.cs.ucla.edu/classes/edison_tutorials/spi.pdf https://lasr.cs.ucla.edu/classes/edison_tutorials/spi.pdf.
I just finished work on a rgb oled. It is driven by an ssd1351 controller which I have connected to mini breakout via a tsx0108e logic level shifter. The level shifter is set to 1.8v on the a side and 3.3v on the b side.
In software I am using spi 5.1. I have all spi5.1 pins set to mode 1. I have assigned two additional gpio's to the function of spi DC (data/ command) and spi RESET. I am driving the display from the atom dual core via mraa. I am controlling DC and RESET manually, the rest are left to the spi controller which configured for mode 0 operation at 25 MHz.
I am pushing a 128x128 array of 16 bit pixels across spi 5.1 at 25MHz, connected with leads not traces, and it is sustaining a 30+ fps frame rate!
I struggled with the spi bus until I set the spi 5.1. Gpios to mode 1 and let the controller do the work. As you I had configured for mode 0 based on info here and elsewhere and had limited success transmitting more than 4 bytes per toggle of the spi DC. This resulted in dropped pixels and disappointing frame rate of .5 fps. It also caused the process to consume 15% - 20% of the cpu bit banging even though I was using mraa_spi_write with a large buffer. Now the process is using less than 3% and refreshing at 30 fps. Spi + DMA....woot woot!!