Re: Raspberry Pi and Lua

[Jay Carlson <nop@...>]

If you're wondering why I'm still posting on this thread on lua-l, it
does tangentially connect. First, the low end is really *interesting*
for embedding; intuition about it often turns out to be wrong. And
luci in openwrt is a pretty big existence proof of just how far you
can go with Lua on Linux on $25 hardware. Second, if you went looking
for RTL8196 datasheets you probably ended up on a bunch of Chinese
language web forums talking about embedded Linux. This was true ten
years ago for the NEC and Toshiba MIPS/SH-3 SoCs for Japanese and
somewhere in between for various Samsung devices in Korean. I still
think it's an interesting thought experiment: what if Lua had been
designed in a locale where characters were not bytes? What would
string.* look like?

On Mon, Mar 12, 2012 at 12:38 PM, KHMan <keinhong@gmail.com> wrote:
> On 3/12/2012 7:10 PM, Stefan Sandberg wrote:

>> Also, why cant you use MythTV, or play .ogg's??

> Here is an example: It doesn't have onboard NAND flash, IIRC you need the OS
> to boot from the SD card slot.

Think of it as socketed eMMC.

 > Getting media data via the USB port brings new questions, get it from what?

A microSD card in a USB connector-sized adapter no doubt. I like the
elago nano II fine. I prefer the microSD adapters with metal shields
to plastic; the heat sinking into the USB socket makes me feel better.

microSD had not been very cost-effective for 16G, and the drop of 50%
in the price of 32G devices is even more recent. 500G 2.5" USB hard
drives are probably OK for media.

Everybody is going to be disappointed in normal Linux performance on
some random consumer-grade flash device, whether it's resident on the
PCB or not. Queue depth is 1: writing a large chunk can take a long
time as the device erases blocks. During that time, read requests
can't be serviced. You'll feel that in the user interface when an
application blocks on a read, or worse, needs to demand-page in the
executable from that device. So you turn down the maximum transfer
size, which can increase write amplification as well as increase
request overhead. Consumer-grade flash has miserable write-leveling,
and combined with controller testing which primarily centers on
cameras and/or Windows writing FAT file systems you can run into bad
data corruption problems.

If cost were no object, I would place the "firmware" (kernel,
squashfs) on one device and everything writable on another.

As it happens I *did* have a MythTV frontend running on what we'd
probably now consider an embedded device: a PPC Mac mini with a failed
hard drive. Had to reimage thumb drives a couple times due to
uncorrectable read errors, and they were expensive name brands like
Sony. For a couple years I've been recording in H.264, and support for
hardware decode is significantly more important than when it was just
MPEG-2 or MPEG-4 ASP--which makes me a little nervous when I see
hardware decode almost always locked behind NDAs.

Jay