Open greiman opened 1 year ago
Since we are using the FSP driver code here I suggest to raise the issue over at the fsp respository.
Doesn't matter, too many problems for me to use R4.
I would keep this open until we have an upstream fix, since the issue is reflected in our API
I reported this upstream as per @aentinger's advice: https://github.com/renesas/fsp/issues/282
One of things that was done in the chipkit core is to extend the WIRE API a bit. On that core, setClock() returns the actual clock frequency (in Hz), which can often be different from the requested rate and that core also has a getClock() to get the current actual clock bit rate in Hz. (not the last rate requested) These are useful to help determine what clock rate is actually being used. I implemented the code for this on that core, so I am familiar with all the details.
I believe we'd be open to accept contributions to solve this issue, even if they bypass the FSP layer, like I've already done for SPI (see https://github.com/arduino/ArduinoCore-renesas/pull/45). Otherwise we've got to defer this until Renesas fixes it upstream :shrug: . It's a bandwidth problem :disappointed: .
The case statements in void
TwoWire::setClock(uint32_t freq)
are at odds with Wire for Uno R3.Uno R3 allows a range of clock values.
The R4 boards only allow values in this enum:
The I2C standard suggest you should allow the best match possible to the requested clock.