sporq/kmk_firmware
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
6baaf5e5d4
kmk_firmware/kmk/boards/converter/keebio/iris_r2.py

44 lines
1.7 KiB
Python
Raw Normal View History

kitsym4: Support the keeb.io Iris using the ProMicro<->ItsyBitsyM4 converter board The thumb cluster maps a little goofy and I'd like to clean up the keymap here - it's ENTIRELY NOT OBVIOUS how this works right now. Using this keymap as an example, the physical layout of my thumb cluster is actually: Far left: Left Next to the right: Right Bottom right: Shift Top right: MO(2) You can see what this maps to in code, and it's not at all intuitive. `swap_indicies`, which we already support, is useless here because, unlike the Planck/Klaranck, these aren't 1:1 key swaps, but an entirely custom mapping of columns. This will require something like QMK's solution to fully custom (or at least partially custom) keymaps at a core level, and isn't something I feel like tackling tonight necessarily.
2018-12-29 08:20:03 +01:00
import board
Continue to shuffle and burn stuff - Remove the concept of "mcus". With only one target platform (CircuitPython), it no longer makes a bunch of sense and has been kept around for "what if" reasons, complicating our import chains and eating up RAM for pointless subclasses. If you're a `board`, you derive from `KeyboardConfig`. If you're a handwire, the user will derive from `KeyboardConfig`. The end. As part of this, `kmk.hid` was refactored heavily to emphasize that CircuitPython is our only supported HID stack, with stubs for future HID implementations (`USB_HID` becomes `AbstractHID`, probably only usable for testing purposes, `CircuitPython_USB_HID` becomes `USBHID`, and `BLEHID` is added with an immediate `NotImplementedError` on instantiation) - `KeyboardConfig` can now take a HID type at runtime. The NRF52840 boards will happily run in either configuration once CircuitPython support is in place, and a completely separate `mcu` subclass for each mode made no sense. This also potentially allows runtime *swaps* of HID driver down the line, but no code has been added to this effect. The default, and only functional value, for this is `HIDModes.USB` - Most consts have been moved to more logical homes - often, the main or, often only, component that uses them. `DiodeOrientation` moved to `kmk.matrix`, and anything HID-related moved to `kmk.hid`
2019-07-25 09:58:23 +02:00
from kmk.matrix import DiodeOrientation
Fix linting; move kmk.util.intify_coordinate to kmk.matrix.intify_coordinate (trying to deprecate/remove util)
2019-07-25 08:43:00 +02:00
from kmk.matrix import intify_coordinate as ic
Continue to shuffle and burn stuff - Remove the concept of "mcus". With only one target platform (CircuitPython), it no longer makes a bunch of sense and has been kept around for "what if" reasons, complicating our import chains and eating up RAM for pointless subclasses. If you're a `board`, you derive from `KeyboardConfig`. If you're a handwire, the user will derive from `KeyboardConfig`. The end. As part of this, `kmk.hid` was refactored heavily to emphasize that CircuitPython is our only supported HID stack, with stubs for future HID implementations (`USB_HID` becomes `AbstractHID`, probably only usable for testing purposes, `CircuitPython_USB_HID` becomes `USBHID`, and `BLEHID` is added with an immediate `NotImplementedError` on instantiation) - `KeyboardConfig` can now take a HID type at runtime. The NRF52840 boards will happily run in either configuration once CircuitPython support is in place, and a completely separate `mcu` subclass for each mode made no sense. This also potentially allows runtime *swaps* of HID driver down the line, but no code has been added to this effect. The default, and only functional value, for this is `HIDModes.USB` - Most consts have been moved to more logical homes - often, the main or, often only, component that uses them. `DiodeOrientation` moved to `kmk.matrix`, and anything HID-related moved to `kmk.hid`
2019-07-25 09:58:23 +02:00
from kmk.keyboard_config import KeyboardConfig as _KeyboardConfig
kitsym4: Support the keeb.io Iris using the ProMicro<->ItsyBitsyM4 converter board The thumb cluster maps a little goofy and I'd like to clean up the keymap here - it's ENTIRELY NOT OBVIOUS how this works right now. Using this keymap as an example, the physical layout of my thumb cluster is actually: Far left: Left Next to the right: Right Bottom right: Shift Top right: MO(2) You can see what this maps to in code, and it's not at all intuitive. `swap_indicies`, which we already support, is useless here because, unlike the Planck/Klaranck, these aren't 1:1 key swaps, but an entirely custom mapping of columns. This will require something like QMK's solution to fully custom (or at least partially custom) keymaps at a core level, and isn't something I feel like tackling tonight necessarily.
2018-12-29 08:20:03 +01:00
Rename "Firmware" to "KeyboardConfig" for clarity in main.py and to illustrate separation of KeyboardConfig/InternalState
2019-07-20 23:53:30 +02:00
class KeyboardConfig(_KeyboardConfig):
kitsym4: Support the keeb.io Iris using the ProMicro<->ItsyBitsyM4 converter board The thumb cluster maps a little goofy and I'd like to clean up the keymap here - it's ENTIRELY NOT OBVIOUS how this works right now. Using this keymap as an example, the physical layout of my thumb cluster is actually: Far left: Left Next to the right: Right Bottom right: Shift Top right: MO(2) You can see what this maps to in code, and it's not at all intuitive. `swap_indicies`, which we already support, is useless here because, unlike the Planck/Klaranck, these aren't 1:1 key swaps, but an entirely custom mapping of columns. This will require something like QMK's solution to fully custom (or at least partially custom) keymaps at a core level, and isn't something I feel like tackling tonight necessarily.
2018-12-29 08:20:03 +01:00
# Pin mappings for converter board found at hardware/README.md
# QMK: MATRIX_COL_PINS { F6, F7, B1, B3, B2, B6 }
# QMK: MATRIX_ROW_PINS { D7, E6, B4, D2, D4 }
Remove a ton of leftover MicroPython code and abstractions, including all of kmk.pins
2019-07-25 09:32:20 +02:00
col_pins = (board.A2, board.A3, board.A4, board.A5, board.SCK, board.MOSI)
row_pins = (board.D11, board.D10, board.D9, board.RX, board.D13)
kitsym4: Support the keeb.io Iris using the ProMicro<->ItsyBitsyM4 converter board The thumb cluster maps a little goofy and I'd like to clean up the keymap here - it's ENTIRELY NOT OBVIOUS how this works right now. Using this keymap as an example, the physical layout of my thumb cluster is actually: Far left: Left Next to the right: Right Bottom right: Shift Top right: MO(2) You can see what this maps to in code, and it's not at all intuitive. `swap_indicies`, which we already support, is useless here because, unlike the Planck/Klaranck, these aren't 1:1 key swaps, but an entirely custom mapping of columns. This will require something like QMK's solution to fully custom (or at least partially custom) keymaps at a core level, and isn't something I feel like tackling tonight necessarily.
2018-12-29 08:20:03 +01:00
diode_orientation = DiodeOrientation.COLUMNS
split_flip = True
split_offsets = (6, 6, 6, 6, 6)
Re-add LED support This reverts commit 5b069a01048b42a589d2fc1a44672ed06607a567.
2019-07-13 02:11:36 +02:00
split_type = 'UART'
kitsym4: Support the keeb.io Iris using the ProMicro<->ItsyBitsyM4 converter board The thumb cluster maps a little goofy and I'd like to clean up the keymap here - it's ENTIRELY NOT OBVIOUS how this works right now. Using this keymap as an example, the physical layout of my thumb cluster is actually: Far left: Left Next to the right: Right Bottom right: Shift Top right: MO(2) You can see what this maps to in code, and it's not at all intuitive. `swap_indicies`, which we already support, is useless here because, unlike the Planck/Klaranck, these aren't 1:1 key swaps, but an entirely custom mapping of columns. This will require something like QMK's solution to fully custom (or at least partially custom) keymaps at a core level, and isn't something I feel like tackling tonight necessarily.
2018-12-29 08:20:03 +01:00
uart_pin = board.SCL
Re-add LED support This reverts commit 5b069a01048b42a589d2fc1a44672ed06607a567.
2019-07-13 02:11:36 +02:00
extra_data_pin = board.SDA
rgb_pixel_pin = board.TX
led_pin = board.D7
Resolves #121: Use flattened keymaps, which can visually represent the logical layout, rather than the physical wiring
2019-05-13 02:04:23 +02:00
coord_mapping = []
coord_mapping.extend(ic(0, x) for x in range(12))
coord_mapping.extend(ic(1, x) for x in range(12))
coord_mapping.extend(ic(2, x) for x in range(12))
# Buckle up friends, the bottom row of this keyboard is wild, and making
# our layouts match, visually, what the keyboard looks like, requires some
# surgery on the bottom two rows of coords
# Row index 3 is actually perfectly sane and we _could_ expose it
# just like the above three rows, however, visually speaking, the
# top-right thumb cluster button (when looking at the left-half PCB)
# is more inline with R3, so we'll jam that key (and its mirror) in here
coord_mapping.extend(ic(3, x) for x in range(6))
coord_mapping.append(ic(4, 2))
coord_mapping.append(ic(4, 9))
coord_mapping.extend(ic(3, x) for x in range(6, 12)) # Now, the rest of R3
# And now, to handle R4, which at this point is down to just six keys
coord_mapping.extend(ic(4, x) for x in range(3, 9))
Reference in New Issue Copy Permalink