Need to quickly toggle or read some logic signals without the hassle of writing a quick program? [Thor_x86], aka [Eric], built an Arduino sketch that does just that — and he threw in the ability to send (or receive) serial messages, too. This is a neat idea — kind of a simplified Bus Pirate.
We should warn you that this is an early release, and there are a few minor issues which we are sure [Eric] will iron out soon. We discovered the function strtol() was misspelled in cmd_send.cpp, and there are some configuration #defines which need to be sorted out in file parsePin.cpp, depending on which Arduino module you are running. We got it running on an Arduino Leonardo the quickest, because it has support for Serial1().
Don’t be discouraged by these glitches in this rev 0 deployment — [Eric] has really made quite a nice tool here. Check his GitHub repository for updates (or submit corrections yourself). All in all, it’s a good addition to your digital tool box. On a completely unrelated note, we really like [Eric]’s USB cable with the right-angle micro connector, grungy though it may be.
Besides the standard tools like Bus Pirate, GreatFET, FTDI modules, etc., are there any similar tools you like to use for bit banging and serial testing? Let us know in the comments below.
These days we’re surrounded by high-speed electronics and it’s no small feat that they can all play nicely in near proximity to each other. We have RF emissions standards to thank, which ensure new products don’t spew forth errant signals that would interfere with the data signals traveling through the ether. It’s long been the stuff of uber-expensive emissions testing labs, and failure to pass can leave you scratching your head. But as Alex Whittimore shows in this workshop from the 2020 Hackaday Remoticon, you can do a lot of RF emissions debugging with simple and inexpensive tools.
You can get a surprisingly clear picture of what kind of RF might be coming off of a product by probing it on your own workbench. Considering the cost of the labs performing FCC and other certifications, this is a necessary skill for anyone who is designing a product headed to market — and still damn interesting for everyone else. Here you can see two examples of the probes used in the process. Although one is a pack of professional tools and other is a bit of enameled wire (magnet wire), both are essentially the same: a loop of wire on which a magnetic field will induce a very small current. Add a Low-Noise Amplifier (LNA) and you’ll be up and measuring in no-time.
All of us who do some programming know that logging is a time-tested way to output messages about the internal state of our code. With varying degrees of adjustable granularity, these messages allow us to keep track of not only the state of the application, but also its overall health. When things do end up going FUBAR, these log messages are usually the first thing we look at as a software equivalent of a Flight Data Recorder in an airplane.
Spending some time and care in not only designing the logging system, but also in deciding what should be logged and at what level, can make our future self appreciate life a lot more. We’re all familiar with the practice of ‘printf-debugging’, where logging is added as part of the usual post-crash autopsy as one tries to figure out what exactly went wrong. It’s one way of doing it, and eventually it works, but we can do much better.
People are lazy, and you’re only going to stick to good logging practices if they are at least as easy if not easier than sprinkling printf() statement throughout the code. Yet at the same time we want to be able to handle things like log levels and newlines without too much extra typing. The most successful logging libraries are built with this
With this blackmagic-espidf project, one can use any ESP8266 board that has at least 2 MB of Flash program storage, though 1 MB should be possible if OTA updated are disabled. After flashing the firmware to the ESP8266 board, the GDB server can be reached on TCP port 2022 and UDP 2023, with a serial port available via TCP/23, UDP2323, or via the physical TX0/RX0 pins on the ESP8266.
The target board to be debugged is hooked up by default to GPIO0 (SWDIO) and GPIO2 (SWCLK) for Serial Wire Debugging, though JTAG is also said to be supported. If set up properly, next one should be able to pop into a fresh remote GDB session:
We all know what bugs in code are. We don’t like them when they are in programs we use, and they’re even worse when they are in code which we have written. Clearly, the best code is bug-free, but how do we get there?
This isn’t a new question, of course, just one that has become ever more important as the total number of lines of code (LoC) that run modern day society keeps increasing and which is affecting even hobbyists more and more often now that everything has a microcontroller inside.
Although many of us know the smug satisfaction of watching a full row of green result markers light up across the board after running the unit tests for a project, the painful reality is that you don’t know whether the code really is functionally correct until it runs in an environment that is akin to the production environment. Yet how can one test an application in this situation?
This is where tools like those contained in the Valgrind suite come into play, allowing us to profile, analyze and otherwise nitpick every single opcode and memory read or write. Let’s take a look, shall we?
If you do much Linux shell scripting, you’ve probably encountered sed — the stream editor — in an example. Maybe you’ve even used it yourself. If all you want to do is substitute text, it is easy and efficient. But if you try to do really elaborate editing, it is often difficult to get things right. The syntax is cryptic and the documentation is lacking. But thanks to [SoptikHa2] you can now debug sed scripts with a text-based GUI debugger. Seriously.
According to the author, the program has several notable features:
Preview variable values, both of them!
See how will a substitute command affect pattern space before it runs
Step through sed script – both forward and backward!
Place breakpoints and examine program state
Hot reload and see what changes as you edit source code
If you’re reading Hackaday, you’ve almost certainly heard of JTAG. There’s an excellent chance you’ve even used it once or twice to reflash an unruly piece of hardware. But how well do you actually know JTAG? More specifically, do you know how useful it can be when reverse engineering hardware?
Whether you’re a JTAG veteran or a novice, this phenomenal guide written by [wrongbaud] is sure to teach you a thing or two. Starting with a low-level explanation of how the interface actually works, the guide takes you though discovering JTAG ports on unknown targets, the current state-of-the-art in open source tools to interact with the device, and finally shows a real-world example of pulling and analyzing a gadget’s firmware.
There’s no way to do his write-up justice with a breakdown or a summary, so we won’t even try. Just get comfortable, maybe grab a drink, and dive in. It’s certainly not a short read, but there isn’t a wasted word on the page. Every piece of the puzzle, from how to figure out an unlabeled pinout to determining the instruction length, is explained in exactly the amount of detail you’re looking for. This is a guide for hackers written by a hacker, and it shows.