Recommendations for general-purpose bus debugger

Equipment
1

Hey folks,

I’m wondering what hardware tools you all use for debugging/testing protocols like:

  • I2C / PMBUS
  • SPI / QSPI
  • UART / USART
  • CAN / LIN
  • 1-Wire

My survey of the market here seems to show that there aren’t many options out there - the best I’ve found is the Bus Pirate, which doesn’t support CAN/LIN and can’t really act as a slave. I’ve seen some others that have poor software support or aren’t really scriptable. When looking at CAN-specific tools, they get insanely expensive.

Does anyone have suggestions for scriptable bus debugging tools that can operate as master and slave for some/most/all of the protocols above? Would love to hear what everyone is using even if it doesn’t meet my ridiculous expectations :slightly_smiling_face:

Shane

2

As a follow-up for anyone else that might be interested, I posted this on Reddit and received some helpful responses.

3

When I just want to talk to something on a board the bus pirate is invaluable. If I am doing board bring up and everything is fresh, I can just put a bus pirate on the i2c, make sure my micro is either desoldered or configured to not cause issues, then start talking to peripherals is great. It’s very easy to script and make sense of some less detailed datasheets.

For CAN bus it gets more complicated. Something like a canable (out of stock) or candlelight. Then just do all test scripting in python. If you want tools to timeline messages and stuff without needed to write anything I suggest shelling out the cash.

I have also done a similar simple usb converter with python scripting for modbus over rs485. The initial investment is higher than just launching an application but it’s cheap and extensible

You could also use a hat on a pi and just ssh or use VSCode remote to dev on that machine as a target.

4

I have a bus pirate, but rarely use it. I found the project confusing, and last time I checked or heard about it, it seems to be (semi?) abandoned. That said, if it’s useful to someone, by all means hang on to it and keep using it.

There are so many ways to proceed for those protocols.

Purpose-built tools

  1. oscilloscope with protocol decoding modules. My low-end Rigol 1054Z can do much of this, and my higher-end MSO5074 does it even better.
  2. logic analyzer, USB-based ones like Analog Discovery or Saleae on up to bench-top dedicated beasts
  3. Bus Pirate
  4. Total Phase analyzers like Beagle, Aardvark, Komodo, etc. A bit pricey

DIY Roll-Your-Own

  1. FTDI chips
  2. MicroPython Pyboard (almost unobtanable these days)
  3. Raspberry Pi (almost unobtainable these days)
  4. Raspberry Pi Pico RP2040
  5. Others, ESP32, Arduino, AVR, ST Discovery boards

Depending on how much effort you want to put into the tools, there are options all up and down the price / feature gamut.

Personally, I’ve been satisfied using an oscilloscope with decoding functions and an Analog Discovery 2 board for most needs when it comes to observing data.

When it comes to generating data, I had some Total Phase modules a long time back. These were very powerful and could even be scripted into a C-language test program, but my units became somewhat obsolete. At the time, they were awkward to use except on Windows, and I found that just using one of the many DIY options shown in my list above was more than adequate for my needs. YMMV.

If you’re comfortable in Python, it’s very simple to fire up a MicroPython script on these embedded modules and bang out your tests in short order. I was really happy with the Pyboard and its metal case, because that made it so easy to carry along in my tool kit and wire up with jumper wires. But one could package an of these modules in a similar fashion.

I’ll make another reply about CAN bus.

Edit: I found the BusPirate project itself confusing, not the actual bus pirate hardware and firmware. Outside of that bad vibe, which admittedly could be off the mark, I was reasonably happy with it.

5

In the last six months, I have worked pretty deep in a few CAN projects and explored the various tools available. The expensive professional systems and their software are no doubt capable, but were overkill for my project and my budget. But if the situation warranted, I wouldn’t shy away from these tools just because they’re commercially sold.

I explored the sub-$200 tools, primarily the sub-$100 ones. The ecosystem of these low-cost CAN bus monitoring, debugging, and testing solutions is large, confusing, and constantly shifting.

The ELM327-variety of OBD2 tools are extremely basic and only suited for very simple automotive monitoring, at low speeds.

For most other projects, I’ve gravitated to the family of USB-to-CAN modules based on Eric Evenchick’s CANtact open-source project. These include the CANable modules from Openlight Labs, the CANable MKS modules from Makerbase, etc. But there are many others in this category.

Wrapping your head around the software tools for CAN is a chore, or it was for me. I try to be OS agnostic when possible, but for these tools I quickly gravitated towards Linux. There are solutions for the other mainstream platforms, but I found the Linux tools to be a better fit for my projects and my way of thinking.

