In case of `row2col = true` the normal matrix scan does not work with RMK v0.8.

[tib888]

I just upgraded my nice!nano split (use_config) to v0.8, and the matrix is not working at all if row2col = true. Both rows and cols measure 0V.
I can not enter anything on the keyboard. Turning off async_matrix feature do not help either.

Just to double check, for HW problems, I set row2col=false -> in that case the matrix scan works well: if I short across the "wrongly" directed diodes, I can "type". In this case cols are High, rows are 0V just as expected.
(The previous version of RMK also worked well.)

[HaoboGu]

@tib888 Could you try #666 ?

[tib888]

I'll test, when I get home.

Until then please look at the inner loop of the matrix scan (in read_event()).
I believe its start index should be fixed to be zero in the subsequent iterations of the outer loop.

for in_idx in in_idx_start..Self::INPUT_PIN_NUM {

proposed fix:

let start = if out_idx == out_idx_start { in_idx_start } else { 0 }
for in_idx in start..Self::INPUT_PIN_NUM {

what do you think?

[HaoboGu]

Oh nice catch! You're correct, it's a bug

[tib888]

@tib888 Could you try #666 ?

I have tested both yours (#666) and mine (#665) fix for this row2col bug with both kind of keyboards.
Both seems to work well. However Mine fix results a much simpler code. So It is up to you to choose one to merge in.

If you chose #666, then do not forget to add the fix from above!

let start = if out_idx == out_idx_start { in_idx_start } else { 0 }
for in_idx in start..Self::INPUT_PIN_NUM {

[HaoboGu]

Could you double check that your implementation doesn't have ghosting key issue. Because the diode direction is row2col, and in your implementation, the actually current direction is col2row, so I suspect that all diodes will be "ignored".

And #665 increases the flash usage about 0.5KB, could you also reduce that?

If your implementation doesn't have ghosting key issue and doesn't increase the flash usage, I'll prefer yours because it is simpler, otherwise I'll choose #666

[tib888]

Here you can check why diodes work in this "upside down" active low setup:

In contrast, if there would be no diodes there this could happen:

[HaoboGu]

is the pink line the ghosting way? When col1 is low, row1 is pulled to low, and so is row2? I'm not sure actually.. Better testing it on the real hardware

[tib888]

Please note that col2 is set to high so the middle diode in the first row is blocking!
(I tested on my hardware.)

[HaoboGu]

Oh yes, you're right.

[HaoboGu]

Is it possible to reduce the flash usage?

[tib888]

About the memory usage: there are a few if COL2ROW s, but those should not increase the size since one branch can be optimized out during compule time (at least in theory).
So I do not know why is the memory usage increased that much on nrfs, while it was decreased on stm32f4?
Maybe the compiler did more inlineing....

[HaoboGu]

I don't know neither.. both stm32f4 and nrf52 are cortex-m4. The memory/flash usage for rp2040/stm32h7 is also increased, so I plan to merge #666 first, keep #665 open until the flash/memory issue is solved?