Screenshot of a logic analyzer software, showing the SDA channel being split into three separate traces

I2C Tap Helps Assign Blame For SDA Conflicts

May 2, 2022 by Arya Voronova 8 Comments

If you’ve ever debugged a misbehaving I2C circuit, you probably know how frustrating it can be. Thankfully [Jim] over at Hackaday.io, has a proto-boardable circuit that can help!

Inter-integrated circuit bus (aka I2C) uses open collector outputs on a two wire interface. Open collector means a device connected to the I2C bus can only pull the bus down to ground. Chips never drive a logic “HIGH” on the wires. When nothing is driving the lines low, a weak resistor pulls the lines up to VCC. This is a good thing, because I2C is also a multidrop bus — meaning many devices can be connected to the bus at the time. Without open collector outputs, one chip could drive a high, while another drives a low – which would create a short circuit, possibly damaging both devices.

Even with all this protection, there can be problems. The SCL and SDA lines in the I2C communication protocol are bidirectional, which means either a controller or a peripheral can pull it low. Sometimes, when tracing I2C communications you’ll need to figure out which part is holding the line low. With many devices sharing the same bus, that can become nigh-impossible. Some folks have tricks with resistors and analog sampling, but the tried and true method of de-soldering and physically lifting chip pins off the bus often comes into play.

[Jim’s] circuit splits SDA signal into controller-side and peripheral-side, helping you make it clear who is to blame for hiccups and stray noise. To do that, he’s using 6N137 optoisolators and LMV393 comparators. [Jim] shared a NapkinCAD schematic with us, meant to be replicate-able in times of dire need. With this design, you can split your I2C bus into four separate channels – controller-side SDA, peripheral-side SDA, combined SDA and SCL. 4 Channels might be a lot for a scope, but this is no problem for today’s cheap logic analyzers.

Continue reading “I2C Tap Helps Assign Blame For SDA Conflicts” →

Hacked GDB Dashboard Puts It All On Display

March 22, 2022 by Al Williams 20 Comments

Not everyone is a fan of GUI interfaces. But some tasks really lend themselves to something over a bare command line. Very few people enjoy old command line text editors like edlin or ed. Debugging is another task where showing source files and variables at all times makes sense. Of course, you don’t absolutely have to have a GUI per se. You can also use a Text User Interface (TUI). In fact, you can build gdb — the GNU Debugger — with a built-in TUI mode. Try adding –tui to your gdb command line and see what happens. There are also many GUI frontends for gdb, but [cyrus-and] has an easy way to get a very useful TUI-like interface to gdb that doesn’t require rebuilding gdb or even hacking its internals in any way.

The secret? The gdb program runs a .gdbinit file on startup. By using Python and some gdb commands, [cyrus-and] causes the debugger to have a nice dashboard interface for your debugging sessions. If you install a helper script, you can even get syntax highlighting.

The system uses modules and you can even add your own custom modules and commands, if you like. You can also control what modules appear on each dashboard display. Normally, the dashboard shows when the program stops. For example, on each breakpoint. However, gdb has a hook system that allows you to trigger a dashboard using the appropriately-named dashboard command on other commands, too. Using the layout option to the dashboard command, you can even trigger different modules at different times.

Installation is simple. Just put the .gdbinit file in your home directory. If you want syntax highlights, you need to install Pygments, too. We understand you can even use his under Windows, if you like.

We don’t always take full advantage, but gdb is actually amazing. The flexible architecture makes all sorts of interesting things possible.

Customisable Micro-Coded Controller Helps With In-Circuit Debugging

December 30, 2021 by Dave Rowntree No comments

Over on Hackaday.io, [Zoltan Pekic] has been busy building a stack of tools for assisting with verifying and debugging retro computing applications. He presents his take on using Intel hex files for customised in-circuit testing, which is based upon simple microcoded sequencers, which are generated automatically from a high level description.

The idea is that it is very useful to be able to use an FPGA development board to emulate the memory bus component of the CPU, allowing direct memory access for design validation purposes. This approach will also allow the production of a test rig to perform board level verification. The microcode compiler (MCC) generates all the VHDL, and support files needed to target a Xilinx FPGA based dev board, but is generic enough to enable targeting other platforms with a little adaptation.

Another interesting use case enables in-circuit tracing of buggy memory accesses, with the microcode sequencer decoding the accesses and dumping the relevant information out to either a serial port, or even direct to an embedded VGA controller, hardware allowing.

This automated approach to generating customisable microcoded hardware is a very nice trick to have in your bag, and even if it only helps in certain circumstances, [Zoltan] notes that it at least serves as an interesting example of the architecture of computers from history, if not much else.

Source for the example 8085 project can be found on the project GitHub, and the toolchain source can found here also.

For an interesting practical use of microding to implement emulations of historical hardware, checkout this neat switchable reproduction calculator project.

QB64 Hits Version 2.0, Gets Enhanced Debugging

October 17, 2021 by Tom Nardi 28 Comments

Despite the name, BASIC isn’t exactly a language recommended for beginners these days. Technology has moved on, and now most people would steer you towards Python if you wanted to get your feet wet with software development. But for those who got their first taste of programming by copying lines of BASIC out of a computer magazine, the language still holds a certain nostalgic appeal.

If that sounds like you, then may we heartily recommend QB64. The open source project seeks to modernize the classic programming language while retaining compatibility for QBasic 4.5, the late-80s BASIC environment Microsoft included with MS-DOS. That modernization not only includes the addition of contemporary technology like OpenGL, but cross-platform support that lets you run the same code on Windows, Linux, and Mac OS.

The QB64 team released version 2.0 just a few days ago, making this the perfect time to give the project a test drive if you haven’t tried it out yet. The changelog includes platform specific improvements for each supported operating system, as well as a long list of general fixes and updates. But arguably the biggest feature for this release is the inclusion of the $Debug metacommand.

When this command is included in your code, the IDE will insert a debugging stub into the compiled program. During execution, the QB64 IDE will switch over to debugging mode, and communicate with your program in real-time over a local TCP/IP connection. The debugging mode lets you step through the code line-by-line, check the values of variables, and set breakpoints. Once you’re done fussing with the code and want to release a final binary, you just need to remove that single $Debug command and recompile.

We’ve talked in the past about using QB64 to revitalize vintage code, and think the project is a fantastic melding of old and new technology. You never know when you might suddenly have the urge to dust off some code you wrote back in the 80s and run it on an OS that didn’t even exist at the time.

Arduino CLI For I/O Pin Testing

March 21, 2021 by Chris Lott 12 Comments

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.

Remoticon Video: Basics Of RF Emissions Debugging Workshop

January 8, 2021 by Mike Szczys 5 Comments

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.

Professionally-made probes in several sizes

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.

I really enjoyed how Alex started his demo with “The Right Way^TM” of doing things — using a proper spectrum analyzer to visualize data from the probes. But the real interesting part is “The Hacker Way^TM” which leverages an RTL-SDR dongle and some open-source software to get the same job done. Primarily that means using SDRAngel and QSpectrumAnalyzer which are both included in the DragonOS_LTS which can be run inside of a virtual machine.
Continue reading “Remoticon Video: Basics Of RF Emissions Debugging Workshop” →

Beyond Printf(): Better Logging Practices For Faster Debugging

July 21, 2020 by Maya Posch 27 Comments

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

Continue reading “Beyond Printf(): Better Logging Practices For Faster Debugging” →