Age | Commit message (Collapse) | Author |
|
The concurrent assertion of ATN and EOI is a PP (parallel poll) query.
The host asserts the control signals, and configured devices may assert
the DIO lines in response.
Because DAV is not involved, and because the input capture may not have
DIO at the start of the PP phase, and may neither have DIO any more at
its end, the check for parallel poll is more complex. Unconditionally
inspecting each sample of the capture is inefficient. Keep manipulating
the main loop's wait conditions instead, to stick with edge navigation
as long as possible, and only switch to inspection of individual samples
when strictly needed.
It's also important to gracefully handle low oversampling. Existing test
cases suffered from PP glitches when ATN asserted in the same location
where EOI deasserted. Be extra conservative about the presence of the
PP phase, expect at least two samples (a difference between its start
and end position) before emitting the annotation.
|
|
The description text of the Commodore peripherals option spanned a
rather wide space. Trim the text for consistency with other options.
|
|
HP gear is said to sometimes send commands (ATN asserted) with a parity.
Introduce an option to check and strip the MSB before interpretation.
Reported-By: Anders Gustafsson <Anders.Gustafsson@pedago.fi>
|
|
|
|
Also flush previously accumulated payload data when the IFC signal
asserts (interface clear, a controller requests ownership of the bus).
This is in line with EOI (end of message) and ATN (start of a command,
including change of "connected" peers or direction of communication).
|
|
When a capture contains output from a talking device, but neither
contains EOI (end of transmission) nor ATN (new commands, including
changes in the set of communicating peers or communication direction),
then lower layer data bytes would be shown but accumulated runs of upper
layer payload data would not. The hp53131a-ton.sr capture demonstrates
this behaviour.
Add transparent support for the typical case of communicating SCPI over
GPIB. Do emit upper layer payload data annotations when termination
sequences for text lines were seen. Allow users to disable this feature
when it's not appropriate for binary content.
It's an internal implementation detail that accumulated data gets flushed.
Communicate the user visible option as "payload data separation", which
should most appropriately reflect the resulting behaviour. The specific
implementation of this feature can also support different kinds of payload
chunk separation.
|
|
This can be used by frontends for decoder search features.
|
|
|
|
Introduce an 'ieee488' protocol decoder which handles both the 16 lines
parallel GPIB variant as well as the serial IEC bus variant. Which kind
of supersedes the 'gpib' and 'iec' decoders.
This implementation increases maintainability because only the extraction
of raw bytes from the parallel or serial bus is separate, and all GPIB
related command/address/data interpretation is shared. This decoder extends
the feature set of the previous versions: Visual annotations are more fine
grained (more classes, additional rows, various text lengths to maintain
usability during zoom). There is binary output for communicated data,
as well as Python output for stacked decoders. Consecutive runs of
talker data gets accumulated, and is made available in binary form as well
as text (with escapes for non-printables). The terse single-letter format
(character codes '0' to 'O' for addresses) is kept for compatibility for
those users who are accustomed to it. The implemented logic also copes
with captures of low samplerate, where edges happen to fall onto the same
sample number which at higher samplerates shall be perceived as distant
and should get processed in their respective order of appearance.
This implementation tracks the most recent configuration of "peers" (the
set of talkers and listeners). A future implementation might support the
isolation of a single conversation out of a busy chat on the bus.
Some optional support for Commodore peripherals is included (currently
limited to disk channels), while it's recommended to move this logic to
a stacked decoder if it grows more complex.
|