EmbeddedRelated.com
Blogs

Embedded Developers, Ditch Your IDEs – Here’s Why!

Amar MahmutbegovicSeptember 25, 20231 comment

Most vendor-provided IDEs are based on Eclipse, a 20-year-old IDE primarily used for the development of Java applications. Nowadays, there are also custom-made IDEs that can feel and appear archaic.

These are reasons not to like IDEs, but they are really not the reasons to avoid using them. They come packed with essential tools (compiler, linker, debugger), streamlining project generation, library addition, building, and deployment processes. And that’s exactly why you should consider pausing their use, but just temporarily.

Why Should You Ditch IDEs (At Least Temporarily)?

By now, you’ve likely realized the headline is a bit of clickbait. IDEs are great – at least some of them. Even if you don’t prefer vendor-provided IDEs, there’s always the option of switching to VSCode. While VSCode is technically a code editor, it offers IDE-like features when extensions are added, and it supports numerous embedded platforms. So, what’s the alternative to IDEs, and why should you give it a shot?

This article is available in PDF format for easy printing

I've always been fascinated with understanding how things work “under the hood.” The first time I used an IDE for programming a microcontroller, I found myself eager to uncover what was happening in the background. How is my code compiled and flashed to a target? Soon enough, I discovered Makefile, a file used by the 'make' build tool designed to automate the build process.

Makefile - Build Automation

Makefile enables you to run the build process from the command line. It removes all the mystery that a GUI (IDE) introduces and grants you full control over the build process. You can specify the exact version of the compiler, set compiler and linker flags, declare all the source files, and include directories. Interestingly, most of the IDEs are actually using Makefile in the background, providing you with a GUI for setting the include files, libraries, compiler flags, etc.

Admittedly, the syntax of Makefile can be a bit cryptic. That’s why I turned to CMake, a more user-friendly tool that generates Makefiles (or other build files) for you, but still offers you full control over your build automation. Both CMake and Makefile are essential for automating unit and integration tests and for setting up CI/CD pipelines.

Vim - The Importance of a Customizable Text Editor

When evaluating text editors, several factors are crucial – syntax highlighting, code completion, and the ability to jump to symbol declarations or definitions. These features are typically available with mainstream IDEs. However, Vim, like VSCode, is primarily a text editor. Its capabilities can be extended through plugins to resemble an IDE, but it is not an IDE itself. Switching from one IDE to another can pose challenges, necessitating a learning curve to adapt to different workflows. A unified text editor experience across different platforms can significantly simplify your life.

Vim is versatile, equipped with advanced features and a vast plugin base, allowing customization to suit your needs. You can set up keyboard shortcuts for various commands. The visual and edit modes enable switching from “regular” edit mode to visual mode, allowing text selection and manipulation using keyboard shortcuts. Although Vim has a steep learning curve, the payoff is a highly efficient code editor that lets you keep your hands solely on the keyboard, eliminating the need for a mouse.

GDB and OpenOCD - Debugging Tools

To debug your project, you will need to learn how to use GDB, a debugger, and OpenOCD, an invaluable tool for in-circuit programming and boundary-scan testing. OpenOCD serves as both a tool for programming (flashing) embedded devices and as a GDB server. Familiarizing yourself with these tools will deepen your understanding of the distinct roles they play in the debugging process and how they complement each other to enable debugging across different targets.

Conclusion 

Crafting your own Makefile or CMake scripts will deepen your understanding of the build process. You will explore various aspects such as compiler and linker flags, linking with static libraries, and setting up header paths. Vim will elevate your code editing speed, and once you’ve acclimated to it, reverting to anything else is challenging.

So, dive into Makefile or CMake. Experiment with Vim basics. It will require effort, but the experience will grant you a more profound understanding of the build process. GDB and OpenOCD are fantastic alternatives to the inbuilt IDE debugger. If you find these tools suitable, you can maintain consistent development experiences across many different embedded targets without switching IDEs.

And here’s the full disclaimer: IDEs are totally cool, and you should use them. However, exploring embedded development without them can illuminate the background processes and enhance your appreciation for the work IDEs perform for you.



[ - ]
Comment by alvangeeOctober 10, 2023

This is all fine and dandy until the moment you need to see which parts of the code are disabled or enabled by the use of #ifdef. That's one feature the good IDE should provide - indexing and showing the code being used for your current build/solution under editing.

I see this problem every single day when our hardware colleagues use Sublime to edit the software code - it's a PITA and one can't possibly do any serious work on a moderately complex project without proper highlighting. Text editors like Sublime can find for you all the declarations of a function, but if there're several declarations with the same name you can't say for sure which one is used and where to jump.

This is THE reason our team doesn't switch to VSCode from Eclipse yet. As soon as we solve this exact issue we are going to ditch Eclipse and jump to VSCode.

With that said, I agree that knowing how things work under the hood is a good exercise and always useful.

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: