Yes, state machine is the way to go.
You need to define a state for every possible place where you want something different to happen, and then chain the states together in the corect logical sequence.
Eg, read the RTC, if timed out, set a state to read the data. When that is done, set the state to whatever routine you need to get the data transmitted. Likewise in the TCP setup, run the setup code ( one state ), and when its complete ( another state ), then enable the data transmission ( a third state ).
Its easy to use a timer to do a lot of this. Get to a state, load a timer with a timeout, set the next state. Then in that state, check whether the timer has timed out, if not, dont change the state ( but carry on and do any other main loop processing ). When the timer has timed out, set the next state, which does the next operation. When that operation is complete, set another state. This way the processor can never be 'blocked' waiting for something to finish.
I do something similar with a mechanical system which uses motors to control several different arms and things, then start a process only when all the arms are in the right places - ie when various limit switches are closed, and/or timers have timed out. Getting the logic right is the main trick. But at least with a state machine, you only have to swap a few state numbers around to change how the logic flow works. It makes it very much easier to follow the logic if you use constants to give each state a meaningful name.
↧