According to what I understand of your post, if you are using a single SPI for 2 threads in my opinion the best way would be to use semaphore process, due to the way the SPI work. As far as I understand you have to read data before trying to send data again, so cleaning the bus at the end of a process would work. If this is not the case, could you specify what you have connect besides the TFT screen and the board, and which processes are on which bus?
Yes as far as my current issue with SPI, I am updating my version of the ILI9341 and the STMPE 610 driver to have each time they wish to set the appropriate CS pin (10 for the ILI9341 and 8 for the STMPE), I grab a common mutex, such that hopefully only one of them be active at any one time.
This will hopefully fix it for this case.
However was wondering if some approach will be taken both in the Arduino IDE (spi library) as well as maybe MRAA.
Obviously it would be great if the Kernel did it for us. On a limited side it can as the spidev library does normally try to set/clear the CS pin. But there is only one CS pin that it works with (I believe hardware supports 2). So that part would not work. Also the current implementation of spidev is not working sufficiently as it appears like it will always set/clear for each call, regardless if you want it to or not. I believe there is a flag as part of the IOCTL that is supposed to let you specify this. Without this control somethings won't work. Example reading back from the ILI9341, works to continue to give you data as long as you keep the CS asserted.
Maybe SPIDEV could be enhanced to make this part work. Also maybe it could be updated somehow to also allow GPIO pins to be used as CS pins within the driver. Not sure, just a thought.
Note: even with my possible changes it still won't address potential issues with also using device drivers on the same SPI bus, and not sure if/when intel supports DMA, how that would influence this.
Hope that makes sense.
Have you already tried the semaphore method in your project yet? Did it help on the SPI communication?
Thanks, it is helping to keep some stuff straight.
Luckily most of this code I started off playing with on the Teensy 3.1, where Paul of PJRC worked with others on the Arduino Developers list and implemented a transaction model, which was integrated into the current Teensy releases. It has also been integrated into Arduino Beta 1.5.8. I am also pretty sure that Paul was able to get this transaction stuff pulled back into the official Adafruit libraries up on github as well.
These libraries had stubs in them to call the begin/end transaction, where I simply put in simple calls to pthread_mutex... Currently this code is only in my Eclipse workspace code project:
This still does not solve everything. Example: I display a button on the screen in one thread, but want to display text in listbox in another. All of their graphic primitives get a complete valid SPI output, but: for example the one thread may set the text point and before it outputs it's text, other thread draws some of the button text there.... So still may need higher level mutex to say I am doing stuff now...
I hope to have this Repository have enough stuff in it, such that I can simply git it on another machine, tell Eclipse to make it my current workspace and build. But I did not want all of the unnecessary stuff like caches so currently I exclude the .metadata and so workspace does not work... Will relax this soon and see. But that is a different thread.