|Anonymous | Login | Signup for a new account||2019-09-16 12:02 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000218||Loader||Serial Monitor Comms||public||2011-07-19 16:02||2011-10-24 23:26|
|Target Version||0.1.0||Fixed in Version|
|Summary||0000218: Implement SM Reset Button|
|Description||Be able to send a reset packet to the SM to get back into the firmware (if the load/run switch is appropriate). Use state determined in 0000216 to enable/disable this button. And rerun the interrogation after such a reset to find out what happened.|
|Tags||No tags attached.|
|Risk of Breakage|
|Do you want me to try to detect the position of the load/run switch before giving the ability to reset ?|
Hmmm, that's a nice idea! You'd have to have an API in the firmware to call to query that information though. I guess it's possible to add such a thing. I'm planning to add similar things anyway. You could already do it from the SM though.
However, I think that that is icing on the cake, they basically have to know to do that anyway, so just finding out what state it's in and displaying it and offering the ability to reset from either state is enough for the first release.
You've already done the reset functionality in a convenient grouped way, but I think having "(dis)connect" and "send reset" always there would be good. Once connected you'd always be in either SM mode or firmware mode, and would be able to disconnect, or perform actions. "send reset" would always be available as long as you were connected (to either) such that you could always send a reset to switch states without informing the loader why you're doing it. The loader would have to check afterwards to see what state it needed to be in, at the least. To be truly robust it would have to check immediately before too, as you never know when a sneaky user is going to hit the reset button or turn the key on and off. Another alternative would be to poll the device every half a second or so as a "are you still alive" but the lazy "are you alive RIGHT NOW" approach seems better.
I guess the main point is that if the foundations of interrogation and serial mode switching and handling of streaming packets and so on are laid out well, applying more advanced stuff on top should be cake later. It needs to be bullet proof and robust, just like everything else in the fold :-)
I'm happy with how it's been improving, btw, it doesn't balk at streams anymore etc. A bit more solidness from the ground up and it'll be great! :-)
|Copyright © 2000 - 2011 MantisBT Group|