In hopes that this is the right place to post this:
I have an SK-FT843-ADAM display with a DUE. The display works fine, but I am having a strange problem with the FT_App_Gauges (EVE) example I am running from FTDI.com. Here is a link to a video showing what the app does. FT App FtGauges - YouTube
Mine does the same thing with one exception. if the values (random or resistance) get below 5000 (50%) on the gauges, the needle disappears until the value gets back up to 50% or higher.
I have looked everywhere (FTDI, Google, etc.) for an answer. I have been studying the manuals, and the code but cannot find the cause. I think it may be a scaling issue? At first I had issues with EEPROM.h not found but resolved that. Now I have a disappearing needle.
If anyone can shed light on what I am missing, I would be grateful.
The FT_App_Gauges example (and all that came in the FTDI-lib like examples) was made to AVR-plattforms, but don´t worry, it´s a little fail on the code, no on the TFT.
TFTLCDCyg:
The FT_App_Gauges example (and all that came in the FTDI-lib like examples) was made to AVR-plattforms, but don´t worry, it´s a little fail on the code, no on the TFT.
PD: I prefer to use the gameduino 2 lib, it´s more efficient and easy to use.
Yes, this is a video of this app in a demonstration that works, but the question was in reference to my app that does not quite work and a request for help debugging the app. This offers no direction on the original question, but thanks for the plug.
After no luck in several forums, I made contact with the support from FTDI, the folks who make the chip on the display. They responded asking me to use the links they provided and download an older version of the Arduino IDE (version 1.0.5-r2) and an older version of the libraries for the display. I tried this and it worked. This IDE had no DUE list in the boards so I tried the mega 2560 and it worked great without lag. With all the mods I made to the demo and the code of my own I added, it works very well and fast. The only issue left to resolve is the arduino systems do not seem to be well suited for high resolution encoders (2048 ppr). The interrupt routines are far to slow to be use with the display (lag issues). Judging from the hundreds of requests for help and work-arounds offered that fall a bit short of the mark, I decided to tackle this next. Also due to no shields being developed to do this without work-arounds that fall short of the mark, I concluded the Arduino platform likely is not capable of this (hope I am wrong). Currently I am working with people from robotshop and their high speed pulse counter to interface it with the SPI and let that board do what the Arduino cannot and just poll the counter periodically to get the count and write the variable that the display is using to control the needle.
I very well could be prejudging the Arduino capabilities or may find that it is my own which are lacking. If anyone has ideas on how to accomplish this, I would be grateful. My next step is to move up the Arduino revision line to get the due going again.
It is proper forum etiquette to edit you thread heading with Solved. Also what did you do to solve it, so someone with the same problem will be helped.
detown:
It is proper forum etiquette to edit you thread heading with Solved. Also what did you do to solve it, so someone with the same problem will be helped.
Apologies. I edited the original post heading and edited my last post to reflect what I did to get the issue resolved.