Setup dev container for ZSWatch development environment

[Kampi]

ToDo

• [x] Necessary extensions for VS Code
• [x] Necessary settings for VS Code
• [ ] Necessary tools
  • [x] AStyle (3.1 @jakkra is this the version from CI/CD?)
  • [x] CodeChecker
  • [ ] Valgrind
• [x] POSIX build possible?
• [x] POSIX GUI
• [ ] Bluetooth connection
• [x] Driver for Segger J-Link
• [x] Downloader for Segger tools
• [x] Debugger
• [x] Update documentation

Open issues

Unplugging the programmer and reconnecting with WSL brick USB in the container. Find a way to fix it

• Windows Host + WSL + Container (Faulty)
• Linux Host without Container (good)
• Linux Host with Container (Faulty)

Shall we use GDB with the JLink GDB Server as replacement because TCP works better than USB?

Pro:

• Container and host are completely separated and different hosts with the container are supported
• No current or future issues with USB
• Remote debugging will be possible (not sure if neccessary)
• Higher variety of possible debugger without changing the project

Contra:

• You need an additional software on your host

[jakkra]

AStyle 3.1 I got from apt-get

[Rayvert64]

It seems like this is started, but I can't seem to find a branch/pull request for this. I can help set it up, I was going to do this anyways for my own setup of this project. 🙂

I'll just start on my end and do a pull request if need be 🙂.

[jakkra]

It seems like this is started, but I can't seem to find a branch/pull request for this. I can help set it up, I was going to do this anyways for my own setup of this project. 🙂

I'll just start on my end and do a pull request if need be 🙂.

Hi, this is the PR we abandoned https://github.com/jakkra/ZSWatch/pull/211

There where too many tradeoffs etc. making the container harder to use than just installing with the nRF tools (which IMO is easy). What I remember, debugging requires starting a GDB server and having extra handling for it in VScode etc. and other quirks.

I'd say don't spend too much time on it, as it turned out quite messy for us to get it running well without tradeoffs.

[Kampi]

As @jakkra mentioned. But you can check out the branch on my GitHub if you want.

[Rayvert64]

Cool thanks @Kampi, but for now I'll just set it up on my side. :)

I'll try to rework it myself for now without looking at your solution unless I get desperate hahaha. If I have a good potential solution for most people, then I might do a pull request.

If I do one though, my guess is that it will probably be something more like template files?(We used to do this at my old workplace) Perhaps that could be a decent solution, as it puts a bit less of a burden of responsibility for you guys. Would you guys be open to that?

[jakkra]

@Rayvert64 I guess so, I don't have any specific idea how to do it. IMO it's not really needed as I think using nRF toolchain is easy and reliable. But if you can come up with something nice sure go ahead.

[Kampi]

@Rayvert64 what do you mean with template?

[Rayvert64]

I mean having files that the user has to copy/edit to set up their files. For example, a .env.template file and a devcontainer.json.template file. These two files you would track, but you wouldn't track the actual .env and devcontainer.jsonfiles. So the template files are a bit more of a "here's a starting point, most people who edit these should get a devcontainer to work."

I know it kinda defeats the "point" of a devcontainer in terms of you can "just start to code," but I don't think I've ever seen a devcontainer not need at least a bit of configuration to get working. 🫠

I don't use them for that purpose, though. I simply use them to keep my actual system "lean." 😅