kmk_firmware icon indicating copy to clipboard operation
kmk_firmware copied to clipboard

Keyboard not responding after adding another row

Open mooks42 opened this issue 2 years ago • 6 comments

Hi!

I'm currently trying to revive a quite old keyboard, unsing a raspberry pico: Cherry G84-4100PAADE

I`ve made a picture of the pin layout of the keyboard: pinbelegung An here's my code:

print("Starting")

import board

from kmk.kmk_keyboard import KMKKeyboard
from kmk.keys import KC
from kmk.scanners import DiodeOrientation

keyboard = KMKKeyboard()

keyboard.col_pins = (board.GP28,board.GP27,board.GP26,board.GP4,board.GP1,board.GP0,board.GP22,board.GP21,)
keyboard.row_pins = (board.GP16,board.GP2,board.GP15,board.GP3,board.GP14,board.GP13,board.GP10,board.GP7,board.GP8,board.GP9,)
keyboard.diode_orientation = DiodeOrientation.COL2ROW

keyboard.keymap = [
    [
        #GP16
        KC.ESCAPE,KC.F1,KC.F2,KC.F3,KC.F4,KC.F5,KC.F6,KC.F7,
        #GP2
        KC.RIGHT,KC.PAUSE,KC.F12,KC.F11,KC.SCROLLLOCK,KC.F10,KC.F9,KC.F8,
        #GP15
        KC.N1,KC.N2,KC.N3,KC.N4,KC.N5,KC.N6,KC.N7,KC.N8,
        #GP3
        KC.DOWN,KC.HOME,KC.NO,KC.BSPC,KC.EQUAL,KC.MINUS,KC.N0,KC.N9,
        #GP14
        KC.TAB,KC.Q,KC.W,KC.E,KC.R,KC.T,KC.Y,KC.U,
        #GP13
        KC.CLCK,KC.A,KC.S,KC.D,KC.F,KC.G,KC.H,KC.J,
        #GP10
        KC.NO,KC.Z,KC.X,KC.C,KC.V,KC.B,KC.N,KC.M,
        #GP7
        KC.UP,KC.PGUP,KC.NO,KC.RBRC,KC.LCBR,KC.P,KC.O,KC.I,
        #GP8
        KC.LEFT,KC.PGDN,KC.ENT,KC.BSLASH,KC.QUOT,KC.SCLN,KC.L,KC.K,
        #GP9
        KC.SPC,KC.END,KC.NO,KC.NO,KC.NO,KC.SLASH,KC.DOT,KC.COMM,
    ]
]

if __name__ == '__main__':
    keyboard.go()

However, after adding row pin GP9 or any other additional row, the board isn't working anymore. Is there maybe a problem if the number of rows is exceeding the number of cols too much?

mooks42 avatar Jun 16 '22 21:06 mooks42

can you watch the bootup in a serial console and see what the output says? https://github.com/KMKfw/kmk_firmware/blob/master/docs/debugging.md

klardotsh avatar Jun 17 '22 23:06 klardotsh

Hi @klardotsh I've checked the serial output :)

Starting
Traceback (most recent call last):
  File "code.py", line 33, in <module>
  File "kmk/keys.py", line 71, in __getattr__
  File "kmk/keys.py", line 370, in __getitem__
  File "kmk/keys.py", line 35, in first_truthy
  File "kmk/keys.py", line 332, in <lambda>
  File "kmk/keys.py", line 28, in left_pipe_until_some
  File "kmk/keys.py", line 52, in maybe_make_shifted_key
  File "kmk/keys.py", line 678, in make_shifted_key
  File "kmk/keys.py", line 71, in __getattr__
  File "kmk/keys.py", line 370, in __getitem__
  File "kmk/keys.py", line 35, in first_truthy
  File "kmk/keys.py", line 212, in <lambda>
  File "kmk/keys.py", line 28, in left_pipe_until_some
  File "kmk/keys.py", line 42, in maybe_make_mod_key
  File "kmk/keys.py", line 674, in make_mod_key
  File "kmk/keys.py", line 663, in make_key
RuntimeError: pystack exhausted

Line 33:

KC.UP,KC.PGUP,KC.NO,KC.RBRC,KC.LCBR,KC.P,KC.O,KC.I,

Can't find any error here :/

mooks42 avatar Jun 18 '22 20:06 mooks42

this may help: https://github.com/KMKfw/kmk_firmware/blob/master/docs/boot.md

xs5871 avatar Jul 04 '22 21:07 xs5871

@xs5871 well currently my boot.py has only the following entries:

import supervisor

supervisor.set_next_stack_limit(4096 + 4096)

do you mean it could help to disable serial or usb? or to increase the stack limit?

mooks42 avatar Jul 12 '22 20:07 mooks42

No, the stack limit should fix most of the pystack exhaust problems, but there are corner cases. We have a PR (#430) in the works that (from my testing) fixes that.

xs5871 avatar Jul 12 '22 22:07 xs5871

I'm assuming this has been resolved?

kdb424 avatar Aug 09 '22 22:08 kdb424

no not really, i've switched now to prk :/

mooks42 avatar Sep 17 '22 12:09 mooks42