geekhack
geekhack Projects => Making Stuff Together! => Topic started by: jstein91 on Thu, 03 September 2020, 09:28:37
-
Well I messed up.
I designed a little numpad to tinker around with. Had it fabricated and assembled. I got them in and now Im working on the software side.
This is where the screw-up comes in. Apparently, and I dont know how I missed this in my final check, I wired the third column to two different pins on the MCU. Both pins are fully wired to the column.
My question is this: in building my software, does it matter which on the pins I actually have COL3 wired to is the one used in the firmware? Should I try to mod the pcb and brake one of the COL3 traces going to the MCU? How should I correct this?
-
is the mcu onboard or an attached promicro?
- no, doesn't matter which you use. use the one that's more logical
- 1st, try to compile without using/noting that extra pin in the firmware & test. might not have to chop traces.
-
is the mcu onboard or an attached promicro?
- no, doesn't matter which you use. use the one that's more logical
- 1st, try to compile without using/noting that extra pin in the firmware & test. might not have to chop traces.
The MCU is an onboard Atmega32.
If i'm unable to compile using either of the pins is my only next option to chop one of the traces?
-
you can have a trace there, that's unused on the mcu. just as long as there's no conflict in the firmware and that pin is not mentioned anywhere in the firmware.
pick one that you will not use and make sure it's not mentioned anywhere in the firmware.
if you're worried. you could cut the trace. to be inconspicuous, use an exacto blade and sever the trace, test with continuity on a multimeter and make sure there's no connection.
-
you can have a trace there, that's unused on the mcu. just as long as there's no conflict in the firmware and that pin is not mentioned anywhere in the firmware.
pick one that you will not use and make sure it's not mentioned anywhere in the firmware.
if you're worried. you could cut the trace. to be inconspicuous, use an exacto blade and sever the trace, test with continuity on a multimeter and make sure there's no connection.
Awesome. Appreciate the help.
-
You may cut the trace or leave it there. The only thing you achieve by cutting the trace is that the MCU will not get damaged if you assign both two connected MCU pins to output and set one to high and the other one to low and leave that that way for a long time. Now that may look dangerous but you must realize that this kind of software mistake can happen even if your schematic is correct. E.g. lets say you drive columns (push-pull instead of open collector with pull up) and read rows; instead of setting a row pin to input you set it to output and by mistake assign it to an opposite logical level than the driving level; if the key at the crossing of the row and the column is pressed and you leave it that way for long time then MCU can get damaged as well.
It is enough if you leave one of the connected pins set to input (i.e. high impedance) and just do not use it. Pins are set this way by default after reset. That is the reason why nevin said you to compile the firmware without noting the pin. If you do not use it then it will stay in the default high impedance mode.
-
thanks for the through explanation vvp
note on the keymap, i don't know if you're doing layering, but zero is a great spot to do a tap/hold Fn (zero when tapped, Fn when held).
LT(layer, kc)
like this: LT(LAYER_1, KC_KP_0)
use this instead of normal MO, this is a great way to sneak a Fn key on a board with a limited number of keys (very popular in the sub 40% group)
- also when i was messing with firmware for the paladin pad, i found that the numlock doesn't like to work when called by a Fn (Fn+key=NunLock), it has to be on the main layer. if you were thinking of using esc at the top left and calling numlock by a Fn.