-
-
Notifications
You must be signed in to change notification settings - Fork 81
pybricks/experimental: Add functions to reboot or intentionally crash the brick #346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… the brick This was being used to test watchdog and exception handler implementation.
|
I do think that having "reboot" and "power off" in shipping firmware would be useful, but it would have to be clearly documented that they indeed do what they say (and thus terminates user programs unexpectedly without saving data). |
|
We do have |
|
Oh so we do. It looks like that performs a clean shutdown? It might be useful to add a clean reboot function. These test functions here perform unclean shutdowns, which is why I've put them in |
|
|
||
| return mp_const_none; | ||
| } | ||
| static MP_DEFINE_CONST_FUN_OBJ_KW(experimental_crash_obj, 0, experimental_crash); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would make more sense to use MP_DEFINE_CONST_FUN_OBJ_0 here.
|
We use to have |
|
Fair enough. Thoughts on keeping |
|
Not sure it would be useful in the long term, but we've used experimental before for some things that were helpful while developing a certain feature only to eventually remove them again. So if it is helpful to keep these around while bringing up EV3, I'm OK with it, but they will probably get removed again when we are done. @laurensvalk is kind of the gate keeper on MicroPython API stuff, so best to see what he has to say. |
Instead of having them as permanently enabled but hidden features, would it be useful to have a few functions like these in a module that you can enable in config as needed? Something like I'd like to have it disabled in the build by default once we get closer to the release, since we've often found that people come to rely on experimental features and temporary hacks become permanent. Since it is early days, it can be enabled by default for now, just like we have sensor port 1 currently disabled by default for now. If we have more than a few and across platforms, maybe it could go in a dedicated module |
Now that you mention it, I can definitely see |
from universe import destroy
destroy(password="So Long, and Thanks for All the Fish!") |
I expect that this might be somewhat controversial to have in final shipping firmware, but this was very useful for debugging I was doing.