I'm trying to use Edison to talk to multiple spi devices, however, I found many issues about Edison's SPI have been discussed.
I found one solution is use GPIO as SPI CS line instead of using hardware SPI CS. Unfortunately, I hard wired the my device to both SPI-5-CS0(GP110) and SPI-5-CS1(GP111) on my pcb. I wonder if it's possible to "disable" SPI CS in SPI driver and manually use SPI CS1 pin as ordinary GPIO?
Yes, it should be possible to disable the predetermined SPI CS and use it as a GPIO. Could you please tell us which platform you are using? Breakout board or Arduino Expansion board? In any case, take a look at both Hardware guides for further information.
I roll my own platform, but I'm using the miniboard platform setting in the MRAA library.
When I tried to use the GP111 (SPI-5-CS1, MRAA Pin 9) with MRAA library, linux returns "Device or resource busy". So library immediately returns fail.
The other question I have is how the MRAA library determines the platform I'm using?
I track down the library looks for the state of GPIO214. (src/x86/intel_edison_fab_c.c line 1166)
How does this work in custom platform? I designed my own platform but MRAA library keeps thinking I'm on Arduino board so that it only exports limited numbers of GPIO. To get around this, I manually disable the check and force the MRAA uses mini board platform.
This message is usually shown when you're trying to export a GPIO pin that has been already exported. However, I've only seen this behavior when using the Arduino Expansion
Board. As you say, it looks like the MRAA library is working under Edison-Arduino conditions. Could you please provide the status debug for the GPIO? It should be in /sys/kernel/debug. I would suggest you to take a look at this article about MRAA on the Intel Edison, there might be some useful information. http://www.i-programmer.info/programming/hardware/8744-exploring-edison-mraa-gpio.html http://www.i-programmer.info/programming/hardware/8744-exploring-edison-mraa-gpio.html.
Also, take a look at this thread. Arfoll talks about using custom hardware with the boar, .
1. I can toggle edison's GPIO on my custom platform by writing /sys/class/gpio/gpioXXX directly (w/o MRAA library). What I'd like to know is the purpose of gpio214 tristate check in MRAA library.
2. I saw some post about CS0 is being used by ADC on Arduino board. Is this hard coded in the kernel? If yes, how can I fix this?
3. The SPI-5-CS1 issue is not platform dependent. I flashed the latest Yocto image on Intel, and test on intel miniboard, sparkfun base block. The results are the same. I look at /sys/class/gpio, gpio111 is not exported. However, if I try to export pin 111, linux returns "Device or resource busy".
The files in /sys/kernel/debug are following:
These are the answers to your questions:
Hi PabloM_Intel, CMata_Intel
2. I couldn't get https://gist.github.com/FantomJAC/69c3e963580e939b0615 this patch to compile successfully into the kernel. Would you mind to show me how to do this?
4. My current workaround is comment out the hard coded CS line in upstream_to_edison.patch line 17404. By doing this, I can use CS0, CS1 as regular GPIO and manually toggle these pins. However, there is another problem by doing this. SPI CLK toggles 1 extra cycle during transmission. If the CS line is controlled by hardware, the CS line will de-assert after that extra edge, since I manually control CS, it's kind of annoying... This behavior only happens when I'm sending 1 byte.
Let me give you more detail on this:
1. We modified the kernel patch file, you can diff the file from here: https://github.com/lab11/IntelEdisonGateway/tree/master/kernel_patch IntelEdisonGateway/kernel_patch at master · lab11/IntelEdisonGateway · GitHub
2. SPI module has an extra clock cycle
CH0: CLK, CH1, MOSI (output from edison), CH2: MISO (output from my peripheral), CS line is not shown here. Since I'm manually controlling CS line, the extra clock cycle (very front of the capture) causes missing 1 bit in the end.
3. I couldn't get https://gist.github.com/FantomJAC/69c3e963580e939b0615 this patch to work. I tried add the file to SRC_URI variable, and paste the file into the kernel patch without success.
I apologize, I mistakenly marked this thread as solved while you still had questions.
Unfortunately, I was unable to add the patch file to the image.
Could you please tell me how did you try to add that last patch that you talked about in your last post? Are you following a guide or document to add the file?
How did you add the patch into the image? Did you have problems with this? You mentioned that it wasn't successful, with this, do you mean that you receive error messages (if you do please post the errors) or that the behavior persists?
I wonder if you try to build this patch into kernel successfully?
What I tried was:
1. copy and paste the patch into giant kernel patch and recompile the kernel. The building process is successful, but I still cannot see spidev5.0
2. modify linux-yocto_3.10.bbappend, add the patch file with SRC_URI variable, the error message is following:
Log data follows:
| DEBUG: Executing shell function do_patch
| Deleted branch meta-temp (was f58e62b).
| [INFO] validating against known patches (edison-standard-meta)
fatal: corrupt patch at line 111# ] (/)(150 %)
| ERROR. could not update git tree
| ERROR: Could not apply patches for edison.
| ERROR: Patch failures can be resolved in the devshell (bitbake -c devshell linux-yocto)
| WARNING: exit code 1 from a shell command.
Have you checked the Yocto Project Development Manual? There's a process which I believe is different to what you're attempting, it consists in creating your own layer for edits/changes, creating the patch (which is already available), setting up the custom layer for the build and then build and modified kernel. I tried something similar to this but I might have left something out of the equation. Have you tried with this approach?
You can check all the steps in here http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html# patching-the-kernel http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html# patching-the-kernel.