Does that mean that we cannot use something like this or wouldn't that only be inaccurate?
if ((pt.x>=420) && (pt.x<=480) && (pt.y>=0) && (pt.y<=40)) {
I already created a menu with up down, left right and zoom + - on the right upper side.
The part works, short press brings that menu up, longer press brings up MainMenu.
The commands for Zoom in and zoom out are quite easy to create I think. It requires to grab the currentzoomlevel and do a i++ or i-- for every touch, download that map and display that map.
I was thinking of something like this:
if ((pt.x>=420) && (pt.x<=480) && (pt.y>=0) && (pt.y<=40)) {
if (currentPage == '0'){
// Page 0 PanAndZoom, page 1 MainMenu, Page 2 manual update, based on presstime
tft.fillScreen(TFT_BLACK);
Serial.println("Zoom IN pressed") ;
currentZoomlevel = geoMap.getCurrentZoomlevel(); //added in geomap.h
for (int i = currentZoomlevel; i++;){
delay(500);
geoMap.downloadMap(mapCenter, i, _downloadCallback);
geoMap.convertToCoordinates({0,0});
geoMap.convertToCoordinates({MAP_WIDTH, MAP_HEIGHT});
tft.fillRect(0, geoMap.getMapHeight(), tft.width(), tft.height() - geoMap.getMapHeight(), TFT_BLACK);
You can find the (probably not compiling version due to missing brackets to close the loop) code here
Mac_che:
Does that mean that we cannot use something like this or wouldn't that only be inaccurate?
If you run the code in post #122 you will see in the Serial Monitor window that the coordinates are in raw ADC values. These could be used but are likely to be in the range 0 - 4095. Also the coordinate origin of the touch screen may not be in the same place as the origin of the screen.
How hard would it be to write (just for debug purposes) an Adafruit compatible driver using ILI9431 as a template. Tried myself but cannot get the init to work (Used your init and notro's init, screen stays white) Any idea's?
Nevermind, it wasn't that :o. After setting a few print statements I saw that it crashed on setFreeFont
Setting it to setTextFont(2); worked.
Have to change a few settings to make it fit the 480*320. It even works on 160MHZ.
I had to use the JPEGDecoder version from FredericPlante. Yours gave me everything but no Google Maps background.
it takes a few changes. (I'll save you the trouble, i'll upload a working sketch) I made a few changes to a few libraries so it's easier to upload it and attach it here since Github is kinda new. (TODO, upload to Github)
I changed a lot to make it fit my screen (320*240) and my wishes. Still working on the touch, I am close.
It sometimes reset and lines (heading) aren't drawn, which it dit initially, have to look in to that.
I want bigger font and more space between the text but hey, I came this far
I took me a while to figure it all out but I managed. Experience in c++ or Arduino code is still below any average. It took a steap learning curve and mostly some time,coffee & perseverance
As always, it wasn't that hard if you know what you're doing (I have some clues what I am doing) but I liked the leaning course. I tried to make as much comments as possible while changing things.
I also included the library's I modified (TFT_eSPi) in the next post (Due to upload size). Read the original readme by Daniel for the others)
fredericplante's Jpegdecoder changed names due to recovery and is now called JPEG_CODEC, old one will work also.
You can find it here
Huge thanx to Bodmer for the liTFT brary and the responses!
By the way, you need this for touch: XPT2046_Touchscreen PaulStoffregen
And ofcourse credits to Daniel Eichhorn who made the whole Planespotter sketch in the first place. See blog
His Github for Planespotter: esp8266-plane-spotter-color
The sketch is as is, I did not gave myself credits in this one. Free to use.
If you cannot open the zip, it's actually a renamed rar file (due to forum limitations)
Modified TFT_eSPI (Added some functions)
Only cpp and .h are modified, Download Bodmer original library here and copy them over.
(Forum limitations and things like that)
Mac_che:
Is there an easy way to download (6Kb) bmp (from a/my internal server) and throw them out of memory when no longer needed?
The simplest method if the server handles http GET commands is to use a method like this example. However as the image is small, and I assume frequently fetched and erased, then the image can be stored in a RAM array otherwise you could wear out the FLASH memory.
What I assume (Please verify) is that it is not possible to write to SPIFFS during runtime, only during setup phase.
Since i can't store the 1500+ images directly to SPIFFS since it's total size is more than 5MB, i was thinking that I simply download the images I need while they're being seen (silhouettes of the airplane) and store them on SPIFFS. I don't think I will ever see all the 1500+ Airplanes on the device so that's not a problem.
Everyime I download the images during runtime it resets and throws a stack trace on the serial interface.
The images are ok since storing (a few ofcourse) of them to SPIFFS directly and show them on the display works.
I am ok with storing them into ram but well, i can't find any examples for it.
Mac_che:
What I assume (Please verify) is that it is not possible to write to SPIFFS during runtime, only during setup phase.
Since i can't store the 1500+ images directly to SPIFFS since it's total size is more than 5MB, i was thinking that I simply download the images I need while they're being seen (silhouettes of the airplane) and store them on SPIFFS. I don't think I will ever see all the 1500+ Airplanes on the device so that's not a problem.
Everyime I download the images during runtime it resets and throws a stack trace on the serial interface.
The images are ok since storing (a few ofcourse) of them to SPIFFS directly and show them on the display works.
I am ok with storing them into ram but well, i can't find any examples for it.
SPIFFS is a FLASH based filing system so files can be created and erased during runtime. The main problem is that the FLASH will eventually wear our after maybe less than 1 million write cycles.
There are many reasons why the ESP8266 throws an exception (stack trace), the common reason is the watchdog reset, in this case calling yield() frequently (more than once per second) fixes it. Another reason is using too much RAM or writing past the end of an array.
Unfortunately it will be difficult for me to help you with your project due to the many unknowns in your setup and sketch.
The TFT_eSPI library has been updated on Github to support the SPI overlap mode with the ESP8266.
This means that a SPI based TFT can share the MOSI, MISO and SCK pins with the program FLASH and thus frees up at least 2 GPIO pins for other uses.
To use this capability the latest Github version of the ESP8266 board package must be used in the IDE, as it is not a formal release yet this must be obtained direct from Github. The board package was updated in May 2017 to support the overlap mode. If readers are unsure how update the board package manually then it would be best to wait for the next board package version to be released.
Can someone with more knowledge of arduino IDE help me porting
to this library?
What I can deduct it's a script with the functions separated from the driver.
Like: VNCScripts>Framebuffer (function calls for the TFT drver...sort of a wrapper)>TFT driver
So it seems like we need to substitue some references to eTFT. When I tried it gave me a lot of errors
(mostly init related errors with the tft driver) I can't figure out what or how to proceed.
IT would be a nice add-on to use it with this driver.