Interrogizer is an Open Source project, aimed at providing developers with an affordable and easily producible tool to aid troubleshooting by enabling measurement of digital signals. Started from a desire to share hardware knowledge around Codethink, the device uses a small microcontroller placed on a simple PCB that can be easily and cheaply produced; allowing for iterations of the product as development progresses.
All information on what is required to build the hardware, software and instructions for use can be found on the project GitLab.
As Interrogizer is a board designed for debugging and prototyping, it provides access to different functionality via a simple interface:
- Low bandwidth (200kHz) logic analyser
- Host controlled GPIO (up to 16 pins)
A logic analyzer is a tool that is used to capture multiple time-varying signals from a digital circuit and then display them for analysis, to aid in developing or debugging digital systems.
Open logic analyzers are not a new thing, but what Interrogizer aims to do differently is to remain low cost, even at the expense of more advanced features. During firmware development there have been points where we could either optimize our approach or just upgrade the hardware to achieve similar results, however the latter way would have led to the overall cost rising.
Interrogizer is based around an STM32F072C8T6. This ARM Cortex M0 microcontroller is the highest priced part on the board; but at around £2.50 it still isn’t considered expensive.
The PCB was designed in the open source PCB design package KiCAD, a program that has seen a lot of development in recent years. KiCAD is a great way for both experienced and newcomers to create PCBs and with the advent of cheap PCB manufacturing it has massively lowered the barrier to entry for hobbyist projects.
It has a USB-B connector for host connection to the device, with a 20-pin output header with GND, 5V, 3.3V and 16 I/O pins broken out. The connectors, physical dimensions and LED placement are done in such a way that the board fits inside an existing off-the-shelf-enclosure that measures 102mm x 52mm x 26mm.
The input header is connected to two groups of pins on the STM32F07, and each of those groups is referred to as a port on the MCU. Port A is 3.3V tolerant as it is also shared with the internal ADC, and port B is 5V tolerant. Both ports are protected by an array of SRV05-4 rail clamps to provide overvoltage and ESD protection.
The remaining GPIO from the microcontroller is broken out to an internal header, primarily to allow for future use, but it’s something that has been helpful during firmware development so far.
There is, of course, an obligatory RGB LED to show device status - visible through the case!
The firmware is based on LibOpenCM3 and revolves around the USB CDC connection to the host PC. Once the device has been enumerated, the host driver software will send commands to determine what function the device fulfills.
Currently that's only the Logic Analyser mode.
USB Commands are polled and each command is mapped to a corresponding function in the firmware.
Interrogizer is being developed with the sigrok stack in mind. We have a development branch from the main trunk of libsigrok to add support for our device. The goal is that these changes will be upstreamed to sigrok.
- libsigrok is a shared library written in C, which provides the basic hardware access device drivers for logic analyzers, as well as input/output file format support.
- libsigrokdecode is a shared library written in C, which provides (streaming) protocol decoding functionality through protocol decoders written in python.
- sigrok-cli is a command-line frontend for sigrok.
- PulseView is a Qt-based logic analyzer and oscilloscope GUI for sigrok.
With support in libsigrok we are able to pipe our captured signals through the stack to be analysed and displayed using existing tooling.
As the firmware matures, and Interrogizer is put to use we can be begin to realise what other functionality can be brought in. Despite its size and cost, the STM32F07 is a versatile and powerful MCU that we're currently not exercising to its full potential.
With hardware changes to the board to support it, the MCU is capable of CAN communication. This would open up the possibility of using Interrogizer on projects that require analyzing the communication networks in modern vehicles.
It would be great to get more speed out of the logic analyzer functionality via an increased sample rate. There are paths to investigate to further optimize the firmware for this; or the possibility of hardware changes to bring in a part capable of USB 2.0 communication.
There are many avenues that can be taken to further develop Interrogizer and our hope is that as these cover vastly different hardware and software approaches that it will appeal to a wide range of people who can contribute and help shape the future of the project.
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Cycling around the world
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- Getting into open source
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Codethink creates custom USB 3 switch to support customer's CI/CD pipeline requirements
- Codethink unlocks data analysis potential for British Cycling
- MIT Doctor delivers Manchester masterclass on innovative safety methodology
- Balance for Better: Women in Technology Codethink Interviews
- Introducing BuildGrid
- Configuring Linux to stabilise latency
- GUADEC 2018 Talks
- Hypervisor Not Required
- Full archive