0
More on menus
One thing that quickly comes to light when working with the Nokia 6610 display - it has no libraries of its own to use: that means that you have to hand-code pretty much everything for it, including making your own fonts and writing your own bitmap display routines.
This means that your code bloats up pretty quickly.
In fact, to demonstrate using bitmaps, drawing strings of text, and including USB support (in order to send commands to the display to test different combinations of things) our code is already a whopping 9.4kb in size.
That leaves around 15kb of space for actually coding that the device should do (on a 18F2455 chip anyway). So almost half of the available program space is taken up with libraries for controlling the display! (ok, it also includes a routine for reading/writing to eeprom, but that it itself is only a few hundred bytes big!)
In fact, forgetting about the eeprom routines could be quite a mistake - instead of hard-coding menu data into the program memory (which strings to display and in which order) it makes a lot of sense to put these strings into external memory.
This offers two distinct advantages: firstly, you're not filling all your program space with strings of characters that make up the menus (you can just use a double-byte word to keep track of the eeprom address that contains the string to draw for each menu item). Secondly, it means porting your device to another language (it's wishful thinking, but there's a massive European market for electronic golf scorecards too) is a relatively painless task: simply update the strings held in eeprom using an external app and your original device code does not need to keep being amended and recompiled. Interesting idea....
Taking this idea a step further, instead of just storing strings in memory, I've decided to store the entire menu structure in eeprom.
The block diagram looks something like this:
The "variable" C has two functions:
The upper three bits are flags to tell us:
The remaining lower bits contain the value (1-31) telling us the number of items in the list.
The variable "goto" has some special/reserved values:
0 = do nothing when any item in this menu is selected
65535 (0xffff) = go into edit mode when any item in this menu is selected
"Edit mode" puts the device into a special state, where each character of the menu item can be highlighted and changed, individually. This means that, for example, player names can be put into a menu (so that a player can be selected) but at the same time, player details can be updated (e.g. change the letters of a players name).
If the variable "goto" has a valid value (i.e. a number between 1-65534) then this is the eeprom memory address containing the next menu. The current menu is cleared from screen (if necessary) and the new menu is drawn.
Here's a sample menu, converted to a byte array and written to eeprom
You'll see how the first byte is 84 (ascii 84=letter T), followed by 105 (ascii 105=i) and so on, spelling out the word "Title" and some padding bytes. The values 4,12,20 are the C,X and Y values, followed by the next line item in the menu: ascii 77=letter M, ascii 101=letter e (and so on, spelling out "Menu item 1").
Here's the resulting menu, drawn on the Nokia 6610 screen:
This means that your code bloats up pretty quickly.
In fact, to demonstrate using bitmaps, drawing strings of text, and including USB support (in order to send commands to the display to test different combinations of things) our code is already a whopping 9.4kb in size.
That leaves around 15kb of space for actually coding that the device should do (on a 18F2455 chip anyway). So almost half of the available program space is taken up with libraries for controlling the display! (ok, it also includes a routine for reading/writing to eeprom, but that it itself is only a few hundred bytes big!)
In fact, forgetting about the eeprom routines could be quite a mistake - instead of hard-coding menu data into the program memory (which strings to display and in which order) it makes a lot of sense to put these strings into external memory.
This offers two distinct advantages: firstly, you're not filling all your program space with strings of characters that make up the menus (you can just use a double-byte word to keep track of the eeprom address that contains the string to draw for each menu item). Secondly, it means porting your device to another language (it's wishful thinking, but there's a massive European market for electronic golf scorecards too) is a relatively painless task: simply update the strings held in eeprom using an external app and your original device code does not need to keep being amended and recompiled. Interesting idea....
Taking this idea a step further, instead of just storing strings in memory, I've decided to store the entire menu structure in eeprom.
The block diagram looks something like this:
- Each menu begins with a title
- C = count the number of items in this menu
- X/Y = position on screen this menu should be displayed at
- goto = pointer to eeprom address of the next menu to be displayed
The "variable" C has two functions:
The upper three bits are flags to tell us:
- Clear the entire screen before drawing this menu?
- Remove this menu after selecting an item?
- (reserved)
The remaining lower bits contain the value (1-31) telling us the number of items in the list.
The variable "goto" has some special/reserved values:
0 = do nothing when any item in this menu is selected
65535 (0xffff) = go into edit mode when any item in this menu is selected
"Edit mode" puts the device into a special state, where each character of the menu item can be highlighted and changed, individually. This means that, for example, player names can be put into a menu (so that a player can be selected) but at the same time, player details can be updated (e.g. change the letters of a players name).
If the variable "goto" has a valid value (i.e. a number between 1-65534) then this is the eeprom memory address containing the next menu. The current menu is cleared from screen (if necessary) and the new menu is drawn.
Here's a sample menu, converted to a byte array and written to eeprom
84, 105, 116, 108, 101, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 12, 20, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 50, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 77, 101, 110, 117, 32, 105, 116, 101, 109, 32, 52, 0, 0, 0, 0, 0, 0, 0, 0, 0
You'll see how the first byte is 84 (ascii 84=letter T), followed by 105 (ascii 105=i) and so on, spelling out the word "Title" and some padding bytes. The values 4,12,20 are the C,X and Y values, followed by the next line item in the menu: ascii 77=letter M, ascii 101=letter e (and so on, spelling out "Menu item 1").
Here's the resulting menu, drawn on the Nokia 6610 screen:
Posts
