Troubleshoot Zephyr Like A Pro With Menuconfig

Troubleshooting high complexity systems like Zephyr requires more thorough tools. Menuconfig allows users to see the layers of their system and adjust settings without requiring a complete system recompilation.

The troubleshoot loop

Modify, compile, test.

Modify, compile, test.

Modify, compile, test.

Modify, compile, test.

How do we break out of this loop of trying to change different settings in a program, recompiling the entire thing, and then waiting for a build to finish? Sure, there are some tools to modify things if you’re step debugging, such as changing parameters in memory. But you can’t go and allocate new memory after compiling normally. So what happens when you need to change things? You find the #define in the code, change the parameter, and recompile. What a slow process!

Moving up the complexity stack

We move up the “complexity stack” from a bare-metal device to running a Real Time Operating System (RTOS) in order to get access to higher level functions. Not only does this allow us to abstract things like network interfaces and target different types of hardware, but it also allows us to add layers of software that would be untenable when running bare-metal firmware. The downside, of course, is that it’s more complex.

When you’re trying to figure out what is going wrong in a complex system like Zephyr, it can mean chasing problems through many layers of functions and threads. It’s hard to keep track of where things are and what is “in charge” when it comes time to change things.

Enter Menuconfig

Menuconfig is a tool borrowed from Linux development that works in a similar way: a high complexity system that needs some level of organization. Obviously, in full Linux systems, the complexity often will be even higher than in an RTOS. In the video below, Marcin shows how he uses Menuconfig to turn features on and off during debugging, including with the Golioth “hello” example. As recommended in the video, new Zephyr users can also utilize Menuconfig to explore the system and which characteristics are enabled and available.

 

 

Chris Gammell
Chris Gammell
Chris is the Head of Developer Relations and Hardware at Golioth. Focusing on hardware and developer relations at that software company means that he is trying to be in the shoes of a hardware or firmware developer using Golioth every day. He does that by building hardware and reference designs that Golioth customers can use to bootstrap their own designs.

Post Comments

More from this author

Related posts

spot_img

Latest posts

Golioth Location General Availability

The Golioth Location Service enters General Availability (GA) today, with some updated and improved functionality, utilizing Golioth Pipelines via a new transformer and destination.

An Introduction to the Cyber Resilience Act (CRA) with Kate Stewart of The Zephyr Project

The Cyber Resilience Act (CRA) from the EU was codified in 2024 to improve cybersecurity among all "digital" devices operating under the CE mark. In this post and video, we discuss what it is, what it means for your business, and the implications of using an open source ecosystem (Zephyr) that assists in reporting issues.

Enabling Bluetooth-to-Cloud on the Renesas DA14695

Golioth's Bluetooth-to-Cloud is now working on the Renesas (Dialog) DA14695, bringing our total vendor count up to 4. This post and video show the device talking to an external sensor and transmitting that data through a standard gateway back to the Golioth cloud, enabling it with the same capabilities as an IP based device on Golioth.

Want to stay up to date with the latest news?

Subscribe to our newsletter and get updates every 2 weeks. Follow the latest blogs and industry trends.