After the 4 byte TXBUF is emptied, there is a sequence for reloading it. Here is the diagram:
- DATA_REQUEST is set tDREQ1 nanoseconds after the falling edge of the clock for the last bit of the address.
- The firmware reads from PMBST, clearing the DATA_REQUEST bit. Since 4 bytes are being sent out, the firmware needs to make sure that TX_COUNT is set to 4.
- Next the firmware needs to write the bytes to TXBUF. All 4 bytes must be written in a single word write operation. It takes ttxbwrite ns after the write for any clock stretching of the ACK to be ended. If the firmware is fast enough, no clock stretching will occur.
- As soon as the data starts being transmitted, the TXBUF is transferred to the shift register
- DATA_REQUEST is set tDREQ1 nanoseconds after the falling edge of the clock for the last bit of the fourth byte.
- The firmware reads from PMBST, clearing the DATA_REQUEST bit. Since one byte is being sent out, the firmware needs to make sure that TX_COUNT is set to 1.
- Next the firmware needs to write the byte to TXBUF. It takes Ttxbwrite ns after the write for any clock stretching of the ACK to be ended. If the firmware is fast enough, no clock stretching will occur.
- As soon as the data starts being transmitted, the TXBUF is transferred to the shift register
- The EOM bit will be set tEOM ns after the falling edge of the data line indicating the stop signal.
EOM ACK handling is the same as the one byte read above. For 6, 7, and 8 bytes, it is only necessary to put more bytes into the TXBUF register and a higher number into TX_COUNT. At 9 bytes, the TXBUF reload needs to occur again. This continues with TXBUF reloads every 4 bytes until the end of the message is reached.
If code is being ported from an processor limited to a 1 byte TXBUF, it is possible to always write only 1 byte to TXBUF, and to keep TX¬¬¬_COUNT always a 1. This will significantly increase overhead because the data request, write to TXBUF sequence will occur on every byte, instead of every 4.