Just seeing if anyone knows of an available qwerty library for touchscreens?
@wesner0019, that’s a leading question! Which driver, which screen etc. You need to give a little more info dude!
2.2" TFT 320x240 pixel, ILI9341 driver with 4 wire resistive touch screen.
I tried browsing the web for something but couldn’t find anything.
That’s why I left it as leading. I was looking for anything that can be adapted to work with this exact setup.
Yup… good luck with that. That’s why I am going with an HMI display that does all work (Nextion).
@peekay, those screens look amazing! Too bad they don’t have a 2.2 version
@wesner0019 what about the 2.4" version?
@peekay123, its too large to fit my project. The 2.2 just barely fits!
@wesner0019, DUDE!!! This is very new and I don’t know much about it but it is worth checking out:
@wesner0019, this is so new I’ve asked them when they will have an updated Arduino library (which I can port). They use a touch panel chip which does all the work and have an onboard SD as well. Making a qwerty keypad will still be some work but a lot simpler. Using the UTFT UTOUCH library may provide some inspiration.
@wesner0019, I ordered one (since it ships from Canada)! It is almost the same cost as the Nextion HMI display! I’ll keep you posted on my findings
@wesner0019, looking at the Digole documentation on their new touch display I found that you can store fonts and command sequences in an onboard 2MB flash! Besides the obvious font feature, the command to draw the entire querty keyboard (filled rectangles and text) could be stored in the board’s flash ONCE and recalled with a single command in user code. This can reduce user code a lot! This could be done with any “base” screen that needs to be drawn (qwerty, numeric keypad, etc). Very cool!
@wesner0019, I should be getting the Digole touch screen today or Monday. One thing you need to consider is that you don’t need to create the keyboard(s) in your app. Instead, you can create an image of a keyboard in your favorite draw app and the key “areas” can be mapped in a table. You can optimize the image for the 320x240 display using 256 colors (1 byte per pixel, 75KB per image) or 65K colors (2 bytes per pixel, 150KB per image). These can be stored in the new display’s onboard flash and displayed using a single command.
Extending this idea, you can create display “pages” using an image for each page. A touch library could keep track of the touch areas while the user code defines display areas/fields.
Your assignment then -> create or find a good querty keyboard image that can be used on the 320x240 display!
Nice didn’t think of this way! I’ll start looking!
@peekay, here’s a start (look familiar):
@wesner0019, perfect! I received the display and I’m working on getting the demo code working so stay tuned. Then, I’ll mock up the keyboard and a couple of keys with some code
here’s the git link to 256k bitmap of original (640x430)
@wesner0019, so it turns out there are two versions of the Digole touch screen. One with the 2MB flash and one without. I ordered the one without. I believe the best one for the job is the one with the flash. Nonetheless, I can do a proof of concept with the keyboard image you gave me. I did a conversion and scaling using the Digole web tool and it looks good with 256 colors. The scaled image takes about 40KB which could be stored in the onboard flash. I’ll be working on a demo for doing the first row of buttons using touch.
@wesner0019, I have a demo of the keyboard working on the display. It is the text keyboard with only the first row for now but I’ll see if I can put a video together for you. I have also received the display version with onboard flash which will make putting up the keyboard graphics much faster. I’ll be playing with that as well.