
How to Use Visual Studio Code to Debug Your NetBurner Applications
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 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
Have you ever found yourself writing an application that, at runtime, reboots seemingly at random? Maybe your application prints trap output to a serial port.
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.
At NetBurner we do our best to deliver a turnkey experience that is easy, fast and as seamless as possible. Yet, there are times when
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.
You can see how this popup was set up in our step-by-step guide: https://wppopupmaker.com/guides/auto-opening-announcement-popups/
From all of us here at NetBurner, we would like to wish you a Happy Holidays and wonderful New Year.
Our offices will be closed from December 24th through January 3rd.
We look forward to seeing you next year!
We use cookies to improve the user experience and for occasional re-marketing efforts. Please click the “I agree” button to consent, otherwise, please navigate away from this page. Here’s a link to our privacy and cookie policy.