While investigating the period of SCL being slower than desired, it was
found that the JITTER_TICKS carry over from the legacy implementation
does not appear to be required anymore. This commit sets JITTER_TICKS
to 0. This implementation was verified via xsim tests and viewed on a
scope to meet i2c specification timings.
Closes #6
It was confirmed that the SCL freq is not related to xmos/xcore_sdk#491.
Testing with an XCORE-EXPLORER-AI, I measured a period of 2.64us, thus 378.8kHz when set for 400kHz. This commit now has a period of 2.56us, thus 390.6kHz.
It is worth noting that the previous version was still within I2C specification, as 400kHz is the maximum frequency, not required frequency.
While investigating the period of SCL being slower than desired, it was found that the JITTER_TICKS carry over from the legacy implementation does not appear to be required anymore. This commit sets JITTER_TICKS to 0. This implementation was verified via xsim tests and viewed on a scope to meet i2c specification timings.
Closes #6 It was confirmed that the SCL freq is not related to xmos/xcore_sdk#491.
Testing with an XCORE-EXPLORER-AI, I measured a period of 2.64us, thus 378.8kHz when set for 400kHz. This commit now has a period of 2.56us, thus 390.6kHz.
It is worth noting that the previous version was still within I2C specification, as 400kHz is the maximum frequency, not required frequency.