I have the highest regards for your contributions in this forum and the competence you share and I'm not implying in any way whatsoever that you are stupid - quite the contrary.
I am not a beginner in this field either and have more years of professional experience with low level software development than I care to admit. Nor would I add to this topic unless I knew it well.
It's also not clear at all how to generate the Repeat Start sequence from the reference material.
With your intimate knowledge of the I2C specification, you will also know that it is impossible to discuss this topic without breaking it down to master/slave transmit/receive and I could only assume you wanted general information on the I2C protocol to be included in the documentation. From your last post however I understand know that you had a specific need.
A master only would call begin with no address, and the slave or slave/master would call begin with an address.
This statement is indeed true and it suggests to me that you may not be intimate with the Wire library. Nor do you offer an explanation to why it would be incorrect.
TWAR = address << 1;
When you call begin with an address above code is all that happends. The address will simply be loaded into the I2C TWAR register. As you know this is used by the atmega to recognize when it's being addressed as a slave. It is used for nothing else whatsoever within the wire library.
The Wire library approach to what you request would be as follows:
beginTransmission(address); // saves copy of address
send(chip_reg); // buffer data
send(chip_sub_reg); // buffer data
endTransmission(); // send as twi master, end with stop
requestFrom(address,count); // receive as master, end with stop
while (available()) {
data=receive();
// do something useful
}
The stop sequence is issued within the ISR that handles TWI state callbacks and there is no way to use the high level API that would allow a send/receive operation to take place without the stop as it is written today.
I have used a number of I2C chips that support repeat start, but I've not run across any that will not also work with a bus release in between.
There are other issues however that have bogged me and I've created a version that address the following:
- smaller memory footprint (isolate master/slave code with a conditional define)
- use static buffers rather than calloc
- add non-blocking versions of the master transmit/request functions with callbacks
As for a function that would combine transmit/receive without releasing the bus would not be much of an issue to add, but I trust you have figured this out already.