I believe you have a logic issue. That is you have:
for(i=0; i<=7; i++)
{
...
if(i > 9){
So your loop has I going from 0 to 7, so your test for i > 9 will always fail and as such your code to output the text never happens.
Kurt
You nailed it. I just had to change it to
if(i+8 > 9){
I need to think of a better way to add the numbers and alpha character’s to the buttons. Thanks
Kurt,
I’ve been to get the keypad to work. to me it seems to have some lag when selecting items from the second row of buttons. This has been a fun and good learning experience for me. Philtkp_Screen_Test2d.ino (10.1 KB)
FYI,
The part that draws the text of the 2nd row of buttons can be a bit simpler…
Something like:
for(i=0; i<=7; i++)
{
tft.fillRoundRect(((i*6)+7)+(i*BOXSIZE), 46, BOXSIZE, BOXSIZE, 7, ILI9341_WHITE);
tft.setCursor(((i*6)+16)+(i*BOXSIZE), 52);
tft.print(i+8, HEX);
}
Thanks, didn’t even that of that
Kurt,
Added a slider to the second screen. seems to work. just need to clean it up some. any pointers would be appreciated.
Tried adding a Third screen and started get a lot of erratic results. Philtkp_Screen_Test2e.ino (12.6 KB)
Hi again,
I tried it and ran into several issues with display/touch. The first main one is that it is not setting the SPI to the right set of registers when it you are touching things…
Main issue is in: SelectedBtn
I hacked it up to look like:
[code]void SelectedBtn(int x1, int y1, int x2, int y2)
{
RestoreSPIRegs(SPIR_TS);
do{
! ts.bufferEmpty();
RestoreSPIRegs(SPIR_TFT);
tft.drawRoundRect (x1, y1, x2, y2, 7, ILI9341_RED);
tft.drawRoundRect (x1+1, y1+1, x2-2, y2-2, 7, ILI9341_RED);
tft.drawRoundRect (x1+2, y1+2, x2-4, y2-4, 7, ILI9341_RED);
RestoreSPIRegs(SPIR_TS);
}
while ( ts.touched());
RestoreSPIRegs(SPIR_TFT);
tft.drawRoundRect (x1, y1, x2, y2, 7, ILI9341_WHITE);
tft.drawRoundRect (x1+1, y1+1, x2-2, y2-2, 7, ILI9341_WHITE);
tft.drawRoundRect (x1+2, y1+2, x2-4, y2-4, 7, ILI9341_WHITE);
}[/code]
Note: I left the line in: ! ts.bufferEmpty();
But I think it is leftover and should probably be removed…
The slider may have some issues with mapping where the knob is and some interference between it and selecting the Next/Prev screen buttons… I have not debugged yet. Note: You obviously see flashing going on when moving the knob. Could probably minimize this, by only redrawing what you have to, which is a little more complex. That is you only need to redraw where the knob was before and can potentially optimize more and only redraw the part of where the knob was that it is not currently… , but this takes a bit more logic…
Also personally if it were me doing this, I would probably setup up a set of graphic objects like button, knob, … which are subclasses of some main class like graphic object. The graphic object would have some standard properties, like maybe a rectangle, maybe text, maybe some colors… It would also have some virtual functions, like draw, pressed… That the classes like button and slider would implement… Pages would simply be a collection of objects. This would have a little more overhead, but makes it easier to reuse things… Just a thought.
Kurt
Kurt,
Tried the code you posted. Still have the same results. I noticed that i started seeing some lagging results after i added the second row of buttons. I’m going to go back there to see where it all starts. will let you know what i find
FYI - I hacked some more on your program yesterday and was running into some interesting issues, which may be why you disabled some of the go to third page or go to main page in some of the processing. First off the code was double clicking… That is while holding your finger on the button, it would keep redrawing the button… I put in a hack for that. Then I was running into, when I then click somewhere else, the first location returned was from where your last place you released from, which causes issues of like jumping you to the next page…
Retried my version, does not have this issue. Probably some subtle difference in what I do once I detect mouse(finger) down… Will take another look, but may be busy for a day or two…
Kurt
P.S - I edited my copy of your stuff and it is working a bit better now…
Philtkp_Screen_Test2e.ino (13.8 KB)
Doing some more playing around. The main thing I am running into with this code base is that the mapping of the touch information is not mapping to screen coordinates.
So your drawing code and your mouse point checking is on different positions. I believe that if you change the mapping to something like:
TS_Point p = ts.getPoint();
Serial.print("<");
Serial.print(map(p.y, TS_MINY, TS_MAXY, tft.width(), 0), DEC);
Serial.print(",");
Serial.print(map(p.x, TS_MINX, TS_MAXX, 0, tft.height()), DEC);
Serial.print(">");
Note: in the above I am simply printing out the mapped values. But if instead set X to the mapping of the p.y and y to the mapping of p.x, then I believe the mapping would be the same.
Hope that makes sense… Could make an update and try it out if that would help?
Edit: Works a lot cleaner I think. Here is a quick and dirty update showing it.
Philtkp_Screen_Test2e.ino (11 KB)
Kurt,
Its a whole lot cleaner. I’m reading through the code looking and trying to understand the differences from the two and they’re out comes.
Thanks for the eye opener.
Hi Again, Yes I am also using 1.20RC2. If you noted in his release notes, That version of ILI9341 is not the fast version, but back to the Adafruit version, with the SPI transaction stuff added.
Not sure if anyone else up here is interested in the SPI stuff, but Paul (Teensy) is working with the Arduino people to come up to a solution to deal with multiple SPI devices, which may run at different speeds and capabilities… The same issues I was running into with speeding up the ILI9341 and still using SPI library for touch display. Paul has this implemented in this RC, not sure how long until Arduino Integrates it for other platforms…
But in the mean time Paul did take my faster version of the ILI9341, strip out all of the non Teensy 3x stuff, put in transaction stuff and is speeding up everything else. That is he brought in the Adafruit GFX code and is speeding it up…
I have been trying it out, debugging it and the like and now have my stuff working with it. More details up at:
forum.pjrc.com/threads/26305-Hig … 29-library
Kurt
Hi,
Just gave it a try. Had to make the modifications you posted on the pjrc forum. Seems to be working.
Philtkp_Screen_Test2e3a.ino (8.86 KB)
As you have already posted on pjrc, I know that you know he has fixed the driver to work with all of the current test programs and you no longer need my modifications 
Again you probably already know this, but he renamed the optimized library. I also retested with my modified version of your code, with the new library name and with all of my SPI switching hacks as this stuff is built into the new SPI code…
Philtkp_Screen_Test2e-140806a.zip (2.05 KB)
Thanks for letting me know. I just gave it a try. its nice having to add the SPI switches within the code
FYI - I have been playing around with the sped up version of the library, in particular the ability to read pixels back in. Finally had some success Can now read in pixels and now can scroll parts of the screen. More details up on the thread: forum.pjrc.com/threads/26305-Hig … #post53604
Note: I forked his version of it and my fork (with new stuff) is up at: github.com/PaulStoffregen/ILI9341_t3
Kurte,
this an off topic question. Just saw the intel Edison looks promising. was thinking of geting one. what do you think? sparkfun.com/products/13024
The Edison looks interesting, did not look today,but last I looked they only had the boards and not any supporting hardware.
Trossen with Intel and others is coming out with a homonoid robot that will have an Edison as well as a new board with an arm m3 processor to control it, which looks interesting