Compile/flash vs Run in VS Code - delay()

Have observed a weird bug in using Particle Workbench on VS Code. It appears that delay() works differently if I compile/flash versus run.

In code I have a loop where it tries to connect to AW9523 a few times before proceeding:

for(int i=0;i<10;i++){
        delay(500);  // hold here 5 s - maybe wiggle wires - proceed tho, don't hang 
        Log.info("AW9523 not found? Check wiring!  %u", i);
        ...etc,

If I compile and flash, each delay takes >5 secs while if I use run, delay is the correct 0.5 sec.

Anyway, I’m about to give up on VS Code/Particle Workbench - I have to go thru so much voodoo to get something to work consistently. Wondering if WiFi console programming is the way to go.

Hi,
I’m not sure I understand what you mean by compile/flash vs run, but the docs are clear on the fact that delay accepts millis, so your delay(500) is supposed to delay for half a second (not for 5 seconds).

5 seconds delay would be:

delay(5000);

Particle Docs:

delay(ms)

don’t give up yet! it’s the best thing ever. VS Code is one of the best text editors/IDEs there is AND if you add Particle Workbench in it, you’ll be super productive.
Best
Gustavo.

1 Like

Thanks for reply. Yes, the 5+ sec delay is wrong - it should be 0.5 sec. By ‘compile/flash’ I mean going to the launch command palette and selecting ‘Compile Application (local)’ and then ‘Flash Application (local)’. By ‘run’ I mean going to the Run menu and selecting ‘Run without debugging’.

I’ve done a little more testing and couldn’t re-create the problem. It appears that possibly the problem is that when I use ‘compile’ from launch command palette it may not recognize that I’ve modified the source? I did the following:

if(something == 1){
do something;
}
print(“something”);

and I changed it to

if(something == 1){
do something;
} else {
print(“something”);
}

But when I compiled then flashed, the revised code didn’t run - it did something and then printed something.

Generally I’ve had best luck when programming multiple devices quitting VSCode and then doing the ‘clean workspace’ on relaunch and then doing ‘run’ and I guess I’ll stick with that for now. I’ve been using Workbench for about 6 months, albeit not every day, and it would be nice to not have it be part of the mystery of why something isn’t working.

1 Like

you could be right. I do not think is a malfunction of the software, but this is my observation:

  • if I modify a file and hit flash (but not compile) VS code will save my file and flash the previously compiled code.
    This can lead me to believe that I flashed my changes, when in fact I flashed whatever got compiled the last time I compiled. Of course, when I hit the flash command, I expect it to flash and not do anything else, but saving the file can be misleading.

@m_m what do you think about this use case? Any improvements that could be made?

EDIT: I must have observed wrong, since I can’t do this again. I can see that the flash puts the device in dfu mode, compiles, then flashes. Sorry!

Cheers

2 Likes