drivers/hall_effect: support for generic hall effect sensors

[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

✔️ PASSED

a1bd6f7 Added a inc_encoder backend to the saul driver test

Success	Failures	Total	Runtime
10564	0	10564	08m:54s

Artifacts

• Documentation preview

[crasbe]

Open Review Comments:

• #21801 (comment)
• #21801 (comment)
• #21801 (comment)

[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.