I'm glad to announce that Workbench now uses the particle flash --local command under the hood when doing local compilation and flashing.
Specifically the changes to the Workbench commands are:
Flash application (local) will only put the device in DFU after compilation succeeds, and it will upgrade Device OS on the device if necessary. This is the command you should use the most for local development.
Flash application and Device OS (local) will no longer compile Device OS (unless you're working with deviceOs@source), and it will always flash Device OS to ensure that the application and OS version match. This is a good command to use if you're pulling out a device from a drawer and you don't remember what version of Device OS was on there last time you used it.
Compile application and Device OS (local) still compiles Device OS to ensure that debug symbols are available before local debugging using Flash application for debug (local)
All the local flash commands also support flashing assets bundled for Asset OTA.
Correction: what I like the most is the new feedback I get while flashing, now we know what is going on at any point in time, well done @jvanier (& team)!
If I may, I sometimes have difficulties getting devices to go into DFU mode when flashing locally from Workbench. The work-around then is to put the device in SAFE-MODE and then flash. Couple of minutes later, all seems to be working again. Am I messing up something in my code that 'keeps the device to busy' to go into DFU mode?
Your help/advice would be appreciated as I cannot always physically get to the device again while making changes to the firmware.
When that happens, how do you put the device in safe mode? Do you use the buttons or the command particle usb safe-mode? Have you tried the command particle usb dfu in this case too?
Device OS prioritizes responding to USB commands to reset the device or enter DFU. That works best for application with SYSTEM_THREAD(ENABLED). If you keep running into this issue, let me know because that's something we will want to investigate.
I haven't tried particle usb safe-mode yet... I will make sure to do this and let you know. So far I just assumed it would not work, so I have been using te buttons.
I do not have SYSTEM_THREAD(ENABLED) for this particular project. I will enable it and most certainly give you some feedback. The same device that was giving this issue (with the same code) has been working just fine all day.
I will be working on it more this evening and let you know then.
Hey Friedl, I'm wondering why do you do that to yourself? Just kidding...
But still curious, is there a reason why you are not using that setting as the default for all your projects? I wonder what are the correct scenarios for this to be off, that's all.
Life is too easy... I want to try and make things more difficult for myself Just kidding of course... Less than a year ago getting Serial.print to work was an unimaginable achievement for me, so bare with me while I learn
Should this not maybe then be a default in DeviceOS then?? Like (SYSTEM_MODE, AUTOMATIC) Thanks for the tip though, will be sure to enable it.
Apologies for all the trivial questions... I have been focusing almost exclusively on PCB design and hardware, left the programming part to the clever people
You should always use SYSTEM_THREAD(ENABLED). There is basically no advantage of not using it, and since almost all commercial products use it, including Tracker Edge and Monitor Edge, threading is far more tested than non-threaded. And threads are actually always enabled even if system threading is off.
The reason system threading is not the default it changes the behavior of how setup() and loop() work. With the default of threading disabled and AUTOMATIC mode, setup() and loop() are only called when cloud-connected. With threading or a different SYSTEM_MODE, they always run. Now it's usually far more useful to have them run and just check if cloud connected if you need to, but it would be a breaking change in behavior.
Using SYSTEM_MODE(AUTOMATIC) is fine.
You'll notice that Tracker Edge and Monitor Edge use SYSTEM_MODE(SEMI_AUTOMATIC) and call Particle.connect() in setup(). This is good if you have a situation where you want to boot but not connect to the cloud.
We do not recommend using SYSTEM_MODE(MANUAL) except if you are using the device without cellular, Wi-Fi, or cloud. The MANUAL mode often behaves in ways you would not expect.
For client products I got used to using SYSTEM MODE (SEMI-AUTOMATIC) with SYSTEM_THREAD (ENABLED). In this case (for a tutorial that relies on the fact that the device needs to be connected to Particle Cloud) I am using SYSTEM_MODE(AUTOMATIC)
I think I have narrowed it down to the following scenario;
Device is running in SYSTEM_MODE(SEMI-AUTOMATIC)
Device is running a simple sketch flashing RGB LED and reading an Analog pin, with a serial print.
There is a 10s delay in the void loop()
SYSTEM_THREAD(ENABLED) was NOT enabled at the time
I was:
unable to flash via USB
unable to put device into DFU or SAFE MODE via USB
unable to flash via Cloud
I tried a brut-force approach and was finally able to flash. The flashing part was very slow, took about 2 minutes from the time it actually started flashing until complete. Current DeviceOS on the unit and the one selected in workbench matched.
Hope this helps. I will keep in mind to enable Threads when using semi automatic mode. As this was simply to test and I did not want to wait for cloud connections all the time, I did not think this would be necessary.
Hey, I suspect this delay was the culprit for the device not entering DFU mode, reason being during those 10 seconds the device is not attending other tasks when SYSTEM_THREAD(ENABLED) is not there, hence not receving the command go to DFU mode.
Cheers
Thanks, well noted. I the final version I implemented timers/soft delays, that was just to speed up testing small code snippets... ended up causing delays
Just kidding of course... Less than a year ago getting 
Thanks for the tip though, will be sure to enable it.