Searching \ for '[PIC]: Table driven user interface' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=table
Search entire site for: 'Table driven user interface'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Table driven user interface'
2002\03\16@064336 by Steven Allard

flavicon
picon face
I want to implement a table driven interface on a PIC using the CCS c
compiler, I have a 2*16 LCD and button debounce routine running, and
want to design a generic interface which is adaptable to several
projects.

Can anyone point me to a good source of information, source code etc ?

I've tried searching google and copernic using ' c table driven user
interface' and several other combinations but find anything relevant to
embedded interfaces.

Any suggestions/pointers will be warmly received

Thanks in advance.

Steve Allard

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\03\16@103843 by Sergio Masci

picon face
----- Original Message -----
From: Steven Allard <.....steveKILLspamspam@spam@ALLARD10052.FREESERVE.CO.UK>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Saturday, March 16, 2002 10:43 AM
Subject: [PIC]: Table driven user interface


{Quote hidden}

I'm not sure what you are trying to do, but if your intension is to display
messages in tables and to navigate these tables depending on external events
(e.g. user pressing buttons) then you might want to look at state machines
(some times refered to as FSM). There is a PIC port of ZMech which allows
you to design (and interactively debug) state machines using state diagrams.

Regards
Sergio Masci
http://www.xcprod.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\03\18@041952 by Steven Allard

flavicon
picon face
Hi,

Sorry my original post wasn't very clear !

> I'm not sure what you are trying to do, but if your intension is to display
> messages in tables and to navigate these tables depending on external events
> (e.g. user pressing buttons)

Thats exactly what I'm doing. At the moment I'm using switch structures to
create simple state machines.

What I would really like to do is build a two dimensional table -

State               Button A            Button B          Button C etc

0                   *Inc()                     x                          x
1                    *Change()           *Start()                  *Stop()
2                        x                      *DoSomething()
*DoSomethingElse()

Using pointers to functions I can keep all the selection logic in one place,
this should mean I can see exactly which function will be called for each
button/state combination, and I can change which function is called by changing
it in the table.

I think the stumbling block may be that according to the compiler documentation
pointers to functions are not allowed ! so I will have to find a work around.

Regards

Steve Allard

> Regards
> Sergio Masci
> http://www.xcprod.com
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\03\18@064411 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

Steven Allard wrote:
> I want to implement a table driven interface on a PIC using the CCS c
> compiler, I have a 2*16 LCD and button debounce routine running, and
> want to design a generic interface which is adaptable to several
> projects.
>
> Can anyone point me to a good source of information, source code etc ?
>
<snip>

Well I can't help you with the 'c' part :) I always code my pic's in asm
but perhaps I can give some minor pointers that would be valid for any
programming language.

I would not choose tables with pointers, instead use contants, either a byte
or two bytes to select the 'action' for one meny choise.
Here's a snippet from an menu system  using only an 6 digit 7 segment LCD,
basic principle would work for any display ( i've used the same for 2x16 ).

The following 'flow' is assumed:

First the main-menu is displayed ( in this case only one line as the display
can only show one line at a time ) MENU0, if the user presses <arrowdown>
then the next menu
is displayed in this example MENU1 ( information is stored in the menu0
structure ), an
<uparrow> instead chooses the previous menu in this case MENU4. Then when
the user
presses <enter> he/she goes to the submenu defined in the mainmenu
structure.
( I assume all mainmenu's has submenus ) Note that the mainmenu contains
information of
the start submenu and end submenu, these are saved and used when the user
presses enter.

Assume the user presses enter at the MENU1 menu, the s/w then shows the
first submenu defined
in that structure, in this case MENU10. Here the same navigation can take
place
uparrow chooses the previos menu ( at this level ) and likewise down arrow
chooses
the next menu ( in example we would loop between menu's MENU10-MENU15 ). An
press
of <Cancel> return to top level and MENU1.

In this structure it's assumed that submenus ( 2:n level ) are always
parameters that
can be changed.
Now MENU10 has an multiple choice menu, i.e. the user selects between
several options
connected with the parameter. If the user presses enter on MENU10 the s/w
shows
the first in an list with parameters where the user can choose whatever
option he desires.
( i.e. no numerical input ). When the 'correct' option is displayed an enter
would 'set'
the parametervalue directly into the corresponding memory adress.

A bit hefty but see if you can figure out the flow.




First you define some constants of meny type's etc:

; menu type definitions ( first byte after the null termintaed menu text )
; *all* menus are required to have :
; 1) an nullterminated text ( of 6 bytes + null )
; 2) 1 type byte ( below )
; 3) 1 option byte see further below.
; The rest of the bytes are depedning in mostly on type but also on option.
;
#define M_HAS_SUB       0       ; a main menu, has submenu/s
                               ; requires 4 bytes of following data:
                               ; 1) Submenulist start
                               ; 2) SubMenuList end ( always ! contignous )
                               ; 3) Next mainmenu ( at this level )
                               ; 4) Previous mainmenu ( at this level )

