Startup and reset issues

[MikeJongen]

The board I am using (LPC55S69-EVK), does not reset the mma8652 sensor after a reset. So, the mma8652 still has old values in its registers, while the driver assumes the mma8652 has been reset. This is especially an issue when the mma8652 is still in active mode, and (most) registers cannot be changed (while the driver still executes functions like set_data_rate and set_scale without returning errors). Is this something the driver should be able to handle? For example, by reading the register values at startup or executing a sensor reset at startup?

Currently, I am using the reset function (of this driver) to reset the mma8652 at startup, and I encountered another issue. The reset also resets the I2C of the mma8652, so for about 200 us, all i2c communication with the mma8652 fails. Should the driver take this in account, and wait until the reset is complete? Or maybe add a note to the documentation?

[eldruin]

This is an interesting scenario. As you already propose, I see basically two ways to handle this:

1. The driver reads all the registers and adapts itself to the current configuration.
2. The device must be reset and reconfigured.

I see the initial appeal of approach 1. but it has some big downsides:

• Your application does not know what the state of the device actually is once it is recreated. It may be that you can reuse the state but it does not seem plausible that any application would recreate the device and just go with whatever state the device is in, so a bunch of additional checking/setup is likely necessary, defeating the whole point (except the case where your hardware setup can guarantee the device to be in a correct state, but this seems rare to me in the field and rather an issue only in a developer setup).
• Technically, the implementation will be somewhat complex / cumbersome to use, especially because of the active/standby mode, which is part of the driver type. This makes it necessary to know what the mode is before calling a hypothetical from_device_state method since the method can only return an object of one type, not one or the other depending on some internal logic.
• This approach risks some configuration not being correctly reconstructed and some mismatch may exist. I think this risk is rather mild, though, given the current straight-forward register representation in the driver.

Provided the partial resets are not a frequent occurrence in the system / initialization delay is not critical, I would favor approach 2. as it seems more authoritative, there is "less that can go wrong" and is just simpler. The device boot time is unfortunate, though (the documentation states it takes 350-500us).

Whether the driver should take care of these delays or not is another interesting discussion. It should be noted that other operations also require some delay like turn-on time being something like 2/ODR + 1ms. Actually in the lsm303agr driver, support for this was recently added so that now the driver waits the necessary time before returning. The cost being that it is necessary to provide a Delay object to the methods that need to wait for something and a forced delay when calling them (without this, you may do something else in the mean time if you can guarantee to take at least the time required for the change to be finalized).

If you are interested in contributing something like that here I would be open to it. Otherwise, you can do the delays in your user code as needed by the device. In any case I would be glad for a PR adding information about these delays to the documentation.