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 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.
Comments
Actually, I think the easiest way is to look at the current sourcecode. As recommened by Pat on the mailinglist, I use the GCS_MAVLink library from the ArduCopter project. Then I looked at the ArduStationII project for the first implementation. From there, it's pretty straightforward, just look in the GCS_MAVLink library's include directory. Every message has it's own header file and those are named in a meaningful way. It's lots of reading you you best have a system with 2 or 3 screens to have multiple files open side-by-side to compare but in the end, it's no black magic.
Nice work Stefan. Would you happen to have any pointers for someone looking to understand the MAVLink protocols? I've gone to http://qgroundcontrol.org/mavlink/start to try and get a clue of how to implement it at a very basic level, but to be honest with you, their explanations are beyond my level of understanding. Any primers out there you'd recommend?