I have just lost couple of weeks trying to do communication between edison and ILI3941 display. I used mraa/upm libraries as ready code.
After lots of unsuccessful tries I discovered the issue. My simplified code is:lcdCSOnm_spi.writeBytem_spi.writeBytem_spi.writeByte
The output on the SPI bus looks like on the attached picture. There is extra clock pulse between setting CS low and sending first byte. As you can see following bytes are not preceded with this pulse, but if I put this code into loop and add 1s delay, always after CS going low I receive similar picture. I have tried to use SPI in mode 3 (my code use mode 0 - default mode), this problematic clock pulse became much shorter but still visible on the scope, and ILI3941 controller also sees it. I have tried to modify the databits to workaround this extra pulse and LCD controller became alive, so this extra pulse after falling edge of CS is a issue here.
Am i doing something wrong? From the mraa code it looks the problem is somewhere in spidev driver, from the observation the pulse appear always after some time when SPI was not use, I suspect the problem is with putting SPI module in sleep. Does anybody know the solution of this problem, in my board I use the freshest available linux image. The issue apear with low frequency of the clock (like on attached image) and with high frequency (15MHz like ILI3941 driver from UPM library).
Thank you for your interest in the Intel Edison Board.
Could you please confirm that this is the code that you have been using: https://github.com/intel-iot-devkit/upm/blob/master/src/ili9341/ili9341.cxx ?
Also, please let me know if you have tested it with a longer delay (like 2s or 5s) to see if the extra clock pulse becomes shorter?
Thank you in advance and looking forward to hear from you,
Initially I took the library mentioned by you, then use its code as templete for proof of concept code shown in previous post. Right now after discovering the issue with SPI I believe the library itself might be fine, mraa library is a wrapper opening linux device and just sending IOCTLs to the drive and also might be perfecly fine, so problem is with spidev driver or some other kernel driver.
In the meantime I discovered this thread I have same conclusion that problem looks like connected with powering down the SPI controller.
I have tested with longer and slower delay between repetition of shown code, without any change. What I can say when I send bytes very frequent there were NEVER additionale clock pulse between them. Other observation is, the lenght of this "evil" clock pulse is random, but ussually within same range shown in scope capture attached to previous post. This variance of lenght is not a problem, but the existance of this pulse after setting CS totally desynchronises SPI communication.
Thank you for your patience.
We were able to reproduce your issue, and indeed, it seems to be a problem with the SPI driver. We would recommend to flash the board using a previous release (maybe ww05 or 3.0) and check if you see the same extra clock pulse. Could you please let me know the outcome of this?
Also, you might want to check the below links below:
I have working display on the same controller (Adafruit 2.8" LCD with capacitive touchscreen). The only difference I'm using latest stuff from community (https://github.com/edison-fw). Ah, and I'm not using UPM/MRAA. The Linux supports framebuffer devices directly through standard APIs.