Stacking the Protocol Decoders i2cdemux or i2cfilter on a known good i2c Signal (i. e. The Dallas DS 1307 Test File) does nothing in Pulseview. The ds1307 Protocol Decoder works fine. In Sigrok-CLI, stacking i2cdemux or i2c filter on top of i2c gives identical output to i2c alone (tested with DS 1307 Test File again). The ds1307 Protocol Decoder works fine.
Hi, thanks for the report! The i2cfilter decoder is working fine actually, i2cfilter and i2cdemux are just a bit more "special" than most other decoders. They don't emit annotations like other decoders but rather "OUT_PYTHON" data which is used by other decoders which stack on top of these. From the docs (admittedly not yet shown nicely in PulseView, we'll fix that): ---- $ sigrok-cli -P i2cfilter --show [...] Documentation: This is a generic I²C filtering protocol decoder. It takes input from the I²C protocol decoder and removes all traffic except that from/to the specified slave address and/or direction. It then outputs the filtered data again as OUTPUT_PROTO of type/format 'i2c' (up the protocol decoder stack). No annotations are output. The I²C slave address to filter out should be passed in as an option 'address', as an integer. A specific read or write operation can be selected with the 'direction' option, which should be 'read', 'write', or 'both'. Both of these are optional; if no options are specified the entire payload of the I²C session will be output. ---- I.e., the i2cfilter decoder is meant to be stacked inbetween the i2c decoder and another higher-level decoder (e.g. i2c->i2cfilter->mxc6225xu or i2c->i2cfilter->ds1307 etc.). Example: $ sigrok-cli -i trekstor_ebr30_a_i2c_30s.sr -P i2c:scl=SCL:sda=SDA,i2cfilter:address=21,mxc6225xu -A mxc6225xu The sample file (from the sigrok-dumps repo) contains I2C communication of 3 different slaves (see README in sigrok-dumps/i2c/trekstor_ebr30_a), one AXP199, one H8563S, and one MXC6225XU. This will filter out only communication with the I2C slave with address decimal 21 (which is 0x15, i.e. the MXC6225XU), from that file. The mxc6225xu decoder is then stacked on top of that "filtered" i2c output then and will only decode what is *actually* MXC6225XU communication. I.e., we will not feed any AXP199 or H8563S communication into the MXC6225XU decoder, since it doesn't know how to correctly decode those. Similarly, the i2cdemux decoder works like this: ---- $ sigrok-cli -P i2cdemux --show This is a generic I²C demultiplexing protocol decoder. It takes an I²C stream as input and outputs multiple I²C streams, each stream containing only I²C packets for one specific I²C slave. ---- This is meant to allow to "split" one I2C data stream into three different i2c streams, each only containing the I2C traffic of a specific slave; that'll allow stacking three different higher-level decoders (like AXP199/H8563S/MXC6225XU in the example above) on top of the three new streams (at the same time, during the same "run"). However, this i2cdemux decoders is not yet working properly indeed and needs a decoder rework and probably also some more support in sigrok-cli and PulseView. Leaving this bug open to track progress on i2cdemux.
Hi. I'm new to sigrok and started experimenting with PulseView. I tried to filter with i2c-filter and found the same problem. Only this bug report helped me. Would it be possible to output both "OUTPUT_PYTHON" and "OUTPUT_ANN" at the same time, so that it can be used standalone? Consider the case of an unknown slave, without a proper decoder available. Right now it's not possible to isolate it in PulseView. As for i2c-demux, since there's no way to stack other decoders (because the outputs are not known beforehand), the "OUTPUT_ANN" would be much more useful.