I will test this tomorrow

Maybe @haukepetersen could test this PR on its Thingy52 ?

I will test this tomorrow

@maribu did you?

Sadly not. I wanted to borrow my colleague's Thingy:52 for testing another PR and this one, but the Thingy:52 went missing. I only put this information in the other PR and forgot about this one.

We have a lot of these Thingy52. If somebody needs one, I probably can give a few to you. I just have to ask my boss first. (I don't think that will be a big problem) So, ping me, if you need one :)

The hts221 should automaticlly be found when I use saul_default, right?
So when I use saul in the shell the sensor should be there, right?

Thanks for having a look @Citrullin !

So when I use saul in the shell the sensor should be there, right?

Yes, that's the idea. The tests/driver_hts221 application should also work.

I cannot get an ack from the hts221, I tried 0x5F address and it doesn't work... The 0x19 address works though which is weird since it should be connected to I2C_DEV 1 not 0...
I believe it has something to do with the power settings. It appears the VDD is actually controlled by this VDD_PWD_CTRL pin (p0.30). It seems a high turns the power on and low turns the power off.

Thanks for testing @MrKevinWeiss! I'll have another look when time permits and will try to update.

I can also return to it (when time permits as well), I tried a bit but couldn't get it going.

Now that #12290 was merged (with the same I2C configuration provided by this PR...), I rebased and also added support for lps22hb (that was merged in the meantime as well).

I also found why @MrKevinWeiss couldn't make it work. Will open a PR now. The bug is pretty awesome.

Ya it still seems like the I2C itself is having some problems. I cannot even use the i2c_scan command...
EDIT
it seems like I can use the scan command on device 1 but not 0 as it locks up.

There might be other problems then. I already fixed another one with lps22hb: the address was not correct.

Hmm ya. With the two PRs I get lockup on i2c dev 0 and can read and scan on address 0x19 on i2c dev 1. With master both 1 and 0 behave like one (which is incorrect). I don't know why the terminal locks up on i2c dev 0 though...

I would use make BOARD=thingy52 -C tests/periph_i2c/ flash term and USEMODULE=i2c_scan make BOARD=thingy52 -C tests/shell/ flash term to show what I am talking about.

It appears the VDD is actually controlled by this VDD_PWD_CTRL pin (p0.30)

Can you try to initialize and set this pin high in board init ?

Yup it seems to have fix it.

So adding

void board_init(void)
{
    gpio_init(GPIO_PIN(0, 30), GPIO_OUT);
    gpio_set(GPIO_PIN(0, 30));
    /* initialize the CPU */
    cpu_init();
}

to both the #12372 and this PR then using the i2c_scan command on i2c_dev 0, no longer freezes the terminal but gives the following output.

> i2c_scan 0
2019-10-04 15:01:41,023 #  i2c_scan 0
2019-10-04 15:01:41,023 # Scanning I2C device 0...
2019-10-04 15:01:41,024 # addr not ack'ed = "-", addr ack'ed = "X", addr reserved = "R", error = "E"
2019-10-04 15:01:41,024 #      0 1 2 3 4 5 6 7 8 9 a b c d e f
2019-10-04 15:01:41,024 # 0x00 R R R R R R R R R R R R R R - -
2019-10-04 15:01:41,035 # 0x10 - - - - - - - - - - - - - - - -
2019-10-04 15:01:41,035 # 0x20 - - - - - - - - - - - - - - - -
2019-10-04 15:01:41,035 # 0x30 - - - - - - - - X - - - - - X -
2019-10-04 15:01:41,035 # 0x40 - - - - - - - - - - - - - - - -
2019-10-04 15:01:41,036 # 0x50 - - - - - - - - - - - - X - - X
2019-10-04 15:01:41,036 # 0x60 - - - - - - - - - - - - - - - -
2019-10-04 15:01:41,036 # 0x70 - - - - - - - - R R R R R R R R

I still don't understand why the terminal is frozen. Maybe it could be that the i2c pins are actually held down and it is waiting on a flag or something. If the sda and scl pins were high impedance I would expect them to just return an error code.

@MrKevinWeiss, I rebased on latest master and added the management of VDD pin in board_init (note that this might have other low-power problems, according to the user manual). Can you give this another look ?

I am out of office until Monday. Maybe ping @leandrolanzieri or @jia200x.

Well it seems to work now however the temperatures and humidity seem off...

2019-10-14 10:11:05,685 # Init HTS221 on I2C_DEV(0)
2019-10-14 10:11:05,685 # H: 0.0%, T: 8.9°C
2019-10-14 10:11:05,685 # H: 0.0%, T: 8.2°C
2019-10-14 10:11:07,657 # H: 0.0%, T: 8.2°C

also on the saul example

> saul read 1
2019-10-14 10:14:33,392 #  saul read 1
2019-10-14 10:14:33,392 # Reading from #1 (hts221|SENSE_TEMP)
2019-10-14 10:14:33,392 # Data:	     9.3°C

I don't know if getting the correct values is out of scope of this PR or not... It isn't that cold in the office.

Does the lps22hb driver work ?

Yup, that seems OK

> saul read 4
2019-10-14 10:48:14,685 #  saul read 4
2019-10-14 10:48:14,686 # Reading from #4 (lps22hb|SENSE_PRESS)
2019-10-14 10:48:14,686 # Data:	       1013 hPa
> saul read 5
2019-10-14 10:48:18,090 #  saul read 5
2019-10-14 10:48:18,091 # Reading from #5 (lps22hb|SENSE_TEMP)
2019-10-14 10:48:18,091 # Data:	     24.98°C

If you want this in I would just raise an issue for the HTS221. I or @JannesVolkens can look into it later.

Looking at the datasheet it may also be improperly calibrated... I would need further investigation but the more I look into this the more I think this is out of scope with the PR. Any objections @aabadie ?

Any objections @aabadie ?

Please ACK :)