Table driven user interface
Archiver
Posts: 46,084
Hi,
Can anybody point me to a working example of a table driven user interface?
Preferred output device is a serial text lcd 2x16 or 4x20.
Preferred input devices are keys.
I would like to program a text intensive menu system into a table that is
offloaded into external eeprom, and then parsing that table while
inside the menu command.
Program language may be pbasic, java or c.
regards peter
Can anybody point me to a working example of a table driven user interface?
Preferred output device is a serial text lcd 2x16 or 4x20.
Preferred input devices are keys.
I would like to program a text intensive menu system into a table that is
offloaded into external eeprom, and then parsing that table while
inside the menu command.
Program language may be pbasic, java or c.
regards peter
Comments
I have been thinking of something along the same lines. Care to shre
some ideas? Using an EEPROM to store the table information is a good
one, sspecially in a Stamp enfironment.
In "the old days" there was a "programming language" called Decision
Tables. This was essentially a State Transition chart. I can think
of four elements:
1. States
2. Events (essentially status bits set outside the table class)
3. Actions (same, set by the table class to cause things to be done
4. Next State
Imagine the States to be arranged vertically (rows) and Events
horizontally (columns). Each table intersection can have a set of
Actions and one Next state. I am currently doing this on a Javelin
Stamp, but the table is hard-coded. I'd love to discuss a way to
generalize it!
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Hi,
>
> Can anybody point me to a working example of a table driven user
interface?
> Preferred output device is a serial text lcd 2x16 or 4x20.
> Preferred input devices are keys.
> I would like to program a text intensive menu system into a table
that is
> offloaded into external eeprom, and then parsing that table while
> inside the menu command.
> Program language may be pbasic, java or c.
>
> regards peter
>Peter,
>
>I have been thinking of something along the same lines. Care to shre
>some ideas? Using an EEPROM to store the table information is a good
>one, sspecially in a Stamp enfironment.
>
>In "the old days" there was a "programming language" called Decision
>Tables. This was essentially a State Transition chart. I can think
>of four elements:
>
>1. States
>2. Events (essentially status bits set outside the table class)
>3. Actions (same, set by the table class to cause things to be done
>4. Next State
>
>Imagine the States to be arranged vertically (rows) and Events
>horizontally (columns). Each table intersection can have a set of
>Actions and one Next state. I am currently doing this on a Javelin
>Stamp, but the table is hard-coded. I'd love to discuss a way to
>generalize it!
>
>Russ
Russ and Peter -
A very similar techniques is often used by operating system task managers in
event driven systems. The last task in the task table is always the system wait
state.
Hopefully the system never reaches that state, other wise nothing is being done.
Just thought I'd mention it, as it uses similar tables and keeps track of
events, and the state of each of the events whether active, pending or complete.
One of the nice things about such a system is the ability to run through the
tables in a commutator fashion, only paying attention to tasks or sub-tasks
which need servicing and pretty much ignoring the rest.
These tasks are also set up in a linked-list scheme. Each task points to the
next task, and back to the prior one. Generally the task list is kept in
priority order, and changing the order is just a matter of changing the each of
the links appropriately.
Getting this back on a Stamp topic, one of the earlier PBasic Stamp Manuals,
possibly Version 1.8 or prior, had a message table for LCD display, if I
remember correctly. I'll see if I can locate it, and if I find it, I'll pass it
along.
Regards,
Bruce Bates
>--- In basicstamps@yahoogroups.com, "Peter Verkaik"
><peterverkaik@b...> wrote:
>> Hi,
>>
>> Can anybody point me to a working example of a table driven user
>interface?
>> Preferred output device is a serial text lcd 2x16 or 4x20.
>> Preferred input devices are keys.
>> I would like to program a text intensive menu system into a table
>that is
>> offloaded into external eeprom, and then parsing that table while
>> inside the menu command.
>> Program language may be pbasic, java or c.
>>
>> 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
>
>
>
>
http://www.dkl.com/pdf/tabledrivendesign.pdf
It lacks however a working example in real code.
But the table descriptions (especially the decision tables)
are good and when inplemented properly could/should reduce
code by 30% or more.
The trick is to define rules, then use a table lookup to
find all matching entries and executing the tasks belonging
to the matching rules.
regards peter
Original Message
From: "Bruce Bates" <bvbates@u...>
To: <basicstamps@yahoogroups.com>
Sent: Sunday, February 29, 2004 12:55 AM
Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> >Peter,
> >
> >I have been thinking of something along the same lines. Care to shre
> >some ideas? Using an EEPROM to store the table information is a good
> >one, sspecially in a Stamp enfironment.
> >
> >In "the old days" there was a "programming language" called Decision
> >Tables. This was essentially a State Transition chart. I can think
> >of four elements:
> >
> >1. States
> >2. Events (essentially status bits set outside the table class)
> >3. Actions (same, set by the table class to cause things to be done
> >4. Next State
> >
> >Imagine the States to be arranged vertically (rows) and Events
> >horizontally (columns). Each table intersection can have a set of
> >Actions and one Next state. I am currently doing this on a Javelin
> >Stamp, but the table is hard-coded. I'd love to discuss a way to
> >generalize it!
> >
> >Russ
>
> Russ and Peter -
>
> A very similar techniques is often used by operating system task managers
in event driven systems. The last task in the task table is always the
system wait state.
> Hopefully the system never reaches that state, other wise nothing is being
done.
>
> Just thought I'd mention it, as it uses similar tables and keeps track of
events, and the state of each of the events whether active, pending or
complete. One of the nice things about such a system is the ability to run
through the tables in a commutator fashion, only paying attention to tasks
or sub-tasks which need servicing and pretty much ignoring the rest.
>
> These tasks are also set up in a linked-list scheme. Each task points to
the next task, and back to the prior one. Generally the task list is kept in
priority order, and changing the order is just a matter of changing the each
of the links appropriately.
>
> Getting this back on a Stamp topic, one of the earlier PBasic Stamp
Manuals, possibly Version 1.8 or prior, had a message table for LCD display,
if I remember correctly. I'll see if I can locate it, and if I find it, I'll
pass it along.
>
> Regards,
>
> Bruce Bates
>
>
>
>
> >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> ><peterverkaik@b...> wrote:
> >> Hi,
> >>
> >> Can anybody point me to a working example of a table driven user
> >interface?
> >> Preferred output device is a serial text lcd 2x16 or 4x20.
> >> Preferred input devices are keys.
> >> I would like to program a text intensive menu system into a table
> >that is
> >> offloaded into external eeprom, and then parsing that table while
> >> inside the menu command.
> >> Program language may be pbasic, java or c.
> >>
> >> 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
> >
> >
> >
> >
>
>
>
> 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
>
>
>
>
>
http://www.imatix.com/html/libero/
A free code generator for table driven design that generates
a framework for C or Java (perhaps useful for the javelin)
and a great number of other languages. Fast reading through
the docs it seems to be possible to add a 'schema' file (language
specific framework file) for other languages, like pbasic.
I will read it closer to find out if this really is possible.
regards peter
Original Message
From: "Peter Verkaik" <peterverkaik@b...>
To: <basicstamps@yahoogroups.com>
Sent: Sunday, February 29, 2004 1:58 AM
Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> I found this to be good reading material
> http://www.dkl.com/pdf/tabledrivendesign.pdf
> It lacks however a working example in real code.
> But the table descriptions (especially the decision tables)
> are good and when inplemented properly could/should reduce
> code by 30% or more.
> The trick is to define rules, then use a table lookup to
> find all matching entries and executing the tasks belonging
> to the matching rules.
>
> regards peter
>
>
Original Message
> From: "Bruce Bates" <bvbates@u...>
> To: <basicstamps@yahoogroups.com>
> Sent: Sunday, February 29, 2004 12:55 AM
> Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > >Peter,
> > >
> > >I have been thinking of something along the same lines. Care to shre
> > >some ideas? Using an EEPROM to store the table information is a good
> > >one, sspecially in a Stamp enfironment.
> > >
> > >In "the old days" there was a "programming language" called Decision
> > >Tables. This was essentially a State Transition chart. I can think
> > >of four elements:
> > >
> > >1. States
> > >2. Events (essentially status bits set outside the table class)
> > >3. Actions (same, set by the table class to cause things to be done
> > >4. Next State
> > >
> > >Imagine the States to be arranged vertically (rows) and Events
> > >horizontally (columns). Each table intersection can have a set of
> > >Actions and one Next state. I am currently doing this on a Javelin
> > >Stamp, but the table is hard-coded. I'd love to discuss a way to
> > >generalize it!
> > >
> > >Russ
> >
> > Russ and Peter -
> >
> > A very similar techniques is often used by operating system task
managers
> in event driven systems. The last task in the task table is always the
> system wait state.
> > Hopefully the system never reaches that state, other wise nothing is
being
> done.
> >
> > Just thought I'd mention it, as it uses similar tables and keeps track
of
> events, and the state of each of the events whether active, pending or
> complete. One of the nice things about such a system is the ability to run
> through the tables in a commutator fashion, only paying attention to
tasks
> or sub-tasks which need servicing and pretty much ignoring the rest.
> >
> > These tasks are also set up in a linked-list scheme. Each task points to
> the next task, and back to the prior one. Generally the task list is kept
in
> priority order, and changing the order is just a matter of changing the
each
> of the links appropriately.
> >
> > Getting this back on a Stamp topic, one of the earlier PBasic Stamp
> Manuals, possibly Version 1.8 or prior, had a message table for LCD
display,
> if I remember correctly. I'll see if I can locate it, and if I find it,
I'll
> pass it along.
> >
> > Regards,
> >
> > Bruce Bates
> >
> >
> >
> >
> > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > ><peterverkaik@b...> wrote:
> > >> Hi,
> > >>
> > >> Can anybody point me to a working example of a table driven user
> > >interface?
> > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > >> Preferred input devices are keys.
> > >> I would like to program a text intensive menu system into a table
> > >that is
> > >> offloaded into external eeprom, and then parsing that table while
> > >> inside the menu command.
> > >> Program language may be pbasic, java or c.
> > >>
> > >> 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
> > >
> > >
> > >
> > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
>
>
>
> 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
>
>
>
>
>
Could you give us a "fer-instance" of what it is you want to accomplish?
I have a device (Solar Energy Inverter) that has an imbedded micro
controller. It uses a menu system where there are several groups of
related menu items each of which has several sub-items. There are
three main types of sub-item. On lets you select a "mode" using left
and right arrow keys. Another uses the arrow keys to
increment/decrement a value. The third is simply information.
There are six control buttons in all. Two to select the main
category, two to select the sub-category, and two as mentioned above.
Such a scheme would be fairly simple to abstract, using EEPROM to
store the menu data.
And I don't think it would be difficult to build a "compler" to stuff
the EEPROM!
Would something on this order be what you're after?
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> I also found this
> http://www.imatix.com/html/libero/
> A free code generator for table driven design that generates
> a framework for C or Java (perhaps useful for the javelin)
> and a great number of other languages. Fast reading through
> the docs it seems to be possible to add a 'schema' file (language
> specific framework file) for other languages, like pbasic.
> I will read it closer to find out if this really is possible.
>
> regards peter
>
>
Original Message
> From: "Peter Verkaik" <peterverkaik@b...>
> To: <basicstamps@yahoogroups.com>
> Sent: Sunday, February 29, 2004 1:58 AM
> Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > I found this to be good reading material
> > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > It lacks however a working example in real code.
> > But the table descriptions (especially the decision tables)
> > are good and when inplemented properly could/should reduce
> > code by 30% or more.
> > The trick is to define rules, then use a table lookup to
> > find all matching entries and executing the tasks belonging
> > to the matching rules.
> >
> > regards peter
> >
> >
Original Message
> > From: "Bruce Bates" <bvbates@u...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Sunday, February 29, 2004 12:55 AM
> > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > >Peter,
> > > >
> > > >I have been thinking of something along the same lines. Care
to shre
> > > >some ideas? Using an EEPROM to store the table information is
a good
> > > >one, sspecially in a Stamp enfironment.
> > > >
> > > >In "the old days" there was a "programming language" called
Decision
> > > >Tables. This was essentially a State Transition chart. I can
think
> > > >of four elements:
> > > >
> > > >1. States
> > > >2. Events (essentially status bits set outside the table class)
> > > >3. Actions (same, set by the table class to cause things to
be done
> > > >4. Next State
> > > >
> > > >Imagine the States to be arranged vertically (rows) and Events
> > > >horizontally (columns). Each table intersection can have a set of
> > > >Actions and one Next state. I am currently doing this on a Javelin
> > > >Stamp, but the table is hard-coded. I'd love to discuss a way to
> > > >generalize it!
> > > >
> > > >Russ
> > >
> > > Russ and Peter -
> > >
> > > A very similar techniques is often used by operating system task
> managers
> > in event driven systems. The last task in the task table is always the
> > system wait state.
> > > Hopefully the system never reaches that state, other wise nothing is
> being
> > done.
> > >
> > > Just thought I'd mention it, as it uses similar tables and keeps
track
> of
> > events, and the state of each of the events whether active, pending or
> > complete. One of the nice things about such a system is the
ability to run
> > through the tables in a commutator fashion, only paying attention to
> tasks
> > or sub-tasks which need servicing and pretty much ignoring the rest.
> > >
> > > These tasks are also set up in a linked-list scheme. Each task
points to
> > the next task, and back to the prior one. Generally the task list
is kept
> in
> > priority order, and changing the order is just a matter of
changing the
> each
> > of the links appropriately.
> > >
> > > Getting this back on a Stamp topic, one of the earlier PBasic Stamp
> > Manuals, possibly Version 1.8 or prior, had a message table for LCD
> display,
> > if I remember correctly. I'll see if I can locate it, and if I
find it,
> I'll
> > pass it along.
> > >
> > > Regards,
> > >
> > > Bruce Bates
> > >
> > >
> > >
> > >
> > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > ><peterverkaik@b...> wrote:
> > > >> Hi,
> > > >>
> > > >> Can anybody point me to a working example of a table driven user
> > > >interface?
> > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > >> Preferred input devices are keys.
> > > >> I would like to program a text intensive menu system into a table
> > > >that is
> > > >> offloaded into external eeprom, and then parsing that table while
> > > >> inside the menu command.
> > > >> Program language may be pbasic, java or c.
> > > >>
> > > >> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
what you're looking for as far as input. I've done a multi-level menu
with an LCD and control inputs (up, down, left, right, enter), is that
what you're looking for? If yes, take a look at this to see if it
helps:
http://www.parallax.com/dl/docs/cols/nv/vol2/col/62.pdf
Note that I wrote that article 3.5 years ago and it could stand an
updating to PBASIC 2.5 syntax.
As far as "table driven control" goes, the first thing I think of is
BRANCH or ON idx GOTO/GOSUB because these use a control value to jump to
the desired section of code.
-- Jon Williams
-- Applications Engineer, Parallax
-- Dallas Office
Original Message
From: Peter Verkaik [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=83upwCJyBkpwVrzlCQWCFfF6YiKeTLXwXWbe_nXNLPeeIifUm__YjlWSeFU_L8aWghVHb8j4hx6VyEgh4YN6yJuj0KY]peterverkaik@b...[/url
Sent: Saturday, February 28, 2004 3:43 PM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Table driven user interface
Hi,
Can anybody point me to a working example of a table driven user
interface? Preferred output device is a serial text lcd 2x16 or 4x20.
Preferred input devices are keys. I would like to program a text
intensive menu system into a table that is offloaded into external
eeprom, and then parsing that table while inside the menu command.
Program language may be pbasic, java or c.
regards peter
I'll start like everybody else, my name is Dan and hope to become a
Stampalcoholic.
I haven't built anything yet but I have a number of projects in my head.
I got my board of edu. about 3 weeks ago but haven't had a chance to
hook it up (btw Active 123 has them for a bit over CAD200; yes I'm from
Canada).
One of my projects will include a main menu - sub menu design so if you
don't mind, can you please share your ideas with me too if you are going
to do it off the mailing list?
I don't have much programming experience but read lots of
manuals/documentation from Parallax so if you want to explaining a few
things along the way feel free to do so.
Basically, my project will activate solenoids, water valves and servos
(nothing new here) and the setup will be done via main menu + sub menus
with an LCD and push buttons for system info and user feedback.
Great newsgroup, I've been lurking on this NS for a long time and am
imprested with the amount of support from everybody and especially
Parallax's people (Jon W. do you ever sleep?).
I think there was someone thinking about starting a BASIC Stamp club in
Canada, any luck with that?
Thanks.
Dan
Original Message
From: russranshaw [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=EypdJ9r5AbW-Mou4JNQA27ipwqNCw87Kb9-fTxRV_SdHIwTfoIThCH4KH2seW003e3OXNNuT9PU]home.rr@c...[/url
Sent: February 29, 2004 10:08 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
Peter,
Could you give us a "fer-instance" of what it is you want to accomplish?
I have a device (Solar Energy Inverter) that has an imbedded micro
controller. It uses a menu system where there are several groups of
related menu items each of which has several sub-items. There are three
main types of sub-item. On lets you select a "mode" using left and
right arrow keys. Another uses the arrow keys to increment/decrement a
value. The third is simply information.
There are six control buttons in all. Two to select the main category,
two to select the sub-category, and two as mentioned above.
Such a scheme would be fairly simple to abstract, using EEPROM to store
the menu data.
And I don't think it would be difficult to build a "compler" to stuff
the EEPROM!
Would something on this order be what you're after?
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik" <peterverkaik@b...>
wrote:
> I also found this
> http://www.imatix.com/html/libero/
> A free code generator for table driven design that generates a
> framework for C or Java (perhaps useful for the javelin) and a great
> number of other languages. Fast reading through the docs it seems to
> be possible to add a 'schema' file (language specific framework file)
> for other languages, like pbasic. I will read it closer to find out if
> this really is possible.
>
> regards peter
>
>
Original Message
> From: "Peter Verkaik" <peterverkaik@b...>
> To: <basicstamps@yahoogroups.com>
> Sent: Sunday, February 29, 2004 1:58 AM
> Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > I found this to be good reading material
> > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > It lacks however a working example in real code.
> > But the table descriptions (especially the decision tables) are good
> > and when inplemented properly could/should reduce code by 30% or
> > more. The trick is to define rules, then use a table lookup to
> > find all matching entries and executing the tasks belonging
> > to the matching rules.
> >
> > regards peter
> >
> >
Original Message
> > From: "Bruce Bates" <bvbates@u...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Sunday, February 29, 2004 12:55 AM
> > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > >Peter,
> > > >
> > > >I have been thinking of something along the same lines. Care
to shre
> > > >some ideas? Using an EEPROM to store the table information is
a good
> > > >one, sspecially in a Stamp enfironment.
> > > >
> > > >In "the old days" there was a "programming language" called
Decision
> > > >Tables. This was essentially a State Transition chart. I can
think
> > > >of four elements:
> > > >
> > > >1. States
> > > >2. Events (essentially status bits set outside the table
class)
> > > >3. Actions (same, set by the table class to cause things to
be done
> > > >4. Next State
> > > >
> > > >Imagine the States to be arranged vertically (rows) and Events
> > > >horizontally (columns). Each table intersection can have a set
> > > >of Actions and one Next state. I am currently doing this on a
> > > >Javelin Stamp, but the table is hard-coded. I'd love to discuss
> > > >a way to generalize it!
> > > >
> > > >Russ
> > >
> > > Russ and Peter -
> > >
> > > A very similar techniques is often used by operating system task
> managers
> > in event driven systems. The last task in the task table is always
> > the system wait state.
> > > Hopefully the system never reaches that state, other wise nothing
> > > is
> being
> > done.
> > >
> > > Just thought I'd mention it, as it uses similar tables and keeps
track
> of
> > events, and the state of each of the events whether active, pending
> > or complete. One of the nice things about such a system is the
ability to run
> > through the tables in a commutator fashion, only paying attention
to
> tasks
> > or sub-tasks which need servicing and pretty much ignoring the rest.
> > >
> > > These tasks are also set up in a linked-list scheme. Each task
points to
> > the next task, and back to the prior one. Generally the task list
is kept
> in
> > priority order, and changing the order is just a matter of
changing the
> each
> > of the links appropriately.
> > >
> > > Getting this back on a Stamp topic, one of the earlier PBasic
> > > Stamp
> > Manuals, possibly Version 1.8 or prior, had a message table for LCD
> display,
> > if I remember correctly. I'll see if I can locate it, and if I
find it,
> I'll
> > pass it along.
> > >
> > > Regards,
> > >
> > > Bruce Bates
> > >
> > >
> > >
> > >
> > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > ><peterverkaik@b...> wrote:
> > > >> Hi,
> > > >>
> > > >> Can anybody point me to a working example of a table driven
> > > >> user
> > > >interface?
> > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > >> Preferred input devices are keys. I would like to program a
> > > >> text intensive menu system into a table
> > > >that is
> > > >> offloaded into external eeprom, and then parsing that table
> > > >> while inside the menu command. Program language may be pbasic,
> > > >> java or c.
> > > >>
> > > >> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
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
-- Jon Williams
-- Applications Engineer, Parallax
-- Dallas Office
Original Message
From: Dan Angiu [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=062Qu2kXrZVKNcNWBc29Mwh3T_qTj23s7rx4QTAf6KW4en4Ge4c4yYvDXDCdAXPL-r8VMzG5nk5e7Ah1iw]dan.angiu@n...[/url
Sent: Sunday, February 29, 2004 11:02 AM
To: basicstamps@yahoogroups.com
Subject: RE: [noparse][[/noparse]basicstamps] Re: Table driven user interface
Hi guys,
I'll start like everybody else, my name is Dan and hope to become a
Stampalcoholic. I haven't built anything yet but I have a number of
projects in my head. I got my board of edu. about 3 weeks ago but
haven't had a chance to hook it up (btw Active 123 has them for a bit
over CAD200; yes I'm from Canada).
One of my projects will include a main menu - sub menu design so if you
don't mind, can you please share your ideas with me too if you are going
to do it off the mailing list? I don't have much programming experience
but read lots of manuals/documentation from Parallax so if you want to
explaining a few things along the way feel free to do so.
Basically, my project will activate solenoids, water valves and servos
(nothing new here) and the setup will be done via main menu + sub menus
with an LCD and push buttons for system info and user feedback.
Great newsgroup, I've been lurking on this NS for a long time and am
imprested with the amount of support from everybody and especially
Parallax's people (Jon W. do you ever sleep?). I think there was someone
thinking about starting a BASIC Stamp club in Canada, any luck with
that?
Thanks.
Dan
Original Message
From: russranshaw [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=UOujogqLzRTH_MVLQeYLJai261XPT2I4JA-jtDbGssg4h0n16eNzpc_P5QMyGxUEMe0tt7qEKu3wYg]home.rr@c...[/url
Sent: February 29, 2004 10:08 AM
To: basicstamps@yahoogroups.com
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
Peter,
Could you give us a "fer-instance" of what it is you want to accomplish?
I have a device (Solar Energy Inverter) that has an imbedded micro
controller. It uses a menu system where there are several groups of
related menu items each of which has several sub-items. There are three
main types of sub-item. On lets you select a "mode" using left and
right arrow keys. Another uses the arrow keys to increment/decrement a
value. The third is simply information.
There are six control buttons in all. Two to select the main category,
two to select the sub-category, and two as mentioned above.
Such a scheme would be fairly simple to abstract, using EEPROM to store
the menu data.
And I don't think it would be difficult to build a "compler" to stuff
the EEPROM!
Would something on this order be what you're after?
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik" <peterverkaik@b...>
wrote:
> I also found this
> http://www.imatix.com/html/libero/
> A free code generator for table driven design that generates a
> framework for C or Java (perhaps useful for the javelin) and a great
> number of other languages. Fast reading through the docs it seems to
> be possible to add a 'schema' file (language specific framework file)
> for other languages, like pbasic. I will read it closer to find out if
> this really is possible.
>
> regards peter
>
>
Original Message
> From: "Peter Verkaik" <peterverkaik@b...>
> To: <basicstamps@yahoogroups.com>
> Sent: Sunday, February 29, 2004 1:58 AM
> Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > I found this to be good reading material
> > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > It lacks however a working example in real code.
> > But the table descriptions (especially the decision tables) are good
> > and when inplemented properly could/should reduce code by 30% or
> > more. The trick is to define rules, then use a table lookup to
> > find all matching entries and executing the tasks belonging
> > to the matching rules.
> >
> > regards peter
> >
> >
Original Message
> > From: "Bruce Bates" <bvbates@u...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Sunday, February 29, 2004 12:55 AM
> > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > >Peter,
> > > >
> > > >I have been thinking of something along the same lines. Care
to shre
> > > >some ideas? Using an EEPROM to store the table information is
a good
> > > >one, sspecially in a Stamp enfironment.
> > > >
> > > >In "the old days" there was a "programming language" called
Decision
> > > >Tables. This was essentially a State Transition chart. I can
think
> > > >of four elements:
> > > >
> > > >1. States
> > > >2. Events (essentially status bits set outside the table
class)
> > > >3. Actions (same, set by the table class to cause things to
be done
> > > >4. Next State
> > > >
> > > >Imagine the States to be arranged vertically (rows) and Events
> > > >horizontally (columns). Each table intersection can have a set
> > > >of Actions and one Next state. I am currently doing this on a
> > > >Javelin Stamp, but the table is hard-coded. I'd love to discuss
> > > >a way to generalize it!
> > > >
> > > >Russ
> > >
> > > Russ and Peter -
> > >
> > > A very similar techniques is often used by operating system task
> managers
> > in event driven systems. The last task in the task table is always
> > the system wait state.
> > > Hopefully the system never reaches that state, other wise nothing
> > > is
> being
> > done.
> > >
> > > Just thought I'd mention it, as it uses similar tables and keeps
track
> of
> > events, and the state of each of the events whether active, pending
> > or complete. One of the nice things about such a system is the
ability to run
> > through the tables in a commutator fashion, only paying attention
to
> tasks
> > or sub-tasks which need servicing and pretty much ignoring the rest.
> > >
> > > These tasks are also set up in a linked-list scheme. Each task
points to
> > the next task, and back to the prior one. Generally the task list
is kept
> in
> > priority order, and changing the order is just a matter of
changing the
> each
> > of the links appropriately.
> > >
> > > Getting this back on a Stamp topic, one of the earlier PBasic
> > > Stamp
> > Manuals, possibly Version 1.8 or prior, had a message table for LCD
> display,
> > if I remember correctly. I'll see if I can locate it, and if I
find it,
> I'll
> > pass it along.
> > >
> > > Regards,
> > >
> > > Bruce Bates
> > >
> > >
> > >
> > >
> > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > ><peterverkaik@b...> wrote:
> > > >> Hi,
> > > >>
> > > >> Can anybody point me to a working example of a table driven
> > > >> user
> > > >interface?
> > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > >> Preferred input devices are keys. I would like to program a
> > > >> text intensive menu system into a table
> > > >that is
> > > >> offloaded into external eeprom, and then parsing that table
> > > >> while inside the menu command. Program language may be pbasic,
> > > >> java or c.
> > > >>
> > > >> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
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
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
This message has been scanned by WebShield. Please report SPAM to
abuse@p....
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
--- In basicstamps@yahoogroups.com, "Dan Angiu" <dan.angiu@n...> wrote:
> Hi guys,
> I'll start like everybody else, my name is Dan and hope to become a
> Stampalcoholic.
> I haven't built anything yet but I have a number of projects in my head.
> I got my board of edu. about 3 weeks ago but haven't had a chance to
> hook it up (btw Active 123 has them for a bit over CAD200; yes I'm from
> Canada).
>
> One of my projects will include a main menu - sub menu design so if you
> don't mind, can you please share your ideas with me too if you are going
> to do it off the mailing list?
> I don't have much programming experience but read lots of
> manuals/documentation from Parallax so if you want to explaining a few
> things along the way feel free to do so.
>
> Basically, my project will activate solenoids, water valves and servos
> (nothing new here) and the setup will be done via main menu + sub menus
> with an LCD and push buttons for system info and user feedback.
>
> Great newsgroup, I've been lurking on this NS for a long time and am
> imprested with the amount of support from everybody and especially
> Parallax's people (Jon W. do you ever sleep?).
> I think there was someone thinking about starting a BASIC Stamp club in
> Canada, any luck with that?
>
> Thanks.
>
> Dan
>
>
>
>
Original Message
> From: russranshaw [noparse][[/noparse]mailto:home.rr@c...]
> Sent: February 29, 2004 10:08 AM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> Peter,
>
> Could you give us a "fer-instance" of what it is you want to accomplish?
>
>
> I have a device (Solar Energy Inverter) that has an imbedded micro
> controller. It uses a menu system where there are several groups of
> related menu items each of which has several sub-items. There are three
> main types of sub-item. On lets you select a "mode" using left and
> right arrow keys. Another uses the arrow keys to increment/decrement a
> value. The third is simply information.
>
> There are six control buttons in all. Two to select the main category,
> two to select the sub-category, and two as mentioned above.
>
> Such a scheme would be fairly simple to abstract, using EEPROM to store
> the menu data.
>
> And I don't think it would be difficult to build a "compler" to stuff
> the EEPROM!
>
> Would something on this order be what you're after?
>
> Russ
>
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik" <peterverkaik@b...>
> wrote:
> > I also found this
> > http://www.imatix.com/html/libero/
> > A free code generator for table driven design that generates a
> > framework for C or Java (perhaps useful for the javelin) and a great
> > number of other languages. Fast reading through the docs it seems to
> > be possible to add a 'schema' file (language specific framework file)
> > for other languages, like pbasic. I will read it closer to find out if
>
> > this really is possible.
> >
> > regards peter
> >
> >
Original Message
> > From: "Peter Verkaik" <peterverkaik@b...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Sunday, February 29, 2004 1:58 AM
> > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > I found this to be good reading material
> > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > It lacks however a working example in real code.
> > > But the table descriptions (especially the decision tables) are good
>
> > > and when inplemented properly could/should reduce code by 30% or
> > > more. The trick is to define rules, then use a table lookup to
> > > find all matching entries and executing the tasks belonging
> > > to the matching rules.
> > >
> > > regards peter
> > >
> > >
Original Message
> > > From: "Bruce Bates" <bvbates@u...>
> > > To: <basicstamps@yahoogroups.com>
> > > Sent: Sunday, February 29, 2004 12:55 AM
> > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > >
> > >
> > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > >Peter,
> > > > >
> > > > >I have been thinking of something along the same lines. Care
> to shre
> > > > >some ideas? Using an EEPROM to store the table information is
> a good
> > > > >one, sspecially in a Stamp enfironment.
> > > > >
> > > > >In "the old days" there was a "programming language" called
> Decision
> > > > >Tables. This was essentially a State Transition chart. I can
> think
> > > > >of four elements:
> > > > >
> > > > >1. States
> > > > >2. Events (essentially status bits set outside the table
> class)
> > > > >3. Actions (same, set by the table class to cause things to
> be done
> > > > >4. Next State
> > > > >
> > > > >Imagine the States to be arranged vertically (rows) and Events
> > > > >horizontally (columns). Each table intersection can have a set
> > > > >of Actions and one Next state. I am currently doing this on a
> > > > >Javelin Stamp, but the table is hard-coded. I'd love to discuss
> > > > >a way to generalize it!
> > > > >
> > > > >Russ
> > > >
> > > > Russ and Peter -
> > > >
> > > > A very similar techniques is often used by operating system task
> > managers
> > > in event driven systems. The last task in the task table is always
> > > the system wait state.
> > > > Hopefully the system never reaches that state, other wise nothing
> > > > is
> > being
> > > done.
> > > >
> > > > Just thought I'd mention it, as it uses similar tables and keeps
> track
> > of
> > > events, and the state of each of the events whether active, pending
> > > or complete. One of the nice things about such a system is the
> ability to run
> > > through the tables in a commutator fashion, only paying attention
> to
> > tasks
> > > or sub-tasks which need servicing and pretty much ignoring the rest.
> > > >
> > > > These tasks are also set up in a linked-list scheme. Each task
> points to
> > > the next task, and back to the prior one. Generally the task list
> is kept
> > in
> > > priority order, and changing the order is just a matter of
> changing the
> > each
> > > of the links appropriately.
> > > >
> > > > Getting this back on a Stamp topic, one of the earlier PBasic
> > > > Stamp
> > > Manuals, possibly Version 1.8 or prior, had a message table for LCD
> > display,
> > > if I remember correctly. I'll see if I can locate it, and if I
> find it,
> > I'll
> > > pass it along.
> > > >
> > > > Regards,
> > > >
> > > > Bruce Bates
> > > >
> > > >
> > > >
> > > >
> > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > ><peterverkaik@b...> wrote:
> > > > >> Hi,
> > > > >>
> > > > >> Can anybody point me to a working example of a table driven
> > > > >> user
> > > > >interface?
> > > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > > >> Preferred input devices are keys. I would like to program a
> > > > >> text intensive menu system into a table
> > > > >that is
> > > > >> offloaded into external eeprom, and then parsing that table
> > > > >> while inside the menu command. Program language may be pbasic,
> > > > >> java or c.
> > > > >>
> > > > >> 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
>
>
>
> 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
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:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=PIMsblVWPZsya6JgZDyBXmZqxtQpkmbQItHgoI6yhP6x6rj0oCxjt5aPMWB0btQRXLq9jef1ly-u]home.rr@c...[/url
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
Immagine a TV commercial. It begins with a shot of a very well
dressed man an woman in the back seat of what appears to be a plush
limosine. They chat amiably, pop the cork on a bottle of champagne
and drink a toast. The man reaches into his jacket pocket and
withdraws a cell phone. He flips it open, puts it to his hear, then
turns a little crank on its side. He pauses, then says "Central?"
The camera draws away to reveal tha the limosine is only the rear
half. The front is a much taller construction, with a man in a
top-hat holding the reins of a team of six beautiful horses which pull
them along. Around them are other similar conveyances, including on
that looks like a VW Beetle.
The message? What we enjoy today as "conveniencs" are simply levels
of abstraction of underlying technology.
I enjoyed reading your article. Yes, it can be done as you so
eloquently showed. But what we are discussing here are ways to
implement a level of abstraction for menu systems. That is, some
central code that does the grunt work of managing menus and can be
re-used in a simple manner.
I have never had the pleasure of working with a BasicStamp. I chose
the Javelin for my project based on its attributes, primarily a larger
RAM space and use of a Java-based language. Again, even these are
levels of abstraction that isolate me from the actual bits and bytes
of the underlying CPU, which itself is an abstration that separates
the apparent CPU from the transistors and gates of the actual processor.
Russ
--- In basicstamps@yahoogroups.com, "Jon Williams" <jwilliams@p...> wrote:
> Storing and printing strings from EEPROM is a no-brainer -- I'm not sure
> what you're looking for as far as input. I've done a multi-level menu
> with an LCD and control inputs (up, down, left, right, enter), is that
> what you're looking for? If yes, take a look at this to see if it
> helps:
>
> http://www.parallax.com/dl/docs/cols/nv/vol2/col/62.pdf
>
> Note that I wrote that article 3.5 years ago and it could stand an
> updating to PBASIC 2.5 syntax.
>
> As far as "table driven control" goes, the first thing I think of is
> BRANCH or ON idx GOTO/GOSUB because these use a control value to jump to
> the desired section of code.
>
> -- Jon Williams
> -- Applications Engineer, Parallax
> -- Dallas Office
>
>
>
Original Message
> From: Peter Verkaik [noparse][[/noparse]mailto[noparse]:p[/noparse]eterverkaik@b...]
> Sent: Saturday, February 28, 2004 3:43 PM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] Table driven user interface
>
>
> Hi,
>
> Can anybody point me to a working example of a table driven user
> interface? Preferred output device is a serial text lcd 2x16 or 4x20.
> Preferred input devices are keys. I would like to program a text
> intensive menu system into a table that is offloaded into external
> eeprom, and then parsing that table while inside the menu command.
> Program language may be pbasic, java or c.
>
> regards peter
Russ, I uploaded something I pieced together. It will not work as it is
incomplete.
I defined a table setup to find out how much code would be needed to
navigate
through menus using tables. The size of the navigation code is even smaller
than I expected.
What I need is to run a setup program (like a PC bios) that has much text,
this is for the benefit of application end-users.
This setup program will be for the javelin. To create the tables I use the
BS
because there is no DATA equivalent for the havelin, and programming such
menus
inline in javelin code eats too much code space.
I would like to discuss the layout of the tables. I am sure they could be
better
organized or perhaps even compacter or more general. The idea is to retrieve
all required settings
from the eeprom rather than hardcoded in the software.
Comments please.
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Sunday, February 29, 2004 4:07 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> Could you give us a "fer-instance" of what it is you want to accomplish?
>
> I have a device (Solar Energy Inverter) that has an imbedded micro
> controller. It uses a menu system where there are several groups of
> related menu items each of which has several sub-items. There are
> three main types of sub-item. On lets you select a "mode" using left
> and right arrow keys. Another uses the arrow keys to
> increment/decrement a value. The third is simply information.
>
> There are six control buttons in all. Two to select the main
> category, two to select the sub-category, and two as mentioned above.
>
> Such a scheme would be fairly simple to abstract, using EEPROM to
> store the menu data.
>
> And I don't think it would be difficult to build a "compler" to stuff
> the EEPROM!
>
> Would something on this order be what you're after?
>
> Russ
>
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > I also found this
> > http://www.imatix.com/html/libero/
> > A free code generator for table driven design that generates
> > a framework for C or Java (perhaps useful for the javelin)
> > and a great number of other languages. Fast reading through
> > the docs it seems to be possible to add a 'schema' file (language
> > specific framework file) for other languages, like pbasic.
> > I will read it closer to find out if this really is possible.
> >
> > regards peter
> >
> >
Original Message
> > From: "Peter Verkaik" <peterverkaik@b...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Sunday, February 29, 2004 1:58 AM
> > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > I found this to be good reading material
> > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > It lacks however a working example in real code.
> > > But the table descriptions (especially the decision tables)
> > > are good and when inplemented properly could/should reduce
> > > code by 30% or more.
> > > The trick is to define rules, then use a table lookup to
> > > find all matching entries and executing the tasks belonging
> > > to the matching rules.
> > >
> > > regards peter
> > >
> > >
Original Message
> > > From: "Bruce Bates" <bvbates@u...>
> > > To: <basicstamps@yahoogroups.com>
> > > Sent: Sunday, February 29, 2004 12:55 AM
> > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > >
> > >
> > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > >Peter,
> > > > >
> > > > >I have been thinking of something along the same lines. Care
> to shre
> > > > >some ideas? Using an EEPROM to store the table information is
> a good
> > > > >one, sspecially in a Stamp enfironment.
> > > > >
> > > > >In "the old days" there was a "programming language" called
> Decision
> > > > >Tables. This was essentially a State Transition chart. I can
> think
> > > > >of four elements:
> > > > >
> > > > >1. States
> > > > >2. Events (essentially status bits set outside the table class)
> > > > >3. Actions (same, set by the table class to cause things to
> be done
> > > > >4. Next State
> > > > >
> > > > >Imagine the States to be arranged vertically (rows) and Events
> > > > >horizontally (columns). Each table intersection can have a set of
> > > > >Actions and one Next state. I am currently doing this on a Javelin
> > > > >Stamp, but the table is hard-coded. I'd love to discuss a way to
> > > > >generalize it!
> > > > >
> > > > >Russ
> > > >
> > > > Russ and Peter -
> > > >
> > > > A very similar techniques is often used by operating system task
> > managers
> > > in event driven systems. The last task in the task table is always the
> > > system wait state.
> > > > Hopefully the system never reaches that state, other wise nothing is
> > being
> > > done.
> > > >
> > > > Just thought I'd mention it, as it uses similar tables and keeps
> track
> > of
> > > events, and the state of each of the events whether active, pending or
> > > complete. One of the nice things about such a system is the
> ability to run
> > > through the tables in a commutator fashion, only paying attention to
> > tasks
> > > or sub-tasks which need servicing and pretty much ignoring the rest.
> > > >
> > > > These tasks are also set up in a linked-list scheme. Each task
> points to
> > > the next task, and back to the prior one. Generally the task list
> is kept
> > in
> > > priority order, and changing the order is just a matter of
> changing the
> > each
> > > of the links appropriately.
> > > >
> > > > Getting this back on a Stamp topic, one of the earlier PBasic Stamp
> > > Manuals, possibly Version 1.8 or prior, had a message table for LCD
> > display,
> > > if I remember correctly. I'll see if I can locate it, and if I
> find it,
> > I'll
> > > pass it along.
> > > >
> > > > Regards,
> > > >
> > > > Bruce Bates
> > > >
> > > >
> > > >
> > > >
> > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > ><peterverkaik@b...> wrote:
> > > > >> Hi,
> > > > >>
> > > > >> Can anybody point me to a working example of a table driven user
> > > > >interface?
> > > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > > >> Preferred input devices are keys.
> > > > >> I would like to program a text intensive menu system into a table
> > > > >that is
> > > > >> offloaded into external eeprom, and then parsing that table while
> > > > >> inside the menu command.
> > > > >> Program language may be pbasic, java or c.
> > > > >>
> > > > >> 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
>
>
>
> 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
>
>
>
>
>
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
I have a similar idea, except what I envision is a "compiler" that
runs on the PC and creates some Java classes, including the menu
driver and a "setup" program. Within the setup program would be a
character array that contained the data destined for the EEPROM. Part
of the table description language would be information about the
starting and ending EEPROM addresses. The user would have to modify
the setup program to get the appropriate pin assignments, driver
class(es) for the EEPROM, etc. My reason for thinking along this line
is that I have a 32k EEPROM, and have other sues for much of it.
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Thanks Jon for your N&V article.
> Russ, I uploaded something I pieced together. It will not work as it is
> incomplete.
> I defined a table setup to find out how much code would be needed to
> navigate
> through menus using tables. The size of the navigation code is even
smaller
> than I expected.
>
> What I need is to run a setup program (like a PC bios) that has much
text,
> this is for the benefit of application end-users.
> This setup program will be for the javelin. To create the tables I
use the
> BS
> because there is no DATA equivalent for the havelin, and programming
such
> menus
> inline in javelin code eats too much code space.
>
> I would like to discuss the layout of the tables. I am sure they
could be
> better
> organized or perhaps even compacter or more general. The idea is to
retrieve
> all required settings
> from the eeprom rather than hardcoded in the software.
>
> Comments please.
>
> regards peter
>
>
>
Original Message
> From: "russranshaw" <home.rr@c...>
> To: <basicstamps@yahoogroups.com>
> Sent: Sunday, February 29, 2004 4:07 PM
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > Peter,
> >
> > Could you give us a "fer-instance" of what it is you want to
accomplish?
> >
> > I have a device (Solar Energy Inverter) that has an imbedded micro
> > controller. It uses a menu system where there are several groups of
> > related menu items each of which has several sub-items. There are
> > three main types of sub-item. On lets you select a "mode" using left
> > and right arrow keys. Another uses the arrow keys to
> > increment/decrement a value. The third is simply information.
> >
> > There are six control buttons in all. Two to select the main
> > category, two to select the sub-category, and two as mentioned above.
> >
> > Such a scheme would be fairly simple to abstract, using EEPROM to
> > store the menu data.
> >
> > And I don't think it would be difficult to build a "compler" to stuff
> > the EEPROM!
> >
> > Would something on this order be what you're after?
> >
> > Russ
> >
> >
> > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > <peterverkaik@b...> wrote:
> > > I also found this
> > > http://www.imatix.com/html/libero/
> > > A free code generator for table driven design that generates
> > > a framework for C or Java (perhaps useful for the javelin)
> > > and a great number of other languages. Fast reading through
> > > the docs it seems to be possible to add a 'schema' file (language
> > > specific framework file) for other languages, like pbasic.
> > > I will read it closer to find out if this really is possible.
> > >
> > > regards peter
> > >
> > >
Original Message
> > > From: "Peter Verkaik" <peterverkaik@b...>
> > > To: <basicstamps@yahoogroups.com>
> > > Sent: Sunday, February 29, 2004 1:58 AM
> > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > >
> > >
> > > > I found this to be good reading material
> > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > It lacks however a working example in real code.
> > > > But the table descriptions (especially the decision tables)
> > > > are good and when inplemented properly could/should reduce
> > > > code by 30% or more.
> > > > The trick is to define rules, then use a table lookup to
> > > > find all matching entries and executing the tasks belonging
> > > > to the matching rules.
> > > >
> > > > regards peter
> > > >
> > > >
Original Message
> > > > From: "Bruce Bates" <bvbates@u...>
> > > > To: <basicstamps@yahoogroups.com>
> > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > >Peter,
> > > > > >
> > > > > >I have been thinking of something along the same lines. Care
> > to shre
> > > > > >some ideas? Using an EEPROM to store the table information is
> > a good
> > > > > >one, sspecially in a Stamp enfironment.
> > > > > >
> > > > > >In "the old days" there was a "programming language" called
> > Decision
> > > > > >Tables. This was essentially a State Transition chart. I can
> > think
> > > > > >of four elements:
> > > > > >
> > > > > >1. States
> > > > > >2. Events (essentially status bits set outside the
table class)
> > > > > >3. Actions (same, set by the table class to cause things to
> > be done
> > > > > >4. Next State
> > > > > >
> > > > > >Imagine the States to be arranged vertically (rows) and Events
> > > > > >horizontally (columns). Each table intersection can have a
set of
> > > > > >Actions and one Next state. I am currently doing this on a
Javelin
> > > > > >Stamp, but the table is hard-coded. I'd love to discuss a
way to
> > > > > >generalize it!
> > > > > >
> > > > > >Russ
> > > > >
> > > > > Russ and Peter -
> > > > >
> > > > > A very similar techniques is often used by operating system task
> > > managers
> > > > in event driven systems. The last task in the task table is
always the
> > > > system wait state.
> > > > > Hopefully the system never reaches that state, other wise
nothing is
> > > being
> > > > done.
> > > > >
> > > > > Just thought I'd mention it, as it uses similar tables and keeps
> > track
> > > of
> > > > events, and the state of each of the events whether active,
pending or
> > > > complete. One of the nice things about such a system is the
> > ability to run
> > > > through the tables in a commutator fashion, only paying
attention to
> > > tasks
> > > > or sub-tasks which need servicing and pretty much ignoring the
rest.
> > > > >
> > > > > These tasks are also set up in a linked-list scheme. Each task
> > points to
> > > > the next task, and back to the prior one. Generally the task list
> > is kept
> > > in
> > > > priority order, and changing the order is just a matter of
> > changing the
> > > each
> > > > of the links appropriately.
> > > > >
> > > > > Getting this back on a Stamp topic, one of the earlier
PBasic Stamp
> > > > Manuals, possibly Version 1.8 or prior, had a message table
for LCD
> > > display,
> > > > if I remember correctly. I'll see if I can locate it, and if I
> > find it,
> > > I'll
> > > > pass it along.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Bruce Bates
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > ><peterverkaik@b...> wrote:
> > > > > >> Hi,
> > > > > >>
> > > > > >> Can anybody point me to a working example of a table
driven user
> > > > > >interface?
> > > > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > > > >> Preferred input devices are keys.
> > > > > >> I would like to program a text intensive menu system into
a table
> > > > > >that is
> > > > > >> offloaded into external eeprom, and then parsing that
table while
> > > > > >> inside the menu command.
> > > > > >> Program language may be pbasic, java or c.
> > > > > >>
> > > > > >> 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
>The message? What we enjoy today as "conveniencs" are simply levels
>of abstraction of underlying technology.
The PBASIC interpreter in the BASIC Stamp is in this sense a table
driven user interface that is built on the underlying PIC
chip/instruction set. The table is the interpreter code that resides
in sequential locations in eeprom, and it consists of instruction
tokens and associated parameters that cause a branch to a subroutine
and actions based on those parameters. Then back to the table for
the next entry. And of course some table entries can alter the
flow. Multitasking processors are a more complicated, as they tend
toward event driven or object oriented programming.
>Peter wrote:
>http://www.dkl.com/pdf/tabledrivendesign.pdf
>It lacks however a working example in real code.
Interesting article, and Wow! they are working in COBOL!
I don't know about a menu interface, but table driven scripts are a
natural for data logging that is synchronized to real time. Each
script block consists of many bytes in a memory area set aside for
the script table. The first entry in each block is a vector pointing
to the next script block in the sequence. Another entry in the block
is a vector pointing to the action to be performed and the rest of
the block consist of the parameters associated with that action. The
actions to be performed, "drivers", use flags and pointers passed by
the system to define their scope and their memory allocation, so that
the drivers can be used in multiple instances without conflict.
Then, changing the data logging scheme means a change in the table
and not in the program mechanism that reads and interprets the table.
For example, a second temperature sensor added to a scheme consists
of a table entry with the vector to the temperature driver, along
with the channels to be used, individual calibration factors, the
formats for LCD or serial data display, etc. The system passes
pointers to the next available file area. New drivers can be
installed for new actions that fit in the schema, for example, an
entirely new type of temperature sensor would entail a driver, but
the driver would be written to fit into the schema and would be
assigned its own vector. On the Stamp 2p/2pe the RUN and STORE
commands allows convenient cross-bank access to the table and to the
drivers.
That is not to say that the very next project won't require something
the does not fit into the schema! That always happens! Otherwise
programmers would be out of work!
-- Tracy
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
>
>
>
>
>
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
> >
> >
> >
> >
> >
joking....is she?
They carry the parallax kits but nothing for individual components.
I'm still searching for places in general that I can order from. I know of
a few drop-in places, that I can't quite remember the names of now....haha
there's supposedly a REALLY good drop-in place near yonge street in TO.
Surplus place and all...
I'll have to find the name of that one!
sb
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Monday, March 01, 2004 7:35 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> 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
> > >
> > >
> > >
> > >
> > >
>
>
>
> 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
>
>
>
>
>
I see your point. But both Basic stamp and javelin cannot hold a full 32KB
eeprom image so multiple
'eeprom program cycles' will be required for a 32KB eeprom. Block size
changes for one cycle
could impact on the other cycles, forcing code changes for those other
cycles.
How about using an underlying structure that shows free and allocated blocks
and that is recognized
by basic stamp and javelin? That way available start and end addresses are
retrieved from the eeprom
itself. What I was thinking of is the javelin heap class I wrote that I can
easily port to the basic stamp.
Each block, either free or allocated, requires only 4 eeprom bytes to
maintain the heap structure.
This structure is limited to a 32KB eeprom. A 64KB eeprom could hold two
heap structures.
Whatever you put in allocated blocks (could be another heap) is up to the
application.
I suggest using signature words to identify allocated blocks.
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Monday, March 01, 2004 7:07 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> I have a similar idea, except what I envision is a "compiler" that
> runs on the PC and creates some Java classes, including the menu
> driver and a "setup" program. Within the setup program would be a
> character array that contained the data destined for the EEPROM. Part
> of the table description language would be information about the
> starting and ending EEPROM addresses. The user would have to modify
> the setup program to get the appropriate pin assignments, driver
> class(es) for the EEPROM, etc. My reason for thinking along this line
> is that I have a 32k EEPROM, and have other sues for much of it.
>
> Russ
>
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > Thanks Jon for your N&V article.
> > Russ, I uploaded something I pieced together. It will not work as it is
> > incomplete.
> > I defined a table setup to find out how much code would be needed to
> > navigate
> > through menus using tables. The size of the navigation code is even
> smaller
> > than I expected.
> >
> > What I need is to run a setup program (like a PC bios) that has much
> text,
> > this is for the benefit of application end-users.
> > This setup program will be for the javelin. To create the tables I
> use the
> > BS
> > because there is no DATA equivalent for the havelin, and programming
> such
> > menus
> > inline in javelin code eats too much code space.
> >
> > I would like to discuss the layout of the tables. I am sure they
> could be
> > better
> > organized or perhaps even compacter or more general. The idea is to
> retrieve
> > all required settings
> > from the eeprom rather than hardcoded in the software.
> >
> > Comments please.
> >
> > regards peter
> >
> >
> >
Original Message
> > From: "russranshaw" <home.rr@c...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Sunday, February 29, 2004 4:07 PM
> > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > Peter,
> > >
> > > Could you give us a "fer-instance" of what it is you want to
> accomplish?
> > >
> > > I have a device (Solar Energy Inverter) that has an imbedded micro
> > > controller. It uses a menu system where there are several groups of
> > > related menu items each of which has several sub-items. There are
> > > three main types of sub-item. On lets you select a "mode" using left
> > > and right arrow keys. Another uses the arrow keys to
> > > increment/decrement a value. The third is simply information.
> > >
> > > There are six control buttons in all. Two to select the main
> > > category, two to select the sub-category, and two as mentioned above.
> > >
> > > Such a scheme would be fairly simple to abstract, using EEPROM to
> > > store the menu data.
> > >
> > > And I don't think it would be difficult to build a "compler" to stuff
> > > the EEPROM!
> > >
> > > Would something on this order be what you're after?
> > >
> > > Russ
> > >
> > >
> > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > <peterverkaik@b...> wrote:
> > > > I also found this
> > > > http://www.imatix.com/html/libero/
> > > > A free code generator for table driven design that generates
> > > > a framework for C or Java (perhaps useful for the javelin)
> > > > and a great number of other languages. Fast reading through
> > > > the docs it seems to be possible to add a 'schema' file (language
> > > > specific framework file) for other languages, like pbasic.
> > > > I will read it closer to find out if this really is possible.
> > > >
> > > > regards peter
> > > >
> > > >
Original Message
> > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > To: <basicstamps@yahoogroups.com>
> > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > > I found this to be good reading material
> > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > It lacks however a working example in real code.
> > > > > But the table descriptions (especially the decision tables)
> > > > > are good and when inplemented properly could/should reduce
> > > > > code by 30% or more.
> > > > > The trick is to define rules, then use a table lookup to
> > > > > find all matching entries and executing the tasks belonging
> > > > > to the matching rules.
> > > > >
> > > > > regards peter
> > > > >
> > > > >
Original Message
> > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > To: <basicstamps@yahoogroups.com>
> > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > >
> > > > >
> > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > >Peter,
> > > > > > >
> > > > > > >I have been thinking of something along the same lines. Care
> > > to shre
> > > > > > >some ideas? Using an EEPROM to store the table information is
> > > a good
> > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > >
> > > > > > >In "the old days" there was a "programming language" called
> > > Decision
> > > > > > >Tables. This was essentially a State Transition chart. I can
> > > think
> > > > > > >of four elements:
> > > > > > >
> > > > > > >1. States
> > > > > > >2. Events (essentially status bits set outside the
> table class)
> > > > > > >3. Actions (same, set by the table class to cause things to
> > > be done
> > > > > > >4. Next State
> > > > > > >
> > > > > > >Imagine the States to be arranged vertically (rows) and Events
> > > > > > >horizontally (columns). Each table intersection can have a
> set of
> > > > > > >Actions and one Next state. I am currently doing this on a
> Javelin
> > > > > > >Stamp, but the table is hard-coded. I'd love to discuss a
> way to
> > > > > > >generalize it!
> > > > > > >
> > > > > > >Russ
> > > > > >
> > > > > > Russ and Peter -
> > > > > >
> > > > > > A very similar techniques is often used by operating system task
> > > > managers
> > > > > in event driven systems. The last task in the task table is
> always the
> > > > > system wait state.
> > > > > > Hopefully the system never reaches that state, other wise
> nothing is
> > > > being
> > > > > done.
> > > > > >
> > > > > > Just thought I'd mention it, as it uses similar tables and keeps
> > > track
> > > > of
> > > > > events, and the state of each of the events whether active,
> pending or
> > > > > complete. One of the nice things about such a system is the
> > > ability to run
> > > > > through the tables in a commutator fashion, only paying
> attention to
> > > > tasks
> > > > > or sub-tasks which need servicing and pretty much ignoring the
> rest.
> > > > > >
> > > > > > These tasks are also set up in a linked-list scheme. Each task
> > > points to
> > > > > the next task, and back to the prior one. Generally the task list
> > > is kept
> > > > in
> > > > > priority order, and changing the order is just a matter of
> > > changing the
> > > > each
> > > > > of the links appropriately.
> > > > > >
> > > > > > Getting this back on a Stamp topic, one of the earlier
> PBasic Stamp
> > > > > Manuals, possibly Version 1.8 or prior, had a message table
> for LCD
> > > > display,
> > > > > if I remember correctly. I'll see if I can locate it, and if I
> > > find it,
> > > > I'll
> > > > > pass it along.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Bruce Bates
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > ><peterverkaik@b...> wrote:
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> Can anybody point me to a working example of a table
> driven user
> > > > > > >interface?
> > > > > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > > > > >> Preferred input devices are keys.
> > > > > > >> I would like to program a text intensive menu system into
> a table
> > > > > > >that is
> > > > > > >> offloaded into external eeprom, and then parsing that
> table while
> > > > > > >> inside the menu command.
> > > > > > >> Program language may be pbasic, java or c.
> > > > > > >>
> > > > > > >> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
>
>
>
> 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
>
>
>
>
>
Errata, the heap structure requires only 2 eeprom bytes to maintain the
structure.
regards peter
Original Message
From: "Peter Verkaik" <peterverkaik@b...>
To: <basicstamps@yahoogroups.com>
Sent: Tuesday, March 02, 2004 11:40 AM
Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Russ,
>
> I see your point. But both Basic stamp and javelin cannot hold a full 32KB
> eeprom image so multiple
> 'eeprom program cycles' will be required for a 32KB eeprom. Block size
> changes for one cycle
> could impact on the other cycles, forcing code changes for those other
> cycles.
> How about using an underlying structure that shows free and allocated
blocks
> and that is recognized
> by basic stamp and javelin? That way available start and end addresses are
> retrieved from the eeprom
> itself. What I was thinking of is the javelin heap class I wrote that I
can
> easily port to the basic stamp.
> Each block, either free or allocated, requires only 4 eeprom bytes to
> maintain the heap structure.
> This structure is limited to a 32KB eeprom. A 64KB eeprom could hold two
> heap structures.
> Whatever you put in allocated blocks (could be another heap) is up to the
> application.
> I suggest using signature words to identify allocated blocks.
>
> regards peter
>
>
Original Message
> From: "russranshaw" <home.rr@c...>
> To: <basicstamps@yahoogroups.com>
> Sent: Monday, March 01, 2004 7:07 PM
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > Peter,
> >
> > I have a similar idea, except what I envision is a "compiler" that
> > runs on the PC and creates some Java classes, including the menu
> > driver and a "setup" program. Within the setup program would be a
> > character array that contained the data destined for the EEPROM. Part
> > of the table description language would be information about the
> > starting and ending EEPROM addresses. The user would have to modify
> > the setup program to get the appropriate pin assignments, driver
> > class(es) for the EEPROM, etc. My reason for thinking along this line
> > is that I have a 32k EEPROM, and have other sues for much of it.
> >
> > Russ
> >
> >
> > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > <peterverkaik@b...> wrote:
> > > Thanks Jon for your N&V article.
> > > Russ, I uploaded something I pieced together. It will not work as it
is
> > > incomplete.
> > > I defined a table setup to find out how much code would be needed to
> > > navigate
> > > through menus using tables. The size of the navigation code is even
> > smaller
> > > than I expected.
> > >
> > > What I need is to run a setup program (like a PC bios) that has much
> > text,
> > > this is for the benefit of application end-users.
> > > This setup program will be for the javelin. To create the tables I
> > use the
> > > BS
> > > because there is no DATA equivalent for the havelin, and programming
> > such
> > > menus
> > > inline in javelin code eats too much code space.
> > >
> > > I would like to discuss the layout of the tables. I am sure they
> > could be
> > > better
> > > organized or perhaps even compacter or more general. The idea is to
> > retrieve
> > > all required settings
> > > from the eeprom rather than hardcoded in the software.
> > >
> > > Comments please.
> > >
> > > regards peter
> > >
> > >
> > >
Original Message
> > > From: "russranshaw" <home.rr@c...>
> > > To: <basicstamps@yahoogroups.com>
> > > Sent: Sunday, February 29, 2004 4:07 PM
> > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > >
> > >
> > > > Peter,
> > > >
> > > > Could you give us a "fer-instance" of what it is you want to
> > accomplish?
> > > >
> > > > I have a device (Solar Energy Inverter) that has an imbedded micro
> > > > controller. It uses a menu system where there are several groups of
> > > > related menu items each of which has several sub-items. There are
> > > > three main types of sub-item. On lets you select a "mode" using
left
> > > > and right arrow keys. Another uses the arrow keys to
> > > > increment/decrement a value. The third is simply information.
> > > >
> > > > There are six control buttons in all. Two to select the main
> > > > category, two to select the sub-category, and two as mentioned
above.
> > > >
> > > > Such a scheme would be fairly simple to abstract, using EEPROM to
> > > > store the menu data.
> > > >
> > > > And I don't think it would be difficult to build a "compler" to
stuff
> > > > the EEPROM!
> > > >
> > > > Would something on this order be what you're after?
> > > >
> > > > Russ
> > > >
> > > >
> > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > <peterverkaik@b...> wrote:
> > > > > I also found this
> > > > > http://www.imatix.com/html/libero/
> > > > > A free code generator for table driven design that generates
> > > > > a framework for C or Java (perhaps useful for the javelin)
> > > > > and a great number of other languages. Fast reading through
> > > > > the docs it seems to be possible to add a 'schema' file (language
> > > > > specific framework file) for other languages, like pbasic.
> > > > > I will read it closer to find out if this really is possible.
> > > > >
> > > > > regards peter
> > > > >
> > > > >
Original Message
> > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > To: <basicstamps@yahoogroups.com>
> > > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > >
> > > > >
> > > > > > I found this to be good reading material
> > > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > > It lacks however a working example in real code.
> > > > > > But the table descriptions (especially the decision tables)
> > > > > > are good and when inplemented properly could/should reduce
> > > > > > code by 30% or more.
> > > > > > The trick is to define rules, then use a table lookup to
> > > > > > find all matching entries and executing the tasks belonging
> > > > > > to the matching rules.
> > > > > >
> > > > > > regards peter
> > > > > >
> > > > > >
Original Message
> > > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > >
> > > > > >
> > > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > > >Peter,
> > > > > > > >
> > > > > > > >I have been thinking of something along the same lines. Care
> > > > to shre
> > > > > > > >some ideas? Using an EEPROM to store the table information
is
> > > > a good
> > > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > > >
> > > > > > > >In "the old days" there was a "programming language" called
> > > > Decision
> > > > > > > >Tables. This was essentially a State Transition chart. I
can
> > > > think
> > > > > > > >of four elements:
> > > > > > > >
> > > > > > > >1. States
> > > > > > > >2. Events (essentially status bits set outside the
> > table class)
> > > > > > > >3. Actions (same, set by the table class to cause things
to
> > > > be done
> > > > > > > >4. Next State
> > > > > > > >
> > > > > > > >Imagine the States to be arranged vertically (rows) and
Events
> > > > > > > >horizontally (columns). Each table intersection can have a
> > set of
> > > > > > > >Actions and one Next state. I am currently doing this on a
> > Javelin
> > > > > > > >Stamp, but the table is hard-coded. I'd love to discuss a
> > way to
> > > > > > > >generalize it!
> > > > > > > >
> > > > > > > >Russ
> > > > > > >
> > > > > > > Russ and Peter -
> > > > > > >
> > > > > > > A very similar techniques is often used by operating system
task
> > > > > managers
> > > > > > in event driven systems. The last task in the task table is
> > always the
> > > > > > system wait state.
> > > > > > > Hopefully the system never reaches that state, other wise
> > nothing is
> > > > > being
> > > > > > done.
> > > > > > >
> > > > > > > Just thought I'd mention it, as it uses similar tables and
keeps
> > > > track
> > > > > of
> > > > > > events, and the state of each of the events whether active,
> > pending or
> > > > > > complete. One of the nice things about such a system is the
> > > > ability to run
> > > > > > through the tables in a commutator fashion, only paying
> > attention to
> > > > > tasks
> > > > > > or sub-tasks which need servicing and pretty much ignoring the
> > rest.
> > > > > > >
> > > > > > > These tasks are also set up in a linked-list scheme. Each task
> > > > points to
> > > > > > the next task, and back to the prior one. Generally the task
list
> > > > is kept
> > > > > in
> > > > > > priority order, and changing the order is just a matter of
> > > > changing the
> > > > > each
> > > > > > of the links appropriately.
> > > > > > >
> > > > > > > Getting this back on a Stamp topic, one of the earlier
> > PBasic Stamp
> > > > > > Manuals, possibly Version 1.8 or prior, had a message table
> > for LCD
> > > > > display,
> > > > > > if I remember correctly. I'll see if I can locate it, and if I
> > > > find it,
> > > > > I'll
> > > > > > pass it along.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Bruce Bates
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > ><peterverkaik@b...> wrote:
> > > > > > > >> Hi,
> > > > > > > >>
> > > > > > > >> Can anybody point me to a working example of a table
> > driven user
> > > > > > > >interface?
> > > > > > > >> Preferred output device is a serial text lcd 2x16 or 4x20.
> > > > > > > >> Preferred input devices are keys.
> > > > > > > >> I would like to program a text intensive menu system into
> > a table
> > > > > > > >that is
> > > > > > > >> offloaded into external eeprom, and then parsing that
> > table while
> > > > > > > >> inside the menu command.
> > > > > > > >> Program language may be pbasic, java or c.
> > > > > > > >>
> > > > > > > >> 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
>
>
>
> 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
>
>
>
>
>
she's a true Canuk.
I buy a lot of components from Digi-Key. They can ship from inside
Canada, which saves the "agent's fee", which can amount to a large
amount! Unfortunately they don't have everything I want/need, such as
the PCV male/female DB9 connectors (escept in lots of 100).
Russ
--- In basicstamps@yahoogroups.com, "SB" <steve.brady@r...> wrote:
> Hmm....is she single?! KIDDING!! unless she is of course...no
really...I'm
> joking....is she?
>
> They carry the parallax kits but nothing for individual components.
>
> I'm still searching for places in general that I can order from. I
know of
> a few drop-in places, that I can't quite remember the names of
now....haha
>
> there's supposedly a REALLY good drop-in place near yonge street in TO.
> Surplus place and all...
> I'll have to find the name of that one!
>
> sb
>
>
Original Message
> From: "russranshaw" <home.rr@c...>
> To: <basicstamps@yahoogroups.com>
> Sent: Monday, March 01, 2004 7:35 PM
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
I'm not sure the elaborteness is justified. Those 32k EEPROMs are
pretty cheap ($5). Besides, I don't see even a very complex menu
requiring anywhere near 32k.
If my original thought dosen't sit well (putting the entire structure
which is destined for the EEPROM in a Javelin program), then one could
write a generic Javelin program that would take a stream of data via a
serial port and write it to the EEPROM. If timing is a problem, it is
feasible to implement a simple error checking packetized protocol
which would request the next packet. That way it would be possible to
download some data, write it to the EEPROM, downloand the next chunk,
write it, etc. I don't see speed being a problem. I guess I don't
understand your point about "cycles".
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> Errata, the heap structure requires only 2 eeprom bytes to maintain the
> structure.
>
> regards peter
>
>
Original Message
> From: "Peter Verkaik" <peterverkaik@b...>
> To: <basicstamps@yahoogroups.com>
> Sent: Tuesday, March 02, 2004 11:40 AM
> Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > Russ,
> >
> > I see your point. But both Basic stamp and javelin cannot hold a
full 32KB
> > eeprom image so multiple
> > 'eeprom program cycles' will be required for a 32KB eeprom. Block size
> > changes for one cycle
> > could impact on the other cycles, forcing code changes for those other
> > cycles.
> > How about using an underlying structure that shows free and allocated
> blocks
> > and that is recognized
> > by basic stamp and javelin? That way available start and end
addresses are
> > retrieved from the eeprom
> > itself. What I was thinking of is the javelin heap class I wrote
that I
> can
> > easily port to the basic stamp.
> > Each block, either free or allocated, requires only 4 eeprom bytes to
> > maintain the heap structure.
> > This structure is limited to a 32KB eeprom. A 64KB eeprom could
hold two
> > heap structures.
> > Whatever you put in allocated blocks (could be another heap) is up
to the
> > application.
> > I suggest using signature words to identify allocated blocks.
> >
> > regards peter
> >
> >
Original Message
> > From: "russranshaw" <home.rr@c...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Monday, March 01, 2004 7:07 PM
> > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > Peter,
> > >
> > > I have a similar idea, except what I envision is a "compiler" that
> > > runs on the PC and creates some Java classes, including the menu
> > > driver and a "setup" program. Within the setup program would be a
> > > character array that contained the data destined for the EEPROM.
Part
> > > of the table description language would be information about the
> > > starting and ending EEPROM addresses. The user would have to modify
> > > the setup program to get the appropriate pin assignments, driver
> > > class(es) for the EEPROM, etc. My reason for thinking along
this line
> > > is that I have a 32k EEPROM, and have other sues for much of it.
> > >
> > > Russ
> > >
> > >
> > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > <peterverkaik@b...> wrote:
> > > > Thanks Jon for your N&V article.
> > > > Russ, I uploaded something I pieced together. It will not work
as it
> is
> > > > incomplete.
> > > > I defined a table setup to find out how much code would be
needed to
> > > > navigate
> > > > through menus using tables. The size of the navigation code is
even
> > > smaller
> > > > than I expected.
> > > >
> > > > What I need is to run a setup program (like a PC bios) that
has much
> > > text,
> > > > this is for the benefit of application end-users.
> > > > This setup program will be for the javelin. To create the tables I
> > > use the
> > > > BS
> > > > because there is no DATA equivalent for the havelin, and
programming
> > > such
> > > > menus
> > > > inline in javelin code eats too much code space.
> > > >
> > > > I would like to discuss the layout of the tables. I am sure they
> > > could be
> > > > better
> > > > organized or perhaps even compacter or more general. The idea
is to
> > > retrieve
> > > > all required settings
> > > > from the eeprom rather than hardcoded in the software.
> > > >
> > > > Comments please.
> > > >
> > > > regards peter
> > > >
> > > >
> > > >
Original Message
> > > > From: "russranshaw" <home.rr@c...>
> > > > To: <basicstamps@yahoogroups.com>
> > > > Sent: Sunday, February 29, 2004 4:07 PM
> > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > > Peter,
> > > > >
> > > > > Could you give us a "fer-instance" of what it is you want to
> > > accomplish?
> > > > >
> > > > > I have a device (Solar Energy Inverter) that has an imbedded
micro
> > > > > controller. It uses a menu system where there are several
groups of
> > > > > related menu items each of which has several sub-items.
There are
> > > > > three main types of sub-item. On lets you select a "mode" using
> left
> > > > > and right arrow keys. Another uses the arrow keys to
> > > > > increment/decrement a value. The third is simply information.
> > > > >
> > > > > There are six control buttons in all. Two to select the main
> > > > > category, two to select the sub-category, and two as mentioned
> above.
> > > > >
> > > > > Such a scheme would be fairly simple to abstract, using
EEPROM to
> > > > > store the menu data.
> > > > >
> > > > > And I don't think it would be difficult to build a "compler" to
> stuff
> > > > > the EEPROM!
> > > > >
> > > > > Would something on this order be what you're after?
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > <peterverkaik@b...> wrote:
> > > > > > I also found this
> > > > > > http://www.imatix.com/html/libero/
> > > > > > A free code generator for table driven design that generates
> > > > > > a framework for C or Java (perhaps useful for the javelin)
> > > > > > and a great number of other languages. Fast reading through
> > > > > > the docs it seems to be possible to add a 'schema' file
(language
> > > > > > specific framework file) for other languages, like pbasic.
> > > > > > I will read it closer to find out if this really is possible.
> > > > > >
> > > > > > regards peter
> > > > > >
> > > > > >
Original Message
> > > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > >
> > > > > >
> > > > > > > I found this to be good reading material
> > > > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > > > It lacks however a working example in real code.
> > > > > > > But the table descriptions (especially the decision tables)
> > > > > > > are good and when inplemented properly could/should reduce
> > > > > > > code by 30% or more.
> > > > > > > The trick is to define rules, then use a table lookup to
> > > > > > > find all matching entries and executing the tasks belonging
> > > > > > > to the matching rules.
> > > > > > >
> > > > > > > regards peter
> > > > > > >
> > > > > > >
Original Message
> > > > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > > >
> > > > > > >
> > > > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > > > >Peter,
> > > > > > > > >
> > > > > > > > >I have been thinking of something along the same
lines. Care
> > > > > to shre
> > > > > > > > >some ideas? Using an EEPROM to store the table
information
> is
> > > > > a good
> > > > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > > > >
> > > > > > > > >In "the old days" there was a "programming language"
called
> > > > > Decision
> > > > > > > > >Tables. This was essentially a State Transition
chart. I
> can
> > > > > think
> > > > > > > > >of four elements:
> > > > > > > > >
> > > > > > > > >1. States
> > > > > > > > >2. Events (essentially status bits set outside the
> > > table class)
> > > > > > > > >3. Actions (same, set by the table class to cause
things
> to
> > > > > be done
> > > > > > > > >4. Next State
> > > > > > > > >
> > > > > > > > >Imagine the States to be arranged vertically (rows) and
> Events
> > > > > > > > >horizontally (columns). Each table intersection can
have a
> > > set of
> > > > > > > > >Actions and one Next state. I am currently doing
this on a
> > > Javelin
> > > > > > > > >Stamp, but the table is hard-coded. I'd love to
discuss a
> > > way to
> > > > > > > > >generalize it!
> > > > > > > > >
> > > > > > > > >Russ
> > > > > > > >
> > > > > > > > Russ and Peter -
> > > > > > > >
> > > > > > > > A very similar techniques is often used by operating
system
> task
> > > > > > managers
> > > > > > > in event driven systems. The last task in the task table is
> > > always the
> > > > > > > system wait state.
> > > > > > > > Hopefully the system never reaches that state, other wise
> > > nothing is
> > > > > > being
> > > > > > > done.
> > > > > > > >
> > > > > > > > Just thought I'd mention it, as it uses similar tables and
> keeps
> > > > > track
> > > > > > of
> > > > > > > events, and the state of each of the events whether active,
> > > pending or
> > > > > > > complete. One of the nice things about such a system is the
> > > > > ability to run
> > > > > > > through the tables in a commutator fashion, only paying
> > > attention to
> > > > > > tasks
> > > > > > > or sub-tasks which need servicing and pretty much
ignoring the
> > > rest.
> > > > > > > >
> > > > > > > > These tasks are also set up in a linked-list scheme.
Each task
> > > > > points to
> > > > > > > the next task, and back to the prior one. Generally the task
> list
> > > > > is kept
> > > > > > in
> > > > > > > priority order, and changing the order is just a matter of
> > > > > changing the
> > > > > > each
> > > > > > > of the links appropriately.
> > > > > > > >
> > > > > > > > Getting this back on a Stamp topic, one of the earlier
> > > PBasic Stamp
> > > > > > > Manuals, possibly Version 1.8 or prior, had a message table
> > > for LCD
> > > > > > display,
> > > > > > > if I remember correctly. I'll see if I can locate it,
and if I
> > > > > find it,
> > > > > > I'll
> > > > > > > pass it along.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Bruce Bates
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > ><peterverkaik@b...> wrote:
> > > > > > > > >> Hi,
> > > > > > > > >>
> > > > > > > > >> Can anybody point me to a working example of a table
> > > driven user
> > > > > > > > >interface?
> > > > > > > > >> Preferred output device is a serial text lcd 2x16
or 4x20.
> > > > > > > > >> Preferred input devices are keys.
> > > > > > > > >> I would like to program a text intensive menu
system into
> > > a table
> > > > > > > > >that is
> > > > > > > > >> offloaded into external eeprom, and then parsing that
> > > table while
> > > > > > > > >> inside the menu command.
> > > > > > > > >> Program language may be pbasic, java or c.
> > > > > > > > >>
> > > > > > > > >> 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
the "Table Driven Interface" is to have
the display bytes stored in an off-chip
EEPROM -- loaded through some method.
The program then knows the 'base' addr.
of each page in the EEPROM table. The
software merely needs to know which addr
to select -- then go to the EEPROM and
transfer the image from the Table to the
Display.
If that's what you're talking about, then
yes, the EEPROM loader program can be put
into the Javelin. Some PC-based Display
Generator program can generate the Display
data, and load it into the EEPROM (through
a simple program on the Javelin, or through
an EEPROM burner, your choice). Then,
the DisplayGen program needs to give you,
the programmer, the table of start addr for
the loaded 'screens'.
Then, you supply those 'screen' start addr to
your program, add the logic to navigate from
screen to screen, and you are good to go.
So, what's the problem with this approach?
Sounds brilliant to me. You get the stand-alone
nature of the Stamp, and nice screens from
the EEPROM.
--- In basicstamps@yahoogroups.com, "russranshaw" <home.rr@c...>
wrote:
> Peter,
>
> I'm not sure the elaborteness is justified. Those 32k EEPROMs are
> pretty cheap ($5). Besides, I don't see even a very complex menu
> requiring anywhere near 32k.
>
> If my original thought dosen't sit well (putting the entire
structure
> which is destined for the EEPROM in a Javelin program), then one
could
> write a generic Javelin program that would take a stream of data
via a
> serial port and write it to the EEPROM. If timing is a problem, it
is
> feasible to implement a simple error checking packetized protocol
> which would request the next packet. That way it would be possible
to
> download some data, write it to the EEPROM, downloand the next
chunk,
> write it, etc. I don't see speed being a problem. I guess I don't
> understand your point about "cycles".
>
> Russ
>
>
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > Russ,
> >
> > Errata, the heap structure requires only 2 eeprom bytes to
maintain the
> > structure.
> >
> > regards peter
> >
> >
Original Message
> > From: "Peter Verkaik" <peterverkaik@b...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Tuesday, March 02, 2004 11:40 AM
> > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > Russ,
> > >
> > > I see your point. But both Basic stamp and javelin cannot hold a
> full 32KB
> > > eeprom image so multiple
> > > 'eeprom program cycles' will be required for a 32KB eeprom.
Block size
> > > changes for one cycle
> > > could impact on the other cycles, forcing code changes for
those other
> > > cycles.
> > > How about using an underlying structure that shows free and
allocated
> > blocks
> > > and that is recognized
> > > by basic stamp and javelin? That way available start and end
> addresses are
> > > retrieved from the eeprom
> > > itself. What I was thinking of is the javelin heap class I
wrote
> that I
> > can
> > > easily port to the basic stamp.
> > > Each block, either free or allocated, requires only 4 eeprom
bytes to
> > > maintain the heap structure.
> > > This structure is limited to a 32KB eeprom. A 64KB eeprom could
> hold two
> > > heap structures.
> > > Whatever you put in allocated blocks (could be another heap) is
up
> to the
> > > application.
> > > I suggest using signature words to identify allocated blocks.
> > >
> > > regards peter
> > >
> > >
Original Message
> > > From: "russranshaw" <home.rr@c...>
> > > To: <basicstamps@yahoogroups.com>
> > > Sent: Monday, March 01, 2004 7:07 PM
> > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > >
> > >
> > > > Peter,
> > > >
> > > > I have a similar idea, except what I envision is a "compiler"
that
> > > > runs on the PC and creates some Java classes, including the
menu
> > > > driver and a "setup" program. Within the setup program would
be a
> > > > character array that contained the data destined for the
EEPROM.
> Part
> > > > of the table description language would be information about
the
> > > > starting and ending EEPROM addresses. The user would have to
modify
> > > > the setup program to get the appropriate pin assignments,
driver
> > > > class(es) for the EEPROM, etc. My reason for thinking along
> this line
> > > > is that I have a 32k EEPROM, and have other sues for much of
it.
> > > >
> > > > Russ
> > > >
> > > >
> > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > <peterverkaik@b...> wrote:
> > > > > Thanks Jon for your N&V article.
> > > > > Russ, I uploaded something I pieced together. It will not
work
> as it
> > is
> > > > > incomplete.
> > > > > I defined a table setup to find out how much code would be
> needed to
> > > > > navigate
> > > > > through menus using tables. The size of the navigation code
is
> even
> > > > smaller
> > > > > than I expected.
> > > > >
> > > > > What I need is to run a setup program (like a PC bios) that
> has much
> > > > text,
> > > > > this is for the benefit of application end-users.
> > > > > This setup program will be for the javelin. To create the
tables I
> > > > use the
> > > > > BS
> > > > > because there is no DATA equivalent for the havelin, and
> programming
> > > > such
> > > > > menus
> > > > > inline in javelin code eats too much code space.
> > > > >
> > > > > I would like to discuss the layout of the tables. I am sure
they
> > > > could be
> > > > > better
> > > > > organized or perhaps even compacter or more general. The
idea
> is to
> > > > retrieve
> > > > > all required settings
> > > > > from the eeprom rather than hardcoded in the software.
> > > > >
> > > > > Comments please.
> > > > >
> > > > > regards peter
> > > > >
> > > > >
> > > > >
Original Message
> > > > > From: "russranshaw" <home.rr@c...>
> > > > > To: <basicstamps@yahoogroups.com>
> > > > > Sent: Sunday, February 29, 2004 4:07 PM
> > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > >
> > > > >
> > > > > > Peter,
> > > > > >
> > > > > > Could you give us a "fer-instance" of what it is you want
to
> > > > accomplish?
> > > > > >
> > > > > > I have a device (Solar Energy Inverter) that has an
imbedded
> micro
> > > > > > controller. It uses a menu system where there are several
> groups of
> > > > > > related menu items each of which has several sub-items.
> There are
> > > > > > three main types of sub-item. On lets you select
a "mode" using
> > left
> > > > > > and right arrow keys. Another uses the arrow keys to
> > > > > > increment/decrement a value. The third is simply
information.
> > > > > >
> > > > > > There are six control buttons in all. Two to select the
main
> > > > > > category, two to select the sub-category, and two as
mentioned
> > above.
> > > > > >
> > > > > > Such a scheme would be fairly simple to abstract, using
> EEPROM to
> > > > > > store the menu data.
> > > > > >
> > > > > > And I don't think it would be difficult to build
a "compler" to
> > stuff
> > > > > > the EEPROM!
> > > > > >
> > > > > > Would something on this order be what you're after?
> > > > > >
> > > > > > Russ
> > > > > >
> > > > > >
> > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > <peterverkaik@b...> wrote:
> > > > > > > I also found this
> > > > > > > http://www.imatix.com/html/libero/
> > > > > > > A free code generator for table driven design that
generates
> > > > > > > a framework for C or Java (perhaps useful for the
javelin)
> > > > > > > and a great number of other languages. Fast reading
through
> > > > > > > the docs it seems to be possible to add a 'schema' file
> (language
> > > > > > > specific framework file) for other languages, like
pbasic.
> > > > > > > I will read it closer to find out if this really is
possible.
> > > > > > >
> > > > > > > regards peter
> > > > > > >
> > > > > > >
Original Message
> > > > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
interface
> > > > > > >
> > > > > > >
> > > > > > > > I found this to be good reading material
> > > > > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > > > > It lacks however a working example in real code.
> > > > > > > > But the table descriptions (especially the decision
tables)
> > > > > > > > are good and when inplemented properly could/should
reduce
> > > > > > > > code by 30% or more.
> > > > > > > > The trick is to define rules, then use a table lookup
to
> > > > > > > > find all matching entries and executing the tasks
belonging
> > > > > > > > to the matching rules.
> > > > > > > >
> > > > > > > > regards peter
> > > > > > > >
> > > > > > > >
Original Message
> > > > > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
interface
> > > > > > > >
> > > > > > > >
> > > > > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > > > > >Peter,
> > > > > > > > > >
> > > > > > > > > >I have been thinking of something along the same
> lines. Care
> > > > > > to shre
> > > > > > > > > >some ideas? Using an EEPROM to store the table
> information
> > is
> > > > > > a good
> > > > > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > > > > >
> > > > > > > > > >In "the old days" there was a "programming
language"
> called
> > > > > > Decision
> > > > > > > > > >Tables. This was essentially a State Transition
> chart. I
> > can
> > > > > > think
> > > > > > > > > >of four elements:
> > > > > > > > > >
> > > > > > > > > >1. States
> > > > > > > > > >2. Events (essentially status bits set outside
the
> > > > table class)
> > > > > > > > > >3. Actions (same, set by the table class to
cause
> things
> > to
> > > > > > be done
> > > > > > > > > >4. Next State
> > > > > > > > > >
> > > > > > > > > >Imagine the States to be arranged vertically
(rows) and
> > Events
> > > > > > > > > >horizontally (columns). Each table intersection
can
> have a
> > > > set of
> > > > > > > > > >Actions and one Next state. I am currently doing
> this on a
> > > > Javelin
> > > > > > > > > >Stamp, but the table is hard-coded. I'd love to
> discuss a
> > > > way to
> > > > > > > > > >generalize it!
> > > > > > > > > >
> > > > > > > > > >Russ
> > > > > > > > >
> > > > > > > > > Russ and Peter -
> > > > > > > > >
> > > > > > > > > A very similar techniques is often used by operating
> system
> > task
> > > > > > > managers
> > > > > > > > in event driven systems. The last task in the task
table is
> > > > always the
> > > > > > > > system wait state.
> > > > > > > > > Hopefully the system never reaches that state,
other wise
> > > > nothing is
> > > > > > > being
> > > > > > > > done.
> > > > > > > > >
> > > > > > > > > Just thought I'd mention it, as it uses similar
tables and
> > keeps
> > > > > > track
> > > > > > > of
> > > > > > > > events, and the state of each of the events whether
active,
> > > > pending or
> > > > > > > > complete. One of the nice things about such a system
is the
> > > > > > ability to run
> > > > > > > > through the tables in a commutator fashion, only
paying
> > > > attention to
> > > > > > > tasks
> > > > > > > > or sub-tasks which need servicing and pretty much
> ignoring the
> > > > rest.
> > > > > > > > >
> > > > > > > > > These tasks are also set up in a linked-list scheme.
> Each task
> > > > > > points to
> > > > > > > > the next task, and back to the prior one. Generally
the task
> > list
> > > > > > is kept
> > > > > > > in
> > > > > > > > priority order, and changing the order is just a
matter of
> > > > > > changing the
> > > > > > > each
> > > > > > > > of the links appropriately.
> > > > > > > > >
> > > > > > > > > Getting this back on a Stamp topic, one of the
earlier
> > > > PBasic Stamp
> > > > > > > > Manuals, possibly Version 1.8 or prior, had a message
table
> > > > for LCD
> > > > > > > display,
> > > > > > > > if I remember correctly. I'll see if I can locate it,
> and if I
> > > > > > find it,
> > > > > > > I'll
> > > > > > > > pass it along.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Bruce Bates
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > > ><peterverkaik@b...> wrote:
> > > > > > > > > >> Hi,
> > > > > > > > > >>
> > > > > > > > > >> Can anybody point me to a working example of a
table
> > > > driven user
> > > > > > > > > >interface?
> > > > > > > > > >> Preferred output device is a serial text lcd 2x16
> or 4x20.
> > > > > > > > > >> Preferred input devices are keys.
> > > > > > > > > >> I would like to program a text intensive menu
> system into
> > > > a table
> > > > > > > > > >that is
> > > > > > > > > >> offloaded into external eeprom, and then parsing
that
> > > > table while
> > > > > > > > > >> inside the menu command.
> > > > > > > > > >> Program language may be pbasic, java or c.
> > > > > > > > > >>
> > > > > > > > > >> 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
>If I understand this approach, the goal of
>the "Table Driven Interface" is to have
>the display bytes stored in an off-chip
>EEPROM -- loaded through some method.
>
>The program then knows the 'base' addr.
>of each page in the EEPROM table. The
>software merely needs to know which addr
>to select -- then go to the EEPROM and
>transfer the image from the Table to the
>Display.
>
>If that's what you're talking about, then
>yes, the EEPROM loader program can be put
>into the Javelin. Some PC-based Display
>Generator program can generate the Display
>data, and load it into the EEPROM (through
>a simple program on the Javelin, or through
>an EEPROM burner, your choice). Then,
>the DisplayGen program needs to give you,
>the programmer, the table of start addr for
>the loaded 'screens'.
>
>Then, you supply those 'screen' start addr to
>your program, add the logic to navigate from
>screen to screen, and you are good to go.
>
>So, what's the problem with this approach?
>Sounds brilliant to me. You get the stand-alone
>nature of the Stamp, and nice screens from
>the EEPROM.
Perhaps a look at the SEETRON TRM-425 would be worthwhile. They do exactly what
you're attempting to do. They even provide a Windows program to enter the data
in the EEPROM. The web site is here: www.seetron.com .
Bruce Bates
<About 10K snipped!>
About cycles,
You mentioned you had also other uses for the eeprom, so the menu data is
only a part
of the total eeprom. If I fill part of the eeprom with menu data from a
basic stamp (that is one cycle),
I may also want to store other data for the runtime application (more
cycles), or fill parts from a PC,
either through stamp or javelin (again more cycles), then finally put the
controller with the runtime
application in place that uses the eeprom contents. To prevent changing
sources to apply moved
addresses all the time, I mentioned the heap as a simple way for each
controller to find out free eeprom areas.
Alan,
Not only screen (in this case LCD) data is put in eeprom, but also the
navigation data. Based on key inputs
you traverse the table until you reach a point where a value must be
assigned to a persistent parameter.
The code to traverse the table is small enough to add to the runtime
application.
I would like some comments on the table formats as I presented them in the
file I uploaded to the forum.
(in folder menu). I tried to insert an additional menu in the table today,
anf that was annoying (too many pointers
needed to be changed). The current format is not good enough for me with
respect to table maintenance.
Some clever ideas please.
regards peter.
Original Message
From: "Allan Lane" <allan.lane@h...>
To: <basicstamps@yahoogroups.com>
Sent: Tuesday, March 02, 2004 7:38 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> If I understand this approach, the goal of
> the "Table Driven Interface" is to have
> the display bytes stored in an off-chip
> EEPROM -- loaded through some method.
>
> The program then knows the 'base' addr.
> of each page in the EEPROM table. The
> software merely needs to know which addr
> to select -- then go to the EEPROM and
> transfer the image from the Table to the
> Display.
>
> If that's what you're talking about, then
> yes, the EEPROM loader program can be put
> into the Javelin. Some PC-based Display
> Generator program can generate the Display
> data, and load it into the EEPROM (through
> a simple program on the Javelin, or through
> an EEPROM burner, your choice). Then,
> the DisplayGen program needs to give you,
> the programmer, the table of start addr for
> the loaded 'screens'.
>
> Then, you supply those 'screen' start addr to
> your program, add the logic to navigate from
> screen to screen, and you are good to go.
>
> So, what's the problem with this approach?
> Sounds brilliant to me. You get the stand-alone
> nature of the Stamp, and nice screens from
> the EEPROM.
>
> --- In basicstamps@yahoogroups.com, "russranshaw" <home.rr@c...>
> wrote:
> > Peter,
> >
> > I'm not sure the elaborteness is justified. Those 32k EEPROMs are
> > pretty cheap ($5). Besides, I don't see even a very complex menu
> > requiring anywhere near 32k.
> >
> > If my original thought dosen't sit well (putting the entire
> structure
> > which is destined for the EEPROM in a Javelin program), then one
> could
> > write a generic Javelin program that would take a stream of data
> via a
> > serial port and write it to the EEPROM. If timing is a problem, it
> is
> > feasible to implement a simple error checking packetized protocol
> > which would request the next packet. That way it would be possible
> to
> > download some data, write it to the EEPROM, downloand the next
> chunk,
> > write it, etc. I don't see speed being a problem. I guess I don't
> > understand your point about "cycles".
> >
> > Russ
> >
> >
> >
> > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > <peterverkaik@b...> wrote:
> > > Russ,
> > >
> > > Errata, the heap structure requires only 2 eeprom bytes to
> maintain the
> > > structure.
> > >
> > > regards peter
> > >
> > >
Original Message
> > > From: "Peter Verkaik" <peterverkaik@b...>
> > > To: <basicstamps@yahoogroups.com>
> > > Sent: Tuesday, March 02, 2004 11:40 AM
> > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > >
> > >
> > > > Russ,
> > > >
> > > > I see your point. But both Basic stamp and javelin cannot hold a
> > full 32KB
> > > > eeprom image so multiple
> > > > 'eeprom program cycles' will be required for a 32KB eeprom.
> Block size
> > > > changes for one cycle
> > > > could impact on the other cycles, forcing code changes for
> those other
> > > > cycles.
> > > > How about using an underlying structure that shows free and
> allocated
> > > blocks
> > > > and that is recognized
> > > > by basic stamp and javelin? That way available start and end
> > addresses are
> > > > retrieved from the eeprom
> > > > itself. What I was thinking of is the javelin heap class I
> wrote
> > that I
> > > can
> > > > easily port to the basic stamp.
> > > > Each block, either free or allocated, requires only 4 eeprom
> bytes to
> > > > maintain the heap structure.
> > > > This structure is limited to a 32KB eeprom. A 64KB eeprom could
> > hold two
> > > > heap structures.
> > > > Whatever you put in allocated blocks (could be another heap) is
> up
> > to the
> > > > application.
> > > > I suggest using signature words to identify allocated blocks.
> > > >
> > > > regards peter
> > > >
> > > >
Original Message
> > > > From: "russranshaw" <home.rr@c...>
> > > > To: <basicstamps@yahoogroups.com>
> > > > Sent: Monday, March 01, 2004 7:07 PM
> > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > > Peter,
> > > > >
> > > > > I have a similar idea, except what I envision is a "compiler"
> that
> > > > > runs on the PC and creates some Java classes, including the
> menu
> > > > > driver and a "setup" program. Within the setup program would
> be a
> > > > > character array that contained the data destined for the
> EEPROM.
> > Part
> > > > > of the table description language would be information about
> the
> > > > > starting and ending EEPROM addresses. The user would have to
> modify
> > > > > the setup program to get the appropriate pin assignments,
> driver
> > > > > class(es) for the EEPROM, etc. My reason for thinking along
> > this line
> > > > > is that I have a 32k EEPROM, and have other sues for much of
> it.
> > > > >
> > > > > Russ
> > > > >
> > > > >
> > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > <peterverkaik@b...> wrote:
> > > > > > Thanks Jon for your N&V article.
> > > > > > Russ, I uploaded something I pieced together. It will not
> work
> > as it
> > > is
> > > > > > incomplete.
> > > > > > I defined a table setup to find out how much code would be
> > needed to
> > > > > > navigate
> > > > > > through menus using tables. The size of the navigation code
> is
> > even
> > > > > smaller
> > > > > > than I expected.
> > > > > >
> > > > > > What I need is to run a setup program (like a PC bios) that
> > has much
> > > > > text,
> > > > > > this is for the benefit of application end-users.
> > > > > > This setup program will be for the javelin. To create the
> tables I
> > > > > use the
> > > > > > BS
> > > > > > because there is no DATA equivalent for the havelin, and
> > programming
> > > > > such
> > > > > > menus
> > > > > > inline in javelin code eats too much code space.
> > > > > >
> > > > > > I would like to discuss the layout of the tables. I am sure
> they
> > > > > could be
> > > > > > better
> > > > > > organized or perhaps even compacter or more general. The
> idea
> > is to
> > > > > retrieve
> > > > > > all required settings
> > > > > > from the eeprom rather than hardcoded in the software.
> > > > > >
> > > > > > Comments please.
> > > > > >
> > > > > > regards peter
> > > > > >
> > > > > >
> > > > > >
Original Message
> > > > > > From: "russranshaw" <home.rr@c...>
> > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > Sent: Sunday, February 29, 2004 4:07 PM
> > > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > >
> > > > > >
> > > > > > > Peter,
> > > > > > >
> > > > > > > Could you give us a "fer-instance" of what it is you want
> to
> > > > > accomplish?
> > > > > > >
> > > > > > > I have a device (Solar Energy Inverter) that has an
> imbedded
> > micro
> > > > > > > controller. It uses a menu system where there are several
> > groups of
> > > > > > > related menu items each of which has several sub-items.
> > There are
> > > > > > > three main types of sub-item. On lets you select
> a "mode" using
> > > left
> > > > > > > and right arrow keys. Another uses the arrow keys to
> > > > > > > increment/decrement a value. The third is simply
> information.
> > > > > > >
> > > > > > > There are six control buttons in all. Two to select the
> main
> > > > > > > category, two to select the sub-category, and two as
> mentioned
> > > above.
> > > > > > >
> > > > > > > Such a scheme would be fairly simple to abstract, using
> > EEPROM to
> > > > > > > store the menu data.
> > > > > > >
> > > > > > > And I don't think it would be difficult to build
> a "compler" to
> > > stuff
> > > > > > > the EEPROM!
> > > > > > >
> > > > > > > Would something on this order be what you're after?
> > > > > > >
> > > > > > > Russ
> > > > > > >
> > > > > > >
> > > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > <peterverkaik@b...> wrote:
> > > > > > > > I also found this
> > > > > > > > http://www.imatix.com/html/libero/
> > > > > > > > A free code generator for table driven design that
> generates
> > > > > > > > a framework for C or Java (perhaps useful for the
> javelin)
> > > > > > > > and a great number of other languages. Fast reading
> through
> > > > > > > > the docs it seems to be possible to add a 'schema' file
> > (language
> > > > > > > > specific framework file) for other languages, like
> pbasic.
> > > > > > > > I will read it closer to find out if this really is
> possible.
> > > > > > > >
> > > > > > > > regards peter
> > > > > > > >
> > > > > > > >
Original Message
> > > > > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> interface
> > > > > > > >
> > > > > > > >
> > > > > > > > > I found this to be good reading material
> > > > > > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > > > > > It lacks however a working example in real code.
> > > > > > > > > But the table descriptions (especially the decision
> tables)
> > > > > > > > > are good and when inplemented properly could/should
> reduce
> > > > > > > > > code by 30% or more.
> > > > > > > > > The trick is to define rules, then use a table lookup
> to
> > > > > > > > > find all matching entries and executing the tasks
> belonging
> > > > > > > > > to the matching rules.
> > > > > > > > >
> > > > > > > > > regards peter
> > > > > > > > >
> > > > > > > > >
Original Message
> > > > > > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> interface
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > > > > > >Peter,
> > > > > > > > > > >
> > > > > > > > > > >I have been thinking of something along the same
> > lines. Care
> > > > > > > to shre
> > > > > > > > > > >some ideas? Using an EEPROM to store the table
> > information
> > > is
> > > > > > > a good
> > > > > > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > > > > > >
> > > > > > > > > > >In "the old days" there was a "programming
> language"
> > called
> > > > > > > Decision
> > > > > > > > > > >Tables. This was essentially a State Transition
> > chart. I
> > > can
> > > > > > > think
> > > > > > > > > > >of four elements:
> > > > > > > > > > >
> > > > > > > > > > >1. States
> > > > > > > > > > >2. Events (essentially status bits set outside
> the
> > > > > table class)
> > > > > > > > > > >3. Actions (same, set by the table class to
> cause
> > things
> > > to
> > > > > > > be done
> > > > > > > > > > >4. Next State
> > > > > > > > > > >
> > > > > > > > > > >Imagine the States to be arranged vertically
> (rows) and
> > > Events
> > > > > > > > > > >horizontally (columns). Each table intersection
> can
> > have a
> > > > > set of
> > > > > > > > > > >Actions and one Next state. I am currently doing
> > this on a
> > > > > Javelin
> > > > > > > > > > >Stamp, but the table is hard-coded. I'd love to
> > discuss a
> > > > > way to
> > > > > > > > > > >generalize it!
> > > > > > > > > > >
> > > > > > > > > > >Russ
> > > > > > > > > >
> > > > > > > > > > Russ and Peter -
> > > > > > > > > >
> > > > > > > > > > A very similar techniques is often used by operating
> > system
> > > task
> > > > > > > > managers
> > > > > > > > > in event driven systems. The last task in the task
> table is
> > > > > always the
> > > > > > > > > system wait state.
> > > > > > > > > > Hopefully the system never reaches that state,
> other wise
> > > > > nothing is
> > > > > > > > being
> > > > > > > > > done.
> > > > > > > > > >
> > > > > > > > > > Just thought I'd mention it, as it uses similar
> tables and
> > > keeps
> > > > > > > track
> > > > > > > > of
> > > > > > > > > events, and the state of each of the events whether
> active,
> > > > > pending or
> > > > > > > > > complete. One of the nice things about such a system
> is the
> > > > > > > ability to run
> > > > > > > > > through the tables in a commutator fashion, only
> paying
> > > > > attention to
> > > > > > > > tasks
> > > > > > > > > or sub-tasks which need servicing and pretty much
> > ignoring the
> > > > > rest.
> > > > > > > > > >
> > > > > > > > > > These tasks are also set up in a linked-list scheme.
> > Each task
> > > > > > > points to
> > > > > > > > > the next task, and back to the prior one. Generally
> the task
> > > list
> > > > > > > is kept
> > > > > > > > in
> > > > > > > > > priority order, and changing the order is just a
> matter of
> > > > > > > changing the
> > > > > > > > each
> > > > > > > > > of the links appropriately.
> > > > > > > > > >
> > > > > > > > > > Getting this back on a Stamp topic, one of the
> earlier
> > > > > PBasic Stamp
> > > > > > > > > Manuals, possibly Version 1.8 or prior, had a message
> table
> > > > > for LCD
> > > > > > > > display,
> > > > > > > > > if I remember correctly. I'll see if I can locate it,
> > and if I
> > > > > > > find it,
> > > > > > > > I'll
> > > > > > > > > pass it along.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Bruce Bates
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > > > ><peterverkaik@b...> wrote:
> > > > > > > > > > >> Hi,
> > > > > > > > > > >>
> > > > > > > > > > >> Can anybody point me to a working example of a
> table
> > > > > driven user
> > > > > > > > > > >interface?
> > > > > > > > > > >> Preferred output device is a serial text lcd 2x16
> > or 4x20.
> > > > > > > > > > >> Preferred input devices are keys.
> > > > > > > > > > >> I would like to program a text intensive menu
> > system into
> > > > > a table
> > > > > > > > > > >that is
> > > > > > > > > > >> offloaded into external eeprom, and then parsing
> that
> > > > > table while
> > > > > > > > > > >> inside the menu command.
> > > > > > > > > > >> Program language may be pbasic, java or c.
> > > > > > > > > > >>
> > > > > > > > > > >> 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
>
>
>
> 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
>
>
>
>
>
Here is what I envision:
1. Prepare a description of the Menu in a file. (I have some
ideas about this).
2. A Windows/whatever program translates the description and produces
one or more Java classes (or PBASIC code) and a file which is a
structured data representation of the menu's display text and navigation.
3. A Java (or PBASIC) program is started, and a Windows/whatever
program reads the data which is destined for the EEPROM and sends it
to the Stamp using some kind of send/wait with error checking
protocol. The Stamp program commits the data to the EEPROM.
4. The Java classes or PBASIC code snippets are combined with an
application program. The resulting program would contain code that
understands the EEPROM data structure. It displays, navigates, and
stores/modifies varuables as dictated by the original Menu description.
I was thinking about relying on a very simple EEPROM management
technique: the designer keeps track of what is where. For example,
put the Menu structure data in the last 4k of a 32k EEPROM and use the
rest of the EEPROM for whatever is needed. This shouldn't be terribly
unreasonable, as I don't forsee the menu data being terribly large for
most application. And if really needed, use dedicated EEPROMs for the
various functions. As I said earler, they are cheap.
Russ
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> About cycles,
> You mentioned you had also other uses for the eeprom, so the menu
data is
> only a part
> of the total eeprom. If I fill part of the eeprom with menu data from a
> basic stamp (that is one cycle),
> I may also want to store other data for the runtime application (more
> cycles), or fill parts from a PC,
> either through stamp or javelin (again more cycles), then finally
put the
> controller with the runtime
> application in place that uses the eeprom contents. To prevent changing
> sources to apply moved
> addresses all the time, I mentioned the heap as a simple way for each
> controller to find out free eeprom areas.
>
> Alan,
> Not only screen (in this case LCD) data is put in eeprom, but also the
> navigation data. Based on key inputs
> you traverse the table until you reach a point where a value must be
> assigned to a persistent parameter.
> The code to traverse the table is small enough to add to the runtime
> application.
>
> I would like some comments on the table formats as I presented them
in the
> file I uploaded to the forum.
> (in folder menu). I tried to insert an additional menu in the table
today,
> anf that was annoying (too many pointers
> needed to be changed). The current format is not good enough for me with
> respect to table maintenance.
> Some clever ideas please.
>
> regards peter.
>
>
>
Original Message
> From: "Allan Lane" <allan.lane@h...>
> To: <basicstamps@yahoogroups.com>
> Sent: Tuesday, March 02, 2004 7:38 PM
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > If I understand this approach, the goal of
> > the "Table Driven Interface" is to have
> > the display bytes stored in an off-chip
> > EEPROM -- loaded through some method.
> >
> > The program then knows the 'base' addr.
> > of each page in the EEPROM table. The
> > software merely needs to know which addr
> > to select -- then go to the EEPROM and
> > transfer the image from the Table to the
> > Display.
> >
> > If that's what you're talking about, then
> > yes, the EEPROM loader program can be put
> > into the Javelin. Some PC-based Display
> > Generator program can generate the Display
> > data, and load it into the EEPROM (through
> > a simple program on the Javelin, or through
> > an EEPROM burner, your choice). Then,
> > the DisplayGen program needs to give you,
> > the programmer, the table of start addr for
> > the loaded 'screens'.
> >
> > Then, you supply those 'screen' start addr to
> > your program, add the logic to navigate from
> > screen to screen, and you are good to go.
> >
> > So, what's the problem with this approach?
> > Sounds brilliant to me. You get the stand-alone
> > nature of the Stamp, and nice screens from
> > the EEPROM.
> >
> > --- In basicstamps@yahoogroups.com, "russranshaw" <home.rr@c...>
> > wrote:
> > > Peter,
> > >
> > > I'm not sure the elaborteness is justified. Those 32k EEPROMs are
> > > pretty cheap ($5). Besides, I don't see even a very complex menu
> > > requiring anywhere near 32k.
> > >
> > > If my original thought dosen't sit well (putting the entire
> > structure
> > > which is destined for the EEPROM in a Javelin program), then one
> > could
> > > write a generic Javelin program that would take a stream of data
> > via a
> > > serial port and write it to the EEPROM. If timing is a problem, it
> > is
> > > feasible to implement a simple error checking packetized protocol
> > > which would request the next packet. That way it would be possible
> > to
> > > download some data, write it to the EEPROM, downloand the next
> > chunk,
> > > write it, etc. I don't see speed being a problem. I guess I don't
> > > understand your point about "cycles".
> > >
> > > Russ
> > >
> > >
> > >
> > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > <peterverkaik@b...> wrote:
> > > > Russ,
> > > >
> > > > Errata, the heap structure requires only 2 eeprom bytes to
> > maintain the
> > > > structure.
> > > >
> > > > regards peter
> > > >
> > > >
Original Message
> > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > To: <basicstamps@yahoogroups.com>
> > > > Sent: Tuesday, March 02, 2004 11:40 AM
> > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > > Russ,
> > > > >
> > > > > I see your point. But both Basic stamp and javelin cannot hold a
> > > full 32KB
> > > > > eeprom image so multiple
> > > > > 'eeprom program cycles' will be required for a 32KB eeprom.
> > Block size
> > > > > changes for one cycle
> > > > > could impact on the other cycles, forcing code changes for
> > those other
> > > > > cycles.
> > > > > How about using an underlying structure that shows free and
> > allocated
> > > > blocks
> > > > > and that is recognized
> > > > > by basic stamp and javelin? That way available start and end
> > > addresses are
> > > > > retrieved from the eeprom
> > > > > itself. What I was thinking of is the javelin heap class I
> > wrote
> > > that I
> > > > can
> > > > > easily port to the basic stamp.
> > > > > Each block, either free or allocated, requires only 4 eeprom
> > bytes to
> > > > > maintain the heap structure.
> > > > > This structure is limited to a 32KB eeprom. A 64KB eeprom could
> > > hold two
> > > > > heap structures.
> > > > > Whatever you put in allocated blocks (could be another heap) is
> > up
> > > to the
> > > > > application.
> > > > > I suggest using signature words to identify allocated blocks.
> > > > >
> > > > > regards peter
> > > > >
> > > > >
Original Message
> > > > > From: "russranshaw" <home.rr@c...>
> > > > > To: <basicstamps@yahoogroups.com>
> > > > > Sent: Monday, March 01, 2004 7:07 PM
> > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > >
> > > > >
> > > > > > Peter,
> > > > > >
> > > > > > I have a similar idea, except what I envision is a "compiler"
> > that
> > > > > > runs on the PC and creates some Java classes, including the
> > menu
> > > > > > driver and a "setup" program. Within the setup program would
> > be a
> > > > > > character array that contained the data destined for the
> > EEPROM.
> > > Part
> > > > > > of the table description language would be information about
> > the
> > > > > > starting and ending EEPROM addresses. The user would have to
> > modify
> > > > > > the setup program to get the appropriate pin assignments,
> > driver
> > > > > > class(es) for the EEPROM, etc. My reason for thinking along
> > > this line
> > > > > > is that I have a 32k EEPROM, and have other sues for much of
> > it.
> > > > > >
> > > > > > Russ
> > > > > >
> > > > > >
> > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > <peterverkaik@b...> wrote:
> > > > > > > Thanks Jon for your N&V article.
> > > > > > > Russ, I uploaded something I pieced together. It will not
> > work
> > > as it
> > > > is
> > > > > > > incomplete.
> > > > > > > I defined a table setup to find out how much code would be
> > > needed to
> > > > > > > navigate
> > > > > > > through menus using tables. The size of the navigation code
> > is
> > > even
> > > > > > smaller
> > > > > > > than I expected.
> > > > > > >
> > > > > > > What I need is to run a setup program (like a PC bios) that
> > > has much
> > > > > > text,
> > > > > > > this is for the benefit of application end-users.
> > > > > > > This setup program will be for the javelin. To create the
> > tables I
> > > > > > use the
> > > > > > > BS
> > > > > > > because there is no DATA equivalent for the havelin, and
> > > programming
> > > > > > such
> > > > > > > menus
> > > > > > > inline in javelin code eats too much code space.
> > > > > > >
> > > > > > > I would like to discuss the layout of the tables. I am sure
> > they
> > > > > > could be
> > > > > > > better
> > > > > > > organized or perhaps even compacter or more general. The
> > idea
> > > is to
> > > > > > retrieve
> > > > > > > all required settings
> > > > > > > from the eeprom rather than hardcoded in the software.
> > > > > > >
> > > > > > > Comments please.
> > > > > > >
> > > > > > > regards peter
> > > > > > >
> > > > > > >
> > > > > > >
Original Message
> > > > > > > From: "russranshaw" <home.rr@c...>
> > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > Sent: Sunday, February 29, 2004 4:07 PM
> > > > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > > >
> > > > > > >
> > > > > > > > Peter,
> > > > > > > >
> > > > > > > > Could you give us a "fer-instance" of what it is you want
> > to
> > > > > > accomplish?
> > > > > > > >
> > > > > > > > I have a device (Solar Energy Inverter) that has an
> > imbedded
> > > micro
> > > > > > > > controller. It uses a menu system where there are several
> > > groups of
> > > > > > > > related menu items each of which has several sub-items.
> > > There are
> > > > > > > > three main types of sub-item. On lets you select
> > a "mode" using
> > > > left
> > > > > > > > and right arrow keys. Another uses the arrow keys to
> > > > > > > > increment/decrement a value. The third is simply
> > information.
> > > > > > > >
> > > > > > > > There are six control buttons in all. Two to select the
> > main
> > > > > > > > category, two to select the sub-category, and two as
> > mentioned
> > > > above.
> > > > > > > >
> > > > > > > > Such a scheme would be fairly simple to abstract, using
> > > EEPROM to
> > > > > > > > store the menu data.
> > > > > > > >
> > > > > > > > And I don't think it would be difficult to build
> > a "compler" to
> > > > stuff
> > > > > > > > the EEPROM!
> > > > > > > >
> > > > > > > > Would something on this order be what you're after?
> > > > > > > >
> > > > > > > > Russ
> > > > > > > >
> > > > > > > >
> > > > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > <peterverkaik@b...> wrote:
> > > > > > > > > I also found this
> > > > > > > > > http://www.imatix.com/html/libero/
> > > > > > > > > A free code generator for table driven design that
> > generates
> > > > > > > > > a framework for C or Java (perhaps useful for the
> > javelin)
> > > > > > > > > and a great number of other languages. Fast reading
> > through
> > > > > > > > > the docs it seems to be possible to add a 'schema' file
> > > (language
> > > > > > > > > specific framework file) for other languages, like
> > pbasic.
> > > > > > > > > I will read it closer to find out if this really is
> > possible.
> > > > > > > > >
> > > > > > > > > regards peter
> > > > > > > > >
> > > > > > > > >
Original Message
> > > > > > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> > interface
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > I found this to be good reading material
> > > > > > > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > > > > > > It lacks however a working example in real code.
> > > > > > > > > > But the table descriptions (especially the decision
> > tables)
> > > > > > > > > > are good and when inplemented properly could/should
> > reduce
> > > > > > > > > > code by 30% or more.
> > > > > > > > > > The trick is to define rules, then use a table lookup
> > to
> > > > > > > > > > find all matching entries and executing the tasks
> > belonging
> > > > > > > > > > to the matching rules.
> > > > > > > > > >
> > > > > > > > > > regards peter
> > > > > > > > > >
> > > > > > > > > >
Original Message
> > > > > > > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> > interface
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > > > > > > >Peter,
> > > > > > > > > > > >
> > > > > > > > > > > >I have been thinking of something along the same
> > > lines. Care
> > > > > > > > to shre
> > > > > > > > > > > >some ideas? Using an EEPROM to store the table
> > > information
> > > > is
> > > > > > > > a good
> > > > > > > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > > > > > > >
> > > > > > > > > > > >In "the old days" there was a "programming
> > language"
> > > called
> > > > > > > > Decision
> > > > > > > > > > > >Tables. This was essentially a State Transition
> > > chart. I
> > > > can
> > > > > > > > think
> > > > > > > > > > > >of four elements:
> > > > > > > > > > > >
> > > > > > > > > > > >1. States
> > > > > > > > > > > >2. Events (essentially status bits set outside
> > the
> > > > > > table class)
> > > > > > > > > > > >3. Actions (same, set by the table class to
> > cause
> > > things
> > > > to
> > > > > > > > be done
> > > > > > > > > > > >4. Next State
> > > > > > > > > > > >
> > > > > > > > > > > >Imagine the States to be arranged vertically
> > (rows) and
> > > > Events
> > > > > > > > > > > >horizontally (columns). Each table intersection
> > can
> > > have a
> > > > > > set of
> > > > > > > > > > > >Actions and one Next state. I am currently doing
> > > this on a
> > > > > > Javelin
> > > > > > > > > > > >Stamp, but the table is hard-coded. I'd love to
> > > discuss a
> > > > > > way to
> > > > > > > > > > > >generalize it!
> > > > > > > > > > > >
> > > > > > > > > > > >Russ
> > > > > > > > > > >
> > > > > > > > > > > Russ and Peter -
> > > > > > > > > > >
> > > > > > > > > > > A very similar techniques is often used by operating
> > > system
> > > > task
> > > > > > > > > managers
> > > > > > > > > > in event driven systems. The last task in the task
> > table is
> > > > > > always the
> > > > > > > > > > system wait state.
> > > > > > > > > > > Hopefully the system never reaches that state,
> > other wise
> > > > > > nothing is
> > > > > > > > > being
> > > > > > > > > > done.
> > > > > > > > > > >
> > > > > > > > > > > Just thought I'd mention it, as it uses similar
> > tables and
> > > > keeps
> > > > > > > > track
> > > > > > > > > of
> > > > > > > > > > events, and the state of each of the events whether
> > active,
> > > > > > pending or
> > > > > > > > > > complete. One of the nice things about such a system
> > is the
> > > > > > > > ability to run
> > > > > > > > > > through the tables in a commutator fashion, only
> > paying
> > > > > > attention to
> > > > > > > > > tasks
> > > > > > > > > > or sub-tasks which need servicing and pretty much
> > > ignoring the
> > > > > > rest.
> > > > > > > > > > >
> > > > > > > > > > > These tasks are also set up in a linked-list scheme.
> > > Each task
> > > > > > > > points to
> > > > > > > > > > the next task, and back to the prior one. Generally
> > the task
> > > > list
> > > > > > > > is kept
> > > > > > > > > in
> > > > > > > > > > priority order, and changing the order is just a
> > matter of
> > > > > > > > changing the
> > > > > > > > > each
> > > > > > > > > > of the links appropriately.
> > > > > > > > > > >
> > > > > > > > > > > Getting this back on a Stamp topic, one of the
> > earlier
> > > > > > PBasic Stamp
> > > > > > > > > > Manuals, possibly Version 1.8 or prior, had a message
> > table
> > > > > > for LCD
> > > > > > > > > display,
> > > > > > > > > > if I remember correctly. I'll see if I can locate it,
> > > and if I
> > > > > > > > find it,
> > > > > > > > > I'll
> > > > > > > > > > pass it along.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > >
> > > > > > > > > > > Bruce Bates
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > > > > ><peterverkaik@b...> wrote:
> > > > > > > > > > > >> Hi,
> > > > > > > > > > > >>
> > > > > > > > > > > >> Can anybody point me to a working example of a
> > table
> > > > > > driven user
> > > > > > > > > > > >interface?
> > > > > > > > > > > >> Preferred output device is a serial text lcd 2x16
> > > or 4x20.
> > > > > > > > > > > >> Preferred input devices are keys.
> > > > > > > > > > > >> I would like to program a text intensive menu
> > > system into
> > > > > > a table
> > > > > > > > > > > >that is
> > > > > > > > > > > >> offloaded into external eeprom, and then parsing
> > that
> > > > > > table while
> > > > > > > > > > > >> inside the menu command.
> > > > > > > > > > > >> Program language may be pbasic, java or c.
> > > > > > > > > > > >>
> > > > > > > > > > > >> 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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
I'm starting a clean slate for this.
Here is a simple idea for setting up a Menu structure:
1.0 Main Menu Item
1.1 First sub-item
bLIST AAA, BBB, CCC
1.2 Second sub-item
iLIST VVV = ('DDD', 23), ('EEE', 123), ('FFF', 987)
1.3 Third sub-item
dITEM 'The value is: ' FOO (3.1)
1.3.1 A third tier menu item
2.0 Second Main Menu Item
etc.
"bLIST" refers t Boolean variables. iLIST to integer variables.
dITEM is used to display a descriptive text followed by an optionally
formatted value (in this case, display as 123.4).
The symantics of the LISTs are: Display the list of names. The user
navigates to a particular choice (suitable indication woul dhave to be
used on the LCD), then when the menu entry is cleared that particular
In the case of dITEM, the user can increment or decrement the value.
The "compiler" translates the AAA, BBB, CCC, VVV into varibles as follows:
static boolean bvarAAA
static boolean bvarBBB
static boolean bvarCCC
static int VVV
static int FOO
Not terrible pretty, but food for thought!
Russ
That would be a nice tool, but regardless of how to fill the eeprom, we
should
define the table formats first. The idea is to have a single piece of code
for the application
program that traverses the tables, no matter how many menu levels there are.
For the
javelin then only a single class is required (no need to generate classes
for each new menu)
for which you define the eeprom start address for the menu data. For pbasic
a traverse
subroutine could be written to include in application programs.
About storage requirements, I defined full screens for a 4x20 lcd, so 80
bytes per screen.
My application requires about 100 persistent parameters (some are array
based) which
in worse case could lead to at least 8000 bytes of required eeprom space.
If possible I rather not define full screen text for each parameters, but
this too is part
of the table format, which we should define first.
Have you any ideas for the tables, including navigation?
regards peter
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Tuesday, March 02, 2004 10:27 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> Here is what I envision:
>
> 1. Prepare a description of the Menu in a file. (I have some
> ideas about this).
> 2. A Windows/whatever program translates the description and produces
> one or more Java classes (or PBASIC code) and a file which is a
> structured data representation of the menu's display text and navigation.
> 3. A Java (or PBASIC) program is started, and a Windows/whatever
> program reads the data which is destined for the EEPROM and sends it
> to the Stamp using some kind of send/wait with error checking
> protocol. The Stamp program commits the data to the EEPROM.
> 4. The Java classes or PBASIC code snippets are combined with an
> application program. The resulting program would contain code that
> understands the EEPROM data structure. It displays, navigates, and
> stores/modifies varuables as dictated by the original Menu description.
>
> I was thinking about relying on a very simple EEPROM management
> technique: the designer keeps track of what is where. For example,
> put the Menu structure data in the last 4k of a 32k EEPROM and use the
> rest of the EEPROM for whatever is needed. This shouldn't be terribly
> unreasonable, as I don't forsee the menu data being terribly large for
> most application. And if really needed, use dedicated EEPROMs for the
> various functions. As I said earler, they are cheap.
>
> Russ
>
> --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> <peterverkaik@b...> wrote:
> > Russ,
> >
> > About cycles,
> > You mentioned you had also other uses for the eeprom, so the menu
> data is
> > only a part
> > of the total eeprom. If I fill part of the eeprom with menu data from a
> > basic stamp (that is one cycle),
> > I may also want to store other data for the runtime application (more
> > cycles), or fill parts from a PC,
> > either through stamp or javelin (again more cycles), then finally
> put the
> > controller with the runtime
> > application in place that uses the eeprom contents. To prevent changing
> > sources to apply moved
> > addresses all the time, I mentioned the heap as a simple way for each
> > controller to find out free eeprom areas.
> >
> > Alan,
> > Not only screen (in this case LCD) data is put in eeprom, but also the
> > navigation data. Based on key inputs
> > you traverse the table until you reach a point where a value must be
> > assigned to a persistent parameter.
> > The code to traverse the table is small enough to add to the runtime
> > application.
> >
> > I would like some comments on the table formats as I presented them
> in the
> > file I uploaded to the forum.
> > (in folder menu). I tried to insert an additional menu in the table
> today,
> > anf that was annoying (too many pointers
> > needed to be changed). The current format is not good enough for me with
> > respect to table maintenance.
> > Some clever ideas please.
> >
> > regards peter.
> >
> >
> >
Original Message
> > From: "Allan Lane" <allan.lane@h...>
> > To: <basicstamps@yahoogroups.com>
> > Sent: Tuesday, March 02, 2004 7:38 PM
> > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> >
> >
> > > If I understand this approach, the goal of
> > > the "Table Driven Interface" is to have
> > > the display bytes stored in an off-chip
> > > EEPROM -- loaded through some method.
> > >
> > > The program then knows the 'base' addr.
> > > of each page in the EEPROM table. The
> > > software merely needs to know which addr
> > > to select -- then go to the EEPROM and
> > > transfer the image from the Table to the
> > > Display.
> > >
> > > If that's what you're talking about, then
> > > yes, the EEPROM loader program can be put
> > > into the Javelin. Some PC-based Display
> > > Generator program can generate the Display
> > > data, and load it into the EEPROM (through
> > > a simple program on the Javelin, or through
> > > an EEPROM burner, your choice). Then,
> > > the DisplayGen program needs to give you,
> > > the programmer, the table of start addr for
> > > the loaded 'screens'.
> > >
> > > Then, you supply those 'screen' start addr to
> > > your program, add the logic to navigate from
> > > screen to screen, and you are good to go.
> > >
> > > So, what's the problem with this approach?
> > > Sounds brilliant to me. You get the stand-alone
> > > nature of the Stamp, and nice screens from
> > > the EEPROM.
> > >
> > > --- In basicstamps@yahoogroups.com, "russranshaw" <home.rr@c...>
> > > wrote:
> > > > Peter,
> > > >
> > > > I'm not sure the elaborteness is justified. Those 32k EEPROMs are
> > > > pretty cheap ($5). Besides, I don't see even a very complex menu
> > > > requiring anywhere near 32k.
> > > >
> > > > If my original thought dosen't sit well (putting the entire
> > > structure
> > > > which is destined for the EEPROM in a Javelin program), then one
> > > could
> > > > write a generic Javelin program that would take a stream of data
> > > via a
> > > > serial port and write it to the EEPROM. If timing is a problem, it
> > > is
> > > > feasible to implement a simple error checking packetized protocol
> > > > which would request the next packet. That way it would be possible
> > > to
> > > > download some data, write it to the EEPROM, downloand the next
> > > chunk,
> > > > write it, etc. I don't see speed being a problem. I guess I don't
> > > > understand your point about "cycles".
> > > >
> > > > Russ
> > > >
> > > >
> > > >
> > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > <peterverkaik@b...> wrote:
> > > > > Russ,
> > > > >
> > > > > Errata, the heap structure requires only 2 eeprom bytes to
> > > maintain the
> > > > > structure.
> > > > >
> > > > > regards peter
> > > > >
> > > > >
Original Message
> > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > To: <basicstamps@yahoogroups.com>
> > > > > Sent: Tuesday, March 02, 2004 11:40 AM
> > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > >
> > > > >
> > > > > > Russ,
> > > > > >
> > > > > > I see your point. But both Basic stamp and javelin cannot hold a
> > > > full 32KB
> > > > > > eeprom image so multiple
> > > > > > 'eeprom program cycles' will be required for a 32KB eeprom.
> > > Block size
> > > > > > changes for one cycle
> > > > > > could impact on the other cycles, forcing code changes for
> > > those other
> > > > > > cycles.
> > > > > > How about using an underlying structure that shows free and
> > > allocated
> > > > > blocks
> > > > > > and that is recognized
> > > > > > by basic stamp and javelin? That way available start and end
> > > > addresses are
> > > > > > retrieved from the eeprom
> > > > > > itself. What I was thinking of is the javelin heap class I
> > > wrote
> > > > that I
> > > > > can
> > > > > > easily port to the basic stamp.
> > > > > > Each block, either free or allocated, requires only 4 eeprom
> > > bytes to
> > > > > > maintain the heap structure.
> > > > > > This structure is limited to a 32KB eeprom. A 64KB eeprom could
> > > > hold two
> > > > > > heap structures.
> > > > > > Whatever you put in allocated blocks (could be another heap) is
> > > up
> > > > to the
> > > > > > application.
> > > > > > I suggest using signature words to identify allocated blocks.
> > > > > >
> > > > > > regards peter
> > > > > >
> > > > > >
Original Message
> > > > > > From: "russranshaw" <home.rr@c...>
> > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > Sent: Monday, March 01, 2004 7:07 PM
> > > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > >
> > > > > >
> > > > > > > Peter,
> > > > > > >
> > > > > > > I have a similar idea, except what I envision is a "compiler"
> > > that
> > > > > > > runs on the PC and creates some Java classes, including the
> > > menu
> > > > > > > driver and a "setup" program. Within the setup program would
> > > be a
> > > > > > > character array that contained the data destined for the
> > > EEPROM.
> > > > Part
> > > > > > > of the table description language would be information about
> > > the
> > > > > > > starting and ending EEPROM addresses. The user would have to
> > > modify
> > > > > > > the setup program to get the appropriate pin assignments,
> > > driver
> > > > > > > class(es) for the EEPROM, etc. My reason for thinking along
> > > > this line
> > > > > > > is that I have a 32k EEPROM, and have other sues for much of
> > > it.
> > > > > > >
> > > > > > > Russ
> > > > > > >
> > > > > > >
> > > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > <peterverkaik@b...> wrote:
> > > > > > > > Thanks Jon for your N&V article.
> > > > > > > > Russ, I uploaded something I pieced together. It will not
> > > work
> > > > as it
> > > > > is
> > > > > > > > incomplete.
> > > > > > > > I defined a table setup to find out how much code would be
> > > > needed to
> > > > > > > > navigate
> > > > > > > > through menus using tables. The size of the navigation code
> > > is
> > > > even
> > > > > > > smaller
> > > > > > > > than I expected.
> > > > > > > >
> > > > > > > > What I need is to run a setup program (like a PC bios) that
> > > > has much
> > > > > > > text,
> > > > > > > > this is for the benefit of application end-users.
> > > > > > > > This setup program will be for the javelin. To create the
> > > tables I
> > > > > > > use the
> > > > > > > > BS
> > > > > > > > because there is no DATA equivalent for the havelin, and
> > > > programming
> > > > > > > such
> > > > > > > > menus
> > > > > > > > inline in javelin code eats too much code space.
> > > > > > > >
> > > > > > > > I would like to discuss the layout of the tables. I am sure
> > > they
> > > > > > > could be
> > > > > > > > better
> > > > > > > > organized or perhaps even compacter or more general. The
> > > idea
> > > > is to
> > > > > > > retrieve
> > > > > > > > all required settings
> > > > > > > > from the eeprom rather than hardcoded in the software.
> > > > > > > >
> > > > > > > > Comments please.
> > > > > > > >
> > > > > > > > regards peter
> > > > > > > >
> > > > > > > >
> > > > > > > >
Original Message
> > > > > > > > From: "russranshaw" <home.rr@c...>
> > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > Sent: Sunday, February 29, 2004 4:07 PM
> > > > > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > > > >
> > > > > > > >
> > > > > > > > > Peter,
> > > > > > > > >
> > > > > > > > > Could you give us a "fer-instance" of what it is you want
> > > to
> > > > > > > accomplish?
> > > > > > > > >
> > > > > > > > > I have a device (Solar Energy Inverter) that has an
> > > imbedded
> > > > micro
> > > > > > > > > controller. It uses a menu system where there are several
> > > > groups of
> > > > > > > > > related menu items each of which has several sub-items.
> > > > There are
> > > > > > > > > three main types of sub-item. On lets you select
> > > a "mode" using
> > > > > left
> > > > > > > > > and right arrow keys. Another uses the arrow keys to
> > > > > > > > > increment/decrement a value. The third is simply
> > > information.
> > > > > > > > >
> > > > > > > > > There are six control buttons in all. Two to select the
> > > main
> > > > > > > > > category, two to select the sub-category, and two as
> > > mentioned
> > > > > above.
> > > > > > > > >
> > > > > > > > > Such a scheme would be fairly simple to abstract, using
> > > > EEPROM to
> > > > > > > > > store the menu data.
> > > > > > > > >
> > > > > > > > > And I don't think it would be difficult to build
> > > a "compler" to
> > > > > stuff
> > > > > > > > > the EEPROM!
> > > > > > > > >
> > > > > > > > > Would something on this order be what you're after?
> > > > > > > > >
> > > > > > > > > Russ
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > > <peterverkaik@b...> wrote:
> > > > > > > > > > I also found this
> > > > > > > > > > http://www.imatix.com/html/libero/
> > > > > > > > > > A free code generator for table driven design that
> > > generates
> > > > > > > > > > a framework for C or Java (perhaps useful for the
> > > javelin)
> > > > > > > > > > and a great number of other languages. Fast reading
> > > through
> > > > > > > > > > the docs it seems to be possible to add a 'schema' file
> > > > (language
> > > > > > > > > > specific framework file) for other languages, like
> > > pbasic.
> > > > > > > > > > I will read it closer to find out if this really is
> > > possible.
> > > > > > > > > >
> > > > > > > > > > regards peter
> > > > > > > > > >
> > > > > > > > > >
Original Message
> > > > > > > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> > > interface
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > I found this to be good reading material
> > > > > > > > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > > > > > > > It lacks however a working example in real code.
> > > > > > > > > > > But the table descriptions (especially the decision
> > > tables)
> > > > > > > > > > > are good and when inplemented properly could/should
> > > reduce
> > > > > > > > > > > code by 30% or more.
> > > > > > > > > > > The trick is to define rules, then use a table lookup
> > > to
> > > > > > > > > > > find all matching entries and executing the tasks
> > > belonging
> > > > > > > > > > > to the matching rules.
> > > > > > > > > > >
> > > > > > > > > > > regards peter
> > > > > > > > > > >
> > > > > > > > > > >
Original Message
> > > > > > > > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> > > interface
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > > > > > > > >Peter,
> > > > > > > > > > > > >
> > > > > > > > > > > > >I have been thinking of something along the same
> > > > lines. Care
> > > > > > > > > to shre
> > > > > > > > > > > > >some ideas? Using an EEPROM to store the table
> > > > information
> > > > > is
> > > > > > > > > a good
> > > > > > > > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > > > > > > > >
> > > > > > > > > > > > >In "the old days" there was a "programming
> > > language"
> > > > called
> > > > > > > > > Decision
> > > > > > > > > > > > >Tables. This was essentially a State Transition
> > > > chart. I
> > > > > can
> > > > > > > > > think
> > > > > > > > > > > > >of four elements:
> > > > > > > > > > > > >
> > > > > > > > > > > > >1. States
> > > > > > > > > > > > >2. Events (essentially status bits set outside
> > > the
> > > > > > > table class)
> > > > > > > > > > > > >3. Actions (same, set by the table class to
> > > cause
> > > > things
> > > > > to
> > > > > > > > > be done
> > > > > > > > > > > > >4. Next State
> > > > > > > > > > > > >
> > > > > > > > > > > > >Imagine the States to be arranged vertically
> > > (rows) and
> > > > > Events
> > > > > > > > > > > > >horizontally (columns). Each table intersection
> > > can
> > > > have a
> > > > > > > set of
> > > > > > > > > > > > >Actions and one Next state. I am currently doing
> > > > this on a
> > > > > > > Javelin
> > > > > > > > > > > > >Stamp, but the table is hard-coded. I'd love to
> > > > discuss a
> > > > > > > way to
> > > > > > > > > > > > >generalize it!
> > > > > > > > > > > > >
> > > > > > > > > > > > >Russ
> > > > > > > > > > > >
> > > > > > > > > > > > Russ and Peter -
> > > > > > > > > > > >
> > > > > > > > > > > > A very similar techniques is often used by operating
> > > > system
> > > > > task
> > > > > > > > > > managers
> > > > > > > > > > > in event driven systems. The last task in the task
> > > table is
> > > > > > > always the
> > > > > > > > > > > system wait state.
> > > > > > > > > > > > Hopefully the system never reaches that state,
> > > other wise
> > > > > > > nothing is
> > > > > > > > > > being
> > > > > > > > > > > done.
> > > > > > > > > > > >
> > > > > > > > > > > > Just thought I'd mention it, as it uses similar
> > > tables and
> > > > > keeps
> > > > > > > > > track
> > > > > > > > > > of
> > > > > > > > > > > events, and the state of each of the events whether
> > > active,
> > > > > > > pending or
> > > > > > > > > > > complete. One of the nice things about such a system
> > > is the
> > > > > > > > > ability to run
> > > > > > > > > > > through the tables in a commutator fashion, only
> > > paying
> > > > > > > attention to
> > > > > > > > > > tasks
> > > > > > > > > > > or sub-tasks which need servicing and pretty much
> > > > ignoring the
> > > > > > > rest.
> > > > > > > > > > > >
> > > > > > > > > > > > These tasks are also set up in a linked-list scheme.
> > > > Each task
> > > > > > > > > points to
> > > > > > > > > > > the next task, and back to the prior one. Generally
> > > the task
> > > > > list
> > > > > > > > > is kept
> > > > > > > > > > in
> > > > > > > > > > > priority order, and changing the order is just a
> > > matter of
> > > > > > > > > changing the
> > > > > > > > > > each
> > > > > > > > > > > of the links appropriately.
> > > > > > > > > > > >
> > > > > > > > > > > > Getting this back on a Stamp topic, one of the
> > > earlier
> > > > > > > PBasic Stamp
> > > > > > > > > > > Manuals, possibly Version 1.8 or prior, had a message
> > > table
> > > > > > > for LCD
> > > > > > > > > > display,
> > > > > > > > > > > if I remember correctly. I'll see if I can locate it,
> > > > and if I
> > > > > > > > > find it,
> > > > > > > > > > I'll
> > > > > > > > > > > pass it along.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > >
> > > > > > > > > > > > Bruce Bates
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >--- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > > > > > ><peterverkaik@b...> wrote:
> > > > > > > > > > > > >> Hi,
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> Can anybody point me to a working example of a
> > > table
> > > > > > > driven user
> > > > > > > > > > > > >interface?
> > > > > > > > > > > > >> Preferred output device is a serial text lcd 2x16
> > > > or 4x20.
> > > > > > > > > > > > >> Preferred input devices are keys.
> > > > > > > > > > > > >> I would like to program a text intensive menu
> > > > system into
> > > > > > > a table
> > > > > > > > > > > > >that is
> > > > > > > > > > > > >> offloaded into external eeprom, and then parsing
> > > that
> > > > > > > table while
> > > > > > > > > > > > >> inside the menu command.
> > > > > > > > > > > > >> Program language may be pbasic, java or c.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> 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
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > >
> > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
>
>
>
> 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
>
>
>
>
>
excel spreadsheet. Then I would put the
link destinations in adjacent cells.
Then I would write a simple excel macro to
traverse the worksheet, writing out the
appropriate 'data' statements to a text file.
I would then cut-and-paste the text
file into the BSX file so when run it
would write the results into the EEPROM.
--- In basicstamps@yahoogroups.com, "Peter Verkaik"
<peterverkaik@b...> wrote:
> Russ,
>
> About cycles,
> You mentioned you had also other uses for the eeprom, so the menu
data is
> only a part
> of the total eeprom. If I fill part of the eeprom with menu data
from a
> basic stamp (that is one cycle),
> I may also want to store other data for the runtime application
(more
> cycles), or fill parts from a PC,
> either through stamp or javelin (again more cycles), then finally
put the
> controller with the runtime
> application in place that uses the eeprom contents. To prevent
changing
> sources to apply moved
> addresses all the time, I mentioned the heap as a simple way for
each
> controller to find out free eeprom areas.
>
> Alan,
> Not only screen (in this case LCD) data is put in eeprom, but also
the
> navigation data. Based on key inputs
> you traverse the table until you reach a point where a value must be
> assigned to a persistent parameter.
> The code to traverse the table is small enough to add to the runtime
> application.
>
> I would like some comments on the table formats as I presented them
in the
> file I uploaded to the forum.
> (in folder menu). I tried to insert an additional menu in the table
today,
> anf that was annoying (too many pointers
> needed to be changed). The current format is not good enough for me
with
> respect to table maintenance.
> Some clever ideas please.
>
> regards peter.
>
>
>
Original Message
> From: "Allan Lane" <allan.lane@h...>
> To: <basicstamps@yahoogroups.com>
> Sent: Tuesday, March 02, 2004 7:38 PM
> Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
>
>
> > If I understand this approach, the goal of
> > the "Table Driven Interface" is to have
> > the display bytes stored in an off-chip
> > EEPROM -- loaded through some method.
> >
> > The program then knows the 'base' addr.
> > of each page in the EEPROM table. The
> > software merely needs to know which addr
> > to select -- then go to the EEPROM and
> > transfer the image from the Table to the
> > Display.
> >
> > If that's what you're talking about, then
> > yes, the EEPROM loader program can be put
> > into the Javelin. Some PC-based Display
> > Generator program can generate the Display
> > data, and load it into the EEPROM (through
> > a simple program on the Javelin, or through
> > an EEPROM burner, your choice). Then,
> > the DisplayGen program needs to give you,
> > the programmer, the table of start addr for
> > the loaded 'screens'.
> >
> > Then, you supply those 'screen' start addr to
> > your program, add the logic to navigate from
> > screen to screen, and you are good to go.
> >
> > So, what's the problem with this approach?
> > Sounds brilliant to me. You get the stand-alone
> > nature of the Stamp, and nice screens from
> > the EEPROM.
> >
> > --- In basicstamps@yahoogroups.com, "russranshaw" <home.rr@c...>
> > wrote:
> > > Peter,
> > >
> > > I'm not sure the elaborteness is justified. Those 32k EEPROMs
are
> > > pretty cheap ($5). Besides, I don't see even a very complex
menu
> > > requiring anywhere near 32k.
> > >
> > > If my original thought dosen't sit well (putting the entire
> > structure
> > > which is destined for the EEPROM in a Javelin program), then one
> > could
> > > write a generic Javelin program that would take a stream of data
> > via a
> > > serial port and write it to the EEPROM. If timing is a
problem, it
> > is
> > > feasible to implement a simple error checking packetized
protocol
> > > which would request the next packet. That way it would be
possible
> > to
> > > download some data, write it to the EEPROM, downloand the next
> > chunk,
> > > write it, etc. I don't see speed being a problem. I guess I
don't
> > > understand your point about "cycles".
> > >
> > > Russ
> > >
> > >
> > >
> > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > <peterverkaik@b...> wrote:
> > > > Russ,
> > > >
> > > > Errata, the heap structure requires only 2 eeprom bytes to
> > maintain the
> > > > structure.
> > > >
> > > > regards peter
> > > >
> > > >
Original Message
> > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > To: <basicstamps@yahoogroups.com>
> > > > Sent: Tuesday, March 02, 2004 11:40 AM
> > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > >
> > > >
> > > > > Russ,
> > > > >
> > > > > I see your point. But both Basic stamp and javelin cannot
hold a
> > > full 32KB
> > > > > eeprom image so multiple
> > > > > 'eeprom program cycles' will be required for a 32KB eeprom.
> > Block size
> > > > > changes for one cycle
> > > > > could impact on the other cycles, forcing code changes for
> > those other
> > > > > cycles.
> > > > > How about using an underlying structure that shows free and
> > allocated
> > > > blocks
> > > > > and that is recognized
> > > > > by basic stamp and javelin? That way available start and end
> > > addresses are
> > > > > retrieved from the eeprom
> > > > > itself. What I was thinking of is the javelin heap class I
> > wrote
> > > that I
> > > > can
> > > > > easily port to the basic stamp.
> > > > > Each block, either free or allocated, requires only 4 eeprom
> > bytes to
> > > > > maintain the heap structure.
> > > > > This structure is limited to a 32KB eeprom. A 64KB eeprom
could
> > > hold two
> > > > > heap structures.
> > > > > Whatever you put in allocated blocks (could be another
heap) is
> > up
> > > to the
> > > > > application.
> > > > > I suggest using signature words to identify allocated
blocks.
> > > > >
> > > > > regards peter
> > > > >
> > > > >
Original Message
> > > > > From: "russranshaw" <home.rr@c...>
> > > > > To: <basicstamps@yahoogroups.com>
> > > > > Sent: Monday, March 01, 2004 7:07 PM
> > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > >
> > > > >
> > > > > > Peter,
> > > > > >
> > > > > > I have a similar idea, except what I envision is
a "compiler"
> > that
> > > > > > runs on the PC and creates some Java classes, including
the
> > menu
> > > > > > driver and a "setup" program. Within the setup program
would
> > be a
> > > > > > character array that contained the data destined for the
> > EEPROM.
> > > Part
> > > > > > of the table description language would be information
about
> > the
> > > > > > starting and ending EEPROM addresses. The user would
have to
> > modify
> > > > > > the setup program to get the appropriate pin assignments,
> > driver
> > > > > > class(es) for the EEPROM, etc. My reason for thinking
along
> > > this line
> > > > > > is that I have a 32k EEPROM, and have other sues for much
of
> > it.
> > > > > >
> > > > > > Russ
> > > > > >
> > > > > >
> > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > <peterverkaik@b...> wrote:
> > > > > > > Thanks Jon for your N&V article.
> > > > > > > Russ, I uploaded something I pieced together. It will
not
> > work
> > > as it
> > > > is
> > > > > > > incomplete.
> > > > > > > I defined a table setup to find out how much code would
be
> > > needed to
> > > > > > > navigate
> > > > > > > through menus using tables. The size of the navigation
code
> > is
> > > even
> > > > > > smaller
> > > > > > > than I expected.
> > > > > > >
> > > > > > > What I need is to run a setup program (like a PC bios)
that
> > > has much
> > > > > > text,
> > > > > > > this is for the benefit of application end-users.
> > > > > > > This setup program will be for the javelin. To create
the
> > tables I
> > > > > > use the
> > > > > > > BS
> > > > > > > because there is no DATA equivalent for the havelin, and
> > > programming
> > > > > > such
> > > > > > > menus
> > > > > > > inline in javelin code eats too much code space.
> > > > > > >
> > > > > > > I would like to discuss the layout of the tables. I am
sure
> > they
> > > > > > could be
> > > > > > > better
> > > > > > > organized or perhaps even compacter or more general. The
> > idea
> > > is to
> > > > > > retrieve
> > > > > > > all required settings
> > > > > > > from the eeprom rather than hardcoded in the software.
> > > > > > >
> > > > > > > Comments please.
> > > > > > >
> > > > > > > regards peter
> > > > > > >
> > > > > > >
> > > > > > >
Original Message
> > > > > > > From: "russranshaw" <home.rr@c...>
> > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > Sent: Sunday, February 29, 2004 4:07 PM
> > > > > > > Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> > > > > > >
> > > > > > >
> > > > > > > > Peter,
> > > > > > > >
> > > > > > > > Could you give us a "fer-instance" of what it is you
want
> > to
> > > > > > accomplish?
> > > > > > > >
> > > > > > > > I have a device (Solar Energy Inverter) that has an
> > imbedded
> > > micro
> > > > > > > > controller. It uses a menu system where there are
several
> > > groups of
> > > > > > > > related menu items each of which has several sub-
items.
> > > There are
> > > > > > > > three main types of sub-item. On lets you select
> > a "mode" using
> > > > left
> > > > > > > > and right arrow keys. Another uses the arrow keys to
> > > > > > > > increment/decrement a value. The third is simply
> > information.
> > > > > > > >
> > > > > > > > There are six control buttons in all. Two to select
the
> > main
> > > > > > > > category, two to select the sub-category, and two as
> > mentioned
> > > > above.
> > > > > > > >
> > > > > > > > Such a scheme would be fairly simple to abstract,
using
> > > EEPROM to
> > > > > > > > store the menu data.
> > > > > > > >
> > > > > > > > And I don't think it would be difficult to build
> > a "compler" to
> > > > stuff
> > > > > > > > the EEPROM!
> > > > > > > >
> > > > > > > > Would something on this order be what you're after?
> > > > > > > >
> > > > > > > > Russ
> > > > > > > >
> > > > > > > >
> > > > > > > > --- In basicstamps@yahoogroups.com, "Peter Verkaik"
> > > > > > > > <peterverkaik@b...> wrote:
> > > > > > > > > I also found this
> > > > > > > > > http://www.imatix.com/html/libero/
> > > > > > > > > A free code generator for table driven design that
> > generates
> > > > > > > > > a framework for C or Java (perhaps useful for the
> > javelin)
> > > > > > > > > and a great number of other languages. Fast reading
> > through
> > > > > > > > > the docs it seems to be possible to add a 'schema'
file
> > > (language
> > > > > > > > > specific framework file) for other languages, like
> > pbasic.
> > > > > > > > > I will read it closer to find out if this really is
> > possible.
> > > > > > > > >
> > > > > > > > > regards peter
> > > > > > > > >
> > > > > > > > >
Original Message
> > > > > > > > > From: "Peter Verkaik" <peterverkaik@b...>
> > > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > > Sent: Sunday, February 29, 2004 1:58 AM
> > > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> > interface
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > I found this to be good reading material
> > > > > > > > > > http://www.dkl.com/pdf/tabledrivendesign.pdf
> > > > > > > > > > It lacks however a working example in real code.
> > > > > > > > > > But the table descriptions (especially the
decision
> > tables)
> > > > > > > > > > are good and when inplemented properly
could/should
> > reduce
> > > > > > > > > > code by 30% or more.
> > > > > > > > > > The trick is to define rules, then use a table
lookup
> > to
> > > > > > > > > > find all matching entries and executing the tasks
> > belonging
> > > > > > > > > > to the matching rules.
> > > > > > > > > >
> > > > > > > > > > regards peter
> > > > > > > > > >
> > > > > > > > > >
Original Message
> > > > > > > > > > From: "Bruce Bates" <bvbates@u...>
> > > > > > > > > > To: <basicstamps@yahoogroups.com>
> > > > > > > > > > Sent: Sunday, February 29, 2004 12:55 AM
> > > > > > > > > > Subject: Re: [noparse][[/noparse]basicstamps] Re: Table driven user
> > interface
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > At 10:54 PM 2/28/04 +0000, russranshaw wrote:
> > > > > > > > > > > >Peter,
> > > > > > > > > > > >
> > > > > > > > > > > >I have been thinking of something along the
same
> > > lines. Care
> > > > > > > > to shre
> > > > > > > > > > > >some ideas? Using an EEPROM to store the table
> > > information
> > > > is
> > > > > > > > a good
> > > > > > > > > > > >one, sspecially in a Stamp enfironment.
> > > > > > > > > > > >
> > > > > > > > > > > >In "the old days" there was a "programming
> > language"
> > > called
> > > > > > > > Decision
> > > > > > > > > > > >Tables. This was essentially a State
Transition
> > > chart. I
> > > > can
> > > > > > > > think
> > > > > > > > > > > >of four elements:
> > > > > > > > > > > >
> > > > > > > > > > > >1. States
> > > > > > > > > > > >2. Events (essentially status bits set
outside
> > the
> > > > > > table class)
> > > > > > > > > > > >3. Actions (same, set by the table class to
> > cause
> > > things
> > > > to
> > > > > > > > be done
> > > > > > > > > > > >4. Next State
> > > > > > > > > > > >
> > > > > > > > > > > >Imagine the States to be arranged vertically
> > (rows) and
> > > > Events
> > > > > > > > > > > >horizontally (columns). Each table
intersection
> > can
> > > have a
> > > > > > set of
> > > > > > > > > > > >Actions and one Next state. I am currently
doing
> > > this on a
> > > > > > Javelin
> > > > > > > > > > > >Stamp, but the table is hard-coded. I'd love
to
> > > discuss a
> > > > > > way to
> > > > > > > > > > > >generalize it!
> > > > > > > > > > > >
> > > > > > > > > > > >Russ
> > > > > > > > > > >
> > > > > > > > > > > Russ and Peter -
> > > > > > > > > > >
> > > > > > > > > > > A very similar techniques is often used by
operating
> > > system
> > > > task
> > > > > > > > > managers
> > > > > > > > > > in event driven systems. The last task in the task
> > table is
> > > > > > always the
> > > > > > > > > > system wait state.
> > > > > > > > > > > Hopefully the system never reaches that state,
> > other wise
> > > > > > nothing is
> > > > > > > > > being
> > > > > > > > > > done.
> > > > > > > > > > >
> > > > > > > > > > > Just thought I'd mention it, as it uses similar
> > tables and
> > > > keeps
> > > > > > > > track
> > > > > > > > > of
> > > > > > > > > > events, and the state of each of the events
whether
> > active,
> > > > > > pending or
> > > > > > > > > > complete. One of the nice things about such a
system
> > is the
> > > > > > > > ability to run
> > > > > > > > > > through the tables in a commutator fashion, only
> > paying
> > > > > > attention to
> > > > > > > > > tasks
> > > > > > > > > > or sub-tasks which need servicing and pretty much
> > > ignoring the
> > > > > > rest.
> > > > > > > > > > >
> > > > > > > > > > > These tasks are also set up in a linked-list
scheme.
> > > Each task
> > > > > > > > points to
> > > > > > > > > > the next task, and back to the prior one.
Generally
> > the task
> > > > list
> > > > > > > > is kept
> > > > > > > > > in
> > > > > > > > > > priority order, and changing the order is just a
> > matter of
> > > > > > > > changing the
> > > > > > > > > each
> > > > > > > > > > of the links appropriately.
> > > > > > > > > > >
> > > > > > > > > > > Getting this back on a Stamp topic, one of the
> > earlier
> > > > > > PBasic Stamp
> > > > > > > > > > Manuals, possibly Version 1.8 or prior, had a
message
> > table
> > > > > > for LCD
> > > > > > > > > display,
> > > > > > > > > > if I remember correctly. I'll see if I can locate
it,
> > > and if I
> > > > > > > > find it,
> > > > > > > > > I'll
> > > > > > > > > > pass it along.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > >
> > > > > > > > > > > Bruce Bates
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >--- In basicstamps@yahoogroups.com, "Peter
Verkaik"
> > > > > > > > > > > ><peterverkaik@b...> wrote:
> > > > > > > > > > > >> Hi,
> > > > > > > > > > > >>
> > > > > > > > > > > >> Can anybody point me to a working example of
a
> > table
> > > > > > driven user
> > > > > > > > > > > >interface?
> > > > > > > > > > > >> Preferred output device is a serial text lcd
2x16
> > > or 4x20.
> > > > > > > > > > > >> Preferred input devices are keys.
> > > > > > > > > > > >> I would like to program a text intensive menu
> > > system into
> > > > > > a table
> > > > > > > > > > > >that is
> > > > > > > > > > > >> offloaded into external eeprom, and then
parsing
> > that
> > > > > > table while
> > > > > > > > > > > >> inside the menu command.
> > > > > > > > > > > >> Program language may be pbasic, java or c.
> > > > > > > > > > > >>
> > > > > > > > > > > >> 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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> >
> >
> >
> > 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
> >
> >
> >
> >
> >
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
Original Message
From: "russranshaw" <home.rr@c...>
To: <basicstamps@yahoogroups.com>
Sent: Tuesday, March 02, 2004 10:45 PM
Subject: [noparse][[/noparse]basicstamps] Re: Table driven user interface
> Peter,
>
> I'm starting a clean slate for this.
>
> Here is a simple idea for setting up a Menu structure:
>
> 1.0 Main Menu Item
> 1.1 First sub-item
> bLIST AAA, BBB, CCC
> 1.2 Second sub-item
> iLIST VVV = ('DDD', 23), ('EEE', 123), ('FFF', 987)
> 1.3 Third sub-item
> dITEM 'The value is: ' FOO (3.1)
> 1.3.1 A third tier menu item
> 2.0 Second Main Menu Item
> etc.
>
> "bLIST" refers t Boolean variables. iLIST to integer variables.
> dITEM is used to display a descriptive text followed by an optionally
> formatted value (in this case, display as 123.4).
>
> The symantics of the LISTs are: Display the list of names. The user
> navigates to a particular choice (suitable indication woul dhave to be
> used on the LCD), then when the menu entry is cleared that particular
> In the case of dITEM, the user can increment or decrement the value.
>
> The "compiler" translates the AAA, BBB, CCC, VVV into varibles as follows:
>
> static boolean bvarAAA
> static boolean bvarBBB
> static boolean bvarCCC
> static int VVV
> static int FOO
>
>
> Not terrible pretty, but food for thought!
>
> Russ
>
>
[noparse][[/noparse]Non-text portions of this message have been removed]