I hope this is appropriate and of interest to the mailing list ...
I've recently released firmware, and a host-based user interface, at
https://github.com/thanks4opensource/buck50. From the README:
buck50 is open-source firmware that turns a "Blue Pill" STM32F103
development board (widely available for approx. US$1.50) into a
multi-purpose test and measurement instrument, including:
* 8 channel, 6+ MHz logic analyzer
- Approx. 5K sample buffer depth
- Samples stored only at signal edges for efficient
memory usage
- Units may be ganged for increased number of channels
- Complex triggering via user-defined state machine
supporting combinations of sequential ("A then B
then C") and logical-OR ("A or B or C") conditionals
- Output to VCD and other file formats for export to
waveform viewing software
* Live monitoring and logging of digital, analog, USART
(sync/async), SPI (MOSI/MISO), and I2C
(master/slave/TX/RX) data
* Simple dual-channel approx. 1 MHz digital storage
oscilloscope, approx. 5K sample buffer depth (10K if
single channel)
* 3 channel digital pulse train generator with
user-defined frequency and per-channel duty cycle and
polarity
* Bidirectional bridge/converter from USART/UART
(async/synchro), SPI (master/slave), or I2C ... to
USB ... to host terminal, UNIX socket, or UNIX pty
device file
* 8-bit parallel output counter (binary or gray code)
* Host terminal ascii or binary input data to 8-bit
parallel output
This is very much a beta release. Bugs, comments, and suggestions
welcome at https://github.com/thanks4opensource/buck50/issues. If
there's a competition for the world's cheapest logic analyzer, I want to
enter it. ;)
Regarding sigrok/PulseView: I really like PulseView (as per my username,
"thanks for open source"). But "buck50" outputs potentially sparse VCD
files with long gaps between between time entries. In fact, I'd like to
specify a timescale of 1/72MHz == 13.888..nsec which is the hardware's
precision (not necessarily accuracy) but the VCD format doesn't allow
floating point timescales, or frequency instead of time. (Is there a
better format I could use? I've experimented with PulseView's
import/export options and didn't find one.)
PulseView's excessive memory consumption with this kind of input is a
well-known issue. Having large gaps in sample data combined with short
timescales exacerbates the problem. Note that other display programs
handle these cases efficiently. More details at
https://github.com/thanks4opensource/buck50#pulseview, but has this been
or will it be addressed in development/future versions of PV and the
underlying sigrok libraries? I really do understand what open source
means, so, yes, I should tackle it myself and submit my changes. I'm
just hoping someone with more experience in the codebase will be doing
it anyway.
Again, thanks for sigrok and PulseView. I hope "buck50" can also be
useful to the open source community.
--
MARK
[email protected]
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
