• Registered: 2009-12-29
  • Posts: 34

Topic: Different plan???

With the changes that are about to happen to the Chumby world as we know it in the near future, it got me thinking about what I was going to do (options seem to be: (1) Zurk's offline firmware, (2) the cut-down service Duane (whom I have an immense amount of respect for) is busy setting up or (3) Something else hand crafted).

I really like the fact that the Chumby platform is sufficiently open that I'm free to make any decision I want.

One of the things I really wanted to do when I got the Chumbies (I have 3 Chumby Classics) was put my own apps on it. There were lots of things I really wanted it to do - for instance being an interface for home automation, a status display for MythTV etc... Some of these I cludged together using PHPShow to display dynamically generated images, but they were far from perfect. The biggest hurdle, and the reason I never got anything more than 'hello world' off the ground, was always the requirement to write Adobe Flash applications.... I don't have any of the Adobe software, and the open source alternatives never seemed to work very well.

...so....

...Is perhaps now a good time to invest some serious effort in creating a platform (build environment, replacement control panel you can link your apps with, providing basic alarm facilities etc..., and necessary additional libraries etc..) where it's easy for users to build and deploy apps written in C/C++ (or assembler if you insist!). Not sure what graphical interface you would go for - I think the devices are too underpowered for X, to perhaps something like DirectFB.

To be clear - my aim isn't to allow existing applications to be recompiled for Chumby - it is simply to provide a really easy to use environment for people to develop their own apps that run well on Chumby, and allow them to do so without loosing basic alarm clock functionality.

What would my ideal be?

Perhaps try to get Debian running (obviously you'd need to leave a USB drive in the back of the Chumby). Not with X or anything - I'll stick with framebuffer.... not perfect, but allows for quick and easy messing around without needed a vast amount of embedded Linux knowledge and lots of packages/libraries available (so for instance you can use libcurl in your app if needed).

Failing that how about resurrecting the OpenEmbedded effort? Make a public Amazon EC2 snapshot available with it all installed and working, so people don't have to worry too much about the cross-compile environment. Create an idiots guide to getting the generated rootfs (and maybe Kernel) somewhere bootable by Chumbies....

Or perhaps aim a lot lower.... Create a way for people to easily compile native apps for the current Chumby rootfs (so the equivalent of a native compiler. Perhaps an Amazon snapshot containing qemu emulating an appropriately setup Chumby like filesystem, with gcc and loads of common libraries installed).

2 Reply by Materdaddy (edited by Materdaddy 2013-01-24 13:57:17)

  • From: Oceanside, CA
  • Registered: 2008-04-17
  • Posts: 650

Re: Different plan???

I love that you posted this.  I hope others join on with suggestions/ideas/code.

I have been (very slowly) working on a few tinkering projects for my array of Chumby devices which I'll throw out there for people's creativity to take hold.

I'm working on a system now that will basically be an auto-updating slideshow.  The idea is that me and my wife can put pictures of our kids on a local shared drive and two I8's that are at our parents' houses will automagically add these photos to their slideshows.  With this, I've downgraded these devices to just picture frames, but with a great feature set.  I started this project using Perigee Slideshow which runs on SDL since ChumbyLurker got SDL working on the chumby a long time ago: http://jstanley.pingerthinger.com/slideshow.html.  I was able to get this up and running relatively quickly with some caveats.  Perigee slideshow didn't rotate images, and it was heavy on memory.  I coded up reading the exif rotation and some quick/dirty loops to rotate the SDL_Surface, but the memory issue wasn't solved sufficiently.  I tried adding a swap file and also setting the OOM value to -17 (OOM_DISABLE) so it wouldn't be killed.  No success.  Because I never had it working reliably I canned it and I've started from scratch in the last couple days.  I'm just going to write a very basic SDL_image/SDL application to display images, then work on the rsync scripts for syncing pictures.

The other project involves running webkit on the Chumby platforms.  I actually was able to get QT's webkit cross-compiled about a week or so before finding this: http://hackaday.com/2012/05/29/webkit-o … oid-flash/ which had a similar goal.  I actually have this working on one of my chumbies that controls my yard sprinklers with the custom controller I built for that.  One of the great things of that was the rapid development.  Once you have the browser compiled and scripts setup to work properly, the web page development can be done on another machine easily and viewed in a browser.  The long-term goal for this is to have a complete automated setup for sprinklers, home security system, garage door indicators, music (pandora, and a few internet streams I frequent), calendar, and weather.  The only things I had working before running out of time were sprinkler control (through cron, not the web interface), pandora, weather, and calendar.  I need to finish the first slideshow project before revisiting this one.

Linux Guy - Occasional Chumby Hacker

Materdaddy's Website

3 Reply by gmcbay (edited by gmcbay 2013-01-24 14:10:37)

  • Registered: 2009-09-02
  • Posts: 22

Re: Different plan???

Completely separate from Duane's effort and totally in isolation I've been working on something like this in what little spare-time programming time I have.

What I'm building runs fine on the existing chumby OS (you just have to kill the running control panel to stop it from bogarting the framebuffer) but the idea is to make it flexible for use across different hardware platforms to free the platform from the hardware (as much as I like all the chumby devices I still have, there won't be any new ones made, and meanwhile the market for cheap Linux ARM devices is exploding -- see raspberry pi, all the various MK HDMI sticks, wandboard, et al.)

Flash isn't a viable option for this because of licensing.  The code for this is all in Go, so you get native performance.  The Go code talks to the OS using the /dev interfaces (eg, /dev/fb0, /dev/touchscreen0, etc, so it theoretically runs on any Linux-alike system that uses the Linux devfb and input system and the apps are being written to be as input neutral as possible (support for touchscreen or keyboard or mouse, ala Android).   The con for this Go-based approach is that we lose the ability for people who aren't traditional programmers to just slap something together in Flash (not to mention the ability to run all the existing apps in the ecosystem), the pro is the native code runs a lot faster allowing for things like on-client parsing of scraped HTML code, etc).   The trick for making this really chumby-like is sandboxing the runtime environment, disabling access to the unsafe package, etc, which I haven't spent a lot of time on thus far but which is theoretically very possible (http://play.golang.org/ does this).

