Hello,
Tsu_dat (300ns min) and Thd_dat(500ns min) are more stringent than NXP I2C spec.(Fast mode)
Isn't this the other way around? We guarantee that the setup time is extended to allow slow I2C slaves to get "extra time" to prepare themselves for a command. If we had a minimum setup time (t_su;dat) that was lower than 100 ns, then we could have created a compatibility problem with slaves that require more than 100 ns to prepare its bus interface.
Since most IC vendors design their I2C bus with NXP I2C spec, they are not meeting the nRF spec. Does nRF work reliably with NXP I2C spec Fast Mode spec?
We have not gotten feedback, that I know of, that we do not work with certain devices.
We have a theoretical place where we can potentially break the I2C spec from NXP, where we can go under the minimum "tlow" defined parameter for fast mode:
Kind regards,
Håkon
I understand it now. The spec on the datasheet meets the requirement by the I2C standard.
peanutbutter said:I understand it now. The spec on the datasheet meets the requirement by the I2C standard.
Glad to hear! I had to read it a couple of times myself before it started to make sense.
Let us know if anything else pops up.
Cheers,
Håkon
peanutbutter said:I understand it now. The spec on the datasheet meets the requirement by the I2C standard.
Glad to hear! I had to read it a couple of times myself before it started to make sense.
Let us know if anything else pops up.
Cheers,
Håkon