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.