EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: TriodeTiger on September 14, 2014, 10:51:27 am
-
I went on a whim and upgraded from a small Nokia monochrome display to something with colour, that can show me some numbers, simple graphs, and other basic things for projects. I splurged on this:
https://learn.adafruit.com/adafruit-3-5-color-320x480-tft-touchscreen-breakout (https://learn.adafruit.com/adafruit-3-5-color-320x480-tft-touchscreen-breakout)
The only issue is, while using the default libraries (and SPI, on a Nano) it appears impossible to implement anything touchscreen to my application. For example, this very simple monitoring app based off a DHT22 humidity/temperature module:
https://lh4.googleusercontent.com/-ZNK6a69KnoA/VBK8y21FChI/AAAAAAAABE0/A5XafT5IWCI/w463-h823-no/20140912_022830_Richtone%28HDR%29.jpg (https://lh4.googleusercontent.com/-ZNK6a69KnoA/VBK8y21FChI/AAAAAAAABE0/A5XafT5IWCI/w463-h823-no/20140912_022830_Richtone%28HDR%29.jpg)
Even if I put all the background stuff (black fill + table lines + *C even) in setup(), and even rewrite text with black and then the new text as a speed trick, the screen takes maybe an entire second to refresh! This means if I want something touchscreen using the code procedurally as all I know or in examples, I have a window of maybe 1/100 a second to for example touch a reading and have it turn to *F, meaning I have to hold it down for a second pretty much. This makes the screen useless to me. Filling the screen with random pixels (in a nested for() loop) takes over 20 seconds, for example.
A few questions:
A) Would it be possible to tie the resistive screen to an interrupt to deal with something as it is pressed?
B) Assuming flooding a screen black is not a processor-intensive application, is the speed of SPI holding me back? Would the Due or something less 8-bit let me get anywhere more than 1FPS? I get a hint the driver at least is capable of 60Hz refresh rate with its default 10MHz internal clock:
http://www.adafruit.com/datasheets/HX8357-D_DS_April2012.pdf (http://www.adafruit.com/datasheets/HX8357-D_DS_April2012.pdf)
C) Is something like this what everyone uses for any sort of screen like this regardless of speed?
http://forum.arduino.cc/index.php/topic,5686.0.html (http://forum.arduino.cc/index.php/topic,5686.0.html)
How do the pros do small touchscreens, assuming I want to keep any hardware and simplicity I have if possible?
Ideally I would just like to have a few FPS for random pixels, or have a display seamlessly change between text even without hacks like I did in the above, maybe a stupid-simple oscilloscope like display, or however. I question whether I am stupid (SPI shit, go parallel?), lazy (using internal SPI and nothing more dedicated?), or they actually sell this screen to people with virtually no real help on the programming (no function references within the adafruitgfx library) or any ability to update the screen fast enough to be vaguely considered useful at all :palm:
3am rant over :)
-
My answer probably won't work for you since you're an Arduino user, but still here are my recommendations:
- Ditch Adruino software and write your own code. This is a lot of work, but if you want to get somewhere on the existing platform, it's the most effective solution.
- Make parallel connection to the LCD instead of serial (if possible on LCD).
- In case this doesn't help, get a faster microcontroller, maybe even a 32 bit instead of 8 bit one.
You might find a way to improve your situation using your current setup, but I'm afraid it will still perform poorly.
-
Reading the touchscreen in an interrupt is a good idea.
The screen has 320x480=153600 pixels. Using 16bpp you have to transfer 307200bytes. Even with the fastest spi clock of 10MHz, you will never get more than 3fps if you update the whole screen. The solution: Only update a small area of the screen with a new text.
But the main problem is not the transfer to the lcd but the calculations of the image data. Generating random numbers takes some time on an AVR. One solution could be starting a spi transfer and then calculating the next data before waiting for the previous transmission to finish. If you know the calculation takes more time than a spi transfer you can even avoid checking spi beeiing busy.
If you have a scope, look at the spi clock while data beeing transferred. If there are large gaps every 8 clocks, then your software overhead is slowing everything down and you can start opimizing your code (using inline functions for spi transfers and similar stuff).
-
yep, the Arduino system/librarys are good for simple stuff and for rapid design but they add so many layers on top of the hardware that speed is severely limited from what the MCU is actually capable of.
Because of this layering its a bit tricky to track down exactly what is slowing down your screen updates.
Ive not had a look at the LCD you have and its Library but most LCDs modules have fast ways and slow ways to do things. And its up to the coder to know which to use when.
eg, to clear the screen you could loop around every pixel in X and Y and do a SetPixelColor(X,Y) function. (really really slow) or issue a custom call to the LCD that clears the entire screen (fast)
When using someone else's library you really don't know what features/capabilities they have, and have not, implemented. When you write your own library you can optimize things for your intended application.
-
A) Would it be possible to tie the resistive screen to an interrupt to deal with something as it is pressed?
Depends what you're using for the touchscreen controller.
B) Assuming flooding a screen black is not a processor-intensive application, is the speed of SPI holding me back? Would the Due or something less 8-bit let me get anywhere more than 1FPS?
The display is capable of ~15MHz serial input clock (66ns cycle); assuming the 64K colours mode which requires 16 clocks/pixel, the fastest you can get is around 6FPS for a full-screen write (all 320x480 pixels.)
The ATmega328/168 in the Arduino can put out ~8MHz max SPI clock, which is still good for a little over 3FPS.
Of course this is assuming there's no other processing, so unless you just want to clear the display or set it all to one colour there will be some more time spent in calculating the pixel value itself, although 20s for a random fill (using what type of RNG?) is a bit on the slow side.
You should definitely switch to a parallel interface if you have the I/O for it - going to 8 bits will multiply the bandwidth by 8 and give full-screen 48FPS theoretical maximum, and probably ~24FPS with the Arduino.
Even if I put all the background stuff (black fill + table lines + *C even) in setup(), and even rewrite text with black and then the new text as a speed trick, the screen takes maybe an entire second to refresh! This means if I want something touchscreen using the code procedurally as all I know or in examples, I have a window of maybe 1/100 a second to for example touch a reading and have it turn to *F, meaning I have to hold it down for a second pretty much.
All display drivers of this type support windowed write - set the area you want to update the pixels in and then send the data for the window only. How big is the area you're updating? That 'C' looks like 16x28 pixels, or 896 bytes, and with windowed write would be <1ms to update between that and 'F'. This is definitely what you should be doing.
yep, the Arduino system/librarys are good for simple stuff and for rapid design but they add so many layers on top of the hardware that speed is severely limited from what the MCU is actually capable of.
Realtime video (with sound!) on an ATmega88: http://www.linusakesson.net/scene/craft/ (http://www.linusakesson.net/scene/craft/)
-
I don't think the problem is in the refreshing of the screen.
Look in your own code for the usage of "delayMicroseconds()" and/or "delay()".
This could explain the low frame-rate.
Some libraries use them a lot too.
You mention the DHT22 humidity/temperature sensor as a data source. These sensors need a lot of time to measure (sampling rate 0.5 Hz). So my best guess would be that this would be the cause of the slow frame-rate.
To test this you could comment out the calls to the DHT22 sensor and see if the frame-rate improves.
-
These sensors need a lot of time to measure (sampling rate 0.5 Hz). So my best guess would be that this would be the cause of the slow frame-rate.
Sampling rate refers to suggested numbers of reads per second which is once every two seconds. The reading is actually performed much faster. I don't remember how fast but certainly fast enough to say this is not the source of delay.
-
You could try using a $19 teensy 3.1 running at 96mhz or wait for the next gen Arduino Zero coming out soon that runs at 48mhz and will probably become the new standard ardudio board.
Its amazing how much smoother you code will probably run at those speeds compared to 16mhz of a typical arduino. I ran into a similar issue with an application that did user input plus audio output interactively that just ran a little sluggish for my taste.
https://www.pjrc.com/teensy/index.html (https://www.pjrc.com/teensy/index.html)
http://arduino.cc/en/Main/ArduinoBoardZero (http://arduino.cc/en/Main/ArduinoBoardZero)