[Arm-netbook] RK3399

Christopher Havel laserhawk64 at gmail.com
Fri Jan 19 03:49:12 GMT 2018

BTW -- not *everything* is nearly as complex as Luke would have you
believe. Close, but not quite, and the two doozies more than make up for
the easier bits...

Keyboards are invariably a passive switch matrix (look it up if you don't
know -- you should, it's worth your time) and not that hard to
reverse-engineer if you have a couple to burn through with a multimeter and
hook probes. It's a matter of an afternoon or two. Touchpads are almost
always either USB or PS/2 and not some alien bull**** (relatively speaking)
like I2C or SPI unless they're bullt into a desktop keyboard (I have seen
this, particularly with wireless keyboard/mouse combos). You probably can
find a datasheet for the 'pad's controller chip and that will give up the
info on how it connects to the world.

It's the screen and battery interfaces that are going to get you and get
you good, time-wise and effort-wise.

LCDs are *very very very* rarely VGA (a *very* few *very* old laptops did
that) and are often either LVDS or (if in a nearly brand-new machine) eDP.
Once in a particularly blue moon, you'll potentially find one that runs
parallel RGBTTL as its interface (my mother had a cheap tablet with an SVGA
[800x600] screen that was RGBTTL.) The problem with LVDS is that the spec
excludes a standard pinout and leaves that to the manufacturers -- so
you've got to basically get in there with an old-fashioned oscilloscope and
poke around until you have an understanding of which pin does what -- not a
simple task when there's forty or fifty pins on a connector! ...oh, and
some will be logic-level (typically 5v but sometimes 3.3v or even 1.8v) and
some will *ahem* not be logic-level but rather analog or differential
signals, which is why a logic analyzer won't do you here -- you'll blow its
input circuits sky high. (...which you *really* don't want because logic
analyzers are expensive... at least, the *useful* ones are.) RGBTTL is
easier -- you can use a logic analyzer for that, if the datasheet doesn't
have the pinout (which it basically always does) -- but, again, there's not
really a standard there as far as pinout is concerned, and you have a
fiddly surface-mount connector with remarkably tiny pin pitch to deal with
as well -- after all, if you can actually solder to a flexible PCB (which
is what those cables always are) without ruining it, you have soldering
skills of near-mythical level and I have a few projects for you to help me
with :P ).

The battery invariably runs SMBus (short for System Management Bus) for
communications, which is an I2C variant -- not too bad to deal with --
except that, like LVDS, there's no standard pinout, and oh by the way you
need a charging circuit as well as knowing the commands to send and receive
over SMBus to make it charge, discharge, and read out its level. Hint: the
industry standard name for the controller chip in the battery is 'fuel
guage', oddly enough -- you'll likely need to find its datasheet (good
luck!) to get the commands, unless you really want to blackbox a battery
that can literally burn your house down if you don't handle it with kid
gloves. (Seriously, look up lithium battery fires on YouTube. If that stuff
doesn't scare the p*ss out of you, either you're one serious pyromaniac or
you have no bladder.)

If you can handle all of that, you can do *exactly* what you're looking
for. Personally, I'd rather figure out a way to basically make a portable
desktop from readily available components (which I've done three times now,
actually) and make do with that.

More information about the arm-netbook mailing list