[TriEmbed] Visual Studio Code question

[Pete Soper]

The way I read this is I just focus on the .cpp and have it explicitly 
#include <Particle.h> and use forward refs that the IDE would otherwise 
need to insert and handle anything else to avoid the need for a #line to 
keep the source lines faithful in the Dwarf info, right? I'm still 
wrapping my head around the notion that mutating  the .ino does not 
force a preprocessor op to update the corresponding .cpp immediately and 
every time. I'd love to hear the rationale for that being a feature. 
Probably to keep folks like you from being hosed as you ignore the .ino! 
   I'm guessing the Particle dev team has been forced into this 
situation and doesn't like it any more than their users do. But I've 
confirmed this strategy works and the other piece is to never ever use 
Code to edit a source file. Now I'm a happy camper. And as it is against 
my religion to depend on the Arduino IDE's magic insertion of function 
prototypes anyway, my regular style is declarations before usages except 
for the odd case where a prototype is necessary (as in with this code 
where I've got two parametric functions in a decl that has to precede 
that function's body).

But I have confirmed the  dependency handling in Particle Workbench is 
naive. For example, mutating one of the libraries does not force the 
library to be recompiled. Instead Particle Workbench seems to just 
compile EVERY SINGLE SOURCE FILE IN ITS SYSTEM when it decides that's 
necessary (i.e. after "clean" followed by "compile" or after creating of 
a new project).  This "compile everything" step is slow as Christmas on 
my fire breathing (not) Asus Industrial V1000M (four laptop Ryzen 
corses: Passmark around 7k). But when I mutate .h and .cpp files visible 
within the project and its libraries the right dependency checking is 
happening. So I'm quite happy now.

Except the Particle debugger simply no workie here after installing 
openocd. I'm missing a daemon setup or something and getting an openocd 
timeout.  But as I said the Particle Forum is my next stop. I won't  be 
describing anything as "naive" in that forum, as that would be arrogance 
on my part. Just speculating about most of this stuff  as a relative 
newbie with these tools.

Thanks again for all the feedback!

-Pete

PS This posting sent with wrong email address the first time and that 
one seems to be rattling around inside the triembed.org Mailman server 
somehow, so if it appears, ignore it.

On 5/13/21 9:56 AM, Jon Wolfe via TriEmbed wrote:
> You're better off ditching the ino (putting in a stub), and working 
> all in cpp files. I do this too with Arduino. There was a trick to 
> stop Workbench from having that lagging view of the filesystem, but I 
> don't remember what it was.
>
> The debugging with rhe Particle JTAG has been super slow since the 
> Argon /Boron generation of their products that changed cpu to use 
> Nordic's nrf52 line. The previous generation used ST ARM chips and was 
> a little easier/nicer to debug using Eclipse and an ST jtag. I never 
> figured out how to speed up debugging before my involved with the 
> project ended. Nordic chips have decent debugging support via a Segger 
> built in to the Nordic dev kit, im not sure why they didn't go that 
> way as a supported debugging method.
>
>