Tracking issue for Encoder support
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?
Yes, thanks for raising the issue! You can post anything about encoder support here:D
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?
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.
I've already added rotary encoder support, it's available by using Rust code only. I'll add the config soon. Please checkout the example here.
Close as the rotary encoder support is considered finished