In our previous article, we reviewed how to configure Visual Studio Code to compile, load, and be more productive in our NetBurner projects. These features
In one of our recent articles, we review how it’s possible to decrypt traffic encrypted with Wireshark for the purpose of debugging. That’s all well
If you’ve ever had the… pleasure… of debugging a application using an SSL/TLS connection with Wireshark (or any other packet analyzer for that matter), you’re
If you need to speed up computations on your NetBurner module but don’t know where to start, you’re in the right place. During my intern project developing a 1/8-scale autonomous vehicle, I hit a brick wall when computationally intensive tasks started to fail. Instead of accepting that I had reached the limit of the board’s performance, I decided to buckle down and managed to decrease the runtime of computationally intensive tasks by an order of magnitude. This article will discuss the simplest things we can do to measure and improve performance. The provided code is designed to run on a NetBurner module but techniques discussed can be applied to any embedded development project.
Debugging code is often one of the biggest headaches that a programmer can encounter. This is especially true in the embedded systems world, where issues can live anywhere between the lowest level of hardware, to the highest level of application code. Code regressions that are the result of an unknown change in your commit history are especially difficult to track down. However, thanks to the simplicity and magic of “Git bisect”, it will quickly become one of your favorite scenarios to debug. In particular, Git bisect is used to track down the exact commit that led to your broken repository state.
There is nothing more frustrating than having a problem and feeling helpless while some oracle on the other end of a nebulous contact form decides your fate. In the ideal world you would be able to solve your own problems without ever needing outside help, right? Our goal at NetBurner is to make the product in such a way that you rarely need support; not because we don’t want to help you, but to get you farther, faster. We still have a way to go and that’s why we take pride in the quality of our support, blog posts and community forums to fill those remaining gaps.
Stack overflows can be one of the most difficult bugs to squash. An overflow is often hidden in a cryptic, non-static error state. Sometimes the application runs without issue. Sometimes it may hard fault and reset the hardware without warning. It may be overwriting data unbeknown to application designer. The worst error state is the dreaded heisenbug: an error that seems to vanish when you go looking for the cause.