Hi everyone,
I have written a library that (I think, at least) markedly simplifies managing a simple graphical user interface on the ILI9341 and similar. It so far written expressly for Teensy 3.5 and 3.6 but should be a very straightforward port.
The code separates out the parameters for each graphical element into a line item in a file that is stored on an SD card. At startup, the parameters are written into RAM and then drawn on the screen. Each element on the screen belongs to a virtual window, so it is possible to not only draw a single object, but there is a command to draw an entire window as well.
Each element can also act as a button. The code requires a single function call in the main loop that polls for a touch. If a button is touched, the function returns the unique ID of the element touched. Actions can then be executed by a switch/case block.
So far, I've only written code for three types of ojbects: a rectangle, circle, and text block. Colors of elements can be changed during execution of the program, as can text content. Activity as a button can also be turned on and off.
I think this approach offers several advantages. First, if you want to add a purely "decorative" element (doesn't act as a button, doesn't need its color or text changed during execution), no additional code is needed. Simply add a line to the rsrc.txt file containing the necessary information and the item will appear the next time the program runs. Second, if you are working on the esthetics of the GUI, you can move an item around on the screen by twiddling the parameters. No recompilation needed, and button functionality will tag happily along. No fixes to that code needed either. Third, language localization becomes much easier. From a control standpoint, I think building a case/switch statement that runs from an item number is much easier.
Runtime functions include the loop polling function as well as an ability to change foreground, background colors on the fly and perhaps most importantly to change text on the fly. Drawing individual objects and virtual windows can handle (as I said before) circles, text, and rectangles. I was going to put in the ability to draw a bitmap, but that got very complicated very quickly, and I didn't have the energy or interest/need for my purposes to pursue it. I still want to put in a couple more simple elements such as a line and a triangle. I also eventually want to write this such that a parameter line can describe an object's size and position as an expression of screen size (e.g., top/left of rectangle 1/4 of y length and 1/8 x length, height .15 of screen y dimension and width .25 of screen x dimension). This would allow for better planning and would make porting code to a different screen much easier.
My work on this got sidetracked when I started building a website for my wife's music teachers association. I suspect many of you out there are much better programmers than I am, and I hope someone can run with the basic ideas I put out there. However, attribution would be greatly appreciated.
Code, more description at
Cheeers,
Ed
I have written a library that (I think, at least) markedly simplifies managing a simple graphical user interface on the ILI9341 and similar. It so far written expressly for Teensy 3.5 and 3.6 but should be a very straightforward port.
The code separates out the parameters for each graphical element into a line item in a file that is stored on an SD card. At startup, the parameters are written into RAM and then drawn on the screen. Each element on the screen belongs to a virtual window, so it is possible to not only draw a single object, but there is a command to draw an entire window as well.
Each element can also act as a button. The code requires a single function call in the main loop that polls for a touch. If a button is touched, the function returns the unique ID of the element touched. Actions can then be executed by a switch/case block.
So far, I've only written code for three types of ojbects: a rectangle, circle, and text block. Colors of elements can be changed during execution of the program, as can text content. Activity as a button can also be turned on and off.
I think this approach offers several advantages. First, if you want to add a purely "decorative" element (doesn't act as a button, doesn't need its color or text changed during execution), no additional code is needed. Simply add a line to the rsrc.txt file containing the necessary information and the item will appear the next time the program runs. Second, if you are working on the esthetics of the GUI, you can move an item around on the screen by twiddling the parameters. No recompilation needed, and button functionality will tag happily along. No fixes to that code needed either. Third, language localization becomes much easier. From a control standpoint, I think building a case/switch statement that runs from an item number is much easier.
Runtime functions include the loop polling function as well as an ability to change foreground, background colors on the fly and perhaps most importantly to change text on the fly. Drawing individual objects and virtual windows can handle (as I said before) circles, text, and rectangles. I was going to put in the ability to draw a bitmap, but that got very complicated very quickly, and I didn't have the energy or interest/need for my purposes to pursue it. I still want to put in a couple more simple elements such as a line and a triangle. I also eventually want to write this such that a parameter line can describe an object's size and position as an expression of screen size (e.g., top/left of rectangle 1/4 of y length and 1/8 x length, height .15 of screen y dimension and width .25 of screen x dimension). This would allow for better planning and would make porting code to a different screen much easier.
My work on this got sidetracked when I started building a website for my wife's music teachers association. I suspect many of you out there are much better programmers than I am, and I hope someone can run with the basic ideas I put out there. However, attribution would be greatly appreciated.
Code, more description at
Cheeers,
Ed