Software architecture using C for mid-range PIC.
in [Embedded]
|
From: Tauno Voipio on 12 Sep 2009 12:36 Vladimir Vassilevsky wrote: > > > 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 DO NOT use MODBUS. The protocol has tight timing requirements for the characters in a packet and for the intervals between packets. It is practically impossible to create a MODBUS program with proper timing running in a PC (Windows or whatever). Yes, there are MODBUS programs for PC's, but I have not seen yet one with the timing according to the bus specifications. -- Tauno Voipio tauno voipio (at) iki fi
From: ChrisQ on 12 Sep 2009 12:32 Frank Buss wrote: > 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. > I've never used flex or yacc, perhaps because every time I look at it, it seems to be more than I really need for simple command parser. It's probably very good if you want to write a compiler, but most embedded command processors use a simple syntax to reduce processing overhead. Have also looked at tcl some years ago, but once again, more than is really needed to do the job, or there were bits I just didn't like, or just simply that it's easier to pull a previous library module out, copy, edit, resave under a new name, to do the job. What would be ideal would be a sort of half way house between flex and table editing manually. Something that is aware of the defined data structures and allows some sort of simplified formal language specification, which then gets compiled into the tables. The key thing here is 'aware of the data structures', which basically means do it yourself. Thus, all there is at present is a set of macros to make the table editing easier. There's a lot of difference between a true command language syntax, for example 'set voltage 24-e3', where it's often easier to use a tokeniser followed by lexical and syntax analysis and the sort of fixed format protocol embedded commands: cmd arg1 arg2 ... arg-n cmd is fixed at 1 to n chars long, with a variable number of args. It's quite easy to write a completely deterministic parser for this using the tree of nodes method, with everything that doesn't match defined as an error. Because there's not much of it, it's quite easy to follow and understand. Contrast that with the typical method of deeply indented case statements implementation, which just becomes unreadable after a couple of pages :-)... Regards, Chris
From: Hans-Bernhard Bröker on 12 Sep 2009 16:16 Fevric J. Glandules wrote: > Let me guess - you live in a 32 bit world, right? <grin> Erm ... no. > This is an 8 bit chip, and from what I've seen of its output, the > C18 compiler isn't all that brilliant [2]. Well, I won't be held liable for you having bad tools. If you really can't trust your C compiler to generate efficient code for a sparse switch on a non-minimal integer type, and since you appear to be allergic to any and all code generators, go ahead and code it yourself: binary search in a table of {command_string,action_function} structs, sorted by command_string. Points will be deducted for using any standard library function like bsearch(), of course. ;-)
From: Fevric J. Glandules on 12 Sep 2009 18:01 ChrisQ wrote: > understand. Contrast that with the typical method of deeply indented > case statements implementation, which just becomes unreadable after a > couple of pages :-)... Yes, I think my switch / case thing is headed for /dev/null. Thanks to all for the pointers. I'll be looking into some sort of command table / tree in due course.
From: Fevric J. Glandules on 12 Sep 2009 18:26
Hans-Bernhard Br�ker wrote: > Fevric J. Glandules wrote: > >> Let me guess - you live in a 32 bit world, right? <grin> > > Erm ... no. Apologies. I based my assumption on: switch((u16)buf[0]<<16 + (u16)buf[1]<<8 + (u16)buf[2]<<0) Is this 8-bit PIC friendly? As I said, I'm trying to get myself (back) into the 8 bit world. So I really don't mind (much) having my ignorance pointed out. >> This is an 8 bit chip, and from what I've seen of its output, the >> C18 compiler isn't all that brilliant [2]. > > Well, I won't be held liable for you having bad tools. Well, I'm stuck with it. Unless the C18 is *so* bad that I can make a case for the client spending more money. Any opinions here on how the C18 measures up? > If you really can't trust your C compiler to generate efficient code for > a sparse switch on a non-minimal integer type, and since you appear to > be allergic to any and all code generators, go ahead and code it I am in no way allergic to anything that will save coding time - but I do worry about how much code space, RAM and CPU cycles general purpose tools will consume. > yourself: binary search in a table of {command_string,action_function} > structs, sorted by command_string. Points will be deducted for using > any standard library function like bsearch(), of course. ;-) Happy to lose points if I gain time! |