When this is a bit more fully baked I'll post about it here but I make absolutely no promises that this will ever fully exist or that if it does it will be ready anytime soon.  It has been a lot of fun to work on though, and ditching Flash has lead to some fantastic app performance.

  • From: Germany
  • Registered: 2010-01-15
  • Posts: 40

Re: Different plan???

It took me several weeks deciding to buy or not to buy a Chumby Classic and the reason was Flash. While the Chumby hard- and software is very open, Flash is closed. And Flash was known to me as a useless technology.

I was very surprised when I decided to buy a Chumby Classic, how well Flash works on the Chumby. Till today my Chumby is the only application where Flash is of use to me. My perception changed a bit when I say that the Flash player consumes continuously 50-80% of CPU load on the Chumby, but okay the Chumby has not much else to do. However, I never started to like Flash.

When the Chumby was born Flash was the right technology to use, unfortunately it was also the technology which brought Chumby Industries to fall.

IMHO today the right technology for Apps is HTML5. I would love to see my Chumby playing HTML5 Apps.

1ras's Website

  • Registered: 2009-12-29
  • Posts: 34

Re: Different plan???

i almost put Qt on my list of possible ways to go (webkit being a very nice to have). Normally it just builds out-of-the-box if you get openembedded building properly.

My personal experience of webkit running on embedded platforms has always been very frustrating - it seems very slow and memory hungry, and never quite renders pages correctly. Having said that i haven't tried it for over 3 years, so it may have come on (or got more resource hungry?).

chumbys have so many potential uses. The problem was that they worked really well as alarm clocks, so i never found the motivation to re-purpose them.

From your post it sounds like you are comfortable with writing code. If i was aiming for your slideshow then personally i'd write a small app capable of fetching a pre-resized jpg from a url (or from a list of urls), decode it with libjpeg then write it straight to the framebuffer. Write some php (or perl, or whatever) to do the heavy lifting of image selection, scaling and rotation. No idea how you'd handle the touchscreen though.

What is needed for all of this is an easy to setup build environment (that goes beyond just a simple toolchain).

An open source replacement control panel with lots of tempting hooks might encourage people to tinker too.

  • From: Germany
  • Registered: 2010-01-15
  • Posts: 40

Re: Different plan???

I use Scratchbox2 on Debian Squeeze with Embedded Debian which is quite easy to install:

apt-get install emdebian-archive-keyring scratchbox2

/etc/apt/sources.list:
# Embedded Debian
deb http://www.emdebian.org/debian/ squeeze main

apt-get update
apt-get install gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

mkdir buildroot
cd buildroot

wget http://files.chumby.com/toolchain/arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
tar xjvf arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

mv arm-2008q3/arm-none-linux-gnueabi/libc/{lib,etc,usr} .
rm -rf usr/lib/bin
rm -rf arm-2008q3

sb2-init chumby arm-linux-gnueabi-gcc

PCRE (Perl Compatible Regular Expressions) for Chumby:

wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.31.tar.bz2
tar xjvf pcre-8.31.tar.bz2
cd pcre-8.31

sb2 ./configure --prefix=/mnt/usb
sb2 make
sb2 make install-strip

lighttpd for Chumby:

apt-get install zlib1g-dev-armel-cross

wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.31.tar.bz2
tar xjvf lighttpd-1.4.31.tar.bz2
cd lighttpd-1.4.31

sb2 CPPFLAGS=-I/mnt/usb/include LDFLAGS=-L/mnt/usb/lib ./configure --prefix=/mnt/usb --libdir=/mnt/usb/lib/lighttpd --without-bzip2
sb2 make
sb2 make install-strip

