Visual Studio Code Support

[vindicatorr]

Something I'd like to see is support under VSCode.

I'm able to work with ST boards using 3 different paths (st-util, cortex-debug (extension?), and openocd).

I've seen very little support for AVR stuff in/for vscode.

Right off the bat, vscode doesn't seem to be able to attach/listen-to simavr. I have the launch.json parameter "serverStarted" looking for "avr_gdb_init listening on port 1234", but it always times-out after 10 seconds (default). When I have the logging verbose in vscode, I can copy/paste the entire logged simvar command (including arguments) into a terminal and it runs just fine there. I would have figured it would work just like how I have st-util set up in vscode, but it doesn't for some reason.

So instead of launching simavr in vscode, I just do it in the terminal and then launch avr-gdb within vscode and things get just as sketchy there as well. I can set breakpoints in vscode and jump over "atmel_start_init()" (using basic/template atmel code to start with), but it bypasses the while loop.

Stepping through that init function, I now see cpptools losing some connection "Connection to server got closed. Server will not be restarted.", but in my terminal simavr still only shows

Loaded 160 .text at address 0x0
Loaded 0 .data
avr_gdb_init listening on port 1234
gdb_network_handler connection opened

so I don't know where that "closing" occurred.

All of this may just be stuff that I need to bring up at https://github.com/microsoft/vscode-cpptools

I just haven't seen squat in terms of references between vscode and AVR stuff. There may be a reason I'm just not aware of.

EDIT0: Never mind with the "closing" crash that seems to be related to the vscode c_cpp extension: https://github.com/microsoft/vscode-cpptools/issues/3270 It didn't happen when I tried it another time. But stepping through that init, I get out of sysctrl_init() and it won't step any further back up. Then if I click on the debugger "pause", simavr notes "GDB hit control-c". Then when I stop the debugger, simavr notes 4 more of those messages. It looks like something borks with the "static inline int8_t sysctrl_init()"

MCUCR = (0 << SM2) | (0 << SM1) | (0 << SM0) | // Idle
            (0 << SE) | (0 << PUD);

where the "return 0" is never hit

[buserror]

I tried to use vscode for C stuff recently, and I couldn't get it to work properly. Basically it failed to read/parse error messages from gcc/make properly so you had to go back manually to check stuff back in the editor, which is defeating the purpose of having an IDE! I've reverted into using Eclipse for now, even if it looks a bit creaky -- the indexer is still miles ahead of vscode, IMO.

[vindicatorr]

I totally get that vscode and extensions have issues. It gets quite maddening for myself as well. Though it really is more like anything I come across anywhere is problematic which makes my getting through my own stuff harder.

I created issues for example with the cpp extension using 1.5GB+ of data in /tmp (which actually is bound to RAM instead of disk space) for intellisense. Also encountered an issue with kernel 5.2 regarding my tv tuner and also just overcame a gpg issue by going with another option. And these last two just happened over the past day. I swear I probably spend more time working through problems than I do on my own projects.

Shoot, I actually posted on AVRFreaks about a simple LED blinking example using Atmel_Start, to find that the code generated for my atmega16 wouldn't even work, so I'm just going lower-level using the datasheet instead. What a pain.

Finally, I made use of simutron (also tried simulavr and simulide) which I think makes use of your simavr and it's been working with debugging via vscode. I may have made "some" change(s) so I could also debug in vscode directly with simavr as well (besides using simutron). I'll just close this now since I'm able to get it working out ok.