Wait - what are users doing in their code that needed this?
SPI should be initialized before anything they do in loop/setup. What global constructor things are end users doing that need SPI to be initialized?
(And as it is - your fix requires users to do something in their code - and undef SPI is not a long term solution - because the first time someone wants to use one of these libraries and SPI they’ll hit this).
@mdma Both #undef SPI and the preprocessor pragma didn’t seem to help and I’m still getting those errors. Is there any way to compile with an older version of the firmware?
Another solution then is to have all the methods in your SPI class do a call to init() (or something like if(!m_binited) init()
- your macro is already incurring a function call overhead every time someone references SPI
I don’t believe calling an init() function will work for instances with virtual functions, such as Serial. We were seeing a system lockup due to the instance not being fully initialized before use (even though the constructor for USBSerial, and base classes Stream and Print merely initialize members that aren’t used in a call to print() - I believe the virtual dispatch table wasn’t yet initialized.)
Since the main issue was with Serial, I have reverted the change to SPI until we can find a solution that doesn’t impact existing libraries, or that we can work with library authors to resolve the issue in some other way.
Ah - people are calling Serial.print in constructors for objects that are used as global statics? (Bad devs, no cookies!).
What things get initialized in the constructor? Here’s one idea that might work. Since globals in a single compilation unit are guaranteed to initialize in order, you could have in the header where the SPI object is defined:
class SPIInitializer {
public:
static bool bInit;
SPIInitializer() {
If(!bInit) {
bInit = true;
// use placement new to call the constructor on SPI (and SPI1/2/3 if necessary)
new (&SPI) SPIClass();
}
};
static SPIInitializer;
The static should ensure that each compilation unit has its own instance of SPIInitializer - the construction of which should run before any code that’s going to want to use/reference SPI. (Ditto Serial).
Any cost of having one SPIInitializer per compilation unit would be offset by not having a function invocation (and the code space cost and time cost) at every SPI reference. Bonus complete removal of runtime overhead vs the macro above.
(If I had a working dev environment handy I’d double check this - but still mostly phone bound, won’t land for a few more hours)
Hello, guys, i have 3 photons and i did not used then since september last year so today i wanted to go back to a project i choose 2 of the photons i select the latest firmware put the simple led blink led and press Flash, after this i get > spark/flash/status failed and one photon works like this but one has the red led blinking like crazy like a morse code or so . What can i do ? it seems that the firmware update crashed my photon i don’t know what was the previous version and it seems that the photon does not respond anymore on anything , if i keep pressed the setup button i get the orange blinking fast and that’s it.
Is there a way to reset this thing ? i`m using mac only so any tutorial on mac would be perfect.
I still have one that i did not touched as i’m afraid not to crash that as well.
Thanks.
You can put the device in Safe Mode and try to reflash a known good code or via DFU Mode and use CLI
npm install -g particle-cli
//or if you already got CLI ratger use
//npm update -g particle-cli
//then
particle update
particle flash --usb tinker
Thanks , it worked, i had to install dfu as i did not had it installed and worked right away, but still on the dashboard every time i do a change in the code and i press flash i get that spark/flash/status failed, is that normal ?
You should not pay too much attention to the failed message.
This is a known bug which should get sorted some time.
ok, thanks a lot .