Well my Nanode project is progressing (it's the one that has the rather
idiosyncratic ethernet handling).
The next question is whether to rejig the basic command handling.
The Nanode software I'm maintaining/improving is basically very simple,
after initialisation it waits for an ethernet UDP packet with a command
code and data in it, then it acts on the command and returns (via UDP
again) some sort of response.
There are currently 34 commands, this will expand somewhat but is
unlikely to ever be more than 100 or so.
The existing code simply has a switch/case block switching on the
command code with the cases handling each command. It's a bit long but
is manageable.
I'm wondering whether to stay with the existing structure or to go to
some sort of table driven approach with an array of something like:-
//
//
// Command table entry structure
//
struct command
{
uint32_t cmd; // the command code
int (* fnc) (int addr); // the address of the function to call
char * str; // the associated LCD string
};
(obviously the function parameters may extend/change)
A linear search of an array of these won't waste much time, speed isn't
of great consequence anyway. Then each command will be a function,
tidier and more modular, but will it actually win me anything (or lose
anything)?
In particular will it use more space, in code or RAM? In code there
will be, say, 50 function calls plus a table instead of a switch
statement with 50 case: blocks. In RAM there will be lots of smaller
functions using a small amount of stack space instead of one big one
with lots of local variables.
This is using the gcc-avr compiler by the way.
My gut feeling is that it probably won't make a big difference either in
code space use or in RAM use but it will probably use a little bit more
of both. The question then is whether the significant amount of rewriting
is worth it for the more elegant (and hence easy to maintain) code.
If there's another approach to managing this sort of command driven
interface then I'd be interested in hearing about it.
--
Chris Green