Messages have 6 header bytes, data bytes and 1 checksum byte.
The 6 header bytes are:
1: i2c destination address (0x82)
2: i2c reply address (0x80)
3,4: message class
5: message type (0x04 = request)
6: data length (0x00 in case of a request)
The 5th byte (6th if you include 0x80) contains the message length. To
double check if the message is correct we can check this against the
actual message length.
Remove the slave thread, set_callback already spawns a thread.
I2CSlave.callback() now puts the result (if valid) in a queue. This item
can be picked up by I2CMaster for further processing.
I2CMaster will wait 0.21s for a result in the queue. 0.21s, because I
always see a response in < 0.2s. If there is no result, it will send the
request again (max 20 retries). This is because I don't get reliable
responses (via pigpiod?). In an earlier commit I mentioned to configure
pigpiod with -s 2 (sample rate 2 microseconds). This doesn't seem to be
true. For example -s 10 gives the same reliability (and less CPU usage
by pigpiod).
--master-only allows to only run the I2C master functionality.
--slave-only allows to only run the I2C slave functionality.
The I2C slave functionality via the "set_callback" mechanism (--type
callback) just executes the pigpio "event_callback()" function and waits
for 2 seconds for a response. The amount of seconds can now be
configured via --slave-timeout.
Argument "--type [callback,wait]" is added to be able to switch between
"wait_for_event()" (previous functionality) and "event_callback()" in
the I2C slave functionality.
In a thread set_callback() executes event_callback() and just (very
dirty) sleeps 2 seconds to get a response or else cancels the event and
stops pigpio.
To get the most reliable output pigpiod is started with -s 2 (sample
rate 2 microseconds). Still most of the time too few bytes are received
on the "getdatalog" action (153 bytes expected).
