Is there any way to call a function when a Core/Photon is being reset by the RESET and/or MODE buttons?
I saw something about Hal_Core_Mode_Button_Pressed, but what I really want is something that could run at reset time. Intended purpose is to clear an LED strip so that lights aren’t shining all through a reboot.
I suppose if it came down to it, I could rig up an external button. But I’m being lazy!
But I don’t want code to run at startup, I want something that will happen just before an actual reset starts… My use case is:
I’m working on LED strip animation code. I frequently need to flash new code (either OTA or DFU).
When I either press the buttons to start to enter DFU, or I start flashing OTA, my code stops running, leaving the LEDs in whatever state they happened to be in.
I’d like to be able to run some sort of shutdown function, which could call strip.clear(); strip.show();, before the halt occurs.
Is there an interrupt I can tie into for these events?
As I mentioned before, I tried using Hal_Core_Mode_Button_Pressed, but it doesn’t kick in when you are using the RESET/MODE button combo.
So forget the reset button. What about catching the start of an OTA update? Is there a hook I can use to run user code before OTA is initiated? If not, I think it could be a useful feature. Even if there was some limitation like "the user code only has 10ms to complete, then the firmware update starts anyways!"
Indeed - there should be a variety of interlocks available around OTA (including: “thanks for offering, not now”, “let me just safe the < whatever > I’m connected to, now you can go ahead”, to “Now is a good time, anything for me ?”) - I have no visibility into if/where these are on the feature roadmap, sorry - someone from Particle will have to chime in on the mechanics.
@mdma has been working on System Events which are callbacks you can register for on specific things. I don’t think this work is completed yet but he has the general frame work and a few sample events working. Here’s the enum that describes what you can register for:
enum SystemEvents {
// begin/progress/end
// wifi, cloud, ota_update
// custom flags
wifi_listen_begin = 1<<1,
wifi_listen_update = 1<<2,
wifi_listen_end = 1<<3,
wifi_listen = wifi_listen_begin + wifi_listen_update + wifi_listen_end,
setup_begin = wifi_listen_begin,
setup_update = wifi_listen_update,
setup_end = wifi_listen_end,
setup_all = wifi_listen,
network_credentials = 1<<4,
network_status = 1<<5,
cloud_status = 1<<6, // parameter is 0 for disconnected, 1 for connecting, 2 for connecting (handshake), 3 for connecting (setup), 8 connected.. other values reserved.
button_status = 1<<7, // parameter is >0 for time pressed in ms (when released) or 0 for just pressed.
firmware_update = 1<<8, // parameter is 0 for begin, 1 for OTA complete, -1 for error.
all_events = 0x7FFFFFFF
};
No - it’s all good, @dougal.
It’s important to understand the use cases, and talk through how features like this are envisaged to work - preferably before/during implementation.