1ras's Website

  • Registered: 2009-12-29
  • Posts: 34

Re: Different plan???

oooh.... Things to play with already (i've never used scratchbox). Will have a go this weekend.

Just had a look at the Go language (something else i'd never heard of). Correct me of i'm wrong but is another along the lines of C# and Java so is easy to sandbox?

  • Registered: 2009-09-02
  • Posts: 22

Re: Different plan???

Go lives somewhere between C/C++ and C#/Java, it has garbage collection but it isn't a VM/bytecode based language like C# or Java, it is actual native compiled code running right on the chip. 

So... it doesn't have the type of bytecode verification that C#/Java do, but they did put some thought into isolating "dangerous" things into an unsafe package.  The system I'm envisioning would likely require apps to be distributed in source code form to maintain the type of security they have on play.golang.org, but as I mentioned I haven't really given the security issues a ton of thought yet.

There are of course other options available like haxe running neko linked to some sort of display system, something based on Mono, etc.

No idea how you'd handle the touchscreen though.

You can open /dev/input/event1 from any programming language that understands files and read touchscreen input that way, the data you read out is in 16-byte chunks and the format is specified in the input_event struct defined in /usr/include/linux/input.h.   In Go, I kick off a goroutine to just continually read this file as data is available and send input events over a published channel as they are received.  Works great.

  • From: Austin, TX
  • Registered: 2009-05-07
  • Posts: 471

Re: Different plan???

I'd also be really curious to see a HaXE/NME based setup -- that could allow reuse of a lot of Flash code, since it uses ActionScript and the Flash API as a starting point, but it compiles to C++ and then to native code, allowing better performance.  For Linux support, it targets SDL, so it should have a good chance of working with the existing Chumby SDL ports that talk to /dev/fb.

I've done a lot of work with WebKit on mobile, and performance there is really tough, especially on the C1/C8 class hardware.  It's really the ARM11-based systems that are finally able to drive the code fast enough to support reasonable apps on a 1024x768 screen.  The Chumby hit that fine line of having a much smaller screen, which means the graphic acceleration support doesn't need to be as great, but you still have the same non-graphical page and data complexity.

unwiredben's Website

10 Reply by gmcbay (edited by gmcbay 2013-01-24 16:07:47)

  • Registered: 2009-09-02
  • Posts: 22

Re: Different plan???

Yeah I'd steer clear of WebKit as a solution for general purpose apps, the chumby devices just don't have enough memory or cpu to do anything interesting with it, IMO.

Haxe is pretty neat, though.  For the last year I was at chumby, most of the new apps I wrote were written in haxe compiled to target AVM1 (ActionScript 2) since that's what our Flash runtime was.  Haxe was so much nicer to code in than AS2.

The allure of Go for me is not having to deal with a scripting/native boundary.  The UI toolkit I've been working on does all of the compositing in 32-bit RGBA space and thus avoids a lot of the banding and general problems we'd always have to work around with Flash apps (it still dumps to a 16 bit framebuffer on the falconwings, but it only takes the color down-conversion hit once instead of it being an accumulating error).  It still manages to run way faster than equivalent flash apps in terms of fps (most screen updates are less than 20 ms, though there's a lot of caching and dirty rect stuff going on to hit that).  It makes the device feel a lot more responsive to touches and such than it ever did to me with Flash code.  And all of this is much easier to manage and keep fast without having to worry about a division between app code and the underlying runtime.

  • From: Chicago Metro Area
  • Registered: 2010-12-18
  • Posts: 81

Re: Different plan???

Ooh, might this give me an excuse to learn go? At $day_job I write mostly open source code in C/C++ and Perl, and with that background I share the frustrations at having a commercial Flash platform on this otherwise mostly open machine. However until an alternative operating environment could offer a similar level of functionality I would be reluctant to switch either of my two systems permanently.

  • Registered: 2013-01-26
  • Posts: 3

Re: Different plan???

Hi All,

i wonder if u guys ever saw this...

http://tnhh.net/v3/text/hacking-qt4-webkit-on-chumby

and if can be usefull

thanks ALL of you

  • From: Oceanside, CA
  • Registered: 2008-04-17
  • Posts: 650

Re: Different plan???

Mestre1966 wrote:

Hi All,

i wonder if u guys ever saw this...

http://tnhh.net/v3/text/hacking-qt4-webkit-on-chumby

and if can be usefull

thanks ALL of you

Yes, this is linked from the hack-a-day article I replied with earlier.

I have webkit working on one of my I8s that is basically an information station that automatically updates.

A few others have mentioned in this thread that they didn't want to play with webkit/qt because it's heavy, but depending on your use case, I think it actually allows for rapid development on another machine that is easily deployed since you simply refresh the web page.

Linux Guy - Occasional Chumby Hacker

Materdaddy's Website