Tracking issue for Encoder support

[tanekere]

Hi 👋,
I wanted to build a project like this one when i found yours; i really like what you have done here. I am not new to rust or embedded programming but am new to embedded programming in Rust. Would this be a good first issue for me?

[HaoboGu]

Yes, thanks for raising the issue! You can post anything about encoder support here:D

[tanekere]

Took a look into this today and looks like most rotary encoders rely on pull-up inputs. But as far as i can tell the rmk-macro crate can only support pull down inputs as of right now. So i guess that will be the first task.
Also, the macros just refer to them as 'input_pin' (eg.convert_gpio_str_to_input_pin) so should i change names to pd_input or keep it like this and just add functions for pull up?

[HaoboGu]

Took a look into this today and looks like most rotary encoders rely on pull-up inputs. But as far as i can tell the rmk-macro crate can only support pull down inputs as of right now. So i guess that will be the first task.

Also, the macros just refer to them as 'input_pin' (eg.convert_gpio_str_to_input_pin) so should i change names to pd_input or keep it like this and just add functions for pull up?

I prefer a new function.

btw I suggest you to implement the rotary encoder first in Rust and add it to rmk-macro after testing it(this is how I adding new features). Since rmk-macro is used to eliminate boilerplate code, which actually adds nothing new.