#define M_HAS_OPT       1       ; a submenu has option/s
                               ; Requires 4 bytes of additional data:
                               ; 1) Optionlist start
                               ; 2) Optionlist end ( always ! contignous )
                               ; 3) Lowpart of pointer to data ( where to
store selection )
                               ; 4) High part of pointer to data ( bank )

#define M_HAS_LNK       2       ; a link start menu
                               ; Requires 4 bytes of additional data:
                               ; 1) 'Next' menu ( the first in the list,
which should in turn point to the next etc )
                               ; 2) Number of menus in the list to display
( i.e length )
                               ; 3) Next mainmenu ( at this level )
                               ; 4) Previous mainmenu ( at this level )

#define M_IS_OPT        3       ; is an option menu     ( dead end )
                               ; Requires 1 byte, but could also have 1
additional byte is uses bitmask
                               ; depending on second otion byte ( see below
)
                               ; 1) Data ( what to store/set when selected
) uses adress from 'calling' subemenu
                               ; 2) Bitmask for bit encoded data ( optional
)

#define M_IS_LINK       4       ; is an part of a link menu ( one way )
                               ; Requires 5 bytes of additional data:
                               ; 1) Optionlist start ( if any, else NULL )
OR number of digits accepted during input
                               ; 2) Optionlist end ( if any, else NULL ) OR
number of bytes stored during input
                               ; 3) The next menu in the list when pressing
enter ( if number of linked menus in
                               ;    the calling link start menu has not
been reached )
                               ; 4) Lowpart of pointer to data ( where to
store selection )
                               ; 5) High part of pointer to data ( bank )


; definition bytes second byte after type byte
; these are interpreted separately depedning on the type of the menu (
previous byte )

; These are for menu type M_IS_OPT
; option definitions cannot use 0 ( as that is 'no-option' )
#define OPT_NO_OPT      0       ; no particular extra interpretation
#define OPT_HAS_BITMASK 1       ; option has one additional byte of bitmask
                               ; 1) Bitmask, all bits set to 1 will be
affected ( set/cleared )
                               ;    the remaing bits ( 0's ) will be left
as-is.
#define OPT_DO_INPUT    2       ; option menu requires input and has 3 bytes
of additional data
                               ; 1) Number of digits accepted ( excluding
decimalpoint )
                               ; 2) Number of bytes stored at data pointer
adress after input
                               ; 3) Input handling byte, what to do with
input data when enter is pressed
                               ;    for example, divide with scale division
to calculate number of division etc.

#define OPT_IS_UNIT     3       ; special option to handle unit
indication/changing only
                               ; basicly it's only an bitmask but handled
separately to
                               ; be able to indicate selection with
'correct' lcd segments.

; These are for M_IS_LINK
; link definitions
#define LNK_NO_OPT      0       ; no particular extra info
#define LNK_HAS_OPT     1       ; This link menu has an otion menu ( uses
the start/end option bytes following )
#define LNK_DO_INPUT    2       ; Link menu requires input and has 3 bytes
of additional data
                               ; 1) Number of digits accepted ( excluding
decimalpoint )
                               ; 2) Number of bytes stored at data pointer
adress after input
                               ; 3) Input handling byte, what to do with
input data when enter is pressed
                               ;    for example, divide with scale division
to calculate number of division etc.

#define LNK_CALL_FUNC   3       ; link menu option for calling an function
when pressing enter
                               ; used mainly for calibration routines


Then the definition of an 'main' (top level) menu:

; menu structure for a main menu:
; * note * for all menu text's if decimal point is used more than 6 bytes
are accepted !
; as the decimal point will not use any of the digits positions.
;* 6 bytes of text ( only capital letters ) always followed by one null byte
;* 1 byte of typedef, for a main meny M_HAS_SUB only
;* 1 byte of optiondef, for a main meny NULL only
;* 1 byte with start submenu offset ( i.e. 7 -> submenu start is menu7 )
;* 1 byte with end submenu offset ( i.e. 9 -> submenu end is menu9 ) *note
submenus most be continous*
;* 1 byte with next mainmenu offset
;* 1 byte with prev mainmenu offset

