|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Hi Lennart and all,
It is not clear from where the list below came from? It looks to me even more complex.
It looks that per the proposal below I will need a “code book” to figure out i.e. encode the state machine.
We need to be careful here and not to drawn to “oscillations” mode at the last mile of the project. This is a small issue and need simple solution.
A text with “shall” that lists all the variables that can’t be changed after IDLE or make them constants defined in IDLE is a simple solution. It also helps with maintenance of it i.e. not further touching the state machine but only a limited text area.
Hi George, Yair,
It's possible to come up with erroneous behavior for nearly every I-type variable, because the state diagram wasn't designed to handle those getting changes while running.
There are many ways to tackle this issue, I'm not hung up on the type assignments I'm proposing, but I do like the uniformness of this solution.
What I could see as an alternative is (so, not introduce types, but I'll refer to the types to see how we should treat each):
A-type: Specifically say that this variable can be set at any time. There aren't that many of these.
D-type and R-type are similar, these need to be variables, but clearly state the rules in the description
F-type: also simple, this is not to be written outside of the function
F/S-type: not sure
I-type: move to the constants section if they can only be written in IDLE, otherwise keep as variable and list states that allow writes
P-type: no issue
S-type: keep in variables section, this will become the default behavior - not writeable by the PSE
All in all, we'd be doing pretty much the same thing.
George and all,
Changing the variables that we want to set in IDLE only and named them “xxxx_latched”, I personally prefer to avoid it unless there is no other option.
What if we do the following options:
On Sun, 2017-10-29 at 15:53 +0000, George Zimmerman wrote: