Kurt,
when using the tft.setRotation(3) to give me the landscape mode for text placement I’m not able to properly sense the touch screen locations. Do I have to flip back and forth between 3 and the default to properly sense the screen?
Not necessarily, actually the two systems are independent of each other. What you instead need to do, is to play around with the mapping of the raw touch values to logical screen locations.
If for example you look at my test program, you will see:
[code]boolean OLEDSGC::GetTouchPoint(word *pwX, word *pwY)
{
SetSPIMode(false);
TS_Point p = ts.getPoint();
// Scale from ~0->4000 to tft.width using the calibration #'s
*pwX = map(p.y, TS_MINX, TS_MAXX, tft.width(), 0);
*pwY = map(p.x, TS_MINY, TS_MAXY, 0, tft.height());
SetSPIMode(true);
return true;
}
[/code]
You will notice that for X I am using raw Y’s … Also in one direction where the Min Raw data is the max screen value and the Max raw is the min screen.
Kurt
Hi Kurt,
Good to see your having fun with your Teensy, Sounds like a convenient method to save ports and wires. I do see he get some faulty readings. Did you also get them or did you adjust it?
I was getting a few bad readings from time to time. But could probably easily adjust code to take care of it. Also could probably also minimize it by maybe taking a couple of samples and averaging as to remove any bad values. Also if I were to use something like this as part of a real project would probably where I was going to make multiple ones, I would probably also get better resistors, like maybe 1% type as to keep it more consistent.
Kurt
Kurt,
I’ve been able run this trial without any issues using teensyduino 1.20 rc1. It took me a bit to understand the mapping of the touch screen part.
I’ll post the code when i get back home. Thanks for the help.
Kurt,
I’m unable to place text on the screen I must be missing something using tft.print( 0xA , HEX); no problem using tft.print( i ); to place numbers
This the part of the code I’m working on
[code]void SetDisplayMainScreen(){
int i;
tft.fillScreen(ILI9341_BLACK);
Serial.println(“BLACK”);
// delay(2000);
tft. setTextColor(ILI9341_BLUE);
//setTextColor(uint16_t color, uint16_t backgroundcolor);
tft.setTextSize(3);
for(i=0; i<=7; i++)
{
tft.fillRoundRect(((i6)+7)+(iBOXSIZE), 7, BOXSIZE, BOXSIZE, 7, ILI9341_WHITE);
tft.setCursor(((i6)+16)+(iBOXSIZE), 13);
tft.print(i);
// tft.drawChar(((i6)+9)+(iBOXSIZE), 9, i, ILI9341_BLUE, ILI9341_WHITE, 2);
}
for(i=0; i<=7; i++)
{
tft.fillRoundRect(((i6)+7)+(iBOXSIZE), 46, BOXSIZE, BOXSIZE, 7, ILI9341_WHITE);
tft.setCursor(((i6)+16)+(iBOXSIZE), 52);
if(i+8 <= 9){tft.print(i+8);}
if(i > 9){
tft.setCursor(((i6)+7)+(iBOXSIZE), 46);
tft.setTextColor(ILI9341_RED);
tft.setTextSize(3);
tft.print(0xA, HEX);}
}
/* tft.fillRoundRect(190, 10, BOXSIZE, BOXSIZE, 7, ILI9341_BLACK);
tft.fillTriangle(200, 35, 220, 35, 210, 20, ILI9341_YELLOW);
*/
// Set which screen is current
uCurrentScreen = SCREEN_MAIN;
}[/code]
Philtkp_Screen_Test2c.ino (13.3 KB)
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)