Am Sat, Feb 10, 2024 at 04:11:17PM +0000 schrieb Jonathan Cameron: > > > > > [...] > > > > #define HDC3020_S_T_RH_THRESH_LOW 0x6100 > > > > #define HDC3020_S_T_RH_THRESH_LOW_CLR 0x610B > > > > #define HDC3020_S_T_RH_THRESH_HIGH_CLR 0x6116 > > > > #define HDC3020_S_T_RH_THRESH_HIGH 0x611D > > > > > > > > #define HDC3020_R_T_RH_THRESH_LOW 0x6102 > > > > #define HDC3020_R_T_RH_THRESH_LOW_CLR 0x6109 > > > > #define HDC3020_R_T_RH_THRESH_HIGH_CLR 0x6114 > > > > #define HDC3020_R_T_RH_THRESH_HIGH 0x611F > > > > > > > > I don't know if it's a good idea, as we would need to make sure it is > > > > big endian in the buffer. Probably with a function that handles this. > > > I think this is the best plan with a > > > put_unaligned_be16() to deal with the endianness. > > > The compiler should be able to optimize that heavily. > > > > > I think that would require some refactoring. I would add patches that > > are fixing this. Have there been reasons for using the pairs ? I'm just > > curious. > > Not that I can think of. Maybe how they are represented on the > dataheet? Often people just copy that stuff without thinking > about it (I know I've been guilty of this ;) > Ok, just wanted to make sure I didn't miss anything. Yes, probably the command table drives one into that direction. Dimitri
