search

Galzai / MK32

Keyboard firmware for ESP32 microcontrollers
678 stars 118 forks source link

To Pull Down, or not to pull down #25

Closed ghost closed 3 years ago

ghost commented 3 years ago

Hi @Galzai , @gijsn ,

Thanks for this project!

I'm busy building my own keyboard, planning on using this as the firmware. The plan is to run both halves from one ESP32. To maximize the RTC pins, I'm planning on using GPIO 34-39, however, these pins don't have software controller pull-ups or pull downs(thanks for the comment in matrix.c btw 😁).

Looking over the scan_matrix code, COL2ROW has a comment that reads Setting column pin as low, and checking if the input of a row pin changes., however, the code sets the level to high? ROW2COL seems to follow the low comment. Is there a reason the two differ?

If that's the case for COL2ROW, then I'll have to use pull-down resistors on the rows defined on GPIO 34-29, but pull-ups for ROW2COL. Not quite sure where the pull up/down direction is defined in code or if it needs to be defined?

Galzai commented 3 years ago

Hey,

I think there are a few things that need to be changed (mistakes in matrix.c): enable pulldown on input pins (I can't think of a good reason not to, but I vaguely remember playing around with this). in ROW2COL the pin should be set as high when scanning. The comment should be updated to setting pin as high...

I haven't been updating the project for a while , so if you perform the changes and they work for you feel free to make a PR.

gijsn commented 3 years ago

Hi, In my fork, I changed the configuration there a bit, because the original spewed errors / warnings for some pins (some of my pins were input only, indeed without pulls. Next to that, the RTC initialization macro SET_BIT needed to use LLU to support pins beyond 32, I think I put that in the PR as well. I used 10K resistors to pull (down, I believe) the rows else they were kept floating and issued random keystrokes.

Note that you dont need to use all RTC pins. I've been using mine for some weeks now, with only some RTC pins, and basically mashing the keyboard will wake it up (after you notice the text is not appearing, it will take some seconds anyway on my Windows machine to start the BLE connection)

ghost commented 3 years ago

I'm some ways of from testing this on my own PCB, but I'll open a PR if I can get this working locally.

Thanks @gijsn for the notes on the RTC pins and the LLU. Will make sure to keep that in mind. To be safe, I'll use pull downs on all my rows (which are going to correspond to the input only pins in the 34+ range).

Slightly off topic, but have you considered individual backlit RGB's using a LED driver?

ghost commented 3 years ago

@Galzai I'd like to pick your brain on the diodes you used on the keyboard. I see traditionally 4148's have been used. The arguments have been:

But this diode's forward voltage is 0.7. Using 10K pull-ups the current is a bit high at approx 3 mA. Have you experimented with higher pull up values and lower forward voltage diodes to reduce power consumption?

I don't have any reference frame of what is a lot here, I'm just going of intuition.

Galzai commented 3 years ago

@DiaanE You can try using different diodes and resistors, but I think the overall effect on power consumption might not be that significant because the current will only flow when keys are pressed (So it really depends on the duration and frequency of keystrokes, which I assume might cause it to be negligible) I did use 4148's on my testing board.

gijsn commented 3 years ago

@DiaanE if you're able to significantly reduce the power consumption Im interested as well. Currently Im using a 400mAh single cell lipo, and it lasts about a day or less.

Concerning the RGB, I think that should be possible. Personally I use the FastLED library in the esp32-arduino framework. I know there's some examples using the RMT functionality of the ESP32 to drive the individually adressable WS2812B RGB leds. Though I opted to not use any backlighting to save power.