Bus API (I2C/SPI) on OASIS 2.0 beta9

IoT Modules General wireless topics
1

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.

synchronous mode:
It’s the similar to the previous versions.

asynchronous mode:
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.

2

It seems that there is no longer any soft I2C…? :frowning:

3

Hello awneil,

No soft I2C. I have just red the about the new TCU service. You can define periodic fast timers with it. I don’t know the minimum duration because the documentation does not describe it, you can only read this kind of parameters from the WCPU thanks to the new registry service…Anyway, i presume you can define a 100 microsec timer. This could mean an I2C speed of 10Kbit/sec, assuming that the io_busRead and io_busWrite latency is not to much. What do you think, how much is the latency of those apis?

It should be much more easier if we would have a stable hardware I2C bus.

4

I’ve only just noticed that the soft I2C has gone, and don’t have a current requirement for it anyhow - so I haven’t given it any great thought (yet).

But, yes - my first inclination would be to investigate the new low-level features like the TCU…

Of course, the old soft I2C never was very fast anyhow!

5

SPI
I can say that the SPI api is not working on OASIS 2.0 beta9. It seems to me that the WCPU usually (not always) forgets to clock out the data to the slave device, altough the SPI read and write functions return code is OK. The same code ( except from the differiences between the ADL BUS API ) is working fine on 6.63 and 6.63c.

I know this is only a beta vesion and apart from the BUS api it looks like promising for me, but when an API is obvioulsy not tested and faulty like this the supported document should not say :

instead it should be mentioned that the Bus API was not tested yet.

I2C
“I2C freeze” issue said to be corrected in the upcoming 6.63d fimware.

6

Any chance of seeing I2C problems solved for Q24NG products?

7

Hello Guys.
I had similar problems with Q64:
http://www.wavecom.com/modules/movie/scenes/forums/viewtopic.php?f=75&t=2485

8

6.63d had been released, but I’ve still got no I2C problem solution. WTF?

9

I2C on oasis 2.11 works. At least for single slave device, short messages and long pauses between sendings. But it is still much better than hardware freeze on OpenAT!
Will test SPI now.