We are still making some nice progress with the project. I finally got the smallprotocol running, which is a propietary but well documented communications protocol with checksums and stuff for the display. Result: Rock solid performance and no trash on the screen if the Arduino sends too fast or some bits get lost.
At this point goes a HUUUGE thankyou to Pat Hickey who helped me out quite a bit on the drones-discuss mailing list. The MAVLink and other libs are really complicated if you are no pro-dev and Pat and others were so nice to point me to the right direction quite a few times during the last few days.
Now, back to the question, why I chose the relatively expensive eDIPTFT from Electronic Assembly...
- EA is a manufacturer which is specialized on industrial embedded systems, means, the products are a bit more robust
- The eDIPTFT series is pretty intelligent and takes quite some load from the developer and the microcontroller.
For example: To create this instrument in the video, you quickly (5mins) design it in the instrument designer of the (costfree) IDE and upload it to the display. Then it's only 3 lines of code... When the screen is called, one line to define the instrument. Then repeatingly one line to update it - and that is just 3 bytes plus instrument ID plus value. And when you leave the screen another command to destroy the instrument. The whole painting stuff is done by the display.
One big part of this project is writing a library of convenience functions for the display.
I tinker with EA displays already for 7 or so years... The functionality makes them really cool for all kinds of projects. You only need one free serial, I²C or SPI port.