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.
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
