drivers/hall_effect: support for generic incremental rotary encoder

[LeonardHerbst]

Contribution description

This introduces a new driver, a test for the driver, and a new SAUL category ID.

Hall effect sensor / magnetic rotary encoder are often attached directly to the shaft of a motor but can also be bough and used independently. This driver is not specific to one model sensor. The driver can be used to measure RPM and revolutions since the last readout.

The test just periodically prints the RPM and revolutions since the last read.

The only other drivers measuring angular velocity were gyro drivers which have a SAUL category ID of there own. Therefore I introduced SAUL_SENSE_SPEED.

Testing procedure

I connected a sensor and ran the provided test and tested it form the shell via the SAUL adaptation.

[riot-ci]

Murdock results

:x: FAILED

9ae5aed914b6d1787f28f6f359d6f4a005a09271 Updates the note to mention all possible overflows

Success	Failures	Total	Runtime
6267	0	10524	05m:39s

Artifacts

[Enoch247]

I only briefly (like 5 minutes) looked at this, but it reminds me of the periph_qdec module. Would it make since to harmonize the two modules in the same way that soft_uart/periph_uart and soft_spi/periph_spi are? Or maybe the periph_qdec module can be brought into this API as a different backend?

[LeonardHerbst]

I only briefly (like 5 minutes) looked at this, but it reminds me of the periph_qdec module. Would it make since to harmonize the two modules in the same way that soft_uart/periph_uart and soft_spi/periph_spi are? Or maybe the periph_qdec module can be brought into this API as a different backend?

Thanks I overlooked periph_qdec! I think bringing it in as an optional backend is the way to go.

[crasbe]

The code looks good, but I don't have any hardware to test this. Perhaps @mguetschow has access to that?

You can squash the commits in the meantime.