Hello,
I got one of these tft/touch screens on Friday and I've been playing with it all weekend. It's a great little shield!
However, I noticed it was quite slow to update so I had a look at the driver software.
I made some small changes to the code and got an immediate improvement (took out some unneeded code that reset parameters on each write) - this improved it by about 80% for filled rectangles and about 50% for text. Next I did some unwinding to make writing faster and got to about 100%/70%
I also made some more substantial changes to the code specifically to make it work better with the SAM3x/Due and I've now got it running about 300% faster with the same SPI bus speed (8Mhz) (using hardware control of CS line and direct access to Sam3x registered). I've done some experimentation and it runs reliably with an SPI clock divisor of 2 (42MHz) and this gives an improvement over the original to about 800% which is definitely worthwhile.
Is there somewhere to post up the code on here or should I just put it on my blog?
Cheers
Dom
PS: I like the resistor captcha but its a bit unfair for colourblind people!
Software driver for Due and 2.8" TFT/cap touch screen
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- dominicbeesley
- Posts: 4
- Joined: Sun Sep 14, 2014 1:11 pm
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Software driver for Due and 2.8" TFT/cap touch screen
Cool! Post a Pull request to github!
- dominicbeesley
- Posts: 4
- Joined: Sun Sep 14, 2014 1:11 pm
Re: Software driver for Due and 2.8" TFT/cap touch screen
Thanks Rick,
I will do that next week after a tidy-up...and once I've worked out what a GitHub pull is!
D
I will do that next week after a tidy-up...and once I've worked out what a GitHub pull is!
D
- adafruit_support_rick
- Posts: 35092
- Joined: Tue Mar 15, 2011 11:42 am
Re: Software driver for Due and 2.8" TFT/cap touch screen
Fork the repository (button in upper right on the adafruit github page) to your github account and apply your changes.
Go back to the adafruit repository page and click "Pull Request", then "New Pull Request", and paste in your fork.
Go back to the adafruit repository page and click "Pull Request", then "New Pull Request", and paste in your fork.
- dominicbeesley
- Posts: 4
- Joined: Sun Sep 14, 2014 1:11 pm
Re: Software driver for Due and 2.8" TFT/cap touch screen
I've had a look at that and it would be a lot of work to merge all the code back and make it work with all boards.
I've attached the files in a zip as I think if you guys are selling this stuff its worth getting it working reasonably efficiently and the methods I've used should be applicable.
As well as stuff specific to the ILI9341 I think it would be good to add a block pixel blit function (in the attachment) this would allow for much faster bitmap plotting
Cheers
Dom
I've attached the files in a zip as I think if you guys are selling this stuff its worth getting it working reasonably efficiently and the methods I've used should be applicable.
As well as stuff specific to the ILI9341 I think it would be good to add a block pixel blit function (in the attachment) this would allow for much faster bitmap plotting
Cheers
Dom
- Attachments
-
- Adafruit_ILI9341-dom.zip
- (26.45 KiB) Downloaded 57 times
- pepijndevos
- Posts: 17
- Joined: Sun Sep 21, 2014 4:17 am
Re: Software driver for Due and 2.8" TFT/cap touch screen
This looks amazing. Any news?
What are the problems with merging this?
Are there any breaking changes?
I made a diff between the current master and your code.
https://gist.github.com/pepijndevos/c90 ... 549be439d0
[edit] I messed up the diff a tiny bit. There are still a few _Don in there.
It also looked like you removed a lot of SPI code.
Is this just because you don;t need it, or was it bad code to begin with?
What are the problems with merging this?
Are there any breaking changes?
I made a diff between the current master and your code.
https://gist.github.com/pepijndevos/c90 ... 549be439d0
[edit] I messed up the diff a tiny bit. There are still a few _Don in there.
It also looked like you removed a lot of SPI code.
Is this just because you don;t need it, or was it bad code to begin with?
- dominicbeesley
- Posts: 4
- Joined: Sun Sep 14, 2014 1:11 pm
Re: Software driver for Due and 2.8" TFT/cap touch screen
Thanks I'm glad you're interested,
I got it going quickly enough to get a nice set of analogue dials working for the car engine data logger I'm playing around with.
There's no real problems with merging other than I don't have much time to spend on this. I got a few evenings when I got the display but now we have a baby on the way in the next few weeks so I'm having to spend all my time making a nursery and moving all my electro-junk out of the way!
A lot of the speed increase was gained by accessing the SPI directly and being a bit more clever with not waiting for the SPI to finish writing before returning from the functions, using the hardware to control CS and being careful about how DC was asserted. It would be possible to get it a good bit quicker by using interrupts and DMA but I ran out of time.
I did have it going a little faster but I wasn't sure that it would be reliable. The SPI hardware will tell you when the transmit register is empty, or when it has finished transmitting the whole byte - the transmit register is emptied after the first _bit_. It should be possible to wait for the first bit to be sent then deassert the DC line and return. This speeds things up but I wasn't sure I'd read the datasheet right and that it was ok to do this with the display.
I also wasn't sure how best to package this as a library and as it diverges from the official APIs and bypasses transactions and such maybe its best left as its own library.
I also added the block blit method to the core graphics library but that could probably be dropped: It does speed up small text with a non-transparent background, again this would work very well with DMA, but is probably not worth the effort of breaking the API.
D
I got it going quickly enough to get a nice set of analogue dials working for the car engine data logger I'm playing around with.
There's no real problems with merging other than I don't have much time to spend on this. I got a few evenings when I got the display but now we have a baby on the way in the next few weeks so I'm having to spend all my time making a nursery and moving all my electro-junk out of the way!
A lot of the speed increase was gained by accessing the SPI directly and being a bit more clever with not waiting for the SPI to finish writing before returning from the functions, using the hardware to control CS and being careful about how DC was asserted. It would be possible to get it a good bit quicker by using interrupts and DMA but I ran out of time.
I did have it going a little faster but I wasn't sure that it would be reliable. The SPI hardware will tell you when the transmit register is empty, or when it has finished transmitting the whole byte - the transmit register is emptied after the first _bit_. It should be possible to wait for the first bit to be sent then deassert the DC line and return. This speeds things up but I wasn't sure I'd read the datasheet right and that it was ok to do this with the display.
I also wasn't sure how best to package this as a library and as it diverges from the official APIs and bypasses transactions and such maybe its best left as its own library.
I also added the block blit method to the core graphics library but that could probably be dropped: It does speed up small text with a non-transparent background, again this would work very well with DMA, but is probably not worth the effort of breaking the API.
D
- pepijndevos
- Posts: 17
- Joined: Sun Sep 21, 2014 4:17 am
Re: Software driver for Due and 2.8" TFT/cap touch screen
Ah, thanks for the info.
I'm actually not using a Due, and I now realize that the most spectacular optimizations are only possible due to Duo's extended hardware SPI.
I'm using a Mega myself, so this is of not much interest to me.
The other 100% might still apply though?
You talked about resetting parameters on every write. Are you talking about setBitOrder and friends?
I can see how that would speed up things, but when using different SPI devices, it might mess things up
Maybe it can be moved out of the inner loop though.
By unrolling I assume you mean your spiwrite16 function?
What is this DC parameter, and what did you do with it?
I'll study your changes some more, and see if I can apply some of them in a way that is backwards and Mega compatible.
I'm actually not using a Due, and I now realize that the most spectacular optimizations are only possible due to Duo's extended hardware SPI.
I'm using a Mega myself, so this is of not much interest to me.
The other 100% might still apply though?
You talked about resetting parameters on every write. Are you talking about setBitOrder and friends?
I can see how that would speed up things, but when using different SPI devices, it might mess things up
Maybe it can be moved out of the inner loop though.
By unrolling I assume you mean your spiwrite16 function?
What is this DC parameter, and what did you do with it?
I'll study your changes some more, and see if I can apply some of them in a way that is backwards and Mega compatible.
- scott_fx
- Posts: 26
- Joined: Wed Jan 18, 2012 7:30 pm
Re: Software driver for Due and 2.8" TFT/cap touch screen
Awesome, i just ordered a screen and was wondering if it was due compatible. Is the zip you linked to the latest driver for it?
Please be positive and constructive with your questions and comments.