On Feb 6, 2014, at 3:06 PM, Paul Koning <paulkoning at comcast.net> wrote:
On Feb 6, 2014, at 12:24 PM, Kyle Owen <kylevowen at gmail.com> wrote:
...
I intend to bring out the Raspberry Pi shortly. The only downside is that
the USB functionality is hindered greatly by the fact that both USB ports
and the Ethernet port all tie into the same bus. Also, I don't mind running
headless, but with both USB ports taken up by USB-serial converters, I
won't have a spot for a flash drive. Either I'll map a network drive or
just suffer with using the SD card. Then again, if I use a real man's
terminal, I'll save a USB port! :)
You might check out the BeagleBone Black. It?s similar but the hardware is open (fully
documented in 4500 or so pages). I forgot just what the USB config looks like, but I do
remember that the stock board has a pair of USB ports plus Ethernet plus microSD, all
available at the same time. Oh yes, plus on-board flash so you don?t usually need the SD.
And several UARTs. There?s an off the shelf plugin board to provide RS232 level serial
I/O from any one of those UARTs. I did a 4 port RS232 level converter; design files
available if anyone wants them.
The BBB is a nice device, but its bundled software is terrible enough
to turn me off of using the thing (and that's saying quite a bit; I'm
pretty tolerant of half-assery most of the time). My biggest complaint,
the one that's pretty much a dealbreaker to me, is that it won't boot
to the embedded flash if you have a uSD card inserted unless that card
is specially formatted to tell uBoot to ignore it. There's no flash
provided on the board to save parameters, so you can't save uBoot's
default boot device (which is hardwired to the uSD card), and instead
of moving on to the next device if booting from the uSD fails, uBoot
just hangs. There's no way to get around it short of rebuilding the
entire Linux and uBoot image and reflashing the whole embedded flash.
That prevents me from booting with (say) an unformatted uSD card in
there so that my unattended host platform can initialize it, which is
absolutely unacceptable. And the worst part was that I couldn't even
figure out why it wasn't booting until I put a serial->CMOS adaptor
on its debug port; the video isn't initialized at boot time, so there's
no status on the screen.
But it is nice hardware. I wish the software it came with wasn't quite
so boneheaded. As popular as the board is, I'm surprised more things
haven't been fixed (suspend mode isn't working either, which apparently
requires some heavy kernel patches from TI that don't work on recent
Linux versions).
If you're not scared of embedded programming (which means getting
intimate with things like board initialization and linker scripts),
I REALLY recommend something bare-metal ARM like the multitude of
cheap eval boards from ST and Atmel. Or, really, even AVR eval boards
without the Arduino stack taking up room (though AVR GCC isn't really
that nice to work with, and the programming tools don't have great
open source support).
- Dave