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.
On May 13, 2021 9:31:06 AM Pete Soper via TriEmbed <[email protected]>
wrote:
The following is not meant to be criticism of VS Code or Particle or
Microsoft, just information about their tool chain in its current state
and the corner cases I seem to be unlucky enough to flush out.
Poking around docs and I can't seem to find the answer to this
question: How to disable the VS Code editor and tell it I'm using an
external editor? I realize VS Code is a code editor and this question
may be another in a long line of benchmarks for heresy. I don't seem
to be able to avoid heresy.
This feature is straight forward with the Arduino IDE and I'm hoping
it's present in VS Code to help me escape from the hopeless confused
state Code (or Particle Workbench?) gets into with mutated files. I'm
seeing a state where it decides I shouldn't really be using vim and so I
can't edit the source from inside Code or outside and have it reflected
sanely in the next build. If I could just find the right button in
files/prefs/settings/Text Editor or the right json entry or something.
But my deeper issue is that even "clean" operations with Particle
workbench don't keep Code from seeing the wrong source files in some
cases. The fact that it doesn't see a clear dependency between .ino and
generated .cpp file (i.e. mutating the former should force recreation of
the latter. And how is it possible a clean doesn't remove the .cpp??? D
U H) All this tells me I need Maxwell's silver hammer. So far I've tried
particle clean local, manual deletion of the .cpp, reset intellisense
database, and reset editor history. Some combination of these has
rescued me but what I really need is a way to say "I'll handle the
source mutations myself" so I can more easily edit a bunch of files at
once and just use Code for the build and debug sessions for where I'm at
with this stuff. Can you tell I still haven't adapted to graphical
interfaces? But I will get my mind right with VS Code, I'm just in a
hurry at the moment.
Also, if there is anybody on the list with experience using the Particle
JTAG debugger with an Argon using Particle Workbench I'd love to get
some of your consulting time for a faster bootstrap and am happy to pay
for it.
Thanks,
Pete
PS This is what it is: my opinion. I love VS Code and don't despise or
hate Microsoft anymore. That started when the kid named Bill was kissing
MITS' ass and moving down the street from them while gloating about his
shitty BASIC implementation and then making his customers his unwitting
alpha and beta testers for decades and duping and screwing this and that
biz partner. I used to have visions of latter day incendiary barrel
bombs dropping on Redmond after getting the campus evacuated to burn all
the source code and stop the torture of Windows users. But their attempt
to embrace and extend open source is going to enable any hidden
imperialist plans to find the same sort of fate as US biz _____ enjoyed
with their attempt at a conquest of China. I wonder if Paul or somebody
else wrote that BASIC? I don't know but don't really care that much.
Yes, I am an ambulatory fossil, but one who knows something about system
software and the difference between juvenile hobby code and commercial
code that respects accumulated wisdom.
_______________________________________________
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
_______________________________________________
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