It also very much depends on how you want to use CAN. Automotive, industrial, other? Do you need standard CAN or FD? If you need FD, how fast? One reason I have so many CAN dongles in my lab is that my first project needed FD at 5 Mbd, and quite a few of the FD-capable gadgets maxed out at 4. If you’re doing automotive projects, there’s a world of other network layers piled atop of CAN, and those take time to grasp and find / write the necessary tools for.

I’ll wrap this up by pointing out the recently released CAN2040 project which uses the RP2040 PIO system to generate CAN signals. This eliminates the need for an external CAN controller chip, which can be hard to find these days (you still need a transceiver). It may have some limitations for your application, but it is very powerful. I just got it up and running yesterday and am looking forward to using it a prototype project. But with this ability, that sure makes the Pico’s RP2040 a potential Bus Pirate Killer.

6

This is a good question and this should continue to be an interesting thread.

I don’t know of one, singular tool that can do everything you mentioned without having to basically doing the grunt work to roll your own (e.g., with a RPi or an MCU). But, there are some relatively inexpensive tools that, taken together, will cover much of what you listed.

You can do an awful lot with the ST-Link V3 Set. Unlike the V2, it’s waaay more than just USB to JTAG/SWD. SPI, serial x 2, I2C and CAN are all included and are easy to work with, not to mention scripting of GPIO using ST’s API. I find myself using it fairly often without an ST part in sight.

https://www.st.com/en/development-tools/stlink-v3set.html

Note: for CAN on the V3 Set, you may need a level shifter/line driver for full functionality. YMMV, depending on the target’s power rails and whatnot. However, as it happens, cheap CAN transceivers are readily available. I have a couple, but as it turns out, I never ended up using them because I picked up a…

Peak PCAN, which is drop-dead simple and not _too expensive.

I went from zero to being fairly productive with the PCAN and its free/included PCAN View software in ~15 minutes. I haven’t needed anything beyond that tool, but there is a paid version that allows for scripting of CAN exchanges, including precise timing.

I work with someone who prefers the paid version. He does much more regression testing. So, I suppose that makes sense.

Another poster mentioned the Analog Discovery. That’s most certainly worth comparing against your requirements. It’s a Swiss Army tool like the V3 Set, but with a different focus.

Any list like this would not be complete without making at least passing mention of the powerful Saleae Logic Pro (personally, I’m not much of a fan of the base, non-Pro model). It’s definitely not cheap and it can’t be used for transmitting, but what it does, it does almost magically well. It’s an extremely capable logic analyzer with respectable analog abilities as well (±10V). Given that its sampling and resolution are pretty decent and that both the digital and analog signals (including mixed) can be recorded and analyzed offline, it can go beyond what even a good scope can do, in many - but certainly not all - practical use cases. That said, for less demanding applications, the Analog Discovery may be all you ever need and it’s roughly 1/7th the cost of the Saleae, IIRC.

Edit: I read back through the thread and see that I missed the earlier mention of the Saleae. I left the above paragraph in place, in the hopes that it still adds to the picture.

1 Like
7

For I2C and SPI there are the Excamera Labs products:

Reasonable CLI tool and C/C++/Python library. I do that the I2CDriver sometimes hangs if there are errors / noise on the bus – requiring a power cycle.

8

Not inexpensive but if you are doing a project with CAN, Total Phase Komodo is well worth the price.

Same for USB and beagle.

Key for any bus tool is the accompanying software and API. That costs alot to develop and maintain so it’s difficult to match the capabilities of a “expensive” tool with something inexpensive.

You’ll rarely regret investing in useful tools that make you more efficient and get projects done faster.

For I2C, SPI, UART, I think that it is better to just use some Micro Python or Arduino code running on a adafruit board. Those low level coms don’t require the same analysis and triggering software that USB or CAN typically involves.

1 Like
9

Hi,
I use the FT232h or FT2232hq

It’s able to do USB to I2C and SPI using MPSSE
There are several breakouts you can find online.

Here’s an example project: GitHub - mbains/linux-802.15.4-sniffer: Linux Based 802.15.4/Zigbee Sniffer

10

I forgot to mention another “unobtanium” candidate that someone mentioned in the parallel Reddit thread — the Glasgow Interface Explorer. Perhaps they’ll be plentiful once the initial batches are complete and shipped to the project backers (this was a Crowd Supply project that got waylaid by the component shortage and coronavirus). I ordered one in Feb 2021 and looks like they’re currently scheduled to ship in June of this year.

This promises to be a great tool that checks almost all the boxes for the various serial interfaces protocols we encounter in embedded system designs.

11

