Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
1,231 Views

Unable to Access SPI on Edison SOC+Custom Board When Connected to Arduino Breakout Board / How to Disconnect Arduino Breakout board SPI

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

```

0 Kudos
6 Replies
Highlighted
Community Manager
24 Views

Hello D.Sync,

 

 

Thank you for your interest in the Intel Edison module.

 

 

Could you please provide me the hardware specifications of your custom made board?

 

 

Thank you,

 

Eliza
0 Kudos
Highlighted
New Contributor I
24 Views

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.

0 Kudos
Highlighted
New Contributor I
24 Views

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

0 Kudos
Highlighted
Community Manager
24 Views

Hello D.Sync,

 

 

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. Please let me know in case I can assist you with more information!

 

 

Thank you,

 

Eliza

 

0 Kudos
Highlighted
Community Manager
24 Views

Hello D.Sync,

 

 

Could you please let me know if I can assist you with anything else?

 

 

Thank you,

 

Eliza
0 Kudos
Highlighted
Beginner
24 Views

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

0 Kudos