Software architecture using C for mid-range PIC.

If your protocol is simple, e.g. "command arg1 arg2 ..." newline "command arg1 arg2 ...", I would just start with something like Rocky described:

void hello(void) { // you can parse command arguments here printf("hello "); }

void world(void) { printf("world!"); }

typedef void(*CommandFunction)(void);

struct Command { char* name; CommandFunction function; };

struct Command commands[] = { { "hello", hello }, { "world", world } };

void evaluate(char* commandName) { int i; for (i = 0; i < sizeof(commands) / sizeof(struct Command); i++) { struct Command* command = &commands[i]; if (strcmp(command->name, commandName) == 0) { command->function(); return; } } printf("command not found: %s\n", commandName); }

int main(int argc, char** argv) { evaluate("hello"); evaluate("world"); evaluate("foo"); return 0; }

If this is too slow, sort the commands alphabetically and use a binary search.

For most projects C18 produces code which is fast enough. Don't worry about speed until it is too slow :-) E.g. if you have a 100 ms measure cycle, it doesn't matter if a function needs 100 us or 1 ms and writing code which is easy to read and to maintain is more important.

The C18 compiler will compile your construct but will generate a lot of instructions to handle it. The PIC architecture does not have a bunch of general registers for C18 to use for register allocation, it only has an accumulator (the W reg) and a few other registers you can use.

The free C18 compiler does not do sub-expression elimination and some other common optimization techniques but does generate reasonably tight code. It wont beat carefully crafted assembler but I know of only

Lookup tables, constants, etc can be forced into flash locations to reduce runtime SRAM requirements. But you suffer a hit having to do a flash read. Since you are new to PIC, carefully study the manual regarding the various run time libraries, pay close attention to the string functions, memory functions and printf. There are different flavors depending on if the source (or destination) is in flash.

I have also found that the default IDE libraries are compiled for 24 bit pointers and you suffer a hit with this. They work but you have to make sure your code memory model matches the library's LARGE model. Anytime I load the IDE I recompile the libraries with the SMALL memory model which gives me 16 bit pointers. This works for all the low end PICs that have less than 64K of flash.

In practice, accurate timing is only required in multidrop slaves. Multiple PCs are seldom used as slaves on the same RS-485 bus.

When the PC acts as a Modbus master or a point-to-point slave, the connection works well with conservative timing, although there might be a few performance in throughput.

Paul

Sorry, but must disagree :-). The problem with the above is that you still have inband data embedded in the code. The only way to make the code completely reusable is to separate form and function. In this case, all the parser needs to know about is the *structure* of the data, not it's content.

I would rewrite the code to allow this:

eStatus = eParseExec (&sRootCommandNode);

Where sRootCommandNode is the command parser table root and the command functions are called via the table contents. It might seem a trivial change, but can have a major impact w/regard to future maintenance and spec change.

The command parser is completely encapsulated and can be replaced in the same application if the command format changes. Being encapsulated, with no global data, it's easy to make it into a library module. After all, who has the time to rewrite the same stuff over and over again ?.

Taking the time to design good data structures is worthwhile, imo and is the key to a robust design...

Regards,

Chris

I tend to use a command function that returns an integer/byte (depending on architecure). Reason being if you return an error code you can do some common error reporting for the parsing such as using return values for

....

or error = command->function(); // insert common argument function error handling here

Even if you want to use C, may I suggest FlashForth, a 16 bit Forth Operating System for the PIC18/PIC30/soonPIC24. It has an inbuilt command interpreter and compiler. It also has an round robin multitasker allowing you to have background tasks in addition to the operator task. Forth code for I2C is provided as an example.

With the compiler you design new command langauges to your liking. These new commands can then interpreted by the interpreter.

-- Mikael

If you can live with out an RTOS. Mature tools, lots of fourms, lots of code samples, A bigger selection of parts, dirt cheap. Sometimes a cheap lame CPU fits the bill.

Or you could use bit vatiables.