summaryrefslogtreecommitdiff
path: root/decoders/ir_irmp/__init__.py
diff options
context:
space:
mode:
authorGerhard Sittig <gerhard.sittig@gmx.net>2023-07-17 20:01:07 +0200
committerGerhard Sittig <gerhard.sittig@gmx.net>2023-07-18 21:28:44 +0200
commit0fbf152810a812baee1d7e69d4621bb8445f9e7e (patch)
tree99f41749eee27f80a55b342d6c1ab0e126d6648f /decoders/ir_irmp/__init__.py
parent35753ccad522da1a1241beec0736aa7049a290bb (diff)
downloadlibsigrokdecode-0fbf152810a812baee1d7e69d4621bb8445f9e7e.tar.gz
libsigrokdecode-0fbf152810a812baee1d7e69d4621bb8445f9e7e.zip
i2c: concentrate sample number and value getting in main loop
It's unfortunate how the symbol / bit value handlers of the I2C decoder keep redundantly accessing the .samplenum property. Ideally they should just get an ss, es, value tuple, while the determination of these params should be kept in the .decode() main loop. Prepare the internal implementation to that approach, but enforce an absolutely backwards compatible behaviour for now. This was verified by the test suite. The data bit handler still keeps updating previous bits' end positions when another bit is seen. Which assumes back to back bits which strictly speaking does not match the protocol's definition. The unfortunate application of the second last bit time's width to the last bit time and the ACK slot is kept as well. And the code path needed to be kept within the bit handler, because the second last bit's width only becomes available when the last bit _was_ handled. Which means that the main loop cannot provide a useful es value which matches the previous implementation's behaviour.
Diffstat (limited to 'decoders/ir_irmp/__init__.py')
0 files changed, 0 insertions, 0 deletions