| ??? 09/26/05 22:00 Read: times |
#101582 - Parsing input data Responding to: ???'s previous message |
What I recommend is evaluating the input in a routine called from main(). You already have a buffer for the received data, so all you need is to add a state machine (variable) to identify where you are in the parsing process. For instance if you are expecting a series of bytes followed by a CR you might have simple states such as
#define STATE_INIT 0 #define STATE_READ 1 #define STATE_DONE 2 : As a new byte is extracted from the input buffer you check the current state of the state variable, act on the data based on it's value and the current state, then update the state variable accordingly. So for instance when you get a CR, you set the state to done and process the data "packet". If you get a CR when you don't expect it (maybe byte count is wrong) then you can discard the data and reset the state to INIT or something. |
| Topic | Author | Date |
| RET to a different address | 01/01/70 00:00 | |
| here is how pseudocode | 01/01/70 00:00 | |
| RET to a different address | 01/01/70 00:00 | |
| no flaw, but 1.000.000 gotchas | 01/01/70 00:00 | |
| That's what I wanted to know | 01/01/70 00:00 | |
| Yes | 01/01/70 00:00 | |
| "clever" | 01/01/70 00:00 | |
| OT: my wife | 01/01/70 00:00 | |
| no flaw, but seriously not recommended | 01/01/70 00:00 | |
| experience | 01/01/70 00:00 | |
| reload SP | 01/01/70 00:00 | |
| restoring stack | 01/01/70 00:00 | |
Recognisable string | 01/01/70 00:00 | |
| named return value | 01/01/70 00:00 | |
| Bad Practice | 01/01/70 00:00 | |
| Well phrased | 01/01/70 00:00 | |
| What I am doing with it | 01/01/70 00:00 | |
| try...catch | 01/01/70 00:00 | |
| setjmp / longjmp | 01/01/70 00:00 | |
| when to try ... catch | 01/01/70 00:00 | |
| the borderline | 01/01/70 00:00 | |
| Promises | 01/01/70 00:00 | |
| who cares if an exceptiom is "acceptable | 01/01/70 00:00 | |
| Parsing input data | 01/01/70 00:00 |