[Arm-netbook] 15in libre hardware laptop PCB progress

[Luke Kenneth Casson Leighton]

ok, so i started last week on the PCBs.

first thing: there's three of them.  the casework, needing to have a
middle strut as well as other internal supports, makes it impossible
to have a single PCB, apart from anything that PCB would be just over
12in wide.  also things need to be on different levels.  so the PCBs
are divided as follows:

* PCB1 - contains the CPU card, I/O connectors, LVDS converter IC, USB
Audio IC, USB Hub, EOMA68 identifier EEPROM, and some ribbon
connectors

* PCB2 - contains an STM32F070 and 3 FPCs: one for the touchpanel LCD
(which has an SPI converter IC on it), one for the capacitive
touchpanel (I2C), and one 16+8 1mm pitch connector for the keyboard.

* PCB3 - contains the battery charger and power IC (an LTC4155) as
well as a battery monitor IC (STC3115) which measures current as well
as voltage.  the LTC4155 is absolutely awesome, it has dual supply
inputs (5V in and USB-OTG), it can be turned round to *supply* 5V
USB-OTG, *and* it can provide up to 3A @ 5V as system output.

all three PCBs will be double-sided 2 layer, with components only on
one side.  cheap and cheerful.  PCB3 will need to be 2oz copper
because it's dealing with 4 to 5 amps in places.

PCB1 is deliberately huge so that i have plenty of space to work with.
i have had to do a little bit of rearranging so that there are less
wires crossing over - for example, the MicroSD and the USB (CM108AH)
Headphone jack have now swapped places.  as a result, the micro-sd
wires can run directly on the TOP layer - without crossing anything
(especially USB traces).  previously, the MicroSD lines would have had
to cross over the USB audio lines.  in a 4 layer PCB that's fine,
because they're separated by an entire GND plane.  in a 2 layer board?
 mmmm.... no :)  so, now, the USB Hub is in the bottom left corner,
the USB differential pairs go directly to the connectors (and to the
USB Audio IC) - no crossing over... nothing.

the SN75LVDS83b (LVDS converter IC) is... distinctly odd.  it's
extremely puzzlingly well designed.  by placing it right next to the
EOMA68 connector the 24-pin RGB/TTL outputs can be kept extremely
short, with virtually no traces needing to cross over.  even the LVDS
differential pair outputs do not need to cross over to other layers:
they may go directly to the LCD connector.

PCB2 is the weird one: it's relatively large (3in x 5in L-shaped) but
has an extremely low component count.  i tried to use a 48-pin
STM32F070, got even the PCB layout done, and realised that it just
wasn't going to work: the multiplexing is just too tight, what with 24
of the pins used up for the 8x16 keyboard matrix.  4 more are needed
for SPI, 2 for I2C, 5 more for GPIO, 2 for USB.

btw - jaezzuss, last night it took 2 hours to go through all the
connections of the keyboard with a multimeter, but it had to be done
:)  i needed to know the layout of the pinouts, and after
experimenting pressing random keys i realised, with deep foreboding,
that i *literally* had to go through absolutely every single key in
turn, starting with ESC and ending at ENTER, putting a heavy object on
every key and then manually scanning with a multimeter *all* 24 pins
and recording the result.  it turns out that yes it's a 16x8 layout.
8 bits vertical, 16 bits horizontal.  there was very little pattern to
the layout.  a little bit of a pattern with the QWERTY keys and the
numpad, but everything else pretty much completely defied logic!

the idea here with the STM32F070 (which is very low cost btw) is that
it will act as a USB-HID device.  so, it will be necessary to provide
power down one bank of 8 GPIOs, and to read 2 bytes of output from 16
GPIOs... that way you identify which keys are held down.  the reason
why i will have to go to the 64-pin QFP is because i don't want to use
pins A0-A7 then B0-B4, C2-C3, then back to bank B for a bit.... i want
to just use A0-A7, B0-B7, C0-C7 or whatever it takes, so that i can
keep things very very simple: read one byte (register A), write one
byte (register B) and so on.

i haven't yet thought about what kind of interface to offer, when
controlling the backlit 480x320 LCD, but that need not be of immediate
concern.  there is plenty of static RAM on-board the STM32F070 to make
an on-board framebuffer.  converting to USB-TTY (ACM) so that commands
can be sent over a USB-serial port... this would tend to be the
simplest way... it can all be taken care of later.

btw, word of warning (to anyone else designing a laptop) - i've had to
shuffle things around somewhat, significantly, based on what
connectors could be obtained today (at reasonable prices).  for
example, FPC 24 pin 1mm "TOP Connect" wasn't available, so i had to
use "Bottom Connect", which meant folding the keyboard's thin-film
circuit connector into an S-Shape in order to fit it within the
available space.   this was to make sure that the connector could
remain on the same side as all the other components on PCB2, otherwise
it is more expensive to lay out the components on the PCB (you can't
use solder reflow).

you just can't predict absolutely everything - you can't expect
absolutely everything to be available.  sometimes you just have to
adjust and work round problems.

l.