Addition:
ParameterType 0 is Enumerated (was reserved)
The parser keeps track of the option index which is used as the enumerated
value.
For example if option 4 is selected, the enumerated value 4 is written to
the
persistent variable. The application then is able to select a correct value
from
a table in the application code, for example a baudrate, which has different
values for BS2, BS2SX etc. (although this table could be in the eeprom also)
Looks like a good start, albeit more xomplex that I was envisioning,
but doable.
If you are ging to keep parameters in EEPROM, their addresses must be
made available to the program. There could also be "working
variables" which are in RAM but not retained in EEPROM. I'm thinking
of a display mode where one wishes to page through a list of current
conditons (temperature, current, pressure, etc.), possibly modifying
some values (reducing current high-temperature).
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Consider this:
>
> 4x20 LCD
> LINE1: menu name or parameter name (10 chars), right side for custom
use (status?)
> LINE2: option1
> LINE3: option2
> LINE4: option3 (blank if not available)
>
> KEYS:6
> X
> 1/U
> X X X X
> cancel 2/L More/R ok
> X
> 3/D
>
> The menutables consist of ParameterBlocks and MenuBlocks
>
> [noparse][[/noparse]ParameterBlock]
> NAME DATA "Parm Name " 'name (10 bytes)
> ADDR DATA WORD 0 'address (2 bytes)
> FIELD DATA 0 'fieldsize (1 byte)
> REORD DATA 0 'recordsize (1 byte)
> ATTR DATA WORD TYPE*4096+1 'b15-b12=type, b11-b0=record
entries (2 bytes)
>
> The parameter block holds name and address of the parameter.
> The parameter name is to be printed on line1 of the lcd.
> The field size is the storage size for this parameter.
> The recordsize is the storage size of the record the parameter is
part of.
> fieldsize=recordsize in case parameter is total record.
> field and record allow address calculation for array based variables
> TYPE is one of the following
> 00 = RESERVED
> 01 = BIT (BINAIR)
> 02 = BYTE (BINAIR)
> 03 = WORD (BINAIR)
> 04 = DEC (ASCII)
> 05 = FLOAT (ASCII)
> 06 = HEX (ASCII)
> 07 = TEXT (ASCII)
> TYPE determines which characters are valid when entering a new value
for a parameter.
>
> [noparse][[/noparse]MenuBlock]
> NAME DATA "Menu Name " 'name (10 bytes)
> PREV DATA WORD PrevMenu 'previous menu (key OK or key CANCEL)
> OPTION1 DATA "menu option 1 " '20 bytes
> OPTION2 DATA "menu option 2 "
> OPTION3 DATA "menu option 3 "
> KEY1 DATA WORD OPT1+TYPE 'MenuBlock or ParameterBlock
or Command
> KEY2 DATA WORD OPY2+TYPE
> KEY3 DATA WORD OPT3+TYPE
> KEYMORE DATA WORD OPTION4
> OPTION4 DATA "menu option 4 " 'second screen with options
> OPTION5 DATA "menu option 5 "
> OPTION6 DATA " "
> KEY1 DATA WORD OPT4+TYPE
> KEY2 DATA WORD OPT5+TYPE
> KEY3 DATA WORD 0
> KEYNORE DATA WORD OPTION1
>
> The menu name is printed on the first line of the lcd.
> PREV points to the previous menublock (0 if main menu)
> OPTION1, OPTION2, OPTION3 are printed on lines 2,3,4 of lcd
> KEY1, KEY2, KEY3 hold next menublock or a parameterblock (0 if no
option)
> KEYMORE points to next options so only lines 2,3,4 of lcd need update
> If there are 3 or less options in total, KEYMORE should be 0.
> If there are more than 3 options, KEYMORE points to the next 3 options
> and KEYMORE for the last 3 options points to the first 3 options to
allow
> cycling through options.
> When the ok key is pressed, a parameter may be updated in eeprom, when
> cancel is pressed changes must be discarded.
> TYPE identifies the type of addresses.
> $0000 identifies options (so parser knows it must print 3 lines)
> $4000 identifies a command (use BRANCH to execute a command)
> $8000 identifies a menublock
> $C000 identifies a parameterblock
> The use of TYPE limits usable eeprom space for menus to 16KB
> but that should not be a real limit.
> When specifying a command, the supplied 'address' is an integervalue
> not an eeprom address.
>
> Since all options at the same menu level are within a single menublock,
> menublocks can be indented to create an optical view of the menu tree.
> This should enhance the readability and allow for easier maintaince.
>
> [noparse][[/noparse]MenuStart]
> MAIN DATA WORD MainMenu 'menublock for main menu
>
> This scheme should be easy to traverse.
>
> Any comments on this please.
>
> regards peter
tions of this message have been removed]
i live in richmond hill. have been to xtreme hobbies a
few times. good guys. xtreme is mostly rc cars and stuff
and a cool indoor dirt track.
http://www.roguerobotics.com/ has their retail shop
through xtreme. erik (runs rogue) is in the process of
setting up rogue/parallax stock there.
they have assorted things like stamps, boe, and various
kits and books.
hey, if you start some kind of canadian stamps club, count
me in.
cheers,
mike
--- In basicstamps@yahoogroups.com, "russranshaw" <home.rr@c...>
wrote:
> Barrie? It's a small world. My wife's daughter lives there!
>
> Does "Extreme Hobbies" carry electronic parts? Maybe DB-9 Male and
> Female PCB connectors?
>
> Russ
>
>
> --- In basicstamps@yahoogroups.com, "SB" <steve.brady@r...> wrote:
> > Hey, I grew up in Fort Erie....went out west and have made it back
> and am I
> > Barrie.
> >
> > Incidentally, there is an "Extreme Hobbies" place in Richmond
> Hill/Vaughn
> > that use stamps for combat bots....that's were I picked up my
> bs2p40....for
> > interests sake anyhow...
> >
> >
Original Message
> > From: "russranshaw" <home.rr@c...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Monday, March 01, 2004 1:00 PM
> > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > Dan,
> > >
> > > I'm in Port Colborne, ON!
> > >
> > > Russ
> > >
> > > --- In basicstamps@yahoogroups.com, "Dan Angiu" <dan.angiu@n...>
> wrote:
> > > > Russ,
> > > > If I hear something I'll let you know. I thought it was
somebody
> on the
> > > > list but probablly I'm wrong.
> > > > I'm in Woodbridge, Ontario.
> > > >
> > > > Jon W. thanks for the link.
> > > >
> > > > Dan
> > > >
> > > >
Original Message
> > > > From: russranshaw [noparse][[/noparse]mailto:home.rr@c...]
> > > > Sent: February 29, 2004 4:44 PM
> > > > To: basicstamps@yahoogroups.com
> > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > Dan,
> > > >
> > > > My name is Russ, and I live in Canada. I hadn't heard ot the
Basic
> > > > Stamp Club up here, so if you find any information, please CC
it
> to me,
> > > > and I'll do likewise!
> > > >
> > > > Russ
> > >
> > >
> > >
> > > To UNSUBSCRIBE, just send mail to:
> > > basicstamps-unsubscribe@yahoogroups.com
> > > from the same email address that you subscribed. Text in the
> Subject and
> > Body of the message will be ignored.
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
Setting/changing runtime variables should be done via commands.
For the javelin the address of a runtime variable cannot be fixed. Use a
switch()
to execute a command, like increase high_temperature. For pbasic you can
locate runtime variables on a fixed address but I would not recommend that.
Let the application code deal with the runtime variables, the menu in eeprom
will supply the userfriendly text.
Part of the application code are the read routines that read user-entered
values.
These are the same routines the parser will use to read user-entered values
for the persistent variables.
The addresses of the persistent variables are public otherwise the
application program
cannot read them. Also the address where the start address of the menutables
is stored
is public (this is just an other persistent variable).
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, March 03, 2004 6:52 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> Looks like a good start, albeit more xomplex that I was envisioning,
> but doable.
>
> If you are ging to keep parameters in EEPROM, their addresses must be
> made available to the program. There could also be "working
> variables" which are in RAM but not retained in EEPROM. I'm thinking
> of a display mode where one wishes to page through a list of current
> conditons (temperature, current, pressure, etc.), possibly modifying
> some values (reducing current high-temperature).
>
> Russ
>
The applicztion program has to have some knowledge about what th emenu
does. The application classes would use methods to get/set the
various variables, whereever they are stored. All of this would be
genrated by the translation software and put into a separate. If
these variables were actually in arrays, then the array indicies could
be stored in the EEPROM table and accessed driectly by the menu class
as needed by direct array reference, or a special method.
A mechanism for doing this in PBASIC is an exercise left for the
student. [noparse]:)[/noparse]
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> Setting/changing runtime variables should be done via commands.
> For the javelin the address of a runtime variable cannot be fixed. Use a
> switch()
> to execute a command, like increase high_temperature. For pbasic you can
> locate runtime variables on a fixed address but I would not
recommend that.
> Let the application code deal with the runtime variables, the menu
in eeprom
> will supply the userfriendly text.
> Part of the application code are the read routines that read
user-entered
> values.
> These are the same routines the parser will use to read user-entered
values
> for the persistent variables.
>
> The addresses of the persistent variables are public otherwise the
> application program
> cannot read them. Also the address where the start address of the
menutables
> is stored
> is public (this is just an other persistent variable).
>
> regards peter
>
>
Original Message
> From: "russranshaw" <home.rr@c...>
> To: <basicstamps@yahoogroups.com>
> Sent: Wednesday, March 03, 2004 6:52 PM
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > Peter,
> >
> > Looks like a good start, albeit more xomplex that I was envisioning,
> > but doable.
> >
> > If you are ging to keep parameters in EEPROM, their addresses must be
> > made available to the program. There could also be "working
> > variables" which are in RAM but not retained in EEPROM. I'm thinking
> > of a display mode where one wishes to page through a list of current
> > conditons (temperature, current, pressure, etc.), possibly modifying
> > some values (reducing current high-temperature).
> >
> > Russ
> >
Sorry, I don;t understand your point.
Imagine you navigate through the menu. At some point
you come to the screen with option 'increase high temp'.
Suppose it is option 2. Pressing the key2 selects this option.
The parser reads the word from eeprom for that key for that
specific screen. If that word equals OPT+$4000 (see layout)
then the parser knows that OPT is a command.
The parser then calls the execute_command subroutine with
the value OPT.
For pbasic:
EXEC_CMD:
BRANCH OPT,[noparse][[/noparse]CMD0,CMD1,CMD2]
ERROR: 'error handling here
CMD0: HIGH_TEMP = HIGH_TEMP-1 'decrease high temp
RETURN
CMD1: HIGH_TEMP = HIGH_TEMP+1 'increase high temp
RETURN
CMD2: 'some other function
RETURN
For the javelin you use switch() instead of BRANCH.
So it is not necessary for the application to know whatever state the menu
is in,
it just performs a function based on an integer value. Obviously the list of
commands
must match the menu screens with respect to the stored integervalue.
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, March 03, 2004 9:01 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> The applicztion program has to have some knowledge about what th emenu
> does. The application classes would use methods to get/set the
> various variables, whereever they are stored. All of this would be
> genrated by the translation software and put into a separate. If
> these variables were actually in arrays, then the array indicies could
> be stored in the EEPROM table and accessed driectly by the menu class
> as needed by direct array reference, or a special method.
>
> A mechanism for doing this in PBASIC is an exercise left for the
> student. [noparse]:)[/noparse]
>
> Russ
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > Russ,
> >
> > Setting/changing runtime variables should be done via commands.
> > For the javelin the address of a runtime variable cannot be fixed. Use a
> > switch()
> > to execute a command, like increase high_temperature. For pbasic you can
> > locate runtime variables on a fixed address but I would not
> recommend that.
> > Let the application code deal with the runtime variables, the menu
> in eeprom
> > will supply the userfriendly text.
> > Part of the application code are the read routines that read
> user-entered
> > values.
> > These are the same routines the parser will use to read user-entered
> values
> > for the persistent variables.
> >
> > The addresses of the persistent variables are public otherwise the
> > application program
> > cannot read them. Also the address where the start address of the
> menutables
> > is stored
> > is public (this is just an other persistent variable).
> >
> > regards peter
I am still not satisfied with the current setup. Too many full screens and
multiple
options on a screen do not improve navigation. So I reconsidered, moving
towards
the setup Jon described in his article (see few posts back), with a few
modifications
to allow more input including text.
Assume 2 line display and 6 navigation keys.
Top line holds menu name + optionally status info.
Bottom line holds item name (submenu or parameter) + optionally its assigned
value
keys: up, down, left, right, ok, cancel
When not in menu mode, press ok to enter menu mode.
Topline will display "Main Menu" (or whatever you want)
Bottom line will display first item of main menu.
Use up and down keys to cycle through menu items.
press cancel to leave current menu (i.e menu up)
Several possibilities depending on the currently displayed item:
1. The bottom line will display the item name + assigned value
Use left and right keys to cycle through available enumerated values or
decrease/increase value
press ok to enter edit mode
A cursor will be placed under the first character of the displayed value
use left and right to move cursor
use up and down to change characters
press ok to accept changes, write them to eeprom or runtime variable and
leave edit mode
or press cancel to leave edit mode and discard changes
2. Sane as 1 but for an array variable, for example to setup 100 ports from
menu PORT
after setting the value, this value is not written to eeprom or runtime
variable,
but instead a submenu is entered with the value as index for the array
Possible way to distinguish from 1 by displaying index [noparse]/noparse after menu
name
Any better suggestion is welcome.
3. The bottom line just displays the item name
press ok to enter a new submenu
top line will display new menu name
bottom line will display first item of new menu.
The right side of the bottom line displays (part) of the assigned value.
If the assigned value does not fit entirely on the display it will scroll
to the left or right during edit without overwriting the item name.
I like the simplified system! We have to keep the primary goal in
mind. That is, the user interface should not be more complex than the
purpose of the system! (I just made that up.)
"Cancel" should display somethink like this:
Cancel what?
Value Line Menu Exit
"Value" restores displayed value to what it was when the item was
first displayed.
"Line" skips the current menu item and goes onto the next one.
"Menu" skips out of the current menue section and goes to the next
section.
"Exit" gets out of the entire menu system to where the system was
vefore presing "OK" in the first place.
What do you mean by "navigation"?
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> I am still not satisfied with the current setup. Too many full
screens and
> multiple
> options on a screen do not improve navigation. So I reconsidered, moving
> towards
> the setup Jon described in his article (see few posts back), with a few
> modifications
> to allow more input including text.
>
> Assume 2 line display and 6 navigation keys.
> Top line holds menu name + optionally status info.
> Bottom line holds item name (submenu or parameter) + optionally its
assigned
> value
> keys: up, down, left, right, ok, cancel
> When not in menu mode, press ok to enter menu mode.
> Topline will display "Main Menu" (or whatever you want)
> Bottom line will display first item of main menu.
> Use up and down keys to cycle through menu items.
> press cancel to leave current menu (i.e menu up)
> Several possibilities depending on the currently displayed item:
> 1. The bottom line will display the item name + assigned value
> Use left and right keys to cycle through available enumerated
values or
> decrease/increase value
> press ok to enter edit mode
> A cursor will be placed under the first character of the
displayed value
> use left and right to move cursor
> use up and down to change characters
> press ok to accept changes, write them to eeprom or runtime
variable and
> leave edit mode
> or press cancel to leave edit mode and discard changes
> 2. Sane as 1 but for an array variable, for example to setup 100
ports from
> menu PORT
> after setting the value, this value is not written to eeprom or
runtime
> variable,
> but instead a submenu is entered with the value as index for the
array
> Possible way to distinguish from 1 by displaying index [noparse]/noparse after menu
> name
> Any better suggestion is welcome.
> 3. The bottom line just displays the item name
> press ok to enter a new submenu
> top line will display new menu name
> bottom line will display first item of new menu.
>
> The right side of the bottom line displays (part) of the assigned value.
> If the assigned value does not fit entirely on the display it will
scroll
> to the left or right during edit without overwriting the item name.
>
> How about this navigation setup?
>
> regards peter
Navigation is my english translation of the dutch word 'navigatie' which
means in this case
"how to browse the menus". Since you asked, I guess it is not an existing
english word.
What would be the correct word?
Cancel is an implied function, canceling the current state (and return to
previous state),
be it editing or browsing a menu (is that correct english?).
Your suggestions:
Value: pressing cancel while entering a value (edit mode) will restore the
original value.
Line: is accomplished with up and down keys when not in edit mode
Menu: is accomplished by pressing cancel when not in edit mode.
Exit: press cancel repeatedly when not in edit mode. Pressing cancel when in
main menu
will leave menu mode. I think this is less annoying than to select an option
each time cancel is pressed.
regards peter
an englisg term to
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, March 04, 2004 3:52 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> I like the simplified system! We have to keep the primary goal in
> mind. That is, the user interface should not be more complex than the
> purpose of the system! (I just made that up.)
>
> "Cancel" should display somethink like this:
>
> Cancel what?
> Value Line Menu Exit
>
> "Value" restores displayed value to what it was when the item was
> first displayed.
>
> "Line" skips the current menu item and goes onto the next one.
>
> "Menu" skips out of the current menue section and goes to the next
> section.
>
> "Exit" gets out of the entire menu system to where the system was
> vefore presing "OK" in the first place.
>
> What do you mean by "navigation"?
>
> Russ
>
>
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > I am still not satisfied with the current setup. Too many full
> screens and
> > multiple
> > options on a screen do not improve navigation. So I reconsidered, moving
> > towards
> > the setup Jon described in his article (see few posts back), with a few
> > modifications
> > to allow more input including text.
> >
> > Assume 2 line display and 6 navigation keys.
> > Top line holds menu name + optionally status info.
> > Bottom line holds item name (submenu or parameter) + optionally its
> assigned
> > value
> > keys: up, down, left, right, ok, cancel
> > When not in menu mode, press ok to enter menu mode.
> > Topline will display "Main Menu" (or whatever you want)
> > Bottom line will display first item of main menu.
> > Use up and down keys to cycle through menu items.
> > press cancel to leave current menu (i.e menu up)
> > Several possibilities depending on the currently displayed item:
> > 1. The bottom line will display the item name + assigned value
> > Use left and right keys to cycle through available enumerated
> values or
> > decrease/increase value
> > press ok to enter edit mode
> > A cursor will be placed under the first character of the
> displayed value
> > use left and right to move cursor
> > use up and down to change characters
> > press ok to accept changes, write them to eeprom or runtime
> variable and
> > leave edit mode
> > or press cancel to leave edit mode and discard changes
> > 2. Sane as 1 but for an array variable, for example to setup 100
> ports from
> > menu PORT
> > after setting the value, this value is not written to eeprom or
> runtime
> > variable,
> > but instead a submenu is entered with the value as index for the
> array
> > Possible way to distinguish from 1 by displaying index [noparse]/noparse after menu
> > name
> > Any better suggestion is welcome.
> > 3. The bottom line just displays the item name
> > press ok to enter a new submenu
> > top line will display new menu name
> > bottom line will display first item of new menu.
> >
> > The right side of the bottom line displays (part) of the assigned value.
> > If the assigned value does not fit entirely on the display it will
> scroll
> > to the left or right during edit without overwriting the item name.
> >
> > How about this navigation setup?
> >
> > regards peter
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
> Yahoo! Groups Links
>
>
>
>
>
You are using correct English. You can use the word
navigate to "mean browse the menus." More correctly,
you could say navigate the menus. Navigation is the
act of navigating or to navigate, have I confused you
yet? Either way works. I knew wht you meant in your
original post.
I worked the last four years, until I got laid off,
as a system integrator for the water/wastewater
industry, but this also applies to industrial controls
in general, and we had to program HMI's (Human Machine
Interface) to show graphics/text mixed and OIT's
(Operator Interface Terminals) to show text only to
display whatever data was required by the customer.
Obviously, we had to set up menus for each screen for
navigation among the various screens, sometimes these
screens were touch screens or they had function keys
that were programmable. If it was touchscreen then we
just set up the buttons on the screen and they were
identified as to their function. In the case of the
function keys under the screen, the last line of text
immediately above the function keys showed what each
key was supposed to do.
I did not do much programming of these devices but it
seems to me that we just put into the code what
screens each button represented. Very similar to the
navigation buttons and hyperlinks on web pages.
This whole thread had gotten me thinking of how I
would go about doing this on a BSII, 4X20 LCD module
and some pushbuttons. I am getting excited about
experimenting with this and see if I can come up with
something workable. Since I don't have external
EEPROMS this could be a challenge, although isn't that
what we technical people like to do? See how much we
can squeeze into a given microcontroller. After all,
NASA launched spaceships and men into outerspace with
as much or less power...smile.
I don't know if I helped or not, but I thought I would
at least interject my 2 cents worth and also tell you
that your English is correct.
So have a great day!!
James E. Merritt
--- Peter Verkaik <peterverkaik@b...> wrote:
> Russ,
>
> Navigation is my english translation of the dutch
> word 'navigatie' which
> means in this case
> "how to browse the menus". Since you asked, I guess
> it is not an existing
> english word.
> What would be the correct word?
>
> Cancel is an implied function, canceling the current
> state (and return to
> previous state),
> be it editing or browsing a menu (is that correct
> english?).
>
> Your suggestions:
>
> Value: pressing cancel while entering a value (edit
> mode) will restore the
> original value.
> Line: is accomplished with up and down keys when
> not in edit mode
> Menu: is accomplished by pressing cancel when not in
> edit mode.
>
> Exit: press cancel repeatedly when not in edit mode.
> Pressing cancel when in
> main menu
> will leave menu mode. I think this is less annoying
> than to select an option
> each time cancel is pressed.
>
> regards peter
>
__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com
No, your English is quite good. I didn't know if you meant User
navigation of the menus or how the software would move about through
the EEPROM data.
Your implied functioning of the Cancel signal should be okay. Actual
implementation will tell.
I will think about this a bit more and get back to you later.
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> Navigation is my english translation of the dutch word 'navigatie' which
> means in this case
> "how to browse the menus". Since you asked, I guess it is not an
existing
> english word.
> What would be the correct word?
>
> Cancel is an implied function, canceling the current state (and
return to
> previous state),
> be it editing or browsing a menu (is that correct english?).
>
> Your suggestions:
>
> Value: pressing cancel while entering a value (edit mode) will
restore the
> original value.
> Line: is accomplished with up and down keys when not in edit mode
> Menu: is accomplished by pressing cancel when not in edit mode.
>
> Exit: press cancel repeatedly when not in edit mode. Pressing cancel
when in
> main menu
> will leave menu mode. I think this is less annoying than to select
an option
> each time cancel is pressed.
>
> regards peter
>
After rereading your last post, I realized that I had mis-read your
closing question. You sain, "How about this navigation setup?" I
mis-read "this" as "the", so thought it might refer to the program's
moving about in EEPROM! (I am visually impaired.)
Okay. The keys: UP, DOWN, LEFT/-, RIGHT/+, OK, CANCEL
(I prefer the dual labeling where appropriate.)
1. Top line displays a MAIN MENU item.
1.a Second line is blank, or available for continuation of first
line. UP/DOWN take you to previous/next MAIN MENU entry.
CANCEL exits the MENU. (What does OK do?)
1.b Pressing RIGHT/+ takes you to the first SUB MENU for
MAIN MENU. The SUB MENU is displayed on line 1.
UP/DOWN take to to previous/next SUB MENU.
1.c If this SUB MENU has choices/values, etc, they are displayed on
line 2.
1.d LEFT/-, RIGHT/+ will move between choices, or decrement/increment
a VALUE. Pressing OK will store the choice/value and move to the
next SUB MENU, if any, else back to the corresponding MAIN MENU.
(What heppens if you have selected/modified, and press UP or
DOWN?)
2. The MENU ARRAY concept is interesting. Once in a particular ARRAY
line, it works as above, except that OK takes you back to the
SUB MENU where you chose the ARRAY line.
3. Agreed. Simple is good. Have to provide for display of values
which contain decimals (51.3, for example). An alternative
would be to allow a LABEL on the second line, always
left-justified, and always right-justify the value.
[noparse][[/noparse]DC AMPS////////-23.4] (/ is a space)
Two modes are available while in menu mode.
BROWSE and EDIT. While in EDIT mode the word
EDIT is displayed on the right side of line 1.
EDIT: this lets you enter a value directly.
LEFT/- and RIGHT/+ move the cursor left/right, scrolling the entered value
left/right
if necessary.
UP and DOWN cycle through the available characters for the current cursor
position.
CANCEL leaves EDIT mode discarding changes.
OK leaves EDIT mode accepting changes.
Leaving EDIT mode means returning to BROWSE mode.
BROWSE: this lets you navigate the menus
UP and DOWN cycle through the items of the currently active menu which
name
is displayed on line1. The available items are displayed on the left side
of line 2 and
their assigned value on the right side of line 2. The name of the item may
have an
index number to its right for array variables.
example: (/ is space)
MenuName////////EDIT
ItemName/003/-327.68
If item is a submenu there is no itemvalue (-327.68)
If item refers to a single variable there is no indexvalue (003)
When not in EDIT mode there is no word EDIT.
Line 2 gets updated each time you press UP or DOWN.
CANCEL moves to the parent menu of the currrent menu, or leaves menu mode
in case current menu is main menu.
Now to the use of LEFT, RIGHT and OK.
There are four possible layouts for line 2.
1. No index and no itemvalue.
Item is a submenu.
LEFT/- and RIGHT/+ do nothing.
OK moves to the submenu.
2. Indexvalue, but no itemvalue.
Item is a submenu for an array type variable.
LEFT/- and RIGHT/+ decrease/increase the indexvalue.
OK enters EDIT mode. See above. Press OK twice to accept the value set
by - and +.
If new indexvalue is accepted move to the submenu, else restore line 2
to original state.
3. Itemvalue, but no indexvalue.
Item is a single variable.
LEFT/- and RIGHT/+ decrease/increase the itemvalue.
OK enters EDIT mode. See above. Press OK twice to accept the value set
by - and +.
If new itemvalue is accepted write it to eeprom/ram, else restore line 2
to original state.
4. Indexvalue and itemvalue.
Item is an array type variable.
LEFT/- and RIGHT/+ decrease/increase the indexvalue.
OK enters EDIT mode. See above. Press OK twice to accepts the value set
by - and +.
If new indexvalue is accepted move cursor to itemvalue, else restore
line 2 to original state..
LEFT/- and RIGHT/+ decrease/increase the itemvalue.
OK enters EDIT mode. See above. Press OK twice to accept the value set
by - and +.
If new itemvalue accepted write it to eeprom/ram, else restore line 2 to
original state
To summarize for BROWSE mode:
UP and DOWN cycle the menu items
LEFT/- and RIGHT/+ decrease/increase a value
CANCEL moves to parent menu
OK accepts value or enters submenu
I think this is the most consistent use for the keys.
regards peter.
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, March 04, 2004 8:02 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> After rereading your last post, I realized that I had mis-read your
> closing question. You sain, "How about this navigation setup?" I
> mis-read "this" as "the", so thought it might refer to the program's
> moving about in EEPROM! (I am visually impaired.)
>
> Okay. The keys: UP, DOWN, LEFT/-, RIGHT/+, OK, CANCEL
>
> (I prefer the dual labeling where appropriate.)
>
> 1. Top line displays a MAIN MENU item.
>
> 1.a Second line is blank, or available for continuation of first
> line. UP/DOWN take you to previous/next MAIN MENU entry.
> CANCEL exits the MENU. (What does OK do?)
>
> 1.b Pressing RIGHT/+ takes you to the first SUB MENU for
> MAIN MENU. The SUB MENU is displayed on line 1.
> UP/DOWN take to to previous/next SUB MENU.
>
> 1.c If this SUB MENU has choices/values, etc, they are displayed on
> line 2.
>
> 1.d LEFT/-, RIGHT/+ will move between choices, or decrement/increment
> a VALUE. Pressing OK will store the choice/value and move to the
> next SUB MENU, if any, else back to the corresponding MAIN MENU.
> (What heppens if you have selected/modified, and press UP or
> DOWN?)
>
> 2. The MENU ARRAY concept is interesting. Once in a particular ARRAY
> line, it works as above, except that OK takes you back to the
> SUB MENU where you chose the ARRAY line.
>
> 3. Agreed. Simple is good. Have to provide for display of values
> which contain decimals (51.3, for example). An alternative
> would be to allow a LABEL on the second line, always
> left-justified, and always right-justify the value.
> [noparse][[/noparse]DC AMPS////////-23.4] (/ is a space)
>
> Russ
There are few rights and wrongs in this business. Your scheme will
work. The main concern is whether you can accomplish your purpose in
a manner that you understand. If this criterion is met, all is well.
It's looking good!
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> Two modes are available while in menu mode.
> BROWSE and EDIT. While in EDIT mode the word
> EDIT is displayed on the right side of line 1.
>
> EDIT: this lets you enter a value directly.
> LEFT/- and RIGHT/+ move the cursor left/right, scrolling the
entered value
> left/right
> if necessary.
> UP and DOWN cycle through the available characters for the current
cursor
> position.
> CANCEL leaves EDIT mode discarding changes.
> OK leaves EDIT mode accepting changes.
> Leaving EDIT mode means returning to BROWSE mode.
>
> BROWSE: this lets you navigate the menus
> UP and DOWN cycle through the items of the currently active menu which
> name
> is displayed on line1. The available items are displayed on the
left side
> of line 2 and
> their assigned value on the right side of line 2. The name of the
item may
> have an
> index number to its right for array variables.
> example: (/ is space)
> MenuName////////EDIT
> ItemName/003/-327.68
> If item is a submenu there is no itemvalue (-327.68)
> If item refers to a single variable there is no indexvalue (003)
> When not in EDIT mode there is no word EDIT.
> Line 2 gets updated each time you press UP or DOWN.
> CANCEL moves to the parent menu of the currrent menu, or leaves
menu mode
> in case current menu is main menu.
> Now to the use of LEFT, RIGHT and OK.
> There are four possible layouts for line 2.
> 1. No index and no itemvalue.
> Item is a submenu.
> LEFT/- and RIGHT/+ do nothing.
> OK moves to the submenu.
> 2. Indexvalue, but no itemvalue.
> Item is a submenu for an array type variable.
> LEFT/- and RIGHT/+ decrease/increase the indexvalue.
> OK enters EDIT mode. See above. Press OK twice to accept the
value set
> by - and +.
> If new indexvalue is accepted move to the submenu, else restore
line 2
> to original state.
> 3. Itemvalue, but no indexvalue.
> Item is a single variable.
> LEFT/- and RIGHT/+ decrease/increase the itemvalue.
> OK enters EDIT mode. See above. Press OK twice to accept the
value set
> by - and +.
> If new itemvalue is accepted write it to eeprom/ram, else
restore line 2
> to original state.
> 4. Indexvalue and itemvalue.
> Item is an array type variable.
> LEFT/- and RIGHT/+ decrease/increase the indexvalue.
> OK enters EDIT mode. See above. Press OK twice to accepts the
value set
> by - and +.
> If new indexvalue is accepted move cursor to itemvalue, else restore
> line 2 to original state..
> LEFT/- and RIGHT/+ decrease/increase the itemvalue.
> OK enters EDIT mode. See above. Press OK twice to accept the
value set
> by - and +.
> If new itemvalue accepted write it to eeprom/ram, else restore
line 2 to
> original state
>
> To summarize for BROWSE mode:
> UP and DOWN cycle the menu items
> LEFT/- and RIGHT/+ decrease/increase a value
> CANCEL moves to parent menu
> OK accepts value or enters submenu
>
> I think this is the most consistent use for the keys.
>
> regards peter.
Now that the key use has changed I had to revise my tables. The new tables are
suddenly so much
simpler. Use the courier new font to display with correct spacing.
'Menu tree data
'There are 4 menu levels.
'Each menu has a name and up to 15 items
'Within each menu:
' prev of menuname points to menuname of previous menu (one level up), 0 if
main menu.
' prev of item1 points to last item, prev of item2 points to item1 etc
' next of menuname is 0
' next of last item points to item1, next of item1 points to item2 etc.
' attr of menuname is highest available index for that submenu (0 for main menu
and submenu without index)
' attr of each item depends on the item type
' item is submenu, then attr is 0 (0 is not a ParameterBlock address)
' item is persistent variable, then attr is pointer to ParameterBlock
' item is command, then attr is commandIndex+$8000 (this limits eepromsize to
32KB)
'
'
'label naming convention for data statements
'MWXYZ where W = 0-F main level
' X = 0-F sub1 level
' Y = 0-F SUB2 level
' Z = 0-F SUB3 level
'MWXYZ prev next attr menu- and itemnames
for lcd
M0 DATA WORD 0 , WORD 0 , WORD 0 , "MAIN "
M1 DATA WORD M2 , WORD M2 , WORD 0 , "ITEM1 "
M10 DATA WORD 0 , WORD 0 , WORD 0 , "SUB1 "
M11 DATA WORD M12 , WORD M12 , WORD 0 , "ITEM11 "
M110 DATA WORD 0 , WORD 0 , WORD 0 , "SUB11 "
M111 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM111 "
M1110 DATA WORD 0 , WORD 0 , WORD 0 , "SUB111 "
M1111 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1111 "
M1112 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1112 "
M1113 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1113 "
M112 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM112 "
M1120 DATA WORD 0 , WORD 0 , WORD 0 , "SUB112 "
M1121 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1121 "
M1122 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1122 "
M1123 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1123 "
M12 DATA WORD M11 , WORD M11 , WORD 0 , "ITEM12 "
M120 DATA WORD 0 , WORD 0 , WORD 0 , "SUB12 "
M121 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM121 "
M1210 DATA WORD 0 , WORD 0 , WORD 0 , "SUB121 "
M1211 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1211 "
M1212 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1212 "
M1213 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1213 "
M122 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM122 "
M1220 DATA WORD 0 , WORD 0 , WORD 0 , "SUB122 "
M1221 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1221 "
M1222 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1222 "
M1223 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1223 "
M2 DATA WORD M1 , WORD M1 , WORD 0 , "ITEM2 "
M20 DATA WORD 0 , WORD 0 , WORD 0 , "SUB2 "
M21 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM21 "
M210 DATA WORD 0 , WORD 0 , WORD 0 , "SUB21 "
M211 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM211 "
M2110 DATA WORD 0 , WORD 0 , WORD 0 , "SUB211 "
M2111 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2111 "
M2112 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2112 "
M2113 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2113 "
M212 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM212 "
M2120 DATA WORD 0 , WORD 0 , WORD 0 , "SUB212 "
M2121 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2121 "
M2122 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2122 "
M2123 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2123 "
M22 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM22 "
M220 DATA WORD 0 , WORD 0 , WORD 0 , "SUB22 "
M221 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM221 "
M2210 DATA WORD 0 , WORD 0 , WORD 0 , "SUB221 "
M2211 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2211 "
M2212 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2212 "
M2213 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2213 "
M222 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM222 "
M2220 DATA WORD 0 , WORD 0 , WORD 0 , "SUB222 "
M2221 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2221 "
M2222 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2222 "
M2223 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2223 "
'[noparse][[/noparse]ParameterBlock]
'ADDRESS DATA WORD 0 'address
'FIELDSIZE DATA WORD 0 'fieldsize
'REORDSIZE DATA WORD 0 'recordsize
'ATTRIBUTE DATA WORD TYPE*4096+1 'b15-b12=type, b11-b0=record
entries
'A record has 1 or more fields.
'Multiple identical records denote an array record, the fields are then array
variables.
'If a record has more than 1 field, the fields must be accessed via a submenu,
where each
'item is one of the fields. A field can be another record having more than 1
field. Another
'submenu is needed to access those fields.
'Parameter Types
DATA_ENUM CON 0 'enumerated, set by option select
DATA_BIT CON 1 'bit storage
DATA_BYTE CON 2 'byte storage, HEX input
DATA_WORD CON 3 'word storage, HEX input
DATA_DEC CON 4 'ascii storahe, key input values '0' to '9' plus
'-'
DATA_FLOAT CON 5 'ascii storahe, key input values '0' to '9' plus
'-' plus '.'
DATA_HEX CON 6 'ascii storage, key input values '0' to '9' plus
'A' to 'F'
DATA_TEXT CON 7 'ascii storage, key input values ascii 32 to
ascii 126
DATA_READONLY CON 8 'OR with other data type to define parameter
read-only
MENU_END DATA 0
How about this table setup? It looks they are perfect to be auto-generated.
Do you have a special tool to generate such tables? (using a script language?)
I did not completely fill in the table but hope the idea is clear.
The double linked lists allow for item select with up and down key easily.
I indented the menu tree for better optical view.
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Friday, March 05, 2004 2:33 AM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> There are few rights and wrongs in this business. Your scheme will
> work. The main concern is whether you can accomplish your purpose in
> a manner that you understand. If this criterion is met, all is well.
>
> It's looking good!
>
> Russ
[noparse][[/noparse]Non-text portions of this message have been removed]
It looks great! It probably covers everything you want to do with it.
I don't have a tool to do the parsing and table generation. However,
it should be fairly simple to write a parser to handle it. I think it
could be done on a Javelin! Just have to feed the data in via a
serial port. Parse each input line and keep information in tables.
Stuff could be written to the EEPROM as needed, then make another pass
(if necessary) to fill in unknowns (forward links). It shouldn't take
more than 2-3k of RAM for the program code. (Wild guess.)
Comments
ParameterType 0 is Enumerated (was reserved)
The parser keeps track of the option index which is used as the enumerated
value.
For example if option 4 is selected, the enumerated value 4 is written to
the
persistent variable. The application then is able to select a correct value
from
a table in the application code, for example a baudrate, which has different
values for BS2, BS2SX etc. (although this table could be in the eeprom also)
regards peter
Looks like a good start, albeit more xomplex that I was envisioning,
but doable.
If you are ging to keep parameters in EEPROM, their addresses must be
made available to the program. There could also be "working
variables" which are in RAM but not retained in EEPROM. I'm thinking
of a display mode where one wishes to page through a list of current
conditons (temperature, current, pressure, etc.), possibly modifying
some values (reducing current high-temperature).
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Consider this:
>
> 4x20 LCD
> LINE1: menu name or parameter name (10 chars), right side for custom
use (status?)
> LINE2: option1
> LINE3: option2
> LINE4: option3 (blank if not available)
>
> KEYS:6
> X
> 1/U
> X X X X
> cancel 2/L More/R ok
> X
> 3/D
>
> The menutables consist of ParameterBlocks and MenuBlocks
>
> [noparse][[/noparse]ParameterBlock]
> NAME DATA "Parm Name " 'name (10 bytes)
> ADDR DATA WORD 0 'address (2 bytes)
> FIELD DATA 0 'fieldsize (1 byte)
> REORD DATA 0 'recordsize (1 byte)
> ATTR DATA WORD TYPE*4096+1 'b15-b12=type, b11-b0=record
entries (2 bytes)
>
> The parameter block holds name and address of the parameter.
> The parameter name is to be printed on line1 of the lcd.
> The field size is the storage size for this parameter.
> The recordsize is the storage size of the record the parameter is
part of.
> fieldsize=recordsize in case parameter is total record.
> field and record allow address calculation for array based variables
> TYPE is one of the following
> 00 = RESERVED
> 01 = BIT (BINAIR)
> 02 = BYTE (BINAIR)
> 03 = WORD (BINAIR)
> 04 = DEC (ASCII)
> 05 = FLOAT (ASCII)
> 06 = HEX (ASCII)
> 07 = TEXT (ASCII)
> TYPE determines which characters are valid when entering a new value
for a parameter.
>
> [noparse][[/noparse]MenuBlock]
> NAME DATA "Menu Name " 'name (10 bytes)
> PREV DATA WORD PrevMenu 'previous menu (key OK or key CANCEL)
> OPTION1 DATA "menu option 1 " '20 bytes
> OPTION2 DATA "menu option 2 "
> OPTION3 DATA "menu option 3 "
> KEY1 DATA WORD OPT1+TYPE 'MenuBlock or ParameterBlock
or Command
> KEY2 DATA WORD OPY2+TYPE
> KEY3 DATA WORD OPT3+TYPE
> KEYMORE DATA WORD OPTION4
> OPTION4 DATA "menu option 4 " 'second screen with options
> OPTION5 DATA "menu option 5 "
> OPTION6 DATA " "
> KEY1 DATA WORD OPT4+TYPE
> KEY2 DATA WORD OPT5+TYPE
> KEY3 DATA WORD 0
> KEYNORE DATA WORD OPTION1
>
> The menu name is printed on the first line of the lcd.
> PREV points to the previous menublock (0 if main menu)
> OPTION1, OPTION2, OPTION3 are printed on lines 2,3,4 of lcd
> KEY1, KEY2, KEY3 hold next menublock or a parameterblock (0 if no
option)
> KEYMORE points to next options so only lines 2,3,4 of lcd need update
> If there are 3 or less options in total, KEYMORE should be 0.
> If there are more than 3 options, KEYMORE points to the next 3 options
> and KEYMORE for the last 3 options points to the first 3 options to
allow
> cycling through options.
> When the ok key is pressed, a parameter may be updated in eeprom, when
> cancel is pressed changes must be discarded.
> TYPE identifies the type of addresses.
> $0000 identifies options (so parser knows it must print 3 lines)
> $4000 identifies a command (use BRANCH to execute a command)
> $8000 identifies a menublock
> $C000 identifies a parameterblock
> The use of TYPE limits usable eeprom space for menus to 16KB
> but that should not be a real limit.
> When specifying a command, the supplied 'address' is an integervalue
> not an eeprom address.
>
> Since all options at the same menu level are within a single menublock,
> menublocks can be indented to create an optical view of the menu tree.
> This should enhance the readability and allow for easier maintaince.
>
> [noparse][[/noparse]MenuStart]
> MAIN DATA WORD MainMenu 'menublock for main menu
>
> This scheme should be easy to traverse.
>
> Any comments on this please.
>
> regards peter
tions of this message have been removed]
i live in richmond hill. have been to xtreme hobbies a
few times. good guys. xtreme is mostly rc cars and stuff
and a cool indoor dirt track.
http://www.roguerobotics.com/ has their retail shop
through xtreme. erik (runs rogue) is in the process of
setting up rogue/parallax stock there.
they have assorted things like stamps, boe, and various
kits and books.
hey, if you start some kind of canadian stamps club, count
me in.
cheers,
mike
--- In basicstamps@yahoogroups.com, "russranshaw" <home.rr@c...>
wrote:
> Barrie? It's a small world. My wife's daughter lives there!
>
> Does "Extreme Hobbies" carry electronic parts? Maybe DB-9 Male and
> Female PCB connectors?
>
> Russ
>
>
> --- In basicstamps@yahoogroups.com, "SB" <steve.brady@r...> wrote:
> > Hey, I grew up in Fort Erie....went out west and have made it back
> and am I
> > Barrie.
> >
> > Incidentally, there is an "Extreme Hobbies" place in Richmond
> Hill/Vaughn
> > that use stamps for combat bots....that's were I picked up my
> bs2p40....for
> > interests sake anyhow...
> >
> >
Original Message
> > From: "russranshaw" <home.rr@c...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Monday, March 01, 2004 1:00 PM
> > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > Dan,
> > >
> > > I'm in Port Colborne, ON!
> > >
> > > Russ
> > >
> > > --- In basicstamps@yahoogroups.com, "Dan Angiu" <dan.angiu@n...>
> wrote:
> > > > Russ,
> > > > If I hear something I'll let you know. I thought it was
somebody
> on the
> > > > list but probablly I'm wrong.
> > > > I'm in Woodbridge, Ontario.
> > > >
> > > > Jon W. thanks for the link.
> > > >
> > > > Dan
> > > >
> > > >
Original Message
> > > > From: russranshaw [noparse][[/noparse]mailto:home.rr@c...]
> > > > Sent: February 29, 2004 4:44 PM
> > > > To: basicstamps@yahoogroups.com
> > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > Dan,
> > > >
> > > > My name is Russ, and I live in Canada. I hadn't heard ot the
Basic
> > > > Stamp Club up here, so if you find any information, please CC
it
> to me,
> > > > and I'll do likewise!
> > > >
> > > > Russ
> > >
> > >
> > >
> > > To UNSUBSCRIBE, just send mail to:
> > > basicstamps-unsubscribe@yahoogroups.com
> > > from the same email address that you subscribed. Text in the
> Subject and
> > Body of the message will be ignored.
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
Setting/changing runtime variables should be done via commands.
For the javelin the address of a runtime variable cannot be fixed. Use a
switch()
to execute a command, like increase high_temperature. For pbasic you can
locate runtime variables on a fixed address but I would not recommend that.
Let the application code deal with the runtime variables, the menu in eeprom
will supply the userfriendly text.
Part of the application code are the read routines that read user-entered
values.
These are the same routines the parser will use to read user-entered values
for the persistent variables.
The addresses of the persistent variables are public otherwise the
application program
cannot read them. Also the address where the start address of the menutables
is stored
is public (this is just an other persistent variable).
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, March 03, 2004 6:52 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> Looks like a good start, albeit more xomplex that I was envisioning,
> but doable.
>
> If you are ging to keep parameters in EEPROM, their addresses must be
> made available to the program. There could also be "working
> variables" which are in RAM but not retained in EEPROM. I'm thinking
> of a display mode where one wishes to page through a list of current
> conditons (temperature, current, pressure, etc.), possibly modifying
> some values (reducing current high-temperature).
>
> Russ
>
The applicztion program has to have some knowledge about what th emenu
does. The application classes would use methods to get/set the
various variables, whereever they are stored. All of this would be
genrated by the translation software and put into a separate. If
these variables were actually in arrays, then the array indicies could
be stored in the EEPROM table and accessed driectly by the menu class
as needed by direct array reference, or a special method.
A mechanism for doing this in PBASIC is an exercise left for the
student. [noparse]:)[/noparse]
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> Setting/changing runtime variables should be done via commands.
> For the javelin the address of a runtime variable cannot be fixed. Use a
> switch()
> to execute a command, like increase high_temperature. For pbasic you can
> locate runtime variables on a fixed address but I would not
recommend that.
> Let the application code deal with the runtime variables, the menu
in eeprom
> will supply the userfriendly text.
> Part of the application code are the read routines that read
user-entered
> values.
> These are the same routines the parser will use to read user-entered
values
> for the persistent variables.
>
> The addresses of the persistent variables are public otherwise the
> application program
> cannot read them. Also the address where the start address of the
menutables
> is stored
> is public (this is just an other persistent variable).
>
> regards peter
>
>
Original Message
> From: "russranshaw" <home.rr@c...>
> To: <basicstamps@yahoogroups.com>
> Sent: Wednesday, March 03, 2004 6:52 PM
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > Peter,
> >
> > Looks like a good start, albeit more xomplex that I was envisioning,
> > but doable.
> >
> > If you are ging to keep parameters in EEPROM, their addresses must be
> > made available to the program. There could also be "working
> > variables" which are in RAM but not retained in EEPROM. I'm thinking
> > of a display mode where one wishes to page through a list of current
> > conditons (temperature, current, pressure, etc.), possibly modifying
> > some values (reducing current high-temperature).
> >
> > Russ
> >
Sorry, I don;t understand your point.
Imagine you navigate through the menu. At some point
you come to the screen with option 'increase high temp'.
Suppose it is option 2. Pressing the key2 selects this option.
The parser reads the word from eeprom for that key for that
specific screen. If that word equals OPT+$4000 (see layout)
then the parser knows that OPT is a command.
The parser then calls the execute_command subroutine with
the value OPT.
For pbasic:
EXEC_CMD:
BRANCH OPT,[noparse][[/noparse]CMD0,CMD1,CMD2]
ERROR: 'error handling here
CMD0: HIGH_TEMP = HIGH_TEMP-1 'decrease high temp
RETURN
CMD1: HIGH_TEMP = HIGH_TEMP+1 'increase high temp
RETURN
CMD2: 'some other function
RETURN
For the javelin you use switch() instead of BRANCH.
So it is not necessary for the application to know whatever state the menu
is in,
it just performs a function based on an integer value. Obviously the list of
commands
must match the menu screens with respect to the stored integervalue.
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, March 03, 2004 9:01 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> The applicztion program has to have some knowledge about what th emenu
> does. The application classes would use methods to get/set the
> various variables, whereever they are stored. All of this would be
> genrated by the translation software and put into a separate. If
> these variables were actually in arrays, then the array indicies could
> be stored in the EEPROM table and accessed driectly by the menu class
> as needed by direct array reference, or a special method.
>
> A mechanism for doing this in PBASIC is an exercise left for the
> student. [noparse]:)[/noparse]
>
> Russ
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > Russ,
> >
> > Setting/changing runtime variables should be done via commands.
> > For the javelin the address of a runtime variable cannot be fixed. Use a
> > switch()
> > to execute a command, like increase high_temperature. For pbasic you can
> > locate runtime variables on a fixed address but I would not
> recommend that.
> > Let the application code deal with the runtime variables, the menu
> in eeprom
> > will supply the userfriendly text.
> > Part of the application code are the read routines that read
> user-entered
> > values.
> > These are the same routines the parser will use to read user-entered
> values
> > for the persistent variables.
> >
> > The addresses of the persistent variables are public otherwise the
> > application program
> > cannot read them. Also the address where the start address of the
> menutables
> > is stored
> > is public (this is just an other persistent variable).
> >
> > regards peter
multiple
options on a screen do not improve navigation. So I reconsidered, moving
towards
the setup Jon described in his article (see few posts back), with a few
modifications
to allow more input including text.
Assume 2 line display and 6 navigation keys.
Top line holds menu name + optionally status info.
Bottom line holds item name (submenu or parameter) + optionally its assigned
value
keys: up, down, left, right, ok, cancel
When not in menu mode, press ok to enter menu mode.
Topline will display "Main Menu" (or whatever you want)
Bottom line will display first item of main menu.
Use up and down keys to cycle through menu items.
press cancel to leave current menu (i.e menu up)
Several possibilities depending on the currently displayed item:
1. The bottom line will display the item name + assigned value
Use left and right keys to cycle through available enumerated values or
decrease/increase value
press ok to enter edit mode
A cursor will be placed under the first character of the displayed value
use left and right to move cursor
use up and down to change characters
press ok to accept changes, write them to eeprom or runtime variable and
leave edit mode
or press cancel to leave edit mode and discard changes
2. Sane as 1 but for an array variable, for example to setup 100 ports from
menu PORT
after setting the value, this value is not written to eeprom or runtime
variable,
but instead a submenu is entered with the value as index for the array
Possible way to distinguish from 1 by displaying index [noparse]/noparse after menu
name
Any better suggestion is welcome.
3. The bottom line just displays the item name
press ok to enter a new submenu
top line will display new menu name
bottom line will display first item of new menu.
The right side of the bottom line displays (part) of the assigned value.
If the assigned value does not fit entirely on the display it will scroll
to the left or right during edit without overwriting the item name.
How about this navigation setup?
regards peter
I like the simplified system! We have to keep the primary goal in
mind. That is, the user interface should not be more complex than the
purpose of the system! (I just made that up.)
"Cancel" should display somethink like this:
Cancel what?
Value Line Menu Exit
"Value" restores displayed value to what it was when the item was
first displayed.
"Line" skips the current menu item and goes onto the next one.
"Menu" skips out of the current menue section and goes to the next
section.
"Exit" gets out of the entire menu system to where the system was
vefore presing "OK" in the first place.
What do you mean by "navigation"?
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> I am still not satisfied with the current setup. Too many full
screens and
> multiple
> options on a screen do not improve navigation. So I reconsidered, moving
> towards
> the setup Jon described in his article (see few posts back), with a few
> modifications
> to allow more input including text.
>
> Assume 2 line display and 6 navigation keys.
> Top line holds menu name + optionally status info.
> Bottom line holds item name (submenu or parameter) + optionally its
assigned
> value
> keys: up, down, left, right, ok, cancel
> When not in menu mode, press ok to enter menu mode.
> Topline will display "Main Menu" (or whatever you want)
> Bottom line will display first item of main menu.
> Use up and down keys to cycle through menu items.
> press cancel to leave current menu (i.e menu up)
> Several possibilities depending on the currently displayed item:
> 1. The bottom line will display the item name + assigned value
> Use left and right keys to cycle through available enumerated
values or
> decrease/increase value
> press ok to enter edit mode
> A cursor will be placed under the first character of the
displayed value
> use left and right to move cursor
> use up and down to change characters
> press ok to accept changes, write them to eeprom or runtime
variable and
> leave edit mode
> or press cancel to leave edit mode and discard changes
> 2. Sane as 1 but for an array variable, for example to setup 100
ports from
> menu PORT
> after setting the value, this value is not written to eeprom or
runtime
> variable,
> but instead a submenu is entered with the value as index for the
array
> Possible way to distinguish from 1 by displaying index [noparse]/noparse after menu
> name
> Any better suggestion is welcome.
> 3. The bottom line just displays the item name
> press ok to enter a new submenu
> top line will display new menu name
> bottom line will display first item of new menu.
>
> The right side of the bottom line displays (part) of the assigned value.
> If the assigned value does not fit entirely on the display it will
scroll
> to the left or right during edit without overwriting the item name.
>
> How about this navigation setup?
>
> regards peter
Navigation is my english translation of the dutch word 'navigatie' which
means in this case
"how to browse the menus". Since you asked, I guess it is not an existing
english word.
What would be the correct word?
Cancel is an implied function, canceling the current state (and return to
previous state),
be it editing or browsing a menu (is that correct english?).
Your suggestions:
Value: pressing cancel while entering a value (edit mode) will restore the
original value.
Line: is accomplished with up and down keys when not in edit mode
Menu: is accomplished by pressing cancel when not in edit mode.
Exit: press cancel repeatedly when not in edit mode. Pressing cancel when in
main menu
will leave menu mode. I think this is less annoying than to select an option
each time cancel is pressed.
regards peter
an englisg term to
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, March 04, 2004 3:52 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> I like the simplified system! We have to keep the primary goal in
> mind. That is, the user interface should not be more complex than the
> purpose of the system! (I just made that up.)
>
> "Cancel" should display somethink like this:
>
> Cancel what?
> Value Line Menu Exit
>
> "Value" restores displayed value to what it was when the item was
> first displayed.
>
> "Line" skips the current menu item and goes onto the next one.
>
> "Menu" skips out of the current menue section and goes to the next
> section.
>
> "Exit" gets out of the entire menu system to where the system was
> vefore presing "OK" in the first place.
>
> What do you mean by "navigation"?
>
> Russ
>
>
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > I am still not satisfied with the current setup. Too many full
> screens and
> > multiple
> > options on a screen do not improve navigation. So I reconsidered, moving
> > towards
> > the setup Jon described in his article (see few posts back), with a few
> > modifications
> > to allow more input including text.
> >
> > Assume 2 line display and 6 navigation keys.
> > Top line holds menu name + optionally status info.
> > Bottom line holds item name (submenu or parameter) + optionally its
> assigned
> > value
> > keys: up, down, left, right, ok, cancel
> > When not in menu mode, press ok to enter menu mode.
> > Topline will display "Main Menu" (or whatever you want)
> > Bottom line will display first item of main menu.
> > Use up and down keys to cycle through menu items.
> > press cancel to leave current menu (i.e menu up)
> > Several possibilities depending on the currently displayed item:
> > 1. The bottom line will display the item name + assigned value
> > Use left and right keys to cycle through available enumerated
> values or
> > decrease/increase value
> > press ok to enter edit mode
> > A cursor will be placed under the first character of the
> displayed value
> > use left and right to move cursor
> > use up and down to change characters
> > press ok to accept changes, write them to eeprom or runtime
> variable and
> > leave edit mode
> > or press cancel to leave edit mode and discard changes
> > 2. Sane as 1 but for an array variable, for example to setup 100
> ports from
> > menu PORT
> > after setting the value, this value is not written to eeprom or
> runtime
> > variable,
> > but instead a submenu is entered with the value as index for the
> array
> > Possible way to distinguish from 1 by displaying index [noparse]/noparse after menu
> > name
> > Any better suggestion is welcome.
> > 3. The bottom line just displays the item name
> > press ok to enter a new submenu
> > top line will display new menu name
> > bottom line will display first item of new menu.
> >
> > The right side of the bottom line displays (part) of the assigned value.
> > If the assigned value does not fit entirely on the display it will
> scroll
> > to the left or right during edit without overwriting the item name.
> >
> > How about this navigation setup?
> >
> > regards peter
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
> Yahoo! Groups Links
>
>
>
>
>
You are using correct English. You can use the word
navigate to "mean browse the menus." More correctly,
you could say navigate the menus. Navigation is the
act of navigating or to navigate, have I confused you
yet? Either way works. I knew wht you meant in your
original post.
I worked the last four years, until I got laid off,
as a system integrator for the water/wastewater
industry, but this also applies to industrial controls
in general, and we had to program HMI's (Human Machine
Interface) to show graphics/text mixed and OIT's
(Operator Interface Terminals) to show text only to
display whatever data was required by the customer.
Obviously, we had to set up menus for each screen for
navigation among the various screens, sometimes these
screens were touch screens or they had function keys
that were programmable. If it was touchscreen then we
just set up the buttons on the screen and they were
identified as to their function. In the case of the
function keys under the screen, the last line of text
immediately above the function keys showed what each
key was supposed to do.
I did not do much programming of these devices but it
seems to me that we just put into the code what
screens each button represented. Very similar to the
navigation buttons and hyperlinks on web pages.
This whole thread had gotten me thinking of how I
would go about doing this on a BSII, 4X20 LCD module
and some pushbuttons. I am getting excited about
experimenting with this and see if I can come up with
something workable. Since I don't have external
EEPROMS this could be a challenge, although isn't that
what we technical people like to do? See how much we
can squeeze into a given microcontroller. After all,
NASA launched spaceships and men into outerspace with
as much or less power...smile.
I don't know if I helped or not, but I thought I would
at least interject my 2 cents worth and also tell you
that your English is correct.
So have a great day!!
James E. Merritt
--- Peter Verkaik <peterverkaik@b...> wrote:
> Russ,
>
> Navigation is my english translation of the dutch
> word 'navigatie' which
> means in this case
> "how to browse the menus". Since you asked, I guess
> it is not an existing
> english word.
> What would be the correct word?
>
> Cancel is an implied function, canceling the current
> state (and return to
> previous state),
> be it editing or browsing a menu (is that correct
> english?).
>
> Your suggestions:
>
> Value: pressing cancel while entering a value (edit
> mode) will restore the
> original value.
> Line: is accomplished with up and down keys when
> not in edit mode
> Menu: is accomplished by pressing cancel when not in
> edit mode.
>
> Exit: press cancel repeatedly when not in edit mode.
> Pressing cancel when in
> main menu
> will leave menu mode. I think this is less annoying
> than to select an option
> each time cancel is pressed.
>
> regards peter
>
__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com
No, your English is quite good. I didn't know if you meant User
navigation of the menus or how the software would move about through
the EEPROM data.
Your implied functioning of the Cancel signal should be okay. Actual
implementation will tell.
I will think about this a bit more and get back to you later.
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> Navigation is my english translation of the dutch word 'navigatie' which
> means in this case
> "how to browse the menus". Since you asked, I guess it is not an
existing
> english word.
> What would be the correct word?
>
> Cancel is an implied function, canceling the current state (and
return to
> previous state),
> be it editing or browsing a menu (is that correct english?).
>
> Your suggestions:
>
> Value: pressing cancel while entering a value (edit mode) will
restore the
> original value.
> Line: is accomplished with up and down keys when not in edit mode
> Menu: is accomplished by pressing cancel when not in edit mode.
>
> Exit: press cancel repeatedly when not in edit mode. Pressing cancel
when in
> main menu
> will leave menu mode. I think this is less annoying than to select
an option
> each time cancel is pressed.
>
> regards peter
>
After rereading your last post, I realized that I had mis-read your
closing question. You sain, "How about this navigation setup?" I
mis-read "this" as "the", so thought it might refer to the program's
moving about in EEPROM! (I am visually impaired.)
Okay. The keys: UP, DOWN, LEFT/-, RIGHT/+, OK, CANCEL
(I prefer the dual labeling where appropriate.)
1. Top line displays a MAIN MENU item.
1.a Second line is blank, or available for continuation of first
line. UP/DOWN take you to previous/next MAIN MENU entry.
CANCEL exits the MENU. (What does OK do?)
1.b Pressing RIGHT/+ takes you to the first SUB MENU for
MAIN MENU. The SUB MENU is displayed on line 1.
UP/DOWN take to to previous/next SUB MENU.
1.c If this SUB MENU has choices/values, etc, they are displayed on
line 2.
1.d LEFT/-, RIGHT/+ will move between choices, or decrement/increment
a VALUE. Pressing OK will store the choice/value and move to the
next SUB MENU, if any, else back to the corresponding MAIN MENU.
(What heppens if you have selected/modified, and press UP or
DOWN?)
2. The MENU ARRAY concept is interesting. Once in a particular ARRAY
line, it works as above, except that OK takes you back to the
SUB MENU where you chose the ARRAY line.
3. Agreed. Simple is good. Have to provide for display of values
which contain decimals (51.3, for example). An alternative
would be to allow a LABEL on the second line, always
left-justified, and always right-justify the value.
[noparse][[/noparse]DC AMPS////////-23.4] (/ is a space)
Russ
Two modes are available while in menu mode.
BROWSE and EDIT. While in EDIT mode the word
EDIT is displayed on the right side of line 1.
EDIT: this lets you enter a value directly.
LEFT/- and RIGHT/+ move the cursor left/right, scrolling the entered value
left/right
if necessary.
UP and DOWN cycle through the available characters for the current cursor
position.
CANCEL leaves EDIT mode discarding changes.
OK leaves EDIT mode accepting changes.
Leaving EDIT mode means returning to BROWSE mode.
BROWSE: this lets you navigate the menus
UP and DOWN cycle through the items of the currently active menu which
name
is displayed on line1. The available items are displayed on the left side
of line 2 and
their assigned value on the right side of line 2. The name of the item may
have an
index number to its right for array variables.
example: (/ is space)
MenuName////////EDIT
ItemName/003/-327.68
If item is a submenu there is no itemvalue (-327.68)
If item refers to a single variable there is no indexvalue (003)
When not in EDIT mode there is no word EDIT.
Line 2 gets updated each time you press UP or DOWN.
CANCEL moves to the parent menu of the currrent menu, or leaves menu mode
in case current menu is main menu.
Now to the use of LEFT, RIGHT and OK.
There are four possible layouts for line 2.
1. No index and no itemvalue.
Item is a submenu.
LEFT/- and RIGHT/+ do nothing.
OK moves to the submenu.
2. Indexvalue, but no itemvalue.
Item is a submenu for an array type variable.
LEFT/- and RIGHT/+ decrease/increase the indexvalue.
OK enters EDIT mode. See above. Press OK twice to accept the value set
by - and +.
If new indexvalue is accepted move to the submenu, else restore line 2
to original state.
3. Itemvalue, but no indexvalue.
Item is a single variable.
LEFT/- and RIGHT/+ decrease/increase the itemvalue.
OK enters EDIT mode. See above. Press OK twice to accept the value set
by - and +.
If new itemvalue is accepted write it to eeprom/ram, else restore line 2
to original state.
4. Indexvalue and itemvalue.
Item is an array type variable.
LEFT/- and RIGHT/+ decrease/increase the indexvalue.
OK enters EDIT mode. See above. Press OK twice to accepts the value set
by - and +.
If new indexvalue is accepted move cursor to itemvalue, else restore
line 2 to original state..
LEFT/- and RIGHT/+ decrease/increase the itemvalue.
OK enters EDIT mode. See above. Press OK twice to accept the value set
by - and +.
If new itemvalue accepted write it to eeprom/ram, else restore line 2 to
original state
To summarize for BROWSE mode:
UP and DOWN cycle the menu items
LEFT/- and RIGHT/+ decrease/increase a value
CANCEL moves to parent menu
OK accepts value or enters submenu
I think this is the most consistent use for the keys.
regards peter.
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, March 04, 2004 8:02 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> After rereading your last post, I realized that I had mis-read your
> closing question. You sain, "How about this navigation setup?" I
> mis-read "this" as "the", so thought it might refer to the program's
> moving about in EEPROM! (I am visually impaired.)
>
> Okay. The keys: UP, DOWN, LEFT/-, RIGHT/+, OK, CANCEL
>
> (I prefer the dual labeling where appropriate.)
>
> 1. Top line displays a MAIN MENU item.
>
> 1.a Second line is blank, or available for continuation of first
> line. UP/DOWN take you to previous/next MAIN MENU entry.
> CANCEL exits the MENU. (What does OK do?)
>
> 1.b Pressing RIGHT/+ takes you to the first SUB MENU for
> MAIN MENU. The SUB MENU is displayed on line 1.
> UP/DOWN take to to previous/next SUB MENU.
>
> 1.c If this SUB MENU has choices/values, etc, they are displayed on
> line 2.
>
> 1.d LEFT/-, RIGHT/+ will move between choices, or decrement/increment
> a VALUE. Pressing OK will store the choice/value and move to the
> next SUB MENU, if any, else back to the corresponding MAIN MENU.
> (What heppens if you have selected/modified, and press UP or
> DOWN?)
>
> 2. The MENU ARRAY concept is interesting. Once in a particular ARRAY
> line, it works as above, except that OK takes you back to the
> SUB MENU where you chose the ARRAY line.
>
> 3. Agreed. Simple is good. Have to provide for display of values
> which contain decimals (51.3, for example). An alternative
> would be to allow a LABEL on the second line, always
> left-justified, and always right-justify the value.
> [noparse][[/noparse]DC AMPS////////-23.4] (/ is a space)
>
> Russ
There are few rights and wrongs in this business. Your scheme will
work. The main concern is whether you can accomplish your purpose in
a manner that you understand. If this criterion is met, all is well.
It's looking good!
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> Two modes are available while in menu mode.
> BROWSE and EDIT. While in EDIT mode the word
> EDIT is displayed on the right side of line 1.
>
> EDIT: this lets you enter a value directly.
> LEFT/- and RIGHT/+ move the cursor left/right, scrolling the
entered value
> left/right
> if necessary.
> UP and DOWN cycle through the available characters for the current
cursor
> position.
> CANCEL leaves EDIT mode discarding changes.
> OK leaves EDIT mode accepting changes.
> Leaving EDIT mode means returning to BROWSE mode.
>
> BROWSE: this lets you navigate the menus
> UP and DOWN cycle through the items of the currently active menu which
> name
> is displayed on line1. The available items are displayed on the
left side
> of line 2 and
> their assigned value on the right side of line 2. The name of the
item may
> have an
> index number to its right for array variables.
> example: (/ is space)
> MenuName////////EDIT
> ItemName/003/-327.68
> If item is a submenu there is no itemvalue (-327.68)
> If item refers to a single variable there is no indexvalue (003)
> When not in EDIT mode there is no word EDIT.
> Line 2 gets updated each time you press UP or DOWN.
> CANCEL moves to the parent menu of the currrent menu, or leaves
menu mode
> in case current menu is main menu.
> Now to the use of LEFT, RIGHT and OK.
> There are four possible layouts for line 2.
> 1. No index and no itemvalue.
> Item is a submenu.
> LEFT/- and RIGHT/+ do nothing.
> OK moves to the submenu.
> 2. Indexvalue, but no itemvalue.
> Item is a submenu for an array type variable.
> LEFT/- and RIGHT/+ decrease/increase the indexvalue.
> OK enters EDIT mode. See above. Press OK twice to accept the
value set
> by - and +.
> If new indexvalue is accepted move to the submenu, else restore
line 2
> to original state.
> 3. Itemvalue, but no indexvalue.
> Item is a single variable.
> LEFT/- and RIGHT/+ decrease/increase the itemvalue.
> OK enters EDIT mode. See above. Press OK twice to accept the
value set
> by - and +.
> If new itemvalue is accepted write it to eeprom/ram, else
restore line 2
> to original state.
> 4. Indexvalue and itemvalue.
> Item is an array type variable.
> LEFT/- and RIGHT/+ decrease/increase the indexvalue.
> OK enters EDIT mode. See above. Press OK twice to accepts the
value set
> by - and +.
> If new indexvalue is accepted move cursor to itemvalue, else restore
> line 2 to original state..
> LEFT/- and RIGHT/+ decrease/increase the itemvalue.
> OK enters EDIT mode. See above. Press OK twice to accept the
value set
> by - and +.
> If new itemvalue accepted write it to eeprom/ram, else restore
line 2 to
> original state
>
> To summarize for BROWSE mode:
> UP and DOWN cycle the menu items
> LEFT/- and RIGHT/+ decrease/increase a value
> CANCEL moves to parent menu
> OK accepts value or enters submenu
>
> I think this is the most consistent use for the keys.
>
> regards peter.
Now that the key use has changed I had to revise my tables. The new tables are
suddenly so much
simpler. Use the courier new font to display with correct spacing.
'Menu tree data
'There are 4 menu levels.
'Each menu has a name and up to 15 items
'Within each menu:
' prev of menuname points to menuname of previous menu (one level up), 0 if
main menu.
' prev of item1 points to last item, prev of item2 points to item1 etc
' next of menuname is 0
' next of last item points to item1, next of item1 points to item2 etc.
' attr of menuname is highest available index for that submenu (0 for main menu
and submenu without index)
' attr of each item depends on the item type
' item is submenu, then attr is 0 (0 is not a ParameterBlock address)
' item is persistent variable, then attr is pointer to ParameterBlock
' item is command, then attr is commandIndex+$8000 (this limits eepromsize to
32KB)
'
'
'label naming convention for data statements
'MWXYZ where W = 0-F main level
' X = 0-F sub1 level
' Y = 0-F SUB2 level
' Z = 0-F SUB3 level
'MWXYZ prev next attr menu- and itemnames
for lcd
M0 DATA WORD 0 , WORD 0 , WORD 0 , "MAIN "
M1 DATA WORD M2 , WORD M2 , WORD 0 , "ITEM1 "
M10 DATA WORD 0 , WORD 0 , WORD 0 , "SUB1 "
M11 DATA WORD M12 , WORD M12 , WORD 0 , "ITEM11 "
M110 DATA WORD 0 , WORD 0 , WORD 0 , "SUB11 "
M111 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM111 "
M1110 DATA WORD 0 , WORD 0 , WORD 0 , "SUB111 "
M1111 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1111 "
M1112 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1112 "
M1113 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1113 "
M112 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM112 "
M1120 DATA WORD 0 , WORD 0 , WORD 0 , "SUB112 "
M1121 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1121 "
M1122 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1122 "
M1123 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1123 "
M12 DATA WORD M11 , WORD M11 , WORD 0 , "ITEM12 "
M120 DATA WORD 0 , WORD 0 , WORD 0 , "SUB12 "
M121 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM121 "
M1210 DATA WORD 0 , WORD 0 , WORD 0 , "SUB121 "
M1211 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1211 "
M1212 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1212 "
M1213 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1213 "
M122 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM122 "
M1220 DATA WORD 0 , WORD 0 , WORD 0 , "SUB122 "
M1221 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1221 "
M1222 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1222 "
M1223 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM1223 "
M2 DATA WORD M1 , WORD M1 , WORD 0 , "ITEM2 "
M20 DATA WORD 0 , WORD 0 , WORD 0 , "SUB2 "
M21 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM21 "
M210 DATA WORD 0 , WORD 0 , WORD 0 , "SUB21 "
M211 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM211 "
M2110 DATA WORD 0 , WORD 0 , WORD 0 , "SUB211 "
M2111 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2111 "
M2112 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2112 "
M2113 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2113 "
M212 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM212 "
M2120 DATA WORD 0 , WORD 0 , WORD 0 , "SUB212 "
M2121 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2121 "
M2122 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2122 "
M2123 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2123 "
M22 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM22 "
M220 DATA WORD 0 , WORD 0 , WORD 0 , "SUB22 "
M221 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM221 "
M2210 DATA WORD 0 , WORD 0 , WORD 0 , "SUB221 "
M2211 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2211 "
M2212 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2212 "
M2213 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2213 "
M222 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM222 "
M2220 DATA WORD 0 , WORD 0 , WORD 0 , "SUB222 "
M2221 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2221 "
M2222 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2222 "
M2223 DATA WORD 0 , WORD 0 , WORD 0 , "ITEM2223 "
'[noparse][[/noparse]ParameterBlock]
'ADDRESS DATA WORD 0 'address
'FIELDSIZE DATA WORD 0 'fieldsize
'REORDSIZE DATA WORD 0 'recordsize
'ATTRIBUTE DATA WORD TYPE*4096+1 'b15-b12=type, b11-b0=record
entries
'A record has 1 or more fields.
'Multiple identical records denote an array record, the fields are then array
variables.
'If a record has more than 1 field, the fields must be accessed via a submenu,
where each
'item is one of the fields. A field can be another record having more than 1
field. Another
'submenu is needed to access those fields.
'Parameter Types
DATA_ENUM CON 0 'enumerated, set by option select
DATA_BIT CON 1 'bit storage
DATA_BYTE CON 2 'byte storage, HEX input
DATA_WORD CON 3 'word storage, HEX input
DATA_DEC CON 4 'ascii storahe, key input values '0' to '9' plus
'-'
DATA_FLOAT CON 5 'ascii storahe, key input values '0' to '9' plus
'-' plus '.'
DATA_HEX CON 6 'ascii storage, key input values '0' to '9' plus
'A' to 'F'
DATA_TEXT CON 7 'ascii storage, key input values ascii 32 to
ascii 126
DATA_READONLY CON 8 'OR with other data type to define parameter
read-only
MENU_END DATA 0
How about this table setup? It looks they are perfect to be auto-generated.
Do you have a special tool to generate such tables? (using a script language?)
I did not completely fill in the table but hope the idea is clear.
The double linked lists allow for item select with up and down key easily.
I indented the menu tree for better optical view.
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Friday, March 05, 2004 2:33 AM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> There are few rights and wrongs in this business. Your scheme will
> work. The main concern is whether you can accomplish your purpose in
> a manner that you understand. If this criterion is met, all is well.
>
> It's looking good!
>
> Russ
[noparse][[/noparse]Non-text portions of this message have been removed]
It looks great! It probably covers everything you want to do with it.
I don't have a tool to do the parsing and table generation. However,
it should be fairly simple to write a parser to handle it. I think it
could be done on a Javelin! Just have to feed the data in via a
serial port. Parse each input line and keep information in tables.
Stuff could be written to the EEPROM as needed, then make another pass
(if necessary) to fill in unknowns (forward links). It shouldn't take
more than 2-3k of RAM for the program code. (Wild guess.)
Russ