- Posts: 4403
GUI
- PhracturedBlue
-
- Offline
Less
More
02 May 2012 23:55 #157
by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
I currently read row-by-row, and only allocate enough RAM to read 320 pixels. Even if you only want to pull a window out of the image, I read the entire line. Thus at the moment, images must be limited to 320 pixels wide. I'm not sure why you'd have issues with the height though. There is no such limit on the height. I'm going to switch to a smarter read function which will support large bitmaps. I'll let you know when it is done.
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
03 May 2012 00:27 #158
by MatCat
Replied by MatCat on topic Re: GUI
Cool, also enough issue is static font color... we need a string printing function that can be passed a color code. I got frames working today, kind of a generic image object, though I am going to put some sort of 'parent-child' tie to it and gui objects that will be contained in them, this way on redraw everything can be rendered properly.
My next step is a dialog box, as well as a method to 'disable' a gui object from interaction, so that when a dialog is up nothing else responds.
I think I will stick to the current idea of a fixed gui array, however I am going to change strings to pointers, this way the text can either come from a const, or ram depending on the need. A fixed array of mostly pointers is not going to impact the memory footprint so bad.
How did you come up with the memory footprint of my GUI system anyway? I was curious to figure that out myself, and on that what would you say is a limit of memory footprint the GUI can use?
For string tables perhaps we should have some sort of ability to grab this from library file or whatever resource we use so that multiple languages can easily be supported?
At either rate I will probably build a basic string table for now just to keep it organized until we can tackle that
.
My next step is a dialog box, as well as a method to 'disable' a gui object from interaction, so that when a dialog is up nothing else responds.
I think I will stick to the current idea of a fixed gui array, however I am going to change strings to pointers, this way the text can either come from a const, or ram depending on the need. A fixed array of mostly pointers is not going to impact the memory footprint so bad.
How did you come up with the memory footprint of my GUI system anyway? I was curious to figure that out myself, and on that what would you say is a limit of memory footprint the GUI can use?
For string tables perhaps we should have some sort of ability to grab this from library file or whatever resource we use so that multiple languages can easily be supported?
At either rate I will probably build a basic string table for now just to keep it organized until we can tackle that
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4403
03 May 2012 03:48 - 03 May 2012 03:48 #159
by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
Pull my latest code.
I added LCD_SetFontColor()
I fixed the code to support large bmp files
I added a helper script that will show RAM and ROM usage when you run 'make' (but only if you compile for ARM)
I added LCD_SetFontColor()
I fixed the code to support large bmp files
I added a helper script that will show RAM and ROM usage when you run 'make' (but only if you compile for ARM)
Last edit: 03 May 2012 03:48 by PhracturedBlue.
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4403
03 May 2012 13:20 - 03 May 2012 13:22 #162
by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
It is RGB565
so to go from your normal 24bit to 16bit color:
red(ff0000) -> f800
green(00ff00) -> 07e0
blue(0000ff) -> 001f
you can add this macro to target.h to make your life easier (untested):But in the end we don't really want to be hardcoding colors (to make themeing easier). so we'll probably read them from a file (in which case you shouldn't really need the macro)
so to go from your normal 24bit to 16bit color:
red(ff0000) -> f800
green(00ff00) -> 07e0
blue(0000ff) -> 001f
you can add this macro to target.h to make your life easier (untested):
#define RGB888_to_RGB565(r, g, b) (((r & 0xf8) << 8) | ((g & 0xfc) << 3) | ((b & 0xf8) >>3))
Last edit: 03 May 2012 13:22 by PhracturedBlue.
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4403
03 May 2012 22:55 #165
by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
There is a real-time-clock, however there is no battery backup, so I don't think it is possible to get actual time.
There is a systick feature that can be used to trigger an interrupt/counter every millisec. I don't think I've got it turned on at the moment though.
I also would need to write something equivalent for the emulator. So at the moment there isn't anything available.
Here is something you can use until I have a properly abstracted solution (untested):
There is a systick feature that can be used to trigger an interrupt/counter every millisec. I don't think I've got it turned on at the moment though.
I also would need to write something equivalent for the emulator. So at the moment there isn't anything available.
Here is something you can use until I have a properly abstracted solution (untested):
#include <sys/timeb.h>
uint32_t millitime()
{
struct timeb tp;
ftime(&tp);
return (tp.time * 1000) + tp.millitm;
}- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4403
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
04 May 2012 05:37 #171
by MatCat
Replied by MatCat on topic Re: GUI
How big of an impact does a pointer have on memory? I am working on getting Dialog boxes in, and I am almost done, but I tried to assign a callback function that has a different parameter setup then what the guiObject is spec'ed for, and obviously it doesn't work
. So I need to add a callback pointer to the Dialogbox struct, which means any other object needing a custom type of callback is going to need an extra pointer in the struct.
I am pretty sure if I check the memory usage of the GUI now it is MUCH smaller footprint then before, but I don't know exactly how much, I still need to install the arm toolchain to do a real compile, and I have no intention of installing a rom on my device until the FS is in place, it is my primary controller I fly with and I generally fly every day, and flashing roms multiple times a day is going to be a choir enough, let alone now when the possiblity of bricking it is higher then it will be down the road a little
.
I am pretty sure if I check the memory usage of the GUI now it is MUCH smaller footprint then before, but I don't know exactly how much, I still need to install the arm toolchain to do a real compile, and I have no intention of installing a rom on my device until the FS is in place, it is my primary controller I fly with and I generally fly every day, and flashing roms multiple times a day is going to be a choir enough, let alone now when the possiblity of bricking it is higher then it will be down the road a little
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4403
04 May 2012 10:35 #177
by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
each memory pointer is 4 bytes
Installing the arm chain is really simple.
use git to grab the summon-arm-toolchain (see the README) and then run the script. It will download everything you need and install it for you.
There is no risk of bricking your Tx. We now understand enough about the system to be entirely sure of that. There is also no reason for you to flash anything at the moment. I believe the emulator is sufficient for where we are now.
Installing the arm chain is really simple.
use git to grab the summon-arm-toolchain (see the README) and then run the script. It will download everything you need and install it for you.
There is no risk of bricking your Tx. We now understand enough about the system to be entirely sure of that. There is also no reason for you to flash anything at the moment. I believe the emulator is sufficient for where we are now.
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4403
04 May 2012 16:44 #178
by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
The code is looking pretty good to me. There are 2 things that need to happen before I pull your code:
1) Can you clean up all the compile warnings? We should keep the code warning free at all times
2) We need to decide on coding style. All thee code should have the same coding style. Specifically the following:
* Indent rules. Today I use 4 spaces, and you are using tabs
* block creation (where the {} go) I don't have a rule here, but generally I place {} on their own line for functions, and on the same line for conditionals/loops
I am not beholden to my rules, but to agree on a standard and stick to them. We could define indent or uncrustify rules but I'm not sure how constraining that would be. We should also setup some sort of lint rules as well. I tried splint, but it doesn't like the openocd headers. I'm not sure what it will take to get it working properly. Maybe something like clang would work better here.
1) Can you clean up all the compile warnings? We should keep the code warning free at all times
2) We need to decide on coding style. All thee code should have the same coding style. Specifically the following:
* Indent rules. Today I use 4 spaces, and you are using tabs
* block creation (where the {} go) I don't have a rule here, but generally I place {} on their own line for functions, and on the same line for conditionals/loops
I am not beholden to my rules, but to agree on a standard and stick to them. We could define indent or uncrustify rules but I'm not sure how constraining that would be. We should also setup some sort of lint rules as well. I tried splint, but it doesn't like the openocd headers. I'm not sure what it will take to get it working properly. Maybe something like clang would work better here.
- PhracturedBlue
-
- Offline
Less
More
- Posts: 4403
04 May 2012 18:01 #179
by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
Also, note that multiple fonts are supported. I just chose a few that I found on the web, but we should be able to support any font up-to 32x32. Ideally, they should be stored in SPIFlash so they can be upgraded as part of the theme. From a GUI perspective, we need to ensure that the GUI doesn't assume a specific font size when doing the layout
You can choose different fonts with LCD_SetFont(font) where 'font' is a number from 0 to 5) (I think font-6 is currently broken)
New fonts can be created using the GLCD font creator I think:
www.mikroe.com/eng/products/view/683/glcd-font-creator/
You can choose different fonts with LCD_SetFont(font) where 'font' is a number from 0 to 5) (I think font-6 is currently broken)
New fonts can be created using the GLCD font creator I think:
www.mikroe.com/eng/products/view/683/glcd-font-creator/
- MatCat
-
Topic Author
- Offline
Less
More
- Posts: 168
Time to create page: 0.179 seconds