Closed sbirnbach closed 9 years ago
eBrnd
commented
12 years ago The clock setting/sending mechanism should run in its own Contiki process, separate from the state machine process. Just like all the other processes that measure and send off data are not connected to the state machine.
Regardless, probably the state machine should be able to send broadcasts. This is a kinda big design decision, so I'd like to talk about that in person when all the HexaPeople are around.
eBrnd
commented
12 years ago Just thinking: At least we should somehow be able to determine the state it is in (create an endpoint which holds the state index; be able to read and broadcast it... even write to it >:) )
On the other hand, this could make the compiler much more (unneccessarily) complicated: If you do a if-machine-A-is-in-state-B condition, it has to know what state index the assembler will give to state B...
eBrnd
commented
11 years ago We discussed this some more: The state machine should at least be able to send QUERY packets in order to get the state of endpoints which do not broadcast, or do not broadcast frequently enough.
Scenario: The state machine has to check two values, then execute some action. It would be nice if the state machine could immediately check the second value once the first one has been received. This could be achieved with caching received values (needs memory, and probably a table of "relevant" endpoint IDs), or with actively query'ing the endpoint.
See issue #97
ghost
commented
9 years ago The state machine has had memory for this kind of thing for a while now and caching is really easy.
I'd like to be able to set the date and time of other hexabus boards triggered by a state machine condition. Therefore I need to send packets as action of a transition.
Example: Button is pressed -> switch current time
This might also be necessary, if we want to build some kind of DCF77 hexabus clock setting mechanism.