software-wise i need something that does nothing more complex than
mount stuff on a micro-sd card, show boot messages on both screens,
and maybe has 2 keyboards plugged in (one into each USB socket) so
that they can bash some keys and see that crud comes up on-screen for
each.
going beyond that... testing I2C, UART and the GPIO.... *sigh*...
that involves writing some software.
Speaking about I2C, UART and GPIO testing - it sounds easy.
I don't yet know which defects you'd want to cover with tests
(mechanical, soldering, faulty parts, maybe all of them), but,
as far as my research goes, you can test both UART and GPIOs
with a loopback test, and I2C could be tested using a simple
device - such as an EEPROM.
Now, I don't have as much testing experience, but I've done a couple
of DIY jigs - not automated, but that's yet to come - and I've been
thinking about a way to make testing jigs. First thing is - it's best if
the test program runs on the computer card itself. I see that's
what you plan to do, and, if I'm not mistaken, cards are going to boot
from a MicroSD card anyway - which is what's needed.
Testing GPIOs can be done easily from software - connect GPIOs
in pairs using resistors (say, 470ohm, just in case one of GPIOs
is shorted to ground/VCC for some mechanical reason). Set first
GPIO as input, second as output, then toggle the second GPIO
and check that value that's read from the input is the same as
value that's on the output.
With more complicated interfaces, it depends. I2C should be
testable by using an I2C device - since you have an EEPROM
inside the card, it makes sense to first test if that's accessible,
then test another device that's located in the test header (say,
a GPIO expander or an ADC, you could use both of those for
testing, too.) You can test SPI in loopback mode by connecting
MISO and MOSI together, though you won't test SCK and CS
that way. UART should easily be testable with a loopback -
though I think you won't want to have the loopback hard-wired,
to make sure that U-Boot messages won't get into U-Boot input
and stop the boot process, or something of that kind =)
If you want to test USB, you don't even need to have engineers
mash on the keyboard, attach two USB devices with unique
IDs (say, CP2012 - you can program those through USB connection)
and make sure they're recognized - in case of CP2012, you can
make a loopback test of their UART, just to make sure data
passes through... Not sure how much sense it'll make, though =)
Now, speaking about SDIO and parallel video interfaces that
you have in EOMA68 pinouts, I have no idea how to test them
automatically =( But the test I listed cover most mechanical pins,
and half of the peripherals, which is already pretty good for
avoiding RMAs of cards with bad solder joints in the USB
or I2C lines. They're also cheap enough in terms of hardware&
software required.
So, the end result could be: a MicroSD card with a stripped down
image of something something Linux that boots as quickly as
possible (with cruft like networking disabled), shows the boot
log on HDMI monitor - then draws a table on the monitor (I
imagine it being a fullscreen application working with
framebuffer, to avoid having to wait for X to load). Cells of
that table would be filled with green or red, depending on
whether tests pass on fail - and an all-green monitor would
indicate all is well =) This should make for streamlined&quick
testing and avoid lots of manual work (excluding that, well,
you still have to plug the card into the testing jig and plug
the cables in).
Now, I don't have *that* much experience, I don't
know which failures you want to protect against,
but if I were to test these cards, this is what I'd do.
Cheers!
Arsenijs
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u