I2C address used in STM32-i2c drivers

[Blast545]

Hello, when using I2C boards to communicate in "Master_Request_Write" and "Master_Request_Read" functions, the I2C address used is taken using the following function:

Address_to_use := UInt8 (Addr) and 2#1#;

This takes the upper 7 bits of the Addr. I think the standard is using the lower 7 bits of the address field, at least for most of "open source" sensors/boards, most of them come with the address written in the lower 7 bits in hexadecimal.

So, it is not like the library it is not working at this point, but it does not follow what I think is an I2C standard. I think there could be two approaches to "solve" this issue:

1. Maybe writing an additional description in the I2C functions that the user should be using: Master_Transmit, Master_Receive, Mem_Write and Mem_Read. Maybe putting this info in the description of the package?

2. Changing the function to shift_left the register address before taking the and/or operations, and updating the I2C address of the already written components. I think this one will require as well some sort of informative text, as some people working already with these libraries might be used to the current state of the library.

Let me know what you think, and thanks for your time!

[Fabien-Chouteau]

Thank you @Blast545, we are indeed not compatible with the most common practice.

I am in favor of changing this, but it will have an impact on the existing projects.

[Blast545]

Yes, I thought the same, changing the library as it is now, might affect the library current users that know how it works.

Eventually users with a problem like the one I had, just need to use a Shift_Left function to solve the problem, so maybe finding a good way to let them know that they have to be careful about this is enough.

[pat-rogers]

On 2/18/2019 10:16 AM, Fabien Chouteau wrote: Thank you @Blast545 <https://github.com/Blast545>, we are indeed not compatible with the most common practice. I am in favor of changing this, but it will have an impact on the existing projects.

I had seen it both ways. Some drivers (in other libs) required the clients to shift the address, others did it for the clients. Some documentation for the actual devices connected on the I2C bus did not seem to do the shifting, ie the docs would just say this device is at address N. (The Mindstorms sonar sensor, IIRC, is at documented as address 1.) Some drivers require the client to set/clear the low-order bit for the direction. I definitely do not think clients should do that themselves. It is less robust for the client to have to remember to do the shift. It is also less robust for the client to have to remember not to do the shift. :-) But since the last bit is used for for things not exactly part of the address, I felt it best to do all the required manipulation -- the shifting and the low-order bit setting/clearing. Originally, the drivers did that. I don't know if that is not done any longer.

[RREE]

I have just learned the hard way that ADL expects the I2C address in the upper 7 bits of a byte. Most libraries that I know and explaining internet ressource simply use the value range 8 .. 16#77# (https://i2cdevices.org/addresses)
BTW the interface cannot distinguish between the 7bit address 16#44# and the 10bit address 16#44#. Both values are valid in the two address spaces