I think that @esden is a member of the forum. Maybe he could provide and update. If it involves chip availability, I at least have a solution to the ICE40.

12

Hi everyone,

I saw this thread. I did not want to mention Glasgow as it is not shipping just yet.

That said, we are getting very close to fulfilling the campaign. We have some boards assembled, thanks to a sponsorship from Screaming Circuits. The new workshop with the new PnP machine is mostly up and running so that we can start assembling the remaining 2000 boards. We do have all the parts for the boards here. The last big dependency that we are waiting for is the last prototype round of the cases, which will take a few more weeks to arrive, if that prototype run is finally without any issues we will order a bigger production run. Unfortunately, we can’t just send the boards to Mouser/CrowdSupply for fulfillment, we have to ship the boards and cases together.

If you are interested you still can secure a place in line by placing a reservation order on the CrowdSupply page.

Let me know if you have more questions.

Cheers,
Piotr

1 Like
13

I want to correct a misrepresentation I made above. The Total Phase analyzers that I have (Aardvark and Beagle), old though they may be, are supported across multiple OS platforms. Sorry about that.

I was confusing them with another USB logic analyzer from TechTools called DigiView DV3100. This worked great when I first bought it. It’s now obsolete (replaced by a newer model) and their software is Windows only.

14

@esden

Back in Feb 2021 when I backed your project, I had no application for CAN. Since then, I’ve had two CAN projects. I read yesterday from the original product description that CAN is a work in progress. Is that still the case? For my personal use case, that would be a fantastic bonus feature.

You say people can still back the project. If I recommend my client to “order” one of these today, how would that work? He would get it some months later, after all the early backer orders are fulfilled? Or is the initial project build lot size large enough to accommodate folks who are still placing orders today? I’m seriously considering getting another one myself and telling my client (who is remote) to get one as well. He’s not an EE, but is handy with Python. This could be a great solution for our projects.

Looking forward to your project’s completion (as well as the USB Luna board, another great debugging tool that is throttled by the “great parts shortage”

15

Hi @rclott,

As for CAN, there is an add-on board that Attie developed. I am not sure what the status of the applet (software/gateware) is at the moment. I think it is still in WIP status, you will have to ask him. He hangs out in the Glasgow and Glasgow-addons channels on our discord.

As for pre-order, the first production batch after the “early-bird” does cover the pre-orders right now. So anyone who places an order now will get it at a very similar time to when majority of the campaign backers will get them.

The whole point of Glasgow is to convert a hardware problem into a software problem. That is why it is packing so much functionality into it’s front-end. The add-ons that people develop for it are meant to bridge the very last gap to the protocol itself. Ideally there is no need to develop or solder any electronics to use Glasgow with the target at hand. That said, having some understanding on how FPGAs work is very useful. The applets do contain gateware written in Amaranth, which is embedded in Python, but it is none the less a Hardware Description Language and has to be treated as such.

I am also very much looking forward to sending out all the hardware to people. I hope it will happen soon. :slight_smile:

Cheers,
Piotr

3 Likes
17

I use the Picoscope when I need protocol analysis. 2000 series are less than 150USD, and you get a lot of protocols included in the price:

Serial bus decoding and protocol analysis

PicoScope can decode 1-Wire, ARINC 429, CAN & CAN FD, DALI, DCC, DMX512, Ethernet, FlexRay, I²C, I²S, LIN, Manchester, MIL-STD-1553, MODBUS, PS/2, SENT, SPI, UART (RS-232 / RS-422 / RS-485), and USB 1.1 protocol data as standard, with more protocols in development and available in the future with free-of-charge software upgrades.

Multiple protocols can be captured and decoded, the only limit being the number of available channels (18 for MSO models). The ability to observe data flow across a bridge (such as CAN bus in, LIN bus out) is incredibly powerful.

The deep memory buffers make the PicoScope 2000B models ideal for serial decoding as it is possible to capture and decode many thousands of frames of data.

19

I have an old picoscope but it can’t do streaming capture.

The Saleae Logic would be my pick but I can’t afford one. The software is fast and beautiful and many other things that Picoscope is not.

20

I used a Saleae (belongs to a client) a few years ago and specifically tried some Python coding. I was surprised to find bugs, and eventually switched over to using an Analog Discovery with positive results.

I’m certainly not anti-Salaea, and it’s on my list of things to get and learn how to spell. But if someone can’t afford one, and has a need, I’d suggest trying an Analog Discovery (I saw a new version 3 is coming out, so maybe this means v2 units can be had at a discount???) As for that Python bug, I can only assume it has since been fixed and/or it was related to using exceptionally high baud rates for my serial capture (like 4+ MB).

2 Likes