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