hi folks bringing this conversation on-list...
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Jul 14, 2016 at 9:21 PM, Albert ARIBAUD albert.aribaud@free.fr wrote:
While the matrix uses "GPIO bytes" (PA0..PA7, PC0..PC7, PB8..PB15), rows are spread over two GPIO bytes (PC+PA), and columns over three (PC+PA+PB). If the mapping could be reworked as follows...
it can't. virtually every single pin is used up: i already had to go from 48-pin to 64-pin.
I was afraid so. Oh well.
Anyway, I'm missing info on how the LCD is interfaced to the STM32 and
SPI.
what other devices there are,
a _lot_. virtually every single one of the 64 pins is used up. it took WEEKS to work it out.
so I'm 99% sure I'm wrong about port C being fully free... Are there schematics of PCB2?
yyep... 1sec...
Thanks a lot. Indeed quite full, and I see the GPIO bytes are routed to the FPC in order, so the spreading comes from how the FPC pins get mapped inside the keyboard, which we don't control... Oh well again.
well we _can_.... but the problem is that the mapping goes something like:
pin 1 row 1 pin 2 row 2 pin 3 column 1 pin 4 row 3 pin 5 column 2 pin 7 row 4 ... ....
it's *not* straightforward, hence the reason why the firmware's not as straightforward as "use GPIO bank A for all rows".
l.