Arduino - Improving refresh rate of a TFT LCD display

I'm working on a digital speedometer project for my car and I ordered a couple different displays from Adafruit to experiment with. One of the displays I ordered is a 2.2" color TFT LCD display. I was really hoping to use this display to show the current speed of my car. One concern I had about using it for that purpose was the speed that an Arduino board could refresh the information on the screen. To test the display I wrote a simple sketch that just displays the number of seconds since start. Here is a video of that first attempt:



The redraw time causes the numbers to look like they are flashing which is very annoying. The mistake I made was blanking out the entire screen with tft.fillScreen(ILI9340_BLACK). It takes quite a while to redraw the entire screen with black.

Next I tried drawing a black rectangle just on the area of the screen where I was drawing numbers. Here is the result:



Huge improvement. Only blanking out that small area greatly sped up the redraw time.
In this next video I have highlighted the redraw area in red to make it easier to see what I am talking about:



What I am realizing at this point is you should only redraw information that has changed. If you watch the last video again, once the number goes past single digits the left digit looks like it is flashing. This is because it is being blanked out and redrawn every time the number changes. When you redraw something that hasn't changed it looks like flashing. Well that's it for now. I am going to continue to work on this more and figure out how to selectively redraw only digits that change. Once I figure that out I'll write up another blog post.
[UPDATE] - Here is part two:
 http://matthewcmcmillan.blogspot.com/2014/08/arduino-tft-lcd-display-refresh-rate-part2.html


Here is the code I was using to do my testing.

	#include "SPI.h"
	#include "Adafruit_GFX.h"
	#include "Adafruit_ILI9340.h"
	#if defined(__SAM3X8E__)
	#undef __FlashStringHelper::F(string_literal)
	#define F(string_literal) string_literal
	#endif
	// These are the pins used for the Mega
	// for Due/Uno/Leonardo use the hardware SPI pins (which are different)
	#define _sclk 52
	#define _miso 50
	#define _mosi 51
	#define _cs 53
	#define _rst 9
	#define _dc 8
	Adafruit_ILI9340 tft = Adafruit_ILI9340(_cs, _dc, _rst);
	void setup() {
	tft.begin();
	tft.setRotation(1);
	tft.fillScreen(ILI9340_BLACK);
	tft.fillRect(120, 70, 115, 70, ILI9340_RED);
	tft.setTextColor(ILI9340_WHITE);
	}
	void loop(void) {
	tft.setCursor(120, 70);
	tft.setTextSize(10);
	tft.print(millis()/1000);
	delay(999);
	tft.fillRect(120, 70, 115, 70, ILI9340_RED);
	//tft.fillScreen(ILI9340_BLACK); //This is very slow
	}

view raw tft_test.ino hosted with ❤ by GitHub

[Updated 2014-08-08 - Added link to part 2 of this topic]

Daemonized rvm ruby tasks using start-stop-daemon

I am very new to Ruby so the solution described in this post might be very obvious to some but I could not find all the parts of this solution in one place. I cobbled together bits and pieces of other peoples startup and capistrano scripts to get this working. My research has also shown there are ruby gems that might handle some of this better but I wasn't trying to reinvent the wheel. Anyhow, on with the show. At work, during our capistrano deployment we have a ruby process that has to be launched in the background. We are using start-stop-daemon to daemonize the process but our use of rvm complicates running rake because the rake binary is stored in the .rvm/gems directory. Normally the path to the rake binary is set from .bashrc and .bash_profile when you log in through a shell but when you execute things from cron, start-up scripts or other non-shell environments the paths don't exist. After some googling and tinkering I finally got something that worked:

task :start_mytask, :roles => :mytask, :except => { :no_release => true } do
  run "RAILS_ENV=#{rails_env} start-stop-daemon --start -b -m -o -d ~/current -p ~/pids/mytask.pid -a /home/ubuntu/.rvm/gems/ruby-1.9.3-p194@global/bin/rake mytask"
end

The downside with this script is I was calling rake for a specific version of ruby. At the time this was good enough to get us by. Fast forward several months and now we are preparing to upgrade to ruby 2.0. Our existing start script needed to be updated to use ruby 2.0 but I wanted to find a better way that wouldn't need to be tweaked each time we upgrade ruby. My first shot at updating the script I switched to executing rvm and calling 'bundle exec rake':

task :start_mytask, :roles => :mytask, :except => { :no_release => true } do
   run "RAILS_ENV=#{rails_env} start-stop-daemon --start -b -m -o --chdir ~/current --pidfile ~/pids/mytask.pid --exec ~/.rvm/bin/rvm -- current do bundle exec rake mytask"
end

This eliminates directly calling rake for a specific version of ruby but introduces a different issue. Executing it this way causes rvm to launch in a bash shell which then executes the rake task. start-stop-daemon creates a pid file based off of the first process started which is the bash process not the rake task. So when you try to stop it start-stop-daemon tries to kill the bash process which won't end because it has a child process running the rake task. I was getting closer but it wasn't perfect. More googling ensued and I discovered I could use rvm-exec instead of rvm. The rvm-exec command fixes the bash shell problem. It was created specifically for calling rvm in scripts. Here is what I finally came up with:

task :start_mytask, :roles => :mytask, :except => { :no_release => true } do
  run "RAILS_ENV=#{rails_env} start-stop-daemon --start -b -m -o --chdir ~/current --pidfile ~/pids/mytask.pid --exec ~/.rvm/bin/rvm-exec -- current bundle exec rake mytask"
end

It will now run independent of a ruby version number and since only one process is launched the pid file is created correctly. One other benefit I realized is now it is much easier to monitor this process. Previously the process was listed as just "rake". If you have more than one running that would get tricky to monitor. Launching it with this new script the process is listed as "rake mytask".

Finally to stop the daemonized rake task run this command:

task :stop_mytask, :roles => :mytask, :except => { :no_release => true } do
   run "start-stop-daemon -o -p ~/pids/mytask.pid --stop"
end


[UPDATE 01/13/2014] I realized today after doing more testing that I should be calling 'current bundle exec rake' instead of 'default bundle exec rake'. When you are upgrading ruby versions it doesn't necessarily mean you want to change the default ruby version in rvm. Using 'current' will cause the script to use whatever ruby is specified in the .rvmrc. I have edited the above scripts to reflect my new findings.