It looks to me that you're ORing terms that you need to be ANDing. I2C_ON is 0xFFFF, so the register is going to be all 1's.
Take a look at the i2c.h file for PIC24:
#define I2C_ON 0xFFFF /*I2C module enabled */
No matter what else you put in the configuration word, they're all going to be 1. Many settings you need (general call off, 7-bit address, etc.) need their corresponding bits to be zero.
Here's how I init the I2C peripheral on a dsPIC33 (essentially the same peripheral and same library calls):
OpenI2C1(I2C1_ON & I2C1_IDLE_CON & I2C1_7BIT_ADD & I2C1_STR_EN & I2C1_SLW_DIS & I2C1_GCALL_DIS & I2C1_SM_EN & I2C1_IPMI_DIS, clk);
Also bear in mind that the clock argument should be unsigned int - not 4.2 :)
(When in doubt, don't use the library call and manually set the SFR bits yourself.)
There is no way to do what you want and still follow the I2C protocol. The closest you can get is the "Repeated Start" condition. Even with a repeated start, you must send the address a second time to read.
"Repeated start" is used in the case of a multi-master system, and it allows a master to lock the bus and prevent it from being taken over by another master. Instead of issuing a stop bit, the master sends another start bit, and retains control of the bus until the stop bit is sent. In this way, you could call the repeated start a single "operation", even though multiple reads/writes can be performed.
In your theoretical protocol, how much speed do you think you'll gain by not issuing the address a second time? Is that time savings needed for your design?
Best Answer
Have you considered the often confused issue of the slave address being considered a 7-bit quantity versus an 8-bit quantity?
When a slave address is considered an 8-bit quantity the least significant bit (LSB) of the address is the R/W bit so the slave device looks like it responds to two addresses, one for read and the other for write.
When specified as a 7-bit quantity the slave address is encoded as a value independent from the R/W bit.
Your waveform picture shows the 0x68 address encoded as 7-bits. But it could be that the device data sheet may have specified as an 8-bit in which case you may need to send out that first byte of the I2C protocol as a value of 0x68 instead of the 0xD0 value you have used now.