Closed lambourg closed 3 years ago
STM32.Setup: automatically calling this function fails if two I2C peripherals are used. This is the case for example when using the Touch Panel and the Audio drivers. This pull request checks that the port is uninitialised before trying to re-initialising it.
Calling the initialization twice is most likely an error, in that case an exception would be more helpful than a silent return.
Ok, so what do you propose? Currently, using the Audio and the Touch Screen raise an exception because the I2C is initialised twice. That was not the case before the introduction of STM32.Setup.
Ok, so what do you propose? Currently, using the Audio and the Touch Screen raise an exception because the I2C is initialised twice. That was not the case before the introduction of STM32.Setup.
Make sure at the board support level that setup is called only once. This will also have the benefit or removing a couple of duplicated lines of code.
Well, that's exactly what this change is about. So what do you propose further (e.g. the STM32.Setup introduction is on your behalf, so what do you see as a fix to the current issue?)
Well, that's exactly what this change is about. So what do you propose further
No, your change is to silently return when trying to reconfigure a I2C port with potentially incompatible GPIOs or speed. Creating a pitfall very hard to debug.
(e.g. the STM32.Setup introduction is on your behalf, so what do you see as a fix to the current issue?)
I said "at the board level". Add an init procedure in STM32.Board than can be called by both audio and TP but will do the init only once. Not only this will factorize the code, it will make it more explicit that this I2C port is a shared resource and should be treated as such.
This fixes various issues I discovered while moving the demos to master.