GUI

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.

Please Log in or Create an account to join the conversation.

More
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 :).

Please Log in or Create an account to join the conversation.

More
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)
Last edit: 03 May 2012 03:48 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
03 May 2012 05:46 #160 by MatCat
Replied by MatCat on topic Re: GUI
Ok I got it :) About to experiment with the coloring, still trying to figure out how to convert the concept of an RGB color to this color format...

Please Log in or Create an account to join the conversation.

More
03 May 2012 05:54 #161 by MatCat
Replied by MatCat on topic Re: GUI
Ok it seems to be 0xRGB? Whats odd is if I make ? F and all 0 it's the same as 0x00f0... and 0x00ff seems to be full blue (equivlent of #0000ff for full rgb...

Please Log in or Create an account to join the conversation.

More
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):
#define RGB888_to_RGB565(r, g, b) (((r & 0xf8) << 8) | ((g & 0xfc) << 3) | ((b & 0xf8) >>3))
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)
Last edit: 03 May 2012 13:22 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

More
03 May 2012 20:09 #163 by MatCat
Replied by MatCat on topic Re: GUI
I agree with you about hardcoding colors, however the colors eventually get read is how they get read, but for now until we have a library system in place :).

Please Log in or Create an account to join the conversation.

More
03 May 2012 22:15 #164 by MatCat
Replied by MatCat on topic Re: GUI
What function could I use to get some sort of time? Just to be able to make accurate timers (time itself doesn't need to be accurate but if it's possible that's nice too :).

Please Log in or Create an account to join the conversation.

More
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):
#include <sys/timeb.h>

uint32_t millitime()
{
  struct timeb tp;
  
  ftime(&tp);
  return (tp.time * 1000) + tp.millitm;
}

Please Log in or Create an account to join the conversation.

More
03 May 2012 23:04 #166 by MatCat
Replied by MatCat on topic Re: GUI
What about a basic function like php's time() function that returns miliseconds since (1970?), that way I can do something like:

timecheck = time();
... some code...

if ((time() - timecheck) >= 2000) { some code } // 2 second check

Please Log in or Create an account to join the conversation.

More
03 May 2012 23:05 #167 by PhracturedBlue
Replied by PhracturedBlue on topic Re: GUI
That is exactly what the above function will do. You can use it until I provide a more proper solution.

Please Log in or Create an account to join the conversation.

More
03 May 2012 23:08 #168 by MatCat
Replied by MatCat on topic Re: GUI
Ok good :)

Please Log in or Create an account to join the conversation.

More
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 :P. 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 :P.

Please Log in or Create an account to join the conversation.

More
04 May 2012 06:21 #174 by MatCat
Replied by MatCat on topic Re: GUI
Dialog box now added.

Please Log in or Create an account to join the conversation.

More
04 May 2012 06:26 #176 by MatCat
Replied by MatCat on topic Re: GUI
Just thought I would add a screenshot :)


Attachments:

Please Log in or Create an account to join the conversation.

More
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.

Please Log in or Create an account to join the conversation.

More
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.

Please Log in or Create an account to join the conversation.

More
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/

Please Log in or Create an account to join the conversation.

More
04 May 2012 18:25 #180 by MatCat
Replied by MatCat on topic Re: GUI
I am going to explore the Eclipse settings and see if I can easily convert tabs to 4 spaces...

Please Log in or Create an account to join the conversation.

More
04 May 2012 18:27 #181 by MatCat
Replied by MatCat on topic Re: GUI
Yeah I eventually plan to implament font checking into the GUI.

Please Log in or Create an account to join the conversation.

Time to create page: 0.119 seconds
Powered by Kunena Forum