Not sure if a new Workbench bug, but chasing subject issue and finally found a work-around but don’t understand what’s going on…
To preface,
Already tried these as described in prior thread here (and as shown in screenshoot below):
‘clean app and OS (local)’
‘reload window’
'build app and OS (local)
Even tried to start a new build task (new VS Code makefile?) as shown here:
Notes,
Able to ‘particle flash --usb tinker’ from CLI (which works), then back to local compile/flash custom firmware but NOGO (again, appears to work but ‘wrong’ firmware)
Fun fact, opening ‘particle serial monitor’ in CLI in cmd window separate from Workbench right after a flash actually crashes the computer (blue screen of death), not sure if a weird interaction?
Side question, why is your app called ‘firmware’ and Particle firmware called ‘OS’?
FINALLY, found that ‘cloud compile’ and either a ‘local flash’ (type in the name of the .bin) or ‘cloud flash’ works. But why?
Both are firmware as they reside in firm (non-volatile) flash memory.
The OS firmware provides the basis (operating system) for the application firmware.
Just as WIndows/Linux/MacOS are software just the same as any application running ontop of the respective OSs.
Can you run particle binary inspect on the binary you get from your local build?
Something else may be funny too, because the Particle vars, funcs are NOT available in console, despite everything compiling great (and Intellisense happy too). Perhaps this is just a symptom right now…
If so, isn’t ideal method to set the OS target version in Workbench, and then local and/or cloud flash to do it right?
Another note, the device is part of a Particle Product and flagged as a development device, wonder if it will take a cloud flash without needing to erase the Product firmware (ex, with ‘particle flash --usb tinker’)?
Speaking of that, is there a handy ‘logger’ app that shows the device ‘booting up’ incl. status of peripherals, maybe LTE too?
Also I’m reading docs and do see the SerialLogHandler which looks great…
Now, does it make sense to use THIS (like global logging) AND the generic Serial.print() (specific events)?
You should not mix the two. You should only use Log.info() and its relatives and the SerialLogHandler and not use Serial.println() and its relatives.
Along other things, the Log.* calls are thread safe, work with multiple output options (Serial1 UART, UDP syslog, SD card, etc.) and that’s what’s used by the system, so you can also get the system logging messages (or disable them, if you prefer).
Thanks again Rickkas! You, ScruffR, and the team are legends, been on here for years. Specifically I recall your serial tutorial and cellular debugging app too.
And great docs, they’ve really come a long ways! I got a couple books too, I like Packt and Manning. But your docs give them a run for the money.
A follow-up note, as suggested in docs, might have to 'expedite' the Particle funcs/vars definitions before setup() {} finishes so they actually register for the cloud to recognize... though how much to expedite I don't know, like where in setup() do they belong, very beginning or somewhere in middle? Too bad you can't just call Particle.connect() after the defs (I tried and think it's already called in background before I call it).
When Particle.connect() is called depends on your SYSTEM_MODE() and whether you use SYSTEM_THREAD(ENABLED) or not.
You can prepare Particle.function(), Particle.variable() and Particle.subscribe() to be registered, before and up to shortly after the cloud connection is established.
The earlier the better IMHO.
The earliest you can do it is in a STARTUP() macro.
