3 ms·

It seems odd that they need to have a signal to unilaterally reset the device, when all you really need is a signal to push it back into a "receptive" state, wh

It seems odd that they need to have a signal to unilaterally reset the device, when all you really need is a signal to push it back into a "receptive" state, where it will accept commands such as "reset firmware" from any control hub that connects to it. Then, all you need to do is use a signal such as "on-off a bunch of times", at which point it goes into receptive state for, say, 30 seconds, then returns to normal operations if nothing sends it a command. Now, if your kids decide to flip the switch on and off a bunch, all you have is a 30 second window where normal commands don't work, after which everything goes back to normal with no real harm done.

Nasrudith 7y ago
I think the issue is that sort of behavior requires coherence it may not have and can fail if say its stacks are stuck in infinite loops. That approach seems a bit more like a "launch options" than a "reset" function. A reset signal on the chip level essentially needs to takes priority over all other processes - since if they aren't responding to requests from entering undefined behavior it will never hand over. Then once reset is achieved it restores it to a base state - implying either a default state like say all 0s or all 1s works without any logic (probably not for internet of things) or it loads over a default state from a ROM.
- kstenerud 7y ago
  The way I see it, if they're able to trigger a reset routine from a series of on-off signals, they can trigger any code path from it. A base configuration wipe or code overwrite could just as easily be a call to a separate code process/stack that runs completely isolated from all configuration values and supports the primitive commands that you'd need anyway to configure the device to a deterministic state for your use case, or update the firmware, etc. If you're able to configure the device in the first place, you're able to trigger it again since nothing on that code path ever changes, has persistent state, or reads configuration values.

Nasrudith 7y ago

I think the issue is that sort of behavior requires coherence it may not have and can fail if say its stacks are stuck in infinite loops. That approach seems a bit more like a "launch options" than a "reset" function. A reset signal on the chip level essentially needs to takes priority over all other processes - since if they aren't responding to requests from entering undefined behavior it will never hand over. Then once reset is achieved it restores it to a base state - implying either a default state like say all 0s or all 1s works without any logic (probably not for internet of things) or it loads over a default state from a ROM.

kstenerud 7y ago
The way I see it, if they're able to trigger a reset routine from a series of on-off signals, they can trigger any code path from it. A base configuration wipe or code overwrite could just as easily be a call to a separate code process/stack that runs completely isolated from all configuration values and supports the primitive commands that you'd need anyway to configure the device to a deterministic state for your use case, or update the firmware, etc. If you're able to configure the device in the first place, you're able to trigger it again since nothing on that code path ever changes, has persistent state, or reads configuration values.