https://wiki.chumby.com/api.php?action=feedcontributions&user=24.30.157.165&feedformat=atomChumby Wiki - User contributions [en]2024-03-29T12:59:58ZUser contributionsMediaWiki 1.23.9//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-03-06T18:05:31Z<p>24.30.157.165: /* Summary */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2.1. Flash Lite 2.1 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary - they're expensive to compute.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
* '''Don't do too many network fetches at the same time''' - Flashlite limits the number of fetches intiated on the same frame, and the total number of fetches in progress at the same time. Considering queuing fetches and intiating new fetches when the previous ones complete.<br />
<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simply restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
* [[Sample Accelerometer Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
*The ascii art is at: /usr/local/etc/sshd_banner <br />
To remove: SSH the Chumby, and use vi:<br />
(vi /usr/local/etc/sshd_banner)<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
rm /tmp/flashplayer_started<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel - deleting <code>/tmp/flashplayer_started</code> prevents it from relaunching the player.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
'''NOTE''': If you are compiling your widgets in AS2, you will have to change the syntax of the ASnative calls in order to compile without errors:<br />
<br />
_bend = ["ASnative"](5,14)(); // this will return a value<br />
_accelerometer = ["ASnative"](5,60); // this will return a function object<br />
<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
==Accelerometer==<br />
<br />
The accelerometer can be found in the "Katamari" model of the chumby. The force values are read-only, and range 0-4095, with zero point (no force) at 2048, and a range of approximately -5 to +5 G. The "current" values are the instantaneous value of the sensor, the "avg" values are a running average of the last couple of readings (which will be somewhat smoother), and the "impact" values represent a change in force above a certain threshold. The "impactTime" can be use to detect when the impact occured. The "impactHints" value is used internally by the driver for housekeeping and is currently undocumented. A "Foo" chumby should return 0 for all values.<br />
Make sure you have:<br />
<br />
_accelerometer = ['ASnative'](5,60);<br />
<br />
Somewhere in your code.<br />
<br />
version = _accelerometer(0);<br />
timestamp = _accelerometer(1);<br />
currentX = _accelerometer(2);<br />
currentY = _accelerometer(3);<br />
currentZ = _accelerometer(4);<br />
avgX = _accelerometer(5);<br />
avgY = _accelerometer(6);<br />
avgZ = _accelerometer(7);<br />
impactX = _accelerometer(8);<br />
impactY = _accelerometer(9);<br />
impactZ = _accelerometer(10);<br />
impactTime = _accelerometer(11);<br />
impactHints = _accelerometer(12);<br />
<br />
A quick way to convert a component to a multiple of G would be:<br />
<br />
gValue = rawValue*0.0024489559928062587-5;<br />
<br />
Note that the value of G varies depending upon your location - the above equation represents an average.<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite 2 will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders that reference _root or _level0 - if you need something globally accessible, consider making it a property of Object, MovieClip or some other built-in object.<br />
* The movie uses device fonts - be sure all the required fonts are embedded<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite 2 does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-02-17T21:50:03Z<p>24.30.157.165: /* DC Power */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary - they're expensive to compute.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
* '''Don't do too many network fetches at the same time''' - Flashlite limits the number of fetches intiated on the same frame, and the total number of fetches in progress at the same time. Considering queuing fetches and intiating new fetches when the previous ones complete.<br />
<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simply restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
rm /tmp/flashplayer_started<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel - deleting <code>/tmp/flashplayer_started</code> prevents it from relaunching the player.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
==Accelerometer==<br />
<br />
The accelerometer can be found in the "Katamari" model of the chumby. The force values are read-only, and range 0-4095, with zero point (no force) at 2048, and a range of approximately -5 to +5 G. The "current" values are the instantaneous value of the sensor, the "avg" values are a running average of the last couple of readings (which will be somewhat smoother), and the "impact" values represent a change in force above a certain threshold. The "impactTime" can be use to detect when the impact occured. The "impactHints" value is used internally by the driver for housekeeping and is currently undocumented. A "Foo" chumby should return 0 for all values.<br />
<br />
_accelerometer = ASnative(5,60);<br />
version = _accelerometer(0);<br />
timestamp = _accelerometer(1);<br />
currentX = _accelerometer(2);<br />
currentY = _accelerometer(3);<br />
currentZ = _accelerometer(4);<br />
avgX = _accelerometer(5);<br />
avgY = _accelerometer(6);<br />
avgZ = _accelerometer(7);<br />
impactX = _accelerometer(8);<br />
impactX = _accelerometer(9);<br />
impactZ = _accelerometer(10);<br />
impactTime = _accelerometer(11);<br />
impactHints = _accelerometer(12);<br />
<br />
A quick way to convert a component to a multiple of G would be:<br />
<br />
gValue = rawValue*0.0024489559928062587-5;<br />
<br />
Note that the value of G varies depending upon your location - the above equation represents an average.<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite 2 will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders that reference _root or _level0 - if you need something globally accessible, consider making it a property of Object, MovieClip or some other built-in object.<br />
* The movie uses device fonts - be sure all the required fonts are embedded<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite 2 does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-01-22T19:04:13Z<p>24.30.157.165: /* Most Common Problems */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary - they're expensive to compute.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
* '''Don't do too many network fetches at the same time''' - Flashlite limits the number of fetches intiated on the same frame, and the total number of fetches in progress at the same time. Considering queuing fetches and intiating new fetches when the previous ones complete.<br />
<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
rm /tmp/flashplayer_started<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel - deleting <code>/tmp/flashplayer_started</code> prevents it from relaunching the player.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite 2 will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders that reference _root or _level0 - if you need something globally accessible, consider making it a property of Object, MovieClip or some other built-in object.<br />
* The movie uses device fonts - be sure all the required fonts are embedded<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite 2 does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-01-22T19:03:25Z<p>24.30.157.165: /* Performance and optimizations */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary - they're expensive to compute.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
* '''Don't do too many network fetches at the same time''' - Flashlite limits the number of fetches intiated on the same frame, and the total number of fetches in progress at the same time. Considering queuing fetches and intiating new fetches when the previous ones complete.<br />
<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
rm /tmp/flashplayer_started<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel - deleting <code>/tmp/flashplayer_started</code> prevents it from relaunching the player.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite 2 will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders that reference _root or _level0 - if you need something globally accessible, consider making it a property of Object.<br />
* The movie uses device fonts - be sure all the required fonts are embedded<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite 2 does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-01-22T18:55:17Z<p>24.30.157.165: /* Most Common Problems */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
rm /tmp/flashplayer_started<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel - deleting <code>/tmp/flashplayer_started</code> prevents it from relaunching the player.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite 2 will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders that reference _root or _level0 - if you need something globally accessible, consider making it a property of Object.<br />
* The movie uses device fonts - be sure all the required fonts are embedded<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite 2 does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Hacking_Linux_for_chumbyHacking Linux for chumby2007-01-19T01:52:10Z<p>24.30.157.165: </p>
<hr />
<div>=Toolchain=<br />
<br />
* download the [http://files.chumby.com/resources/Gcc-3.3.2-glibc-2.3.2.tar.gz Chumby Toolchain] to <code>/usr</code><br />
* extract<br />
# tar zxvf gcc-3.3.2-glibc-2.3.2.tar.gz<br />
* create Embedix dir and symlink<br />
# mkdir -p /opt/Embedix/usr/local/arm-linux<br />
# ln -s /usr /opt/Embedix/usr/local/arm-linux/gcc-3.3.2-glibc-2.3.2<br />
* if it does not already exist, open <code>/usr/bin/arm-linux-make</code> with your favorite editor and enter:<br />
#!/bin/sh<br />
echo make ARCH=arm CROSS=arm-linux- CC=arm-linux-gcc AR=arm-linux-ar NM=arm-linux-nm RANLIB=arm-linux-ranlib CXX=arm-linux-g++ AS=arm-linux-as LD=arm-linux-ld STRIP=arm-linux-strip BUILDCC=gcc BUILD_CC=gcc CC_FOR_BUILD=gcc "$@"<br />
exec make ARCH=arm CROSS=arm-linux- CC=arm-linux-gcc AR=arm-linux-ar NM=arm-linux-nm RANLIB=arm-linux-ranlib CXX=arm-linux-g++ AS=arm-linux-as LD=arm-linux-ld STRIP=arm-linux-strip BUILDCC=gcc BUILD_CC=gcc CC_FOR_BUILD=gcc "$@"<br />
* set <code>/usr/bin/arm-linux-make</code> executable<br />
# chmod +x /usr/bin/arm-linux-make<br />
<br />
=Kernel=<br />
<br />
The Alpha chumby runs a modified linux 2.4.20 kernel.<br />
<br />
The BSP is distributed via a CD image, or from a link that is forthcoming.<br />
<br />
'''Compiling the Kernel'''<br />
<br />
* create the parent directory<br />
mkdir ~/imx21<br />
cd ~/imx21<br />
*download copy the following iMX21 linux kernel source tarball to ~/imx21:<br />
[http://files.chumby.com/resources/Linux-2.4.20.tar.bz2 Linux-2.4.20.tar.bz2]<br />
* untar/unbzip the iMX21 linux kernel source<br />
[root@vm_machine imx21]# tar xvjf linux-2.4.20.tar.bz2<br />
* copy the following patch files to ~/imx21:<br />
[http://files.chumby.com/resources/Patch_mx21_rel3.1 Patch_mx21_rel3.1]<br><br />
[http://files.chumby.com/resources/Patch_mx21_rel3.1_bugfix_20050923 Patch_mx21_rel3.1_bugfix_20050923]<br><br />
[http://files.chumby.com/resources/Chumby_kernel.diff Chumby_kernel.diff]<br />
*change dirs to linux-2.4.20 and apply patches:<br />
[root@vm_machine imx21]# cd linux-2.4.20<br />
[root@vm_machine linux-2.4.20]# cat ../Patch_mx21_rel3.1 |patch -p1<br />
[root@vm_machine linux-2.4.20]# cat ../Patch_mx21_rel3.1_bugfix_20050923 |patch -p1<br />
[root@vm_machine linux-2.4.20]# cat ../Chumby_kernel.diff |patch -p1<br />
*copy the mx2.config to .config<br />
[root@vm_machine linux-2.4.20]# cp mx2.config .config<br />
* run 'make menuconfig' and exit, saving the file (this step is necessary in order to create the autoconf target)<br />
[root@vm_machine linux-2.4.20]# make menuconfig<br />
*run 'make dep' in order to create dependency tree<br />
[root@vm_machine linux-2.4.20]# make dep<br />
*build the image by running 'make Image'<br />
[root@vm_machine linux-2.4.20]# make Image<br />
* the following Image should be created:<br />
[root@vm_machine linux-2.4.20]# ls -la arch/arm/boot/Image<br />
-rwxr-xr-x 1 root root 2176064 Apr 19 18:49 arch/arm/boot/Image</div>24.30.157.165//wiki.chumby.com/index.php?title=Development_toolsDevelopment tools2007-01-06T01:41:03Z<p>24.30.157.165: </p>
<hr />
<div>=Programming languages=<br />
* [[python]]<br/><br />
* [[ruby]]<br/><br />
* [[java]]<br/><br />
* [[squeak]]<br/></div>24.30.157.165//wiki.chumby.com/index.php?title=Development_toolsDevelopment tools2007-01-06T01:40:53Z<p>24.30.157.165: </p>
<hr />
<div>=Programming anguages=<br />
* [[python]]<br/><br />
* [[ruby]]<br/><br />
* [[java]]<br/><br />
* [[squeak]]<br/></div>24.30.157.165//wiki.chumby.com/index.php?title=Development_toolsDevelopment tools2007-01-06T01:40:36Z<p>24.30.157.165: </p>
<hr />
<div>=Languages=<br />
* [[python]]<br/><br />
* [[ruby]]<br/><br />
* [[java]]<br/><br />
* [[squeak]]<br/></div>24.30.157.165//wiki.chumby.com/index.php?title=PythonPython2007-01-06T01:39:28Z<p>24.30.157.165: /* If you're too lazy to do all that... */</p>
<hr />
<div>=Why Python?=<br />
* because writing in C sucks<br />
* your time is valuable<br />
* once a python zealot, always a python zealot.<br />
<br />
<br />
=Compiling python from source=<br />
<br />
Supposedly there are patches that will allow you cross compile python. Unfortunately I wasn't able to get it to work. The problem is that the Python build system uses the binary it generates to finish the build process - meaning that in a cross compiling situation you have to build an arm binary *and* a localhost binary (i686-linux-gnu or whatever).<br/><br />
<br/><br />
A good starting point is http://www.mail-archive.com/patches@python.org/msg03662.html.<br />
<br />
=Using an existing python binary=<br />
<br />
<p><br />
Luckily a number of existing linux platforms already support builds for the arm-linux. It is fairly painless to grab a binary from one of these systems and make it work on the chumby. I used the binary from [http://pymaemo.sourceforge.net/cgi-bin/moin.cgi python for maemo] project. The [http://maemo.org/ Maemo] project is the open source effort by Nokia to get linux and associated tools work on their arm based 770 platform.<br />
</p><br />
* Download the python maemo binary from [http://pymaemo.sourceforge.net/cgi-bin/moin.cgi/ here]. You are looking for the PyMaemo 1.1 runtime.<br />
* The download is in a DEB file. There is probably some official way to untar a DEB file. However, the easiest solution is to run "tar x filename.deb". That will dump out the contents of the file.<br />
* You should see something like data.tar.gz. untar this file in the location of your choosing. For the purposes of this recipe I will assume you used the folder "chumby-python"<br />
* The next step is to make this folder available to the Chumby. There are two options: 1) copy the contents to a thumb drive or 2) simply mount this folder via NFS.<br />
* NFS:<br />
** [[chumby_tricks | Enable SSH with a USB thumb drive]]. Your other option is to use find the easter egg that turns on the SSH server. A source of inspiration might be the Davinci Code.<br />
** Login to your chumby via SSH.<br />
** Mount your "chumby-python" folder via NFS - this assumes that you have exposed "chumby-python" using your nfs exports file. Assuming that your server name is chumbyfanboi and your "chumby-python" is located at /opt/chumby/chumby-python, execute the following command: <br />
** "mount -o nolock -t nfs chumbyfanboi:/opt/chumby/chumby-python /python". "-o nolock" is important because portmap isn't running on the chumby.<br />
** cd to /python/usr/bin.<br />
** exec ./python2.4<br />
** you should now be running python! Note that the Maemo distribution only includes the basic python packages.<br />
* Mount via USB (I haven't done this so please add your instructions here)<br />
=If you're too lazy to do all that...=<br />
You can download all of this prebuilt in [http://files.chumby.com/languages/python/chumby_python.tgz chumby_python.tgz] (3.8MB).<br />
<br />
Just unpack onto a USB drive, add your python code and a "debugchumby" script, and you can write your own python applications for your chumby!</div>24.30.157.165//wiki.chumby.com/index.php?title=PythonPython2007-01-06T01:39:04Z<p>24.30.157.165: </p>
<hr />
<div>=Why Python?=<br />
* because writing in C sucks<br />
* your time is valuable<br />
* once a python zealot, always a python zealot.<br />
<br />
<br />
=Compiling python from source=<br />
<br />
Supposedly there are patches that will allow you cross compile python. Unfortunately I wasn't able to get it to work. The problem is that the Python build system uses the binary it generates to finish the build process - meaning that in a cross compiling situation you have to build an arm binary *and* a localhost binary (i686-linux-gnu or whatever).<br/><br />
<br/><br />
A good starting point is http://www.mail-archive.com/patches@python.org/msg03662.html.<br />
<br />
=Using an existing python binary=<br />
<br />
<p><br />
Luckily a number of existing linux platforms already support builds for the arm-linux. It is fairly painless to grab a binary from one of these systems and make it work on the chumby. I used the binary from [http://pymaemo.sourceforge.net/cgi-bin/moin.cgi python for maemo] project. The [http://maemo.org/ Maemo] project is the open source effort by Nokia to get linux and associated tools work on their arm based 770 platform.<br />
</p><br />
* Download the python maemo binary from [http://pymaemo.sourceforge.net/cgi-bin/moin.cgi/ here]. You are looking for the PyMaemo 1.1 runtime.<br />
* The download is in a DEB file. There is probably some official way to untar a DEB file. However, the easiest solution is to run "tar x filename.deb". That will dump out the contents of the file.<br />
* You should see something like data.tar.gz. untar this file in the location of your choosing. For the purposes of this recipe I will assume you used the folder "chumby-python"<br />
* The next step is to make this folder available to the Chumby. There are two options: 1) copy the contents to a thumb drive or 2) simply mount this folder via NFS.<br />
* NFS:<br />
** [[chumby_tricks | Enable SSH with a USB thumb drive]]. Your other option is to use find the easter egg that turns on the SSH server. A source of inspiration might be the Davinci Code.<br />
** Login to your chumby via SSH.<br />
** Mount your "chumby-python" folder via NFS - this assumes that you have exposed "chumby-python" using your nfs exports file. Assuming that your server name is chumbyfanboi and your "chumby-python" is located at /opt/chumby/chumby-python, execute the following command: <br />
** "mount -o nolock -t nfs chumbyfanboi:/opt/chumby/chumby-python /python". "-o nolock" is important because portmap isn't running on the chumby.<br />
** cd to /python/usr/bin.<br />
** exec ./python2.4<br />
** you should now be running python! Note that the Maemo distribution only includes the basic python packages.<br />
* Mount via USB (I haven't done this so please add your instructions here)<br />
=If you're too lazy to do all that...=<br />
You can download all of this prebuilt in [http://files.chumby.com/languages/python/chumby_python.tgz chumby_python.tgz].<br />
<br />
Just unpack onto a USB drive, add your python code and a "debugchumby" script, and you can write your own python applications for your chumby!</div>24.30.157.165//wiki.chumby.com/index.php?title=RubyRuby2007-01-06T01:38:23Z<p>24.30.157.165: </p>
<hr />
<div>A dongle image for ruby-1.8.4 can be found at [http://files.chumby.com/languages/ruby/chumby_ruby.tgz chumby_ruby.tgz] (2.3MB).<br />
<br />
You can unpack this and use a <code>debugchumby</code> file to launch a ruby program or launch <code>sshd</code>.<br />
It supports <code>irb</code>, <code>erb</code> and <code>ruby</code>.<br />
<br />
This is an extracted version of Ruby for the Nokia 770 taken from [http://rubyforge.org/projects/rubynokia770/ here].</div>24.30.157.165//wiki.chumby.com/index.php?title=RubyRuby2007-01-06T01:31:51Z<p>24.30.157.165: </p>
<hr />
<div>A dongle image for ruby-1.8.4 can be found at [http://files.chumby.com/languages/ruby/chumbyruby.tgz chumbyruby.tgz].<br />
<br />
You can unpack this and use a <code>debugchumby</code> file to launch a ruby program or launch <code>sshd</code>.<br />
It supports <code>irb</code>, <code>erb</code> and <code>ruby</code>.<br />
<br />
This is an extracted version of Ruby for the Nokia 770 taken from [http://rubyforge.org/projects/rubynokia770/ here].</div>24.30.157.165//wiki.chumby.com/index.php?title=Development_toolsDevelopment tools2007-01-06T01:27:06Z<p>24.30.157.165: </p>
<hr />
<div>[[python]]<br/><br />
[[ruby]]<br/><br />
[[java]]<br/><br />
[[squeak]]<br/></div>24.30.157.165//wiki.chumby.com/index.php?title=PythonPython2007-01-03T23:26:11Z<p>24.30.157.165: </p>
<hr />
<div>=Why Python?=<br />
* because writing in C sucks<br />
* your time is valuable<br />
* once a python zealot, always a python zealot.<br />
<br />
<br />
=Compiling python from source=<br />
<br />
Supposedly there are patches that will allow you cross compile python. Unfortunately I wasn't able to get it to work. The problem is that the Python build system uses the binary it generates to finish the build process - meaning that in a cross compiling situation you have to build an arm binary *and* a localhost binary (i686-linux-gnu or whatever).<br/><br />
<br/><br />
A good starting point is http://www.mail-archive.com/patches@python.org/msg03662.html.<br />
<br />
=Using an existing python binary=<br />
<br />
<p><br />
Luckily a number of existing linux platforms already support builds for the arm-linux. It is fairly painless to grab a binary from one of these systems and make it work on the chumby. I used the binary from [http://pymaemo.sourceforge.net/cgi-bin/moin.cgi python for maemo] project. The [http://maemo.org/ Maemo] project is the open source effort by Nokia to get linux and associated tools work on their arm based 770 platform.<br />
</p><br />
* Download the python maemo binary from [http://pymaemo.sourceforge.net/cgi-bin/moin.cgi/ here]. You are looking for the PyMaemo 1.1 runtime.<br />
* The download is in a DEB file. There is probably some official way to untar a DEB file. However, the easiest solution is to run "tar x filename.deb". That will dump out the contents of the file.<br />
* You should see something like data.tar.gz. untar this file in the location of your choosing. For the purposes of this recipe I will assume you used the folder "chumby-python"<br />
* The next step is to make this folder available to the Chumby. There are two options: 1) copy the contents to a thumb drive or 2) simply mount this folder via NFS.<br />
* NFS:<br />
** [[chumby_tricks | Enable SSH with a USB thumb drive]]. Your other option is to use find the easter egg that turns on the SSH server. A source of inspiration might be the Davinci Code.<br />
** Login to your chumby via SSH.<br />
** Mount your "chumby-python" folder via NFS - this assumes that you have exposed "chumby-python" using your nfs exports file. Assuming that your server name is chumbyfanboi and your "chumby-python" is located at /opt/chumby/chumby-python, execute the following command: <br />
** "mount -o nolock -t nfs chumbyfanboi:/opt/chumby/chumby-python /python". "-o nolock" is important because portmap isn't running on the chumby.<br />
** cd to /python/usr/bin.<br />
** exec ./python2.4<br />
** you should now be running python! Note that the Maemo distribution only includes the basic python packages.<br />
* Mount via USB (I haven't done this so please add your instructions here)<br />
=If you're too lazy to do all that...=<br />
You can download all of this prebuilt in [http://files.chumby.com/languages/python/chumbypython.tgz chumbypython.tgz].<br />
<br />
Just unpack onto a USB drive, add your python code and a "debugchumby" script, and you can write your own python applications for your chumby!</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-01-03T20:22:26Z<p>24.30.157.165: /* Iterating With chumbyflashplayer.x */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
rm /tmp/flashplayer_started<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel - deleting <code>/tmp/flashplayer_started</code> prevents it from relaunching the player.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders that reference _root or _level0<br />
* The movie uses device fonts - be sure all the required fonts are embedded<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-01-03T05:54:13Z<p>24.30.157.165: /* Most Common Problems */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders that reference _root or _level0<br />
* The movie uses device fonts - be sure all the required fonts are embedded<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2007-01-03T05:52:38Z<p>24.30.157.165: /* Flash Access to Sensors */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
=Leaks=<br />
Even Flash can be subject to memory leaks - the most common way to create a memory leak is to allocate '''XML''' objects as local variables. For instance, the code<br />
<br />
function someFunction() {<br />
var x = new XML();<br />
x.onLoad = doSomething;<br />
x.load("http://some.url");<br />
}<br />
<br />
...will result in a memory leak. '''XML''' objects should be assigned to movieclip properties, and assigned to '''undefined''' when no longer used.<br />
<br />
Eventually, memory leaks will cause the chumby to crash, although not always in the offending widget.<br />
<br />
Another class of leaks is "interval" leaks. The use of '''setInterval()''' without corresponding '''clearInterval()''' will result in interval objects accumulating. Since widgets can be unloaded at any time, it's possible that the opportunity to clear an interval may not happen. Therefore, intervals should be avoided within widgets. The typical symptom of an interval leak is the widget seeming to get too many interval callbacks, although eventually the CPU will get overloaded with too many interval firings, and the chumby becoming extremely sluggish.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());<br />
<br />
=Most Common Problems=<br />
<br />
The most common problems with widgets that seem to fail on the chumby are:<br />
<br />
* The movie is the wrong version - FlashLite will not play Flash 8 or Flash 9 movies.<br />
* The movie does not have sufficient security privileges - crossdomain files may not exist on the external content servers<br />
* The movie is not written to be loaded into another movie - this is often the case with movies with preloaders<br />
* The movie uses device fonts<br />
* The movie has the wrong frame rate - the chumby wants widgets to be 12fps<br />
* The movie has the wrong dimensions - the widgets should be 320x240<br />
* The movie contains Flash Video - FlashLite does not support Flash Video</div>24.30.157.165//wiki.chumby.com/index.php?title=Main_PageMain Page2006-11-25T02:20:01Z<p>24.30.157.165: </p>
<hr />
<div><big>'''Welcome to Chumby Wiki!'''</big><br />
<br />
=Other sites in the vast Chumby Network=<br />
[http://www.chumby.com Chumby web site]<br/><br />
[http://forum.chumby.com Chumby forums]<br/><br />
[http://chumby.wordpress.com/ Chumby blog]<br/><br />
<br />
=Problems with your chumby=<br />
[[Troubleshooting]]<br/><br />
<br />
=Hacking the chumby=<br />
[[General FAQ]] Add your knowledge here!<br/><br />
[[Using existing chumby widgets]]<br/><br />
[[Developing widgets for chumby]]<br/><br />
[[Hacking hardware for chumby]]<br/><br />
[[Hacking Linux for chumby]]<br/><br />
[[Blinging for chumby]]<br/><br />
[[Chumby tricks]] (web server, ssh, ?)<br/><br />
[[Open Source Flash Development]]<br/><br />
[[development tools]]<br/><br />
<br />
<br />
=The Chumbyista Community=<br />
irc: #chumby on irc.freenode.net and irc.oftc.net<br />
mailing lists?</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Webcam_WidgetSample Webcam Widget2006-11-10T22:17:55Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/samplecam_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/samplecam.fla samplecam.fla]<br />
<br />
This example file shows how to make a simple webcam widget that displays a JPEG image feed. This particular cam is showing the [http://www.turtlebayresort.com/ Turtle Bay Resort Spa] on Oahu - this camera is actually under user control on their website, so you may see it move every now and then.<br />
<br />
The server that is providing the the images *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
In this case, the cam was designed to be used from Flash, so the site has the proper permissions files. If you're attempting to pull a webcam feed from a server that does *not* support these permissions, you may not get any images - in that case, you'll need to provide a proxy server that does have the correct permissions which pulls the images from the webcam on behalf of the widget.<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Banner Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_RSS_WidgetSample RSS Widget2006-11-10T22:17:40Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/recentwidgets_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/recentwidgets.fla recentwidgets.fla]<br />
<br />
This example file shows how to make a simple widget that displays an [http://en.wikipedia.org/wiki/RSS_%28file_format%29 RSS] feed.<br />
<br />
In this case, we're using [http://www.chumby.com/rss/recentwidgets Chumby: Recent Widgets] RSS feed that the [http://www.chumby.com chumby.com] website provides that lists the most recent 10 new or updated public widgets. The source file is heavily commented and can be used as a template for your own RSS-based widgets.<br />
<br />
One thing to keep in mind when you create an RSS-based widget is that the server that is providing the RSS *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
This example widget works because chumby.com has the necessary file that grants access [http://www.chumby.com/crossdomain.xml here].<br />
<br />
If you have a widget that seems to work fine standalone, but not from a physical chumby or virtual chumby, that's very likely the cause - it will probably also fail if run from a web page. If you don't have access to the source of the feed to implement the proper access rights, then you can get around this by creating another server with the proper access rights that can proxy the original feed.<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Binary_Clock_WidgetSample Binary Clock Widget2006-11-10T22:17:20Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/binaryclock_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/binaryclock.fla binaryclock.fla]<br />
<br />
This example file shows how to make a simple clock widget that shows the time in binary (actually [http://en.wikipedia.org/wiki/Binary-coded_decimal BCD]).<br />
<br />
The clock is read with each column a digit in the time - the clock in the screen shot reads (15:14:16), which is a little after 3:14pm.<br />
<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Clock_WidgetSample Clock Widget2006-11-10T22:17:08Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/sampleclock_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/sampleclock.fla sampleclock.fla]<br />
<br />
This example file shows how to make a simple analog clock widget.<br />
<br />
<br />
Other examples:<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Banner_WidgetSample Banner Widget2006-11-10T22:16:39Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/simplebanner_ss.jpg<br />
<br />
'''FLA source files (requires Flash MX or later)''':<br />
[http://files.chumby.com/widgetexamples/simplebanner.fla simplebanner.fla],<br />
[http://files.chumby.com/widgetexamples/simplebanner_config.fla simplebanner_config.fla]<br />
<br />
This example file shows how to make a simple banner widget. It basically allows the user to specify a line of text that she wants to<br />
display on her chumby. This example shows the basics behind creating a configuration movie that will run on the website, and<br />
how to access that information from the widget.<br />
<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-10T22:09:51Z<p>24.30.157.165: /* Example widgets */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
Widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
* [[Sample Banner Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Binary_Clock_WidgetSample Binary Clock Widget2006-11-09T20:35:25Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/binaryclock_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/binaryclock.fla binaryclock.fla]<br />
<br />
This example file shows how to make a simple clock widget that shows the time in binary (actually [http://en.wikipedia.org/wiki/Binary-coded_decimal BCD]).<br />
<br />
The clock is read with each column a digit in the time - the clock in the screen shot reads (15:14:16), which is a little after 3:14pm.<br />
<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Webcam_WidgetSample Webcam Widget2006-11-05T23:24:08Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/samplecam_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/samplecam.fla samplecam.fla]<br />
<br />
This example file shows how to make a simple webcam widget that displays a JPEG image feed. This particular cam is showing the [http://www.turtlebayresort.com/ Turtle Bay Resort Spa] on Oahu - this camera is actually under user control on their website, so you may see it move every now and then.<br />
<br />
The server that is providing the the images *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
In this case, the cam was designed to be used from Flash, so the site has the proper permissions files. If you're attempting to pull a webcam feed from a server that does *not* support these permissions, you may not get any images - in that case, you'll need to provide a proxy server that does have the correct permissions which pulls the images from the webcam on behalf of the widget.<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_RSS_WidgetSample RSS Widget2006-11-05T23:23:56Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/recentwidgets_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/recentwidgets.fla recentwidgets.fla]<br />
<br />
This example file shows how to make a simple widget that displays an [http://en.wikipedia.org/wiki/RSS_%28file_format%29 RSS] feed.<br />
<br />
In this case, we're using [http://www.chumby.com/rss/recentwidgets Chumby: Recent Widgets] RSS feed that the [http://www.chumby.com chumby.com] website provides that lists the most recent 10 new or updated public widgets. The source file is heavily commented and can be used as a template for your own RSS-based widgets.<br />
<br />
One thing to keep in mind when you create an RSS-based widget is that the server that is providing the RSS *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
This example widget works because chumby.com has the necessary file that grants access [http://www.chumby.com/crossdomain.xml here].<br />
<br />
If you have a widget that seems to work fine standalone, but not from a physical chumby or virtual chumby, that's very likely the cause - it will probably also fail if run from a web page. If you don't have access to the source of the feed to implement the proper access rights, then you can get around this by creating another server with the proper access rights that can proxy the original feed.<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Clock_WidgetSample Clock Widget2006-11-05T23:23:42Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/sampleclock_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/sampleclock.fla sampleclock.fla]<br />
<br />
This example file shows how to make a simple analog clock widget.<br />
<br />
<br />
Other examples:<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Binary_Clock_WidgetSample Binary Clock Widget2006-11-05T23:23:11Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/binaryclock_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/binaryclock.fla binaryclock.fla]<br />
<br />
This example file shows how to make a simple clock widget taht shows the time in binary.<br />
<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-05T23:22:15Z<p>24.30.157.165: /* Example widgets */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample Binary Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Chumby_tricksChumby tricks2006-11-05T21:32:51Z<p>24.30.157.165: /* Finding your Chumby */</p>
<hr />
<div>=Finding your Chumby=<br />
<br />
[http://www.macosxhints.com/article.php?story=20051026183044858 Browsing bonjour services from the command line]<br />
<br />
I downloaded the [http://www.tildesoft.com/Programs.html Bonjour Browser] (under OSX) and run it.<br />
<br />
[[http://testingrange.com/pix/chumby/bonjour_browser.png Screen shot of bonjour browser]] <br />
<br />
<br />
You can see the Chumby listed here in the Bonjour Browser, along with the IP Address.<br />
<br />
The IP is also available on the Chumby itself from the Control Panel on the Settings->Info screen.<br />
<br />
=Browsing=<br />
<br />
Hints: Browseatwork but no textentry unless you use the nifty little spot made for when you wanted to browse with your psp via the Wipeout hack... Or point it to a place where it has your bookmarks in html form<br />
<br />
Just my two cents.<br />
<br />
=HTTPD/Built in Web Server=<br />
<br />
The Chumby advertises itself via Bonjour, Apple's system for advertising services.<br />
<br />
You can use the Bonjour bookmark that supposedly exists in Safari, but I am unable to find that. So used the tools under Finding Your Chumby to get an IP address to use.<br />
<br />
(Bonjour bookmarks in Safari can be enabled or disabled in the Safari preferences. From the Safari menu choose Preferences. Choose Bookmarks and check the Bonjour checkboxes.)<br />
<br />
Use the IP address you got from above, for example:<br />
http://10.0.1.11<br />
<br />
There are limited options on the web server right now, but you get a pretty picture and you can see wireless stats.<br />
<br />
[[http://testingrange.com/pix/chumby/chumby_web_20060828.png Screen shot of output of Chumby's built in web server]] The web page in the chumby as of 2006-08-28<br />
<br />
<br />
=SSHD=<br />
<br />
The Chumby comes with sshd, but it is not running by default (can you imagine chumby's running all over, usually behind NAT, but sometimes exposed, with sshd enabled and a default password? It would be chaos I say as people rooted my alarm clock! Enough fear mongering!)<br />
<br />
You need to run sshd.<br />
<br />
* The USB thumbdrive should be formatted with fat, vfat, or fat32 (this is the default for any thumbdrive you purchase I believe)<br />
* Put a file on a USB thumbdrive called "debugchumby"<br />
* It must be at the root level of the file system on the USB device<br />
* It must be marked executable<br />
* If it is a script (mostly likely), it should have the typical bang header:<br />
<br />
<pre><br />
#!/bin/sh<br />
/sbin/sshd<br />
</pre><br />
<br />
* This is not a feature you can count on - it may be removed or changed at any time.<br />
<br />
* You probably want to try connecting with the root account. Use the IP address from browsing Bonjour, or just look around your IP range until you find the machine (as far as I can see, Chumbies don't advertise ssh on Bonjour/Zeroconf, even when running sshd)<br />
<br />
* from linux you can do:<br />
<pre><br />
nmap ip-address<br />
</pre><br />
*...or you can look on the Settings/Info screen in the Control Panel for the current IP of the chumby<br />
<br />
'''this has been tested and verified on a foo camp chumby '''<br />
<br />
=SSHD Easter Egg=<br />
There's also an easter-egg method to start sshd on the Foo Camp chumbies. This trick may not survive firmware updates, so don't count on it being in future versions. You must have the network configured and running properly for this to work.<br />
<br />
* Bring up the Control Panel by gently squeezing the chumby<br />
* Press the "Settings" button on the left side<br />
* Press the "Info" button in the upper left<br />
* Press the legs in the background image of the octopus in the following sequence: 1, 1, 2, 3, 5<br />
* You should get a little popup of the octopus winking at you<br />
* You can now ssh into the chumby with the IP listed on the Info screen, with the user "root". For example:<br />
# ssh 192.168.1.102 -l root<br />
<br />
Don't forget to create and add your [[Max Chumbroom]] pictures.<br />
<br />
=File Manager=<br />
<br />
You can open a File Manager on the Chumby via an Easter Egg. Your clues are: settings->info and tapping...<br />
<br />
You can browse the file system, but it doesn't appear that you can open or execute files from the file manager.<br />
<br />
But you can determine that there are no easter eggs in the web server.<br />
<br />
=Chumby via Serial=<br />
<br />
There is a serial port somewhere. Getting to it involves a special cable and 'shims' and getting voltages right-if you attach a straight serial cable you will, apparantly, blow it up.<br />
<br />
I believe you need a RS-232 to TTL voltage converter to use the serial port. Google it.<br />
<br />
There is also a USB port</div>24.30.157.165//wiki.chumby.com/index.php?title=Chumby_tricksChumby tricks2006-11-05T21:32:28Z<p>24.30.157.165: /* Finding your Chumby */</p>
<hr />
<div>=Finding your Chumby=<br />
<br />
[http://www.macosxhints.com/article.php?story=20051026183044858 Browsing bonjour services from the command line]<br />
<br />
I downloaded the [http://www.tildesoft.com/Programs.html Bonjour Browser] (under OSX) and run it.<br />
<br />
[[http://testingrange.com/pix/chumby/bonjour_browser.png Screen shot of bonjour browser]] <br />
<br />
<br />
You can see the Chumby listed here in the Bonjour Browser, along with the IP Address.<br />
<br />
The IP is also available from the Control Panel on the Settings->Info screen.<br />
<br />
=Browsing=<br />
<br />
Hints: Browseatwork but no textentry unless you use the nifty little spot made for when you wanted to browse with your psp via the Wipeout hack... Or point it to a place where it has your bookmarks in html form<br />
<br />
Just my two cents.<br />
<br />
=HTTPD/Built in Web Server=<br />
<br />
The Chumby advertises itself via Bonjour, Apple's system for advertising services.<br />
<br />
You can use the Bonjour bookmark that supposedly exists in Safari, but I am unable to find that. So used the tools under Finding Your Chumby to get an IP address to use.<br />
<br />
(Bonjour bookmarks in Safari can be enabled or disabled in the Safari preferences. From the Safari menu choose Preferences. Choose Bookmarks and check the Bonjour checkboxes.)<br />
<br />
Use the IP address you got from above, for example:<br />
http://10.0.1.11<br />
<br />
There are limited options on the web server right now, but you get a pretty picture and you can see wireless stats.<br />
<br />
[[http://testingrange.com/pix/chumby/chumby_web_20060828.png Screen shot of output of Chumby's built in web server]] The web page in the chumby as of 2006-08-28<br />
<br />
<br />
=SSHD=<br />
<br />
The Chumby comes with sshd, but it is not running by default (can you imagine chumby's running all over, usually behind NAT, but sometimes exposed, with sshd enabled and a default password? It would be chaos I say as people rooted my alarm clock! Enough fear mongering!)<br />
<br />
You need to run sshd.<br />
<br />
* The USB thumbdrive should be formatted with fat, vfat, or fat32 (this is the default for any thumbdrive you purchase I believe)<br />
* Put a file on a USB thumbdrive called "debugchumby"<br />
* It must be at the root level of the file system on the USB device<br />
* It must be marked executable<br />
* If it is a script (mostly likely), it should have the typical bang header:<br />
<br />
<pre><br />
#!/bin/sh<br />
/sbin/sshd<br />
</pre><br />
<br />
* This is not a feature you can count on - it may be removed or changed at any time.<br />
<br />
* You probably want to try connecting with the root account. Use the IP address from browsing Bonjour, or just look around your IP range until you find the machine (as far as I can see, Chumbies don't advertise ssh on Bonjour/Zeroconf, even when running sshd)<br />
<br />
* from linux you can do:<br />
<pre><br />
nmap ip-address<br />
</pre><br />
*...or you can look on the Settings/Info screen in the Control Panel for the current IP of the chumby<br />
<br />
'''this has been tested and verified on a foo camp chumby '''<br />
<br />
=SSHD Easter Egg=<br />
There's also an easter-egg method to start sshd on the Foo Camp chumbies. This trick may not survive firmware updates, so don't count on it being in future versions. You must have the network configured and running properly for this to work.<br />
<br />
* Bring up the Control Panel by gently squeezing the chumby<br />
* Press the "Settings" button on the left side<br />
* Press the "Info" button in the upper left<br />
* Press the legs in the background image of the octopus in the following sequence: 1, 1, 2, 3, 5<br />
* You should get a little popup of the octopus winking at you<br />
* You can now ssh into the chumby with the IP listed on the Info screen, with the user "root". For example:<br />
# ssh 192.168.1.102 -l root<br />
<br />
Don't forget to create and add your [[Max Chumbroom]] pictures.<br />
<br />
=File Manager=<br />
<br />
You can open a File Manager on the Chumby via an Easter Egg. Your clues are: settings->info and tapping...<br />
<br />
You can browse the file system, but it doesn't appear that you can open or execute files from the file manager.<br />
<br />
But you can determine that there are no easter eggs in the web server.<br />
<br />
=Chumby via Serial=<br />
<br />
There is a serial port somewhere. Getting to it involves a special cable and 'shims' and getting voltages right-if you attach a straight serial cable you will, apparantly, blow it up.<br />
<br />
I believe you need a RS-232 to TTL voltage converter to use the serial port. Google it.<br />
<br />
There is also a USB port</div>24.30.157.165//wiki.chumby.com/index.php?title=Chumby_tricksChumby tricks2006-11-05T21:31:50Z<p>24.30.157.165: /* SSH */</p>
<hr />
<div>=Finding your Chumby=<br />
<br />
[http://www.macosxhints.com/article.php?story=20051026183044858 Browsing bonjour services from the command line]<br />
<br />
I downloaded the [http://www.tildesoft.com/Programs.html Bonjour Browser] (under OSX) and run it.<br />
<br />
[[http://testingrange.com/pix/chumby/bonjour_browser.png Screen shot of bonjour browser]] <br />
<br />
<br />
You can see the Chumby listed here in the Bonjour Browser, along with the IP Address.<br />
<br />
=Browsing=<br />
<br />
Hints: Browseatwork but no textentry unless you use the nifty little spot made for when you wanted to browse with your psp via the Wipeout hack... Or point it to a place where it has your bookmarks in html form<br />
<br />
Just my two cents.<br />
<br />
=HTTPD/Built in Web Server=<br />
<br />
The Chumby advertises itself via Bonjour, Apple's system for advertising services.<br />
<br />
You can use the Bonjour bookmark that supposedly exists in Safari, but I am unable to find that. So used the tools under Finding Your Chumby to get an IP address to use.<br />
<br />
(Bonjour bookmarks in Safari can be enabled or disabled in the Safari preferences. From the Safari menu choose Preferences. Choose Bookmarks and check the Bonjour checkboxes.)<br />
<br />
Use the IP address you got from above, for example:<br />
http://10.0.1.11<br />
<br />
There are limited options on the web server right now, but you get a pretty picture and you can see wireless stats.<br />
<br />
[[http://testingrange.com/pix/chumby/chumby_web_20060828.png Screen shot of output of Chumby's built in web server]] The web page in the chumby as of 2006-08-28<br />
<br />
<br />
=SSHD=<br />
<br />
The Chumby comes with sshd, but it is not running by default (can you imagine chumby's running all over, usually behind NAT, but sometimes exposed, with sshd enabled and a default password? It would be chaos I say as people rooted my alarm clock! Enough fear mongering!)<br />
<br />
You need to run sshd.<br />
<br />
* The USB thumbdrive should be formatted with fat, vfat, or fat32 (this is the default for any thumbdrive you purchase I believe)<br />
* Put a file on a USB thumbdrive called "debugchumby"<br />
* It must be at the root level of the file system on the USB device<br />
* It must be marked executable<br />
* If it is a script (mostly likely), it should have the typical bang header:<br />
<br />
<pre><br />
#!/bin/sh<br />
/sbin/sshd<br />
</pre><br />
<br />
* This is not a feature you can count on - it may be removed or changed at any time.<br />
<br />
* You probably want to try connecting with the root account. Use the IP address from browsing Bonjour, or just look around your IP range until you find the machine (as far as I can see, Chumbies don't advertise ssh on Bonjour/Zeroconf, even when running sshd)<br />
<br />
* from linux you can do:<br />
<pre><br />
nmap ip-address<br />
</pre><br />
*...or you can look on the Settings/Info screen in the Control Panel for the current IP of the chumby<br />
<br />
'''this has been tested and verified on a foo camp chumby '''<br />
<br />
=SSHD Easter Egg=<br />
There's also an easter-egg method to start sshd on the Foo Camp chumbies. This trick may not survive firmware updates, so don't count on it being in future versions. You must have the network configured and running properly for this to work.<br />
<br />
* Bring up the Control Panel by gently squeezing the chumby<br />
* Press the "Settings" button on the left side<br />
* Press the "Info" button in the upper left<br />
* Press the legs in the background image of the octopus in the following sequence: 1, 1, 2, 3, 5<br />
* You should get a little popup of the octopus winking at you<br />
* You can now ssh into the chumby with the IP listed on the Info screen, with the user "root". For example:<br />
# ssh 192.168.1.102 -l root<br />
<br />
Don't forget to create and add your [[Max Chumbroom]] pictures.<br />
<br />
=File Manager=<br />
<br />
You can open a File Manager on the Chumby via an Easter Egg. Your clues are: settings->info and tapping...<br />
<br />
You can browse the file system, but it doesn't appear that you can open or execute files from the file manager.<br />
<br />
But you can determine that there are no easter eggs in the web server.<br />
<br />
=Chumby via Serial=<br />
<br />
There is a serial port somewhere. Getting to it involves a special cable and 'shims' and getting voltages right-if you attach a straight serial cable you will, apparantly, blow it up.<br />
<br />
I believe you need a RS-232 to TTL voltage converter to use the serial port. Google it.<br />
<br />
There is also a USB port</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-05T21:17:10Z<p>24.30.157.165: /* Testing a widget locally */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
The chumby itself has no substantial local storage, so you should not expect to store widgets on the chumby. The protoype ''does'' allow write access to the built-in NAND Flash, however, there's isn't much free space and it will be entirely overwritten by firmware updates. Future versions of the chumby will be read-only. If you want to run Flash movies on the device itself without uploading to the chumby servers, you'll need to do it from a USB mass storage device plugged into the back of the chumby.<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-04T04:07:03Z<p>24.30.157.165: /* Performance and optimizations */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid gradients.''' Gradient fills, particularly radial gradients and gradients with translucency, are expensive. Use them sparingly.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
* '''Avoid lots of text.''' Lots of small text can be expensive to render. The chumby is meant to be read from a few feet away, so you really should be using large text anyway.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-04T04:02:14Z<p>24.30.157.165: /* Performance and optimizations */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks and techniques that can make the difference between a sluggish movie and one that works smoothly.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-04T04:01:27Z<p>24.30.157.165: /* Iterating With Chumbyplayer.x */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks a techniques that can make the difference between a sluggish movie and one that works nicely.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With chumbyflashplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-04T04:00:53Z<p>24.30.157.165: /* Summary */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby).<br />
<br />
=Performance and optimizations=<br />
<br />
The protoype chumby has a 266Mhz ARM9 processor - similar in performance to a low-end Pentium desktop. There are certain tricks a techniques that can make the difference between a sluggish movie and one that works nicely.<br />
<br />
* '''Change property values only when necessary.''' The very act of changing a property can result in a redraw of that object, even if the value itself hasn't changed. Be sure to check to see if changing the property is necessary before changing it - for instance, don't change the _rotation value of the hour hand of a clock if it hasn't actually moved.<br />
<br />
* '''Change dynamic text only when necessary.''' If the text isn't actually different, don't change it.<br />
<br />
* '''Reduce the size of images by playing with compression settings.''' Make the images as small as possible with acceptable quality.<br />
<br />
* '''Reduce the size of audio by playing with compression settings.''' As with images, try for small size with acceptable quality.<br />
<br />
* '''Simplify vector graphics.''' See if you can use Flash's curve simplification to reduce the number of points and curves. For static graphics, you might even be better off creating bitmaps and using them instead.<br />
<br />
* '''Avoid layered translucent areas.''' Piling on a lot of translucency is expensive. You may be better off using PNGs with these effects already composited. If you can use masks, use them.<br />
<br />
* '''Avoid full-frame animation.''' Animation that changes large areas of the display can slow down the animation - try to keep the percentage of the screen being updated as small as possible for any given frame.<br />
<br />
* '''Use tweening sparingly.''' Try to keep tweening to one or two small objects at a time. Don't use shape tweens unless absolutely necessary.<br />
<br />
* '''Avoid processing a lot of data in a single frame.''' Try queuing data in an array and process one item per frame. It complicates things a little bit, but will result in smoother operation and will avoid Actionscript timeouts.<br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With Chumbyplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-04T03:29:13Z<p>24.30.157.165: /* Using "virtual chumby" */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby). <br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, or you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With Chumbyplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-04T03:28:34Z<p>24.30.157.165: /* Uploading a widget */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby). <br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixel JPEG thumbnail image which represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, of you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With Chumbyplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Webcam_WidgetSample Webcam Widget2006-11-03T00:09:59Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/samplecam_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/samplecam.fla samplecam.fla]<br />
<br />
This example file shows how to make a simple webcam widget that displays a JPEG image feed. This particular cam is showing the [http://www.turtlebayresort.com/ Turtle Bay Resort Spa] on Oahu - this camera is actually under user control on their website, so you may see it move every now and then.<br />
<br />
The server that is providing the the images *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
In this case, the cam was designed to be used from Flash, so the site has the proper permissions files. If you're attempting to pull a webcam feed from a server that does *not* support these permissions, you may not get any images - in that case, you'll need to provide a proxy server that does have the correct permissions which pulls the images from the webcam on behalf of the widget.<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Webcam_WidgetSample Webcam Widget2006-11-02T23:53:11Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/samplecam_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/samplecam.fla samplecam.fla]<br />
<br />
This example file shows how to make a simple webcam widget that displays a JPEG image feed. This particular cam is showing the http://www.turtlebayresort.com/ Turtle Bay Resort Spa] on Oahu - this camera is actually under user control on their website, so you may see it move every now and then.<br />
<br />
The server that is providing the the images *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
In this case, the cam was designed to be used from Flash, so the site has the proper permissions files. If you're attempting to pull a webcam feed from a server that does *not* support these permissions, you may not get any images - in that case, you'll need to provide a proxy server that does have the correct permissions which pulls the images from the webcam on behalf of the widget.<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_RSS_WidgetSample RSS Widget2006-11-02T23:46:36Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/recentwidgets_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/recentwidgets.fla recentwidgets.fla]<br />
<br />
This example file shows how to make a simple widget that displays an [http://en.wikipedia.org/wiki/RSS_%28file_format%29 RSS] feed.<br />
<br />
In this case, we're using [http://www.chumby.com/rss/recentwidgets Chumby: Recent Widgets] RSS feed that the [http://www.chumby.com chumby.com] website provides that lists the most recent 10 new or updated public widgets. The source file is heavily commented and can be used as a template for your own RSS-based widgets.<br />
<br />
One thing to keep in mind when you create an RSS-based widget is that the server that is providing the RSS *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
This example widget works because chumby.com has the necessary file that grants access [http://www.chumby.com/crossdomain.xml here].<br />
<br />
If you have a widget that seems to work fine standalone, but not from a physical chumby or virtual chumby, that's very likely the cause - it will probably also fail if run from a web page. If you don't have access to the source of the feed to implement the proper access rights, then you can get around this by creating another server with the proper access rights that can proxy the original feed.<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Clock_WidgetSample Clock Widget2006-11-02T23:45:56Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/sampleclock_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/sampleclock.fla sampleclock.fla]<br />
<br />
This example file shows how to make a simple analog clock widget.<br />
<br />
<br />
Other examples:<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Clock_WidgetSample Clock Widget2006-11-02T23:45:39Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/sampleclock_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/sampleclock.fla sampleclock.fla]<br />
<br />
This example file shows how to make a simple analog clock widget.<br />
<br />
<br />
Other examples:<br />
* [[Sample RSS Widget]]<br />
* [[Sampe Webcam Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_Webcam_WidgetSample Webcam Widget2006-11-02T23:44:54Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/samplecam_ss.jpg<br />
<br />
'''FLA source file (requires Flash MX or later)''': [http://files.chumby.com/widgetexamples/samplecam.fla samplecam.fla]<br />
<br />
This example file shows how to make a simple webcam widget that displays a JPEG image feed. This particular cam is showing the Turtle Bay Resort Spa on Oahu - this camera is actually under user control on their website, so you may see it move every now and then.<br />
<br />
The server that is providing the the images *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
Other examples:<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Developing_widgets_for_chumbyDeveloping widgets for chumby2006-11-02T23:35:05Z<p>24.30.157.165: /* Example widgets */</p>
<hr />
<div>=Summary=<br />
Widgets for the Chumby are developed for Adobe Flash Lite 2, possibly with Flash Lite 2.1 being used in the future. Flash Lite 2 has a feature-set like that of Flash 7, meaning no Flash video (as the device alone isn't fast enough to play back video at a usable rate anyhow, though future implementations may allow for the use of the Alpha Chumby's processor's hardware accelerator for video). <br />
<br />
As of right now, <br />
* PNG and GIF image format aren't included. This could change in the future.<br />
* Progressive JPEG support isn't included.<br />
* It does not support video (Sorenson or On2) or Nelly Moser audio<br />
* It does not support LocalConnection or XMLSocket.<br />
* It does not support the Flash Communication Server<br />
* There are no device fonts - all fonts must be embedded in the movie<br />
* Playback of external audio files (MP3, etc) are not yet supported.<br />
<br />
Also important for developers to note is that the device's current input system is a touchscreen, meaning that mouseMove events will only occur while mouseDown (equivalent on current computers of only being able to move the mouse while holding a mouse button), which may/will have some effect on how your programs operate. <br />
<br />
For efficiency's sake, Flash Lite downsamples images and embedded fonts, so avoid resizing images and small serif fonts, as detail will be lost. <br />
<br />
Developers should avoid "play" or "repeat" buttons, and whenever possible opt for as little complex interactions with Chumby as possible; it is recommended that widgets need no human interaction. Text entry should also be avoided whenever possible, as the Chumby's text input system is crude at the moment, and most methods of touch screen text input are covered by patents and thusly won't be included in Chumby. (Most on-screen keyboards need more space than Chumby has, or are designed to operate with a stylus, which is not recommended for use with Chumby). <br />
<br />
=Widget Environment=<br />
Widgets are given a set of parameters about the environment of the chumby: For example:<br />
<br />
this['_chumby_movie_url']='http://www.chumby.com/xml/movies/12345678-1234-1234-1234-123456781234'<br />
this['_chumby_chumby_id']='87654321-4321-4321-4321-432187654321'<br />
this['_chumby_chumby_name']='TestChumby'<br />
this['_chumby_profile_id']='ABCDEF12-ABCD-ABCD-ABCD-ABCDEF12345678'<br />
this['_chumby_profile_name']='Default'<br />
this['_chumby_user_id']='FEDCBA9876-FEDC-FEDC-FEDC-FEDCBA98765432'<br />
this['_chumby_user_name']='johndoe'<br />
this['_chumby_widget_instance_href']='http://www.chumby.com/xml/widgetinstances/12121212-1212-1212-1212-121212121212'<br />
this['_chumby_widget_instance_id']='12121212-1212-1212-1212-121212121212'<br />
this['_chumby_base_url']='http://www.chumby.com'<br />
<br />
A widget that has a configuration dialog may create additional values - for instance, a horoscope widget might create:<br />
this['sign'] = 'Scorpio'<br />
<br />
=Security=<br />
The widget has a security sandbox similar to a movie running in a browser plugin - an external source of content should have an appropriate '''crossdomain.xml''' file to expose content to the widget. For more information, please see the following Flash Player Technotes and Articles:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
One should also build widgets so they can be loadMovie()'d into another "virtual chumby" movie at some level other than _root - this means you should try to avoid adding random properties to _root or the built-in objects.<br />
<br />
In general, widgets should be under 100K in size in order to reduce download time and use the minimum of storage in the device itself.<br />
<br />
=Testing a widget locally=<br />
<br />
* Get a USB dongle, formatted as VFAT, and put your Flash movie on the top level.<br />
* Create a script file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/usr/bin/chumbyflashplayer.x -i /mnt/usb/<name of flash file>.swf<br />
The file must use UNIX-style line terminations, and the last line must be terminated.<br />
* Plug the dongle into the USB port on the back of your chumby<br />
* Power it up - after the opening animation, your widget should run<br />
<br />
=Uploading a widget=<br />
<br />
You can upload a widget to our service which you can then use on your chumby. You will need to have the SWF for your widget, and a 80x60 pixels JPEG thumbnail image whcih represents your widget.<br />
<br />
* Create an account with chumby.com, if you haven't already<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys<br />
* Select "my widgets" from the "my chumby" menu<br />
* Click the "upload a widget" link<br />
* Fill in the information<br />
<br />
A widget uploaded using this mechanism will show up in the widget mix configuration, and can be selected just like any other widget, however, these uploaded widgets will only be accessible from your account. In the future, you'll be able to share these widgets with your friends, and even submit them to chumby for public access.<br />
<br />
<br />
=Using "virtual chumby"=<br />
<br />
The website has a mechanism for testing widgets in a Flash-based simulation of the widget playback of a real chumby. You do not need a physical chumby to utilize this functionality.<br />
<br />
* Create an account with chumby.com, if you haven't already.<br />
* Log in - you will probably be redirected to a page that offers to let you register a chumby, or a list of your current physical chumbys.<br />
* Select "my widget mixes" from the "my chumby" menu.<br />
* Click the "virtual chumby for this widget mix" link for one of the widget mixes - you should have at least one called "Default".<br />
<br />
You can add widgets to any given widget mix. Both the real and virtual chumbys will check in for updated widget mixes every five minutes or so, of you can simple restart the Flash movie by reloading the virtual chumby's page.<br />
<br />
=Example widgets=<br />
<br />
Here are some Flash source (.fla) files for various types of widgets:<br />
<br />
* [[Sample Clock Widget]]<br />
* [[Sample RSS Widget]]<br />
* [[Sample Webcam Widget]]<br />
<br />
=Using SCP to Test Applications=<br />
<br />
Do you know the joke about the how to avoid getting lost and stranded on a forest trek? Bring some vermouth and gin with you, and if you get lost, sit on a tree stump and mix 3/4 cup gin with a 1/4 vermouth and from all around the forest, people will jump at you and say, "that's no way to mix a martini"... and you're saved!<br />
<br />
In a similar vein, I'm putting up how I was able to get a edit/compile/debug cycle going for the Chumby in the hopes someone who can improve it, "jumps out".<br />
<br />
I was able to develop and test a few FlashLite apps using the method of placing a file on the USB key and moving and back and forth to the Chumby. This got old quickly, so I found this (somewhat) better workflow.<br />
Although SSH is available using the method above, so you can remotely open a shell from your development workstation, scp is not on the chumby.<br />
<br />
* Create a VFAT formatted usb key as described above.<br />
* Create a executable file on the dongle called "'''debugchumby'''" with the contents<br />
#!/bin/sh<br />
/bin/sshd<br />
* Test that this is working by restarting the Chumby and ensure you can ssh into this as root from your development box. Since root doesn't have a password, it's a good idea to remove the key and reboot after you finish development.<br />
ssh -l root chumby<br />
You should get a root prompt at this point. Note, I've got dnsmasq running so my chumby has a 'name', it might just be an IP address for you (e.g. ssh -l root 192.168.0.XXX)<br />
* Note where your usb key is mounted on the chumby - it's /mnt/usb for me (and likely for you)<br />
* Put usb key back in your development box.<br />
* Get a copy of '''scp''' either by compiling it for ARM-linux, or find a precompiled ARM version. For instance, for Zaurus, there an scp in the OpenSSH package: http://www.killefiz.de/zaurus/showdetail.php?app=1035. The files can be unzipped & untarred, eventually locating '''scp'''.<br />
* place '''scp''' in the usb key root directory.<br />
* place usb key back in the chumby, and then reboot the chumby again<br />
* cd to /usr/bin on the chumby and create a symlink to the scp on /mnt/usb/. You could also just copy scp to /usr/bin, and I'm sure there's some clever way to set the path to have the /mnt/usb/scp, but I didn't bother (can be done with <code>PATH=$PATH:/mnt/usb</code>)<br />
(on Chumby)<br />
cd /usr/bin<br />
ln -s /mnt/usb/scp /usr/bin<br />
cd /mnt/usb<br />
chmod +x scp<br />
* from your development box terminal window, as sudo (or root), you should now be able to copy a file<br />
sudo scp <filename> chumby:<br />
* from your chumby terminal window, you should now see the file you've just uploaded in /mnt/usb/<filename><br />
<br />
Good luck! This is much easier than moving the usb key back and forth!<br />
<br />
* Notes: sftp_server can be done similarly. This would be nicer because there's some nice GUI front-ends for it. however, I'm not able to get it working with the few minutes I've spent on it. I believe it has something to do with the sextopus ascii logo that is creating a problem for the sftp initiation, according to some googling on sftp_server failure modes. I'd like to temporarily remove this ascii art and see if it helps (where is it being called from?). Or maybe not...<br />
* Clearly you can save a step above by putting the scp on the key first. I thought it was worth getting ssh running first...<br />
* Samba would be very nice, you could save the flash swf on the chumby right from Flash Professional.<br />
* File Access Monitor to detect newly dropped SWF file, and automatically reinvoke Chumbyplayer.x<br />
<br />
-hbchumby<br />
<br />
=Iterating With Chumbyplayer.x=<br />
<br />
Now that you can move files to the Chumby easily, how can you iterate?<br />
What I did is create a similar script on the Chumby (in <code>/mnt/usb</code>) that kills the current Chumby player and restarts it with my test application:<br />
<br />
#!/bin/sh<br />
killall chumbyflashplayer.x<br />
/usr/bin/chumbyflashplayer.x -i mytestapp.swf<br />
<br />
The chumby has a watchdog timer that looks for lockups in the FlashLite Player or Control Panel, so it may try to restart the built-in movie. You can prevent the script from doing this by removing the file <code>/tmp/flashplayer_started</code> before launching <code>chumbyflashplayer.x</code> with your movie.<br />
<br />
-hbchumby<br />
<br />
=Flash Access to Sensors=<br />
The Chumby Flash Player has some ASnative calls to access the various sensors<br />
<br />
'''NOTE''': These are very likely to change in future releases - use at your own peril.<br />
<br />
==Touchscreen==<br />
<br />
Normally, the touchscreen is calibrated by the user using the Control Panel, however, raw coordinates are available.<br />
<br />
_rawX = ASnative(5,10); // get the last raw touchscreen X coordinate<br />
_rawY = ASnative(5,11); // get the last raw touchscreen Y coordinate<br />
trace('x:'+_rawX()+', y:'+_rawY());<br />
<br />
==Bend Sensor==<br />
<br />
The bend sensor is currently used by the Control Panel to bring up the controls.<br />
<br />
_bend = ASnative(5,14); // get the "last" bend sensor reading<br />
trace(_bend());<br />
<br />
_bent = ASnative(5,25); // get the "bent" flag (0/1)<br />
trace(_bent());<br />
<br />
_bendAverage = ASnative(5,28); // get the 10-second running average of the bend sensor<br />
<br />
==Light Sensor==<br />
<br />
_light = ASnative(5,15); // get the ambient light sensor reading<br />
trace(_light());<br />
<br />
==Display==<br />
<br />
This allows you turn off the display, perhaps for power reasons.<br />
<br />
_getLCDMute = ASnative(5,19); // get the value of the LCD "mute"<br />
_setLCDMute = ASnative(5,20); // set the value of the LCD "mute"<br />
trace(_getLCDMute());<br />
_setLCDMute(1);<br />
<br />
The "brightness" values are used by the Linux kernel to automatically dim the display. There are 16 subranges, each with its own threshold<br />
and associated brightness values.<br />
<br />
_getBrightnessForRange = ASnative(5,21); // get the display brightness for the indexed light level range<br />
_setBrightnessForRange = ASnative(5,22); // set the display brightness for the indexed light level range<br />
for (i=0;i<16;i++) trace(_getBrightnessForRange(i));<br />
_setBrightnessForRange(5,255);<br />
<br />
_getBrightnessThresholdForRange = ASnative(5,23); // get the threshold for the indexed light level range<br />
_setBrightnessThresholdForRange = ASnative(5,24); // set the threshold for the indexed light level range<br />
trace(_getBrightnessThresholdForRange(5));<br />
_setBrightnessThresholdForRange(5,24);<br />
<br />
==Speaker==<br />
<br />
This cuts off audio to the built in speakers, but still allows audio through the headphone jack.<br />
<br />
_getSpeakerMute = ASnative(5,17);<br />
_setSpeakerMute = ASnative(5,18);<br />
trace(_getSpeakerMute());<br />
_setSpeakerMute(1);<br />
<br />
==DC Power==<br />
<br />
This tells you whether the device is connected to the DC power adaptor, or if it's running on the 9V battery. Currently, the Control Panel will turn off the display if the device is running on battery.<br />
<br />
_dcPower = ASnative(5,16);<br />
trace(_dcPower());</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_RSS_WidgetSample RSS Widget2006-11-02T17:14:40Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/recentwidgets_ss.jpg<br />
<br />
This example file shows how to make a simple widget that displays an [http://en.wikipedia.org/wiki/RSS_%28file_format%29 RSS] feed.<br />
<br />
In this case, we're using [http://www.chumby.com/rss/recentwidgets Chumby: Recent Widgets] RSS feed that the [http://www.chumby.com chumby.com] website provides that lists the most recent 10 new or updated public widgets. The source file is heavily commented and can be used as a template for your own RSS-based widgets.<br />
<br />
One thing to keep in mind when you create an RSS-based widget is that the server that is providing the RSS *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
This example widget works because chumby.com has the necessary file that grants access [http://www.chumby.com/crossdomain.xml here].<br />
<br />
If you have a widget that seems to work fine standalone, but not from a physical chumby or virtual chumby, that's very likely the cause - it will probably also fail if run from a web page. If you don't have access to the source of the feed to implement the proper access rights, then you can get around this by creating another server with the proper access rights that can proxy the original feed.<br />
<br />
FLA source file (requires Flash MX or later): [http://files.chumby.com/widgetexamples/recentwidgets.fla recentwidgets.fla]<br />
<br />
Other examples: [[Sample Clock Widget]]</div>24.30.157.165//wiki.chumby.com/index.php?title=Sample_RSS_WidgetSample RSS Widget2006-11-02T17:11:02Z<p>24.30.157.165: </p>
<hr />
<div>http://files.chumby.com/widgetexamples/recentwidgets_ss.jpg<br />
<br />
This example file shows how to make a simple widget that displays an [http://en.wikipedia.org/wiki/RSS_%28file_format%29 RSS] feed.<br />
<br />
In this case, we're using [http://www.chumby.com/rss/recentwidgets Chumby: Recent Widgets] RSS feed that the [http://www.chumby.com chumby.com] website provides that lists the most recent 10 new or updated public widgets. The source file is heavily commented and can be used as a template for your own RSS-based widgets.<br />
<br />
One thing to keep in mind when you create an RSS-based widget is that the server that is providing the RSS *must* allow Flash access to that feed by using a "crossdomain.xml" file - you can read more about this at:<br />
* [http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14213 External data not accessible outside a Macromedia Flash movie's domain]<br />
* [http://www.adobe.com/devnet/flash/articles/fplayer_security.html Security Changes in Macromedia Flash Player 7]<br />
<br />
If you have a widget that seems to work fine standalone, but not from a real chumby or virtual chumby, that's very likely the cause - it will probably also fail if loaded into a web page. If you don't have access to the source of the feed to implement the proper access rights, then you can get around this by creating another server with the proper access rights that can proxy the original feed.<br />
<br />
FLA source file (requires Flash MX or later): [http://files.chumby.com/widgetexamples/recentwidgets.fla recentwidgets.fla]<br />
<br />
Other examples: [[Sample Clock Widget]]</div>24.30.157.165