I have tested the bus API of OS 6.63c and OASIS beta9 using I2c which promises new asyncronous mode for handling I2C/SPI.
OS 6.63c, OAT 4.26
The bus API is pratically the same as the previous errors, altough i can easily “hang” the CPU like on the previous versions. I suspect the problem is around the “clock-streching” behaviour because i don’t see problems when communicating with a fast slave device like a sensor.The document still does not even mention “clock_scretching” but i suspect this is supported for some level. Unfortunetely from a point the whole module could freeze from it.
new return codes for bus write API:
o ADL_BUS_TRANSMISSION_NOT_COMPLETED if an error of transmission occurs
(I2C bus only).
o ADL_BUS_LINE_ERROR if I2C lines are not in a good state (I2C bus only).
OS R7.00 OASis 2.0 beta9
there is a problem with the ChipAddress parameter of adl_busI2CSettings_t struct. With 7 bit addresslength the b7 bit is ignored not the b0 bit. (the previous versions ignored the b0 bit and the this part of the documentation is not changed) So if the address of the slave device is 0xA0 you should set (0xA0 >> 1) in the ChipAddress parameter of the adl_busI2CSettings_t parameter.
If i subscribe for a second I2C device the whole WCPU freezes.( The I2c data and clock line stays low, only the
repower helps ).
Some of the return codes of the adl_busWrite/adl_busRead functions disappeared. There is no way to indicate
different bus errors, which could help with developing.
It’s the similar to the previous versions.
First of all, i didn’t experinenced freezes using asyncron API (with one I2C subscription). adl_busWrite worked perfectly. My only problem is that i don’t know when the provided buffer is filled With the new data after adl_busRead. When the interrupt occurs the received data is not in the provided buffer, but some time after the interrupt i can find the received data in the buffer. I could not find this information in the provided documents.
I will test SPI API soon and i will write down here my experiences.