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

Developer Tools Particle Workbench
1

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.

2

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)

https://docs.particle.io/cards/firmware/time/delay/#delay-

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
3

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
4

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