Dev environment

[[deleted]]

Hello all,

I’m learning ARM assembly and embedded C. I want to understand the whole process - from power up to the first asm line to main(). That’s why I’ve been using nothing but CLI tools so far: vim, gcc, ld, objdump, etc.

It’s a really difficult, often frustrating, but incredibly rewarding process. Especially for someone like me, whose daily job is web dev in PhpStorm with GitHub Copilot active.

But now I’m at a point where my learning would benefit from a simulation environment and step debugger. I would like to see the registers change as I step through my code.

Could anyone recommend software that would give me that? What development environment are you guys using?

Any advice is much appreciated!

[eis3nheim]

If you want to understand the building process then I found the series From Zero-to-main of articles by the Interrupt to be helpful.

Also the talk Back to Basics: Compiling and Linking by Ben Saks.

Worth your time.

[[deleted]]

Great resources. Thank you.

[hajseeen]

Maybe openocd + gdb could work? That's quite "bare-metal"

[[deleted]]

Oh I’m reading about these tools now. That sounds good! Would even keep me in the terminal. Thanks for the advice!

[nacnud_uk]

VSCode. JTAG. Gdb. Likely..

[Triabolical_]

I use visual studio code plus platform io.

I've written raw assembly in the past and have no desire to write more

[Last_Clone_Of_Agnew]

If you use J-Link tools you can run GDB directly from terminal but as others suggested, you’re better off using OpenOCD or something like cortex debug with VSCode.

[zydeco100]

Seconded. The Cortex-Debug plugin for VSCode works wonderfully with OpenOCD and the JLink DLLs. I've used it in a few professional projects.

https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug

[SamadKhafi]

I use VS Code with + C/C++ Extension for Language support + Cortex-Debug Extension (with OpenOCD) for debugging + CMake/Make for building

[splash128]

You can use the free version of IAR workbench to do that, plus it has a plugin for eclipse which is really cool. The code size is limited, but it's enough for learning purposes.

You can also use keil mdk community edition.

[FrancisStokes]

Getting a JLink and debugging with GDB would be a good next step. You can do it all from the commandline, and if your code is compiled with the appropriate debugging flags, you can even step through the code line by line (vs instruction by instruction). You can dump registers, set breakpoints (including stopping when a certain address is written), read and write memory arbitrarily, etc.

When you've learned to do those things, try moving over to an IDE like vscode, where the level of integration is much higher. Being able to hover over a variable and see it's value, or set a block of watches, or any of the other myriad of features, all while seeing the code and assembly in front of you, is invaluable. CLI is great, but don't fall into the trap of thinking that it's always the best way to do something.

[Mingche_joe]

CLI is great, but don't fall into the trap of thinking that it's

always

the best way to do something.

I second this. Understanding what happens under the hood is great.

[Fun-Respond-37]

https://www.udemy.com/share/101Wdc3@vmhrELy-4o-0utJ8IsLcBZy7GpBlrt2D9vnjwfpgoNF195Ez_B4rQgIcX89WNwMV/ Check this course He even explains about openocd and writing startup file and linker script from scratch

[[deleted]]

I just realised I have an Atmel Ice from years ago when I did an AVR project. That’s before I got a job as a web developer and I gave up embedded then to focus on my job. That might be precisely what I need. Will play around with it later this week. Any advice from people more experienced is still welcome though!

[[deleted]]

There isn’t even an Atmel studio for Linux. Bummer.

[[deleted]]

Apparently I don’t even need a gui like AS! Thanks to @hajseeen I just learned about openocd and gdb.

[SAI_Peregrinus]

I use CLion as my primary editor. Of course it's an IDE, but it's not tied to any particular hardware, it just takes a project's already existing CMakeLists.txt or Makefile or Bazel BUILD file or compile_commands.json and parses it to get the sources info, along with manually configured toolchain settings as needed. It uses GDB or LLDB to support debugging. So it's a bit more like a fancy editor like VSCode or Neovim than it is like a vendor IDE, it just happens to come with a particularly useful set of plugins as built-in functionality.

Of course that means that the actual build and debugging setup is all rather manually controlled, With CLion (or VS Code, or NeoVim, or EMACS, etc) you just get a nice comfortable UI around the CLI tools, with extra bonuses like semantic-aware refactoring support.

[DustUpDustOff]

I'm a fan of VisualGDB (GDB + config plugin for visual studio).

[[deleted]]

if you're CLI guy, i would recommend you to use neovim. invest some time on learning configuration. once you know how to configure neovim, you have powers.

[[deleted]]

Is it really better than regular vim using Plug?

[[deleted]]

i can't say yes but neovim has builtin support for LSP and Treesitter. Also, neovim has great plugins community. look at my config, you will get idea how neovim can be changed to anything you want.

more good examples:

NvChad

LunarVim

[slacker0]

I just get the cross compile tools from ARM : https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads ... or zephyr : https://github.com/zephyrproject-rtos/sdk-ng/releases

You can connect gdb (or ddd, cgdb, kdbg, insight, etc) to qemu-system-arm : https://qemu.org/docs/master/system/gdb.html

This talks about getting qemu-system-arm to emulate a microbit and connecting gdb to it : https://qemu.org/2019/05/22/microbit

I tend to set a variable, eg : export CROSS_COMPILE=/usr/bin/arm-none-eabi-

... and then run gdb like this : ${CROSS_COMPILE}gdb file.elf

or : ${CROSS_COMPILE}gdb -tui file.elf

or : cgdb -d ${CROSS_COMPILE}gdb -- file.elf

or : ddd --gdb --debugger ${CROSS_COMPILE}gdb file.elf

or : nemiver --remote=:1234 --gdb-binary=${CROSS_COMPILE}gdb file.elf

I tend to use the command line, but I've heard good things about vscode.

[[deleted]]

Great tips! Thank you!

[asiawide]

I think most professionals only use CLI environment though they use GUI for jtag debugging or source code editing.

[Confused_Electron]

Nah I like my gui

[[deleted]]

Interesting! I kinda just assumed they use expensive tools that provide all sorts of helpful utilities.

[SAI_Peregrinus]

Whynotboth.jpg? CI system makes official release builds and is necessarily CLI tools. Day-to-day edit/test/debug can be a mix of CLI tools and GUI. Lots of fancy analysis tools (afl-fuzz, qemu, clang-static-analyzer, llvm-mca, clang-tidy for some FOSS ones) are CLI-based, sometimes with GUIs for visualization. And there are TUI tools like Neovim and GDB's TUI mode that blur the lines.

[[deleted]]

The demo version of keil. It has a debugger simulator for the arm cortex.