Hi Stefan.
Many thanks for the bug spot and stating my fix has sorted it out.
I have also fixed the LSM9DS1 for FC9.
I will ask Ben to push to the update system.
Many thanks to you too.
Now it compiles and works very well.
What I have noticed is that with the LSM9DS1 and the MCP690x Thermocouple on the same I2C bus, there is a clock problem.
Only if I set the clock of the LSM9DS1 to 100kHz, the MCP690x has a 100kHz and is working.
If I set the clock of the LSM9DS1 to 400kHz the MCP690x has 400kHz and is not working.
I don't know if the problem is from the MCP690x or LSM9DS1.
Hi Stefan.
The issue will be the MCP6900 hax a maximum clock frequency of 100KHz.
Unless Ben knows different, I'm assuming that the I2C frequency will be assigned to last component to be initilised.
For two different frequencies, you have a choice of using both component on the same connections, with a frequency of 100KHz.
Or use two separate channels.
If 2 channels are not available, then you could use software mode 100KHz for MCP6900 and channel1 400KHz for LSM9DS.
The conclusion is you will need two extra pins if you want to run both at the maximum speed.
At the moment the I2C clock is still causing me problems.
With the LSM9DS1 I have to change the configuration every time I load the program, otherwise the LSM9DS1 remains in software mode.
This means an I2C clock of 25Khz measured with the oscilloscope. It would be an advantage if the component works properly.
If I then select Channel1 and 100khz for LSM9DS1, the clock runs at 100kHz.
But if I set LSM9DS1 Channel1 to 400Khz, the clock still runs at 100kHz
It is also not clear to me how the bus works.
Can I use any component with the specified clock or how exactly does it work? Does it depend on the order of the init of the component as Martin assumes? I have to connect more components and want to connect them correctly.
With an ESP32 device the first component intialised sets the rate of the hardware I2C or SPI channel. All other subsequent component using the same peripheral channel will use the already defined settings. For software channels each rate will be independent to that specific component.
It should be possible for the hardware peripherals to automatically switch their rate to match that specified by the component but will likely add overhead to perform the check and do the switch. I'll look into this as it would be nice to have.
Hopefully the pin corruption in software mode is resolved with the latest library update.
Ok. I will pay more attention to the order of the components.
But that would also mean that I have to adjust the speed of all components with the slowest component on the board
I have done the update, unfortunately it changes the components back to software mode when loading again.
before:
2024-06-17_16-01-26.PNG (17.1 KiB) Viewed 5887 times
after save and load.
2024-06-17_16-02-21.PNG (22.5 KiB) Viewed 5887 times
But that would also mean that I have to adjust the speed of all components with the slowest component on the board.
Yes and to be honest this might be wise anyway for I2C comms on a shared bus, otherwise the faster comms may cause the slower devices to behaive unpredictably.
I have done the update, unfortunately it changes the components back to software mode when loading again.
Now everything works perfect! Saving and reopening is now ok.
All bytes and values are also ok.
Also the speed of the I2C bus is now 400kHz as it should be.
(The cause was MCP960X_Thermocouple1 for the slow speed. I have set this MCP960X_Thermocouple to I2C software mode.)