i2c repeated start transactions

52 posts   Page 3 of 3   1, 2, 3
by joan » Sun Jun 04, 2017 5:28 pm
rchackman wrote:@joan thanks for swift reply... and pigpio really is excellent, just not fast enough for my project (sadly). Have you considered creating a version directly callable from python rather than via the daemon (or am I being stupid)?.

You can always use the smbus module from Python, that won't have any overhead - of course this assumes you are not running the script from a remote PC. pigpio does not force you to use the in-built I2C functions.
User avatar
Posts: 12688
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK
by rchackman » Mon Jun 05, 2017 9:09 pm
@joan Indeed I am using smbus and my code is running local on the pi.

The i2c device I want to communicate with is a homebrew based on a PIC12F1840.

Fortunately, the PIC allows me to hold off the clock on the falling edge of the 8th bit (to support user decision whether to ACK or not). The pi honours this stretch allowing me to read and buffer bytes _before_ the ACK on WRITEs. Interrupts are still generated on the 9th bit falling edge (the ACK bit) but I can detect which side of the ACK bit I am and release the clock very quickly in this case.

At 100 kbaud I'm in and out of my ISR after ACKs in time for the RESTART condition to be met on WRITE-READ transactions - the RESTART you correctly asserted would be present in bcm2835 - and combined WRITE READ transactions are correctly executed.

The scheme falls over at 200k and 400k (the only other values I've had time to test tonight). I've not yet had a chance to fully diagnose the cause but I anticipate it'll be something to do with even the short hold off following ACKs being long enough to mess up the timing.
Posts: 3
Joined: Sun Jun 04, 2017 3:11 pm