Software architecture using C for mid-range PIC.
in [Embedded]
|
From: ChrisQ on 12 Sep 2009 09:34 Paul Carpenter wrote: > So put the list of triplets in a command table, that means it is easy to > maintain, then have a matching table of functions to jump to. > Table driven methods are invariably the best way to deal with this, as there will always be more commands later. The standard way here is to define the parse table as a n way linked list of nodes, where each node has a table of valid chars at that node, and associated links to either another node or function pointer to exec the command. As the syntax is defined by the structure of the tree, it can handle command sequences of any length. It works well for small and large command sets and the code to drive it just becomes a list processor, around a dozen lines of C from start to end. Also, you only have to write the code once, a new syntax just needs a new set of node definitions. Regards, Chris
From: Frank Buss on 12 Sep 2009 11:24 ChrisQ wrote: > Table driven methods are invariably the best way to deal with this, as > there will always be more commands later. The standard way here is to > define the parse table as a n way linked list of nodes, where each node > has a table of valid chars at that node, and associated links to either > another node or function pointer to exec the command. As the syntax is > defined by the structure of the tree, it can handle command sequences of > any length. And if you are lazy and don't want to write tree tables by hand, you can use flex for it. This one, just in case you don't know it: http://flex.sourceforge.net -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Rocky on 12 Sep 2009 11:40 On Sep 12, 5:24 pm, Frank Buss <f...(a)frank-buss.de> wrote: > ChrisQ wrote: > > Table driven methods are invariably the best way to deal with this, as > > there will always be more commands later. The standard way here is to > > define the parse table as a n way linked list of nodes, where each node > > has a table of valid chars at that node, and associated links to either > > another node or function pointer to exec the command. As the syntax is > > defined by the structure of the tree, it can handle command sequences of > > any length. > > And if you are lazy and don't want to write tree tables by hand, you can > use flex for it. This one, just in case you don't know it: > > http://flex.sourceforge.net > > -- Or if more lazy and using C define a structure that contains a pointer to a const string and a pointer to the function that handles that particular string. Declare an intitilised array of this structure. Also been using it since the assembler days on a Z80 and now on the 8052 and the PIC in C.
From: Frank Buss on 12 Sep 2009 12:05 Rocky wrote: > Or if more lazy and using C define a structure that contains a pointer > to a const string and a pointer to the function that handles that > particular string. Declare an intitilised array of this structure. > Also been using it since the assembler days on a Z80 and now on the > 8052 and the PIC in C. Yes, this is possible for very simple protocols. If you have many commands or some kind of syntax, flex is better, because you can match tokens with regular expressions. Maybe combined with Yacc, or your own simple recursive descent parser. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Vladimir Vassilevsky on 12 Sep 2009 12:24
Fevric J. Glandules wrote: > Bob wrote: > > >>I'm always amazed at how hung-up programmers get about parsing. If you >>have the authority to define the command set, you can make it easy on >>yourself by having fixed length commands; Even a single character (A - >>Z, e.g.) might suffice. > > > That's probably what I would have done; OTOH at least they are all > exactly three characters long. Create an unambiguous fixed width binary protocol over RS-232. Implement some basic integrity checking (such as checksums) so the occasional garbage characters would not be interpreted as the valid commands. Create a PC GUI application to communicate to your device. The common users love GUI and hate command line and batch files. Depending on your application, it could make sense to stick with a standard protocol, such as MODBUS. This makes the things lot simpler for both developers and users. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com |