MENU0:  DB   "S.POINT",0x00,M_HAS_SUB,NULL,30,32,1,4 ; mainmenu setpoint
MENU1:  DB   "SER 1 ",0x00,M_HAS_SUB,NULL,10,15,2,0 ; mainmenu internal
serial port
MENU2:  DB   "SER 2 ",0x00,M_HAS_SUB,NULL,23,27,3,1 ; mainmenu extra
'serial' port ( or analoge output )
MENU3:  DB   "IN.OUT ",0x00,M_HAS_SUB,NULL,16,19,4,2 ; mainmenu input's,
outputs
MENU4:  DB   "IND.LED",0x00,M_HAS_SUB,NULL,33,33,0,3 ; mainmenu function of
lthe led's on the display



An <enter> at MENU1 would take you to an second level menu ( in this case
always parameters that can be set/changed )
(note also have pointers to the ram, that's the DW Uart_xxx part ):



; menu structure for a submenu:
;* 6 bytes of text ( only capital letters ) always followed by one null byte
;* 1 byte of typedef, various depedning on option
;* 1 byte of optiondef, various depedning on option
;* 1 byte with start option offset ( i.e. 7 -> optionmenu start is menu7 )
;* 1 byte with end optionmenu offset ( i.e. 9 -> optionmenu end is menu9 )
*note optionmenus most be continous*
;* 2 bytes pointer to the data source in ram ( where to get/put data )
; submenus for internal serial port
MENU10: DB  "BAUD  ",0x00,M_HAS_OPT,NULL,50,55
       DW   UART_Baud;  mainmenu baudrate
MENU11: DB  "DATA  ",0x00,M_HAS_OPT,NULL,56,57; mainmenu data format
       DW   UART_Ctrl
MENU12: DB  "PROTO ",0x00,M_HAS_OPT,NULL,58,59; mainmenu protocol
       DW   UART_Ctrl
MENU13: DB  "ID    ",0x00,M_HAS_OPT,NULL,73,73; internal port id
       DW   UART_Id
MENU14: DB  "UNIT  ",0x00,M_HAS_OPT,NULL,89,90; mainmenu data format
       DW   UART_Ctrl
MENU15: DB   "AUTO.SE",0x00,M_HAS_OPT,NULL,91,92;  ; auto send data
       DW   UART_Ctrl+1

An <enter> at MENU10 would take you to an parameter selection menu:

; options for baudrate internal port
MENU50: DB   "  1200",0x00,M_IS_OPT,NULL,CALC_LOW_BAUD(1200)
MENU51: DB   "  2400",0x00,M_IS_OPT,NULL,CALC_LOW_BAUD(2400)
MENU52: DB   "  4800",0x00,M_IS_OPT,NULL,CALC_LOW_BAUD(4800)
MENU53: DB   "  9600",0x00,M_IS_OPT,NULL,CALC_LOW_BAUD(9600)
MENU54: DB   " 19200",0x00,M_IS_OPT,NULL,CALC_LOW_BAUD(19200)
MENU55: DB   " 38400",0x00,M_IS_OPT,NULL,CALC_LOW_BAUD(38400)

An enter at anyone of these would set the corresponding ram adress
( in this case UART_Baud ) to the value defined for each parameter.

Another example setting/clearing some bits, for example MENU11 above
has two options stored in a 1 bit 'bitpattern'. The define M_IS_OPT
tells the menu s/w that this is an 'dead-end' lowest level, the define
OPT_HAS_BITMASK tells the s/w how to interpret the following bytes
and how many there are. In bitmask case there are always two bytes
following, the first has the bit pattern to 'set/clear' if the user presses
<enter>, the second has the mask to which bits that are affected at
the memory adress UART_Ctrl ( in this case only lowest bit ).

; options for data format internal port
; note ? displayed as '-'                       data        mask
MENU56: DB   "   7?E",0x00,M_IS_OPT,OPT_HAS_BITMASK,b'00000001',b'00000001'
; 7 db even parity
MENU57: DB   "   8?N",0x00,M_IS_OPT,OPT_HAS_BITMASK,b'00000000',b'00000001'
; 8 db no parity


This type of menu requires that the navigation trough the menu is saved (
i.e.
must remeber the entry point at each level ) For example
MENU1->MENU10->MENU50
so that the s/w can go back the same route. Apart from that is fairly
compact and
'dissconected' with the code. It's easy to change/add/remove menus and
parameters
as the code has all the instructions inside the menustructure itself.
Normally code changes are only needed for each additional type if input i.e.
numerical, bitpattern, selections etc. For numerical input I have additional
flags
that indicate number of digits accepted, if dp can be placed etc etc.


/Tony

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\03\18@132406 by Sergio Masci

picon face
----- Original Message -----
From: Steven Allard <stevespamspam_OUTALLARD10052.FREESERVE.CO.UK>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Monday, March 18, 2002 9:15 AM
Subject: Re: [PIC]: Table driven user interface


> Hi,
>
> Sorry my original post wasn't very clear !
>
> > I'm not sure what you are trying to do, but if your intension is to
display
> > messages in tables and to navigate these tables depending on external
events
{Quote hidden}

*Stop()
>  2                        x                      *DoSomething()
> *DoSomethingElse()
>
> Using pointers to functions I can keep all the selection logic in one
place,
> this should mean I can see exactly which function will be called for each
> button/state combination, and I can change which function is called by
changing
> it in the table.

The PIC version of ZMech builds state transition tables for you from state
diagrams. Each state has a state monitor function (a function that is called
repeatedly while the state machine is idle) and each event transition has an
associated event transition function. Events are generated by input changes
or internally by other functions (e.g. from a state monitor function looking
at some software condition - maybe comms).

>
> I think the stumbling block may be that according to the compiler
documentation
> pointers to functions are not allowed ! so I will have to find a work
around.
>

There are various problems associated with generating efficient code for a
PIC from C source. The main problem seems to stem from the fact that to
allocate temporary storage you either need to use a software stack (which is
very expensive in terms of CPU time) or allocate the temporary storage
statically at compile time. This requires that you know which functions will
be calling other functions so that you can ensure that the temporary storage
is shared without a runtime clash. Using pointers to functions causes
problems with this approach and you may find that a kludge to execute a
function through an assembler backdoor may sometimes unepectedly fail after
you modify some unrelated section of your C code. This is one reason why
XCASM does not support high level function calls in its high level code
generator.

I beleive that IAR have a state machine development tool of their own that
they ship for free. BUT you need to buy an IAR C compiler to use it

There is also a version of ZMech that generates and uses C/C++ code, but
that wont be any good to you if your C compiler doesn't handle function
pointers correctly.

Regards
Sergio

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\03\19@070214 by Steven Allard

flavicon
picon face
Hello,

Thanks for the code snippet Tony it's a great solution ! I'm going to try and
implement it in C, if anyone else is interested I'll post my efforts on the
list.

Regards

Steve Allard

K|bek Tony wrote:

{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\03\20@055902 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

Steve Allard wrote:
>Thanks for the code snippet Tony it's a great solution ! I'm going to try
and
>implement it in C, if anyone else is interested I'll post my efforts on the
>list.

Yes it's an neat solution, however I forgot to mention the menu pointer
table :)
that is used to 'connect' the menu number to each menu entry, this as the
menu
'structures' ( or definitions ) are allowed to have different lenght one
must use
an pointer table to access the menu. It looks like this:

MENU_PTR_TABLE
       DW MENU0
       DW MENU1
       DW MENU2
       DW MENU3
       DW MENU4
       DW MENU5
       DW MENU6
       DW MENU7
       ..etc
Then follows the actual menu's:
MENU0:  DB   "S.POINT",0x00,M_HAS_SUB,NULL,30,32,1,4 ; mainmenu setpoint
MENU1:  DB   "SER 1 ",0x00,M_HAS_SUB,NULL,10,15,2,0 ; mainmenu internal
serial port

..etc..


So the menu offset is used as an entry to the pointer table( used on an
18c452 so TABLAT is available ),
the menu pointer is fechted and then the actual menu is read.

It's an variant of Scott Dattalo:s 'large string' tables onthe piclist site.

I posted an variant of it a year or so ago(for 18x) :

http://www.infosite.com/~jkeyzer/piclist/2001/Jan/2353.html


I had intentions to actually make an 'Pic menu builder' as a windows
program a long time ago, but time hasn't permitted it just yet :)

Sorry to not mention it in my erlier posting :)

/Tony§

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\03\22@084048 by Carlos Ojea

flavicon
face
>Thanks for the code snippet Tony it's a great solution ! I'm going to try
and
>implement it in C, if anyone else is interested I'll post my efforts on the
>list.


Do that please. I'm also using switch structures to make state machines and
think your idea could help in writing a source code 'nice & clean'.

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...