During porting I've been using VSCode, it is a nice tool works on Linux and Windows. Also, with some configuration allows me to xcross debug Betaflight via gdb on the orange PI board.
How is this done? First need to create a configuration to start the gdb on the host, in my case it is Ubuntu running on x86 processor. Here is the launch.json:
{
"name": "C++ Launch gdbserver",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/obj/main/betaflight_LINUX.elf",
"miDebuggerServerAddress": "192.168.1.20:9091",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true,
"linux": {
"MIMode": "gdb",
"miDebuggerPath": "aarch64-linux-gdb",
},
"osx": {
"MIMode": "gdb",
"miDebuggerPath": "aarch64-linux-gdb",
},
"windows": {
"MIMode": "gdb",
"miDebuggerPath": "aarch64-linux-gdb",
}
}
So, this will is the aarch64-linux-gdb that was compile using build root and the ARM target file Betaflight_LINUX.elf file.
On the target, Orange PI Zero plus 2, I use ssh to start a gdbserver session. Using the following command: # gdbserver :9091 obj/main/betaflight_LINUX.elf
this allows the host to attach to gdbserver to debug the app on the target.
I use rsync to copy changes from x86 to orange pi. So, after finding the issue, edit the code using VSCode, cross compile, rsync the start gdbserver.
I was going to add ssh to the launch, but, I tend to forget to do rysnc. Post any questions.
Oh, using gdb and VSCode allows you to set break points in SRC and debug on the remote target. Nice, the only issue is restarting a debug session requires you to manually restart gdbserver on the target.
If you have questions let me know. Right now debugging why IMU is not being found using SPI.
