So this ended up taking longer than expected so far because the touch screens I originally bought to work with were misrepresented in their specs, causing much confusion and hair pulling from my end but here we are!!
I’ve been working lately on re-writing the display drivers of DAVEga to work with the ili9341 touch screen display driver, and I now have the whole thing ported over to a level of feature parity with the original DAVEga found here.
I was never quite satisfied with the 177x220px display of the original, and I didn’t really want to have any mechanical buttons either, so I’ve been busy making this!!
This is a 2.8", 240 x 320px touch screen display showcasing the ever-popular DAVEga with scaled up UI components and a few buttons for touch interface on the screen towards the bottom (wip on either look/feel). Below it is the original display that DAVEga currently runs on for a size comparison.
I’ve also made and printed a custom holder for this that I plan to put on my mountainboard:
There’s basically no more new code changes that need to be made, but I think I understand better now by Janpom is opting to use a more powerful microcontroller than the Arduino Nano. With twice as many pixels to drive, there’s a lot more time taken on the SPI bus and it definitely feels much slower than the original resolution. I have an ESP32 coming in today to see if I can get it ported to that, but I have some concerns with touch screen library compatibility. If all else fails, I know for a fact that it will work without any issues on a Teensy 3.6. I’ve done several projects with the ili9341 touch screens using Teensies and the only reason I didn’t go to that from the beginning is I think if this is going to (hopefully) be used by others, I’d like to keep the overall cost as low as possible and the Teensy costs twice as much as the ESP32.
I’ll be updating this thread as it gets closer to posting the Github link and will also post about any new features/improvements to it here.
Removing the need for physical buttons, and a vastly more configurable experience at runtime. For example, I’ve seen a handful of screenshots like this:
There is obviously more info to show that is overflowing off of the screen. I’m adding up/down arrows in the upper and lower right corners to allow the dialog to be scrolled through and see the remaining bit. The way I implemented the touch screen UI and logic, each screen on the DaveGa will be able to have custom logic on it for how to handle button presses.
I consider version 1.0 of this to be feature parity with original DaveGa, but plan on adding more features, such as menus to set/update configurations at runtime that are more complex than what only 3 buttons would permit. Imagine a screen in addition to the horizontal, vertical, and text screens that was able to have rich input with a multitude of buttons, sliders and settable parameters.
That’s the other thing; the buttons on the original DaveGa have purposes set in stone as to what they do. A screen can now have a completely custom button rendered on screen with a very specific purpose only relevant for at screen without needing to add a physical button. Those scroll buttons is a prime example and a small addition to roll into my v1.0
¯_(ツ)_/¯ There wasn’t anything wrong with the original, just a matter of preference. I prefer the updated one but if folks aren’t very opinionated about it then it’s not worth rolling into the build.
I’m heavily considering extending it with a realtime display graph like this:
The y axis would dynamically grow/shrink depending on the max/min values needed to display on screen.
Thoughts?
It’s great that you’re contributing to the open source version. I like the improved color gradient for the battery SoC. I will steal the idea for the new davega. I’m not sure how much the touch screen features are worth pursuing. IMO the hardware buttons are more appropriate for controlling the davega since you don’t really need to interact with it that much and unlike the touch screen you can use the buttons while wearing gloves. Anyway, great job so far. I’m looking forward to more updates.
Any realtime data you want to show has to be big and easy to process. Otherwise it’s useless since you won’t be able to follow it while riding. Once above 25-30 km/h, all I can do is take a quick glance at the speed time to time. I’m very skeptical about any kind of realtime charts. I can’t see how that would be any good except for testing things on a bench… at which point you can simply use the vesc tool.
Hmm… Yeah gloves might definitely make it a harder to press smaller buttons. The touch screens I"m using are resistive touch, so you don’t need finger-to-screen for it to register, just the force alone like the oldschool Palm Pilots is fine. Tradeoff is lack of multi-touch.
So far I’ve added the ability for each screen to run a ‘processTouchInput’ function alongside the normal update() calls, and you can pass into it the button states of the existing physical buttons. That way each screen can know if the physical buttons are pressed and use those inputs as well. Haven’t put any effort yet into a ‘settings’ screen but I think enabling/disabling physical buttons could be an option on there.
Also, you did a phenomenal job structuring the project. Very high code quality to work with
Edit: Except for this one line!! lol I ended up spending a few hours trying to figure out why numbers weren’t showing up on the screen if they were too far to the right and it’s because uint8_t has a max value of 127 so any coordinate passed that will integer overflow/wrap
In theory yes. In practice, I’m not sure if you’d want to. I’ll see if I can get a gif or video of the lag to show it, but it’s definitely much slower to the point where it was pretty unsatisfactory for me. There may be some steps that can be taken to optimize how the big numbers are drawn, but that’s a non-trivial effort.
The other thing is that in order to use touch features, there’s 5 more pins from the touch display that need to be connected to in order to process touch commands. It’s still possible to use the existing physical buttons though.
tldr: Yes, but the experience is currently sub-optimal. Don’t bother unless some improvements can be made to optimize display rendering.
Thanks for the compliments. I have done some coding before.
uint8_t is an unsigned 8 bit integer so the max value is 255. This was enough for 176x220 pixels. Not a bug there. Obviously, with 240x320 you have a problem.
I’m not sure how much the touch screen features are worth pursuing. IMO the hardware buttons are more appropriate for controlling the davega since you don’t really need to interact with it that much and unlike the touch screen you can use the buttons while wearing gloves. Anyway, great job so far. I’m looking forward to more updates.
