• 1 Post
  • 8 Comments
Joined 2 years ago
cake
Cake day: June 15th, 2023

help-circle
  • I’m using ATmega micros, on my Lily58. If I remember correctly, the default QMK behaviour was to use the USB to select which half was the master and what side it was on. That would work on RP2040 boards just as well so that may be what the provided firmware does.

    I would suggest you just flash them both then see what they do. If they are swapped, try connecting the USB to the other half. If that works then you don’t have a problem. There’s no risk of damaging them and the RP2040 is pretty easy to reflash.

    I wasn’t satisfied with that method and set QMK to store the sides in eeprom so I could use the same firmware but connect to either one. I’m not sure if the 2040 has a separate non-volatile memory so you’ll likely need a different method. I think a GPIO can be grounded to set the side but the Lily58 doesn’t do this. You could add a bodge wire if you want this but you have to customise QMK to use that method.




  • I would encourage you not to split things up too finely. A single repo for your environment would allow you to see all related changes with git. E.g. if you set up a new VM it might need a playbook to set something up, a script to automate a task, and a DNS entry. With a well put together commit message explaining why you’re making those changes there’s not much need for external documentation.

    Maybe if you want some more info organised in a wiki, point to the initial commit where you introduced some set up. That way you can see how something was structured. Or if you have a issue tracker you can comment with research on something and then close the issue when you commit a resolution.

    Try not to have info spread out too much or maintaining all the pieces will become a chore. Make it simple and easy to keep up.





  • While true, you would have to change the firmware to swap column and row polarity if you reverse all the diodes e.g. #define DIODE_DIRECTION ROW2COL in QMK. Conventionally, QMK assumes rows are on the cathode side of the diodes and drives the columns high. ROW2COL reverses that so that the rows are driven high and columns scanned instead.

    It’s best to stick to the convention so you avoid surprises.