Openmoko - User contributions [en]

Variometer

2008-10-08T17:12:50Z

Johan: /* Variometer */ - typo

{{wishlist}}
[[Category:Hardware_ideas]]

===Variometer===
The variometer signal is simply the derivative of the barometer signal. It gives a much more accurate vertical speed signal than is possible with GPS.This kind of measurement is used by the free flying community (hanggliding, paragliding, ballooning). A device that allows teams of pilots to share position and speed (with accurate vertical speed) data would be lots of fun.
[http://en.wikipedia.org/wiki/Variometer Variometer Reference]

====Hardware====
It could be best to filter and differentiate the analog pressure signal and then digitize. Another possibility is to differentiate the height in software. A robust solution is to compute a linear regression of a sliding window of height samples. The height samples can be computed using integer arithmetic by a pressure->altitude lookup table followed by interpolation. Maybe it's even possible to add detail based on the accelerometers.

References to applicable transducers:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX4100 Freescale MPX4100 (was Motorola)] - needs 5V power supply, 11 x 11 x 6 mm
*[http://www.intersema.com/site/technical/ms5540.php Intersema MS5540B Altimeter/Barometer Module], 2.2 - 3.6V, 3-wire serial interface, 6.2 x 6.4 mm
*[http://www.bosch-sensortec.com/content/language1/html/3477.htm Bosch SMD500 digital pressure sensor: altimeter and barometer], 2.2 - 3.6V, I2C interface, 5 x 5 x 1.5 mm, included temperature sensor
*[http://www.vti.fi/en/products-solutions/products/pressure-sensors/scp1000-pressure-sensor/ VTI SCP1000 pressure sensor],2.4 - 3.3V, I2C or SPI interface, 6.1 mm dia x 1.7mm, included temperature sensor

====Hardware solution====
=====Signal Conditioning=====

The absolute pressure signal needs to be:
#Differentiated
#Filtered

*Operational amplifiers in the following configuration:

See the signal conditioning example in this [http://www.freescale.com/files/sensors/doc/app_note/AN1326.pdf Application Note]<br \>
It might be best to use a single chip solution if we can find the right fit e.g.: [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4590 Max1464]

The software solution can simply be done in the variometer application with some very simple math.

=====A/D=====
We would need two A/D channels:
#Absolute Pressure - 12 bit minimum (assuming a operating range of 0 - 12000 meter 12 bits would give resolution of 2.9304 m)
#Differential Pressure - 10 bit minimum (assuming a range of +-20m/s 10 bits would give a resolution of 0.0391 m/s)

[http://www.freescale.com/files/sensors/doc/app_note/AN1100.pdf Extending 8 bit sampling to a usable range for pressure sensing]

====Driver Code====
The driver code samples the input channels and converts the input values from pressure to altitude:

The relationship between static pressure and pressure altitude is defined in terms of the properties of the International Standard Atmosphere. Up to 36,090 ft this can be expressed as:

<math>
z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122}
</math>

Where:

*z = pressure altitude (meter)
*<math>P_{ind}</math> = static pressure (kPa)

These values are provided to listeners in multiple applications.
The sample rate should be application adjustable to conserve power.

====Application code====
Applications can use the altitude data or combine the data with GPS and accelerometer data.
Commonly Kalman filter/observer techniques are used to combine data from multiple sensor types into a robust(with respect to sensor noise), high accuracy estimate of position and speed in 3 axis.

'''References:'''
*[http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html The Kalman Filter: Navigation's Integration Workhorse]
*[http://www.cs.unc.edu/~welch/kalman/ Kalman Filter Portal from the University of North Carolina at Chapel Hill]
*[http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter article on Wikipedia]

=====Variometer Code=====
Combine measurements as described above.
Apply knowledge about the aircraft dynamics to increase accuracy:
*Total Energy compensation
*Relative Netto Compensation - use accelerometer data to sense when glider is turning in a thermal

'''User Interface'''

*Display speed data in ergonomic manner.
*Display speed for pilots in group.
*Visual and audible guidance to pilot with best climb rate (given reasonable proximity)
*Possible integration with mapping application

====Server Based Services====
Auto discovery service
*Pilots with Openmoko based variometers can choose to publish their status on a central service.
*Based on location - the system will notify pilots of the presence of others that can participate in group flying.

====Freerunner====
Maybe it is possible to do that on the Freerunner ?

Connection :

*SPI or I2C (or through the debug board connector ?)
*HID device (ex: Oak USB Sensor Atmospheric Pressure [toradex.ch])

Getting Started with your Neo FreeRunner

2008-06-23T23:44:45Z

Johan: typo fix

{{Languages|Getting Started with your Neo FreeRunner}}
__NOTOC__
__NOEDITSECTION__

{| class="wikitable" cellspacing="2" cellpadding="2" style="padding: 0%; margin:0em 0em 1em 0em; border:1px solid #cccccc; background:#eeeeee; width:100%;floating="center"; "
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:75% " |
<div align="left">
Thank you for purchasing this Developer release of Neo FreeRunner. The [[Neo FreeRunner]] phone is the second hardware platform to take advantage of Openmoko. This guide will help you know your Neo FreeRunner and how to starte use your Neo FreeRunner.
! style="background:#fcfcfc;border-left:1px solid #9999cc;border-right:1px ; border-top:2px solid 75d806; border:1px solid #222222; width:25% " |
[[Image:Freerunner box.png|200px|thumb|Neo FreeRunner Package]]
|}

=Contents =

: [[Image:Circle２.gif|10px]] What Is In The Box

: [[Image:Circle２.gif|10px]] Getting To Know Neo FreeRunner

: [[Image:Circle２.gif|10px]] Turning On Neo FreeRunner

: [[Image:Circle２.gif|10px]] Flashing Neo FreeRunner

: [[Image:Circle２.gif|10px]] Connect To Neo FreeRunner By USB Networking.

== What Is In The Box==

{| class="wikitable" cellspacing="2" cellpadding="2" style="padding: 0%; margin:0em 0em 1em 0em; border:1px solid #ffffff; background:#ffffff; width:80%; floating="center"; "
! style="background:#ffffff;border-left:1px solid #ffffff;border-right:1px ; border-top:2px solid ffffff; border:1px solid #ffffff; " |
<div align="left">
[[Image:GTA02ALL.png|400px|thumb|Inside package]]
|

: [[Image:Circle２.gif|10px]] Neo FreeRunner
: [[Image:Circle２.gif|10px]] Stylus
: [[Image:Circle２.gif|10px]] Battery
: [[Image:Circle２.gif|10px]] Charger
: [[Image:Circle２.gif|10px]] USB Cable
: [[Image:Circle２.gif|10px]] microSD Card 512MB
|}
</div>

==Getting To Know Neo FreeRunner==

<div align-center>
<table width="80%" style="clear: both; border: 1px solid #ffffff; border-collapse: collapse; padding: 0.2em; margin: 0; font-size: 100%; margin: 0 1px;">
<tr valign="top" style="background: #ffffff">
<td style="width: 25px; padding-left: 0.5em;">
</td>
<td style="width: 10px; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:menu8.jpg|370px|thumb|AUX Button and phone jack(From left to right)|center]]</td><td style="padding: 1px 1em 0; background: #ffffff;">
[[Image:menu9.jpg|365px|thumb|Power, USB and external GPS Antenna (From left to right)|center]]</td></tr></table>
</div>

<div align-center>
<table width="80%" style="clear: both; border: 1px solid #ffffff; border-collapse: collapse; padding: 0.2em; margin: 0; font-size: 100%; margin: 0 1px;">
<tr valign="top" style="background: #ffffff">
<td style="width: 50%; padding-left: 0.5em;">
</td>
<td style="width: 50%; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:menu12.jpg|233px|thumb|AUX Back side with battery|center]]</td><td style="padding: 1px 1em 0; background: #ffffff;">
[[Image:menu11.jpg|260px|thumb|Put the SIM card and SD card here|center]]</td></tr></table>
</div>

<div align-center>
<table width="80%" style="clear: both; border: 1px solid #ffffff; border-collapse: collapse; padding: 0.2em; margin: 0; font-size: 100%; margin: 0 1px;">
<tr valign="top" style="background: #ffffff">
<td style="width: 50%; padding-left: 0.5em;">
</td>
<td style="width: 50%; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:menu13.jpg|233px|thumb|open case from this side |center]]</td><td style="padding: 1px 1em 0; background: #ffffff;">
[[Image:menu14.jpg|250px|thumb|Opened|center]]</td></tr></table>
</div>

===Turning On Neo FreeRunner===

You can boot your Neo FreeRunner in following ways:

: [[Image:Circle２.gif|10px]] You can power up into an Openmoko image directly.

: [[Image:Circle２.gif|10px]] Boot into [[Bootloader|U-Boot]] via [[NAND Flash]].

: [[Image:Circle２.gif|10px]] Boot into U-Boot via NOR Flash.

These ways allows you to update the kernel and root filesystem.

====Log in Openmoko Image====

<div align-center>
<table width="100%" style="clear: both; border: 1px solid #ffffff; border-collapse: collapse; padding: 0.2em; margin: 0; font-size: 100%; margin: 0 1px;">
<tr valign="top" style="background: #ffffff">
<td style="width: 25px; padding-left: 0.5em;">

</td>
<td style="width: 10px; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:Menu2.jpg|200px|right|thumb]]</td><td style="padding: 1px 1em 0; background: #eeeeee;">
Press and hold Power button (about 8 seconds) until Openmoko splash screen turns up. You may now release the Power button, and Neo FreeRunner will continue to boot into Openmoko Image.

</td></tr></table>
</div>

====Log in U-Boot in NAND Flash====

<div align-center>
<table width="100%" style="clear: both; border: 1px solid #ffffff; border-collapse: collapse; padding: 0.2em; margin: 0; font-size: 100%; margin: 0 1px;">
<tr valign="top" style="background: #ffffff">
<td style="width: 25px; padding-left: 0.5em;">

</td>
<td style="width: 10px; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:Menu7.jpg|200px|right|thumb]]</td><td style="padding: 1px 1em 0; background: #eeeeee;">
Press and hold Power button, then press and hold AUX button (about 5~8 seconds ). You can see BOOT MENU for NAND Flash. Press AUX to select the options, Power to execute.
</td></tr></table>
</div>
====Log in U-Boot in NOR Flash====

<div align-center>
<table width="100%" style="clear: both; border: 1px solid #ffffff; border-collapse: collapse; padding: 0.2em; margin: 0; font-size: 100%; margin: 0 1px;">
<tr valign="top" style="background: #ffffff">
<td style="width: 25px; padding-left: 0.5em;">

</td>
<td style="width: 10px; white-space: nowrap; padding: 4px 1em 0 0.5em; border-right: 1px solid #ffffff;">[[Image:Menu6.jpg|200px|right|thumb]]</td><td style="padding: 1px 1em 0; background: #eeeeee;">

Press and hold AUX button, then press and hold Power button. Release AUX button. You can see BOOT MENU for NOR Flash. ( This options usually used for developer. If you can't log in NAND , you can log in U-Boot in NOR Flash. )
</td></tr></table>
</div>

{{note| There are six options you can choose when you log in NOR Flash.
1. Boot

2. [[Boot from sd card|Boot from MicroSD]]

3. Set console to USB

4. Set console to Serial

5. Reset

6. Power off

}}

==Flashing Neo FreeRunner==
As Openmoko development continues, Openmoko regularly releases updated versions of the Openmoko root filesystem, the kernel, and the[[Bootloader| U-Boot]]. These may be programmed into the Flash memory of Neo FreeRunner. You can use the USB cable and Openmoko provided tool to flash Neo FreeRunner.

{{note|Openmoko software team build images daily. If you want to use the newest image, you can download image from daily build. But we recommend you download the most stable image from http://downloads.openmoko.org/releases/Freerunner/. Images here has been tested by test team.}}

===Step1. Download DFU-until===

You can download the flashing tool from:
http://downloads.openmoko.org/releases/Freerunner/dfu-util

On the GNU/Linux host, you you can use folloing command download U-Boot utility.
wget http://downloads.openmoko.org/releases/Freerunner/dfu-util

===Step 2. Flashing Kernel===

You can download kernel from
http://downloads.openmoko.org/releases/Freerunner/

Type in the following command in the terminal of a GNU/Linux host.
./dfu-util -a (partion name) -R -D (download image file name)

ex:

./dfu-util -a kernel -R -D uImage-2.6.24+svnr4082-r4055-r3-neo1973.bin

{| class="wikitable" cellspacing="2" cellpadding="2" style="padding: 0%; margin:0em 0em 1em 0em; border:0px solid #ffffff; background:#ffffff; width:100%;floating="center"; "
! style="background:#ffffff;border-left:1px solid #ffffff;border-right:1px ; border-top:2px solid ffffff; border:1px solid #ffffff; width:75% " |
<div align="left">
[[Image:menu15.jpg|thumb|Log in Neo FressRunner in NOR Flash, connect your Neo with Linux Host via USB cable]]
Before you execute the command , please log in Neo FreeRunner in NOR Flash . Neo FreeRunner needs to boot into U-Boot when flashing.

Then connect your Neo with Linux Host via USB cable. Press Enter execute the command.When flashing succeeds

status(0) = No error condition is present<br>
Done!
</div>
|}

{{note| The meaning of parameter you spcified:
-a --alt alt Specify the altsetting of the DFU interface by name or by number<br>
-R --reset Issue USB Reset signalling once we're finished<br>
-D --download file Write firmware from<file> into device <br>
}}

===Step 3. Flashing Root Filesystem ===
You can download the root filesystem from :
http://downloads.openmoko.org/releases/Freerunner/

Type in the following command in the terminal of a GNU/Linux host.

./dfu-util -a rootfs -R -D openmoko-devel-image-fic-gta02.jffs2

When flashing succeeds

status(0) = No error condition is present<br>
Done!

==Connect To Neo FreeRunner By USB Networking==

Connect Neo FreeRunner to Linux host with USB cable. After booting into Openmoko image, there will be a new interface, usb0, in your Linux host.

=====Manual Method=====
Type in the following command in the terminal of a GNU/Linux host.

ifconfig usb0 192.168.0.200 netmask 255.255.255.0
ssh root@192.168.0.202

Press Enter to pass the password.

=====Automatic Method=====
*Debian and derivatives (Ubuntu, Sidux etc.)
Edit /etc/network/interfaces

auto usb0
iface usb0 inet static
address 192.168.0.200
netmask 255.255.255.0

Restart the networking service and type in the following command in the terminal of GNU/Linux host.

ssh root@192.168.0.202

Press Enter to pass the password.

=====Making things even more automatic=====
If you don't want to remember the IP number of your phone you can create an alias by adding the following line to your /etc/hosts:

192.168.0.202 openmoko

Now it should immediately be possible to connect your phone using the following command line:

ssh root@openmoko

====Appendex====
If you want to know more about FreeRunner, you can get more information in following topics:
* [[GTA02 Openness]]
* [[Neo FreeRunner]]
* [[Neo FreeRunner GTA02 Hardware]]
* [[FreeRunner/Buttons and LEDs]]

[[Category:Software]]
[[Category:Documentation]]

Wishlist/Speech synthesis

2007-08-29T20:57:43Z

Johan: /* Idea */

{{Wishlist}}
=Idea=

Openmoko would benefit from a built-in speech synthesis library.
*[http://espeak.sourceforge.net/ eSpeak] looks like a good candidate, and is around 700k (is this big for speech synthesis libs?)
*[http://www.cstr.ed.ac.uk/projects/festival/ Festival] is Open Source and sounds OK - it is the code behind weather radio in the US.

=Uses=

* Speak the caller's name while playing the ringtone. The advantage of knowing who's calling without having to set up custom tones for each phone book entry. This works really well on modern Nokias.
* Auto read sms messages when using a headset (ie when driving)
* [[Wishlist:Human screening|Human screening]], [[Answering Machine]], or a generic audio menu used by those applications.
* Paste text into phone call.

=See Also=
* [[Wishlist:Human screening]]
* [[Answering Machine]]
* [[Wishlist-ANARM]]

[[Category:Ideas]]

Wishlist/BuiltInScriptingLanguage

2007-08-21T18:22:56Z

Johan: /* Lua */

{{Wishlist}}
Many different scripting languages will be optionally available in the repository.
However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

All core applications and scripting languages must fit into the internal memory, along with some space for user data.

Otherwise it is very difficult for the user to swap the SD.

== Feature matrix ==
Since there are a lot of options, the main features of the candidates should be collected in a matrix.
Fill in and add to this if possible.
{| class="wikitable" style="background:#efefef;" cellspacing="0" cellpadding="3" border="1"
! align="center" |'''Language'''
! align="center" |'''Current Status'''
! align="center" |'''Disk Footprint'''
! align="center" |'''Memory Footprint'''
! align="center" |'''Compilable'''
! align="center" |'''Scriptable'''
|-style="background: #DDFFDD;"
! align="center" |Java
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT / gcj
|align="center" |?
|-
!align="center" |Python
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT(Psyco) / Pyrex
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |C#/mono
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT
|align="center" |N
|-
!align="center" |Perl
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|-style="background: #DDFFDD;"
!align="center" |Haskell
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |Y
|align="center" |Y
|-
!align="center" |LUA
|align="center" |Mature/Active
|align="center" |Light
|align="center" |Light
|align="center" |JIT(Lua-JIT)
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |Ruby
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil. A good intro is this [http://www.linuxjournal.com/article/9605 recent LJ article]
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn. Reference the [http://www.lua.org/pil/ online book].
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page. Specifically the [http://luaforge.net/projects/lua-gtk/ Lua-gtk project]
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using '''[http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]'''/[http://pyinline.sourceforge.net/ PyInline]/Boost/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# [http://opensource.nokia.com/projects/pythonfors60/ Example implementation] for Symbian. The runtime environment is under 1mb, with a footprint of about 150kb. It works very well on my nokia 6680.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].
# Jython would make it almost 'free', but it's slower and [http://www.jython.org/docs/differences.html not identical] to CPython.

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Wishlist/BuiltInScriptingLanguage

2007-08-21T18:12:16Z

Johan: /* Lua */ - referenced LJ article on LUA

{{Wishlist}}
Many different scripting languages will be optionally available in the repository.
However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

All core applications and scripting languages must fit into the internal memory, along with some space for user data.

Otherwise it is very difficult for the user to swap the SD.

== Feature matrix ==
Since there are a lot of options, the main features of the candidates should be collected in a matrix.
Fill in and add to this if possible.
{| class="wikitable" style="background:#efefef;" cellspacing="0" cellpadding="3" border="1"
! align="center" |'''Language'''
! align="center" |'''Current Status'''
! align="center" |'''Disk Footprint'''
! align="center" |'''Memory Footprint'''
! align="center" |'''Compilable'''
! align="center" |'''Scriptable'''
|-style="background: #DDFFDD;"
! align="center" |Java
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT / gcj
|align="center" |?
|-
!align="center" |Python
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT(Psyco) / Pyrex
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |C#/mono
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT
|align="center" |N
|-
!align="center" |Perl
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|-style="background: #DDFFDD;"
!align="center" |Haskell
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |Y
|align="center" |Y
|-
!align="center" |LUA
|align="center" |Mature/Active
|align="center" |Light
|align="center" |Light
|align="center" |JIT(Lua-JIT)
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |Ruby
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil. A good intro is this [http://www.linuxjournal.com/article/9605 recent LJ article]
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn. Reference the [http://www.lua.org/pil/ online book].
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using '''[http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]'''/[http://pyinline.sourceforge.net/ PyInline]/Boost/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# [http://opensource.nokia.com/projects/pythonfors60/ Example implementation] for Symbian. The runtime environment is under 1mb, with a footprint of about 150kb. It works very well on my nokia 6680.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].
# Jython would make it almost 'free', but it's slower and [http://www.jython.org/docs/differences.html not identical] to CPython.

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Wishlist/BuiltInScriptingLanguage

2007-08-21T18:05:55Z

Johan: /* Feature matrix */

{{Wishlist}}
Many different scripting languages will be optionally available in the repository.
However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

All core applications and scripting languages must fit into the internal memory, along with some space for user data.

Otherwise it is very difficult for the user to swap the SD.

== Feature matrix ==
Since there are a lot of options, the main features of the candidates should be collected in a matrix.
Fill in and add to this if possible.
{| class="wikitable" style="background:#efefef;" cellspacing="0" cellpadding="3" border="1"
! align="center" |'''Language'''
! align="center" |'''Current Status'''
! align="center" |'''Disk Footprint'''
! align="center" |'''Memory Footprint'''
! align="center" |'''Compilable'''
! align="center" |'''Scriptable'''
|-style="background: #DDFFDD;"
! align="center" |Java
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT / gcj
|align="center" |?
|-
!align="center" |Python
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT(Psyco) / Pyrex
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |C#/mono
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT
|align="center" |N
|-
!align="center" |Perl
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|-style="background: #DDFFDD;"
!align="center" |Haskell
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |Y
|align="center" |Y
|-
!align="center" |LUA
|align="center" |Mature/Active
|align="center" |Light
|align="center" |Light
|align="center" |JIT(Lua-JIT)
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |Ruby
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn. Reference the [http://www.lua.org/pil/ online book].
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using '''[http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]'''/[http://pyinline.sourceforge.net/ PyInline]/Boost/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# [http://opensource.nokia.com/projects/pythonfors60/ Example implementation] for Symbian. The runtime environment is under 1mb, with a footprint of about 150kb. It works very well on my nokia 6680.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].
# Jython would make it almost 'free', but it's slower and [http://www.jython.org/docs/differences.html not identical] to CPython.

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Screen Shots

2007-08-21T14:54:54Z

Johan: /* From a Remote Connected Desktop */

[[Category:Guides]]

__TOC__

= OpenMoko 2007.2 update =
Press and hold power button, choose Screenshot from menu :)

=Screen Grab, Screen Snapshot=
useful for filing bugs etc:

'''Note on Screen orientation''':

'''xrandr -o 1''' turns screen to landscape mode (xrandr -o 0 to go back to ordinary portrait):
<pre>xrandr -o 0 # default </pre>
<pre>xrandr -o 1 # landscape - from right side </pre>
<pre>xrandr -o 2 # upside down </pre>
<pre>xrandr -o 3 # landscape - from left side </pre>

==Locally from the device==

You can grab screen shots manually by using the following command on your Neo:

# cat /dev/fb0 >myscreenshot_001.raw

You can then convert this on your pc with fb2png by using the following command:

# fb2png myscreenshot_001.raw myscreenshot_001.png 9 480 640 16

You can also push a screen capture back onto the display:

# cat myscreenshot_001.raw >/dev/fb0

If you want to show a sequence of screens in an animation you can use convert. Once you have all your screen shots as .pngs try:

# convert -delay 25 -dispose Background +page myscreenshot_*.png -loop 0 animated_test.gif

The command

# fbgrab filename.png

directly creates a PNG on the Neo.

==From a Remote Connected Desktop==

On the device: <pre>xhost 192.168.0.200</pre> Where 192.168.0.200 is the IP of your desktop.

On the desktop: <pre>xwd -root -display 192.168.0.202:0 > dump.xwd</pre> Where 192.168.0.202 is the device IP.

The xwd file can be read by the Gimp:

[[Image:ScreenShotExample.png|left|Example Screenshot]]
<br style="clear:both" />

Screen Shots

2007-08-20T22:25:02Z

Johan: local screen shot

[[Category:Guides]]

__TOC__

=Screen Grab, Screen Snapshot=
useful for filing bugs etc:

'''Note on Screen orientation''':

'''xrandr -o 1''' turns screen to landscape mode (xrandr -o 0 to go back to ordinary portrait):
<pre>xrandr -o 0 # default </pre>
<pre>xrandr -o 1 # landscape - from right side </pre>
<pre>xrandr -o 2 # upside down </pre>
<pre>xrandr -o 3 # landscape - from left side </pre>

==Locally from the device==

You can grab screen shots manually by using the following command on your Neo:

# cat /dev/fb0 >myscreenshot_001.raw

You can then convert this on your pc with fb2png by using the following command:

# fb2png myscreenshot_001.raw myscreenshot_001.png 9 480 640 16

You can also push a screen capture back onto the display:

# cat myscreenshot_001.raw >/dev/fb0

If you want to show a sequence of screens in an animation you can use convert. Once you have all your screen shots as .pngs try:

# convert -delay 25 -dispose Background +page myscreenshot_*.png -loop 0 animated_test.gif

==From a Remote Connected Desktop==

:On the device: <pre>xhost 192.168.0.200</pre> Where 192.168.0.200 is the IP of your desktop.

:On the desktop: <pre>xwd -root -display 192.168.0.202:0 > dump.xwd</pre> Where 192.168.0.202 is the device IP.

:The xwd file can be read by the Gimp:

[[Image:ScreenShotExample.png|left|Example Screenshot]]
<br style="clear:both" />

Screen Shots

2007-08-20T14:56:02Z

Johan:

User talk:PTT

2007-08-16T16:19:32Z

Johan: /* Vario */

== Vario ==

Hi PTT - I like your contributions to the [[Variometer]] page. I did not know about those nifty digital output pressure transducers.
I am a little concerned about differentiating the digital signal in software - don't think it would make a good vario.
I guess we have to build it and test.<br />
[[User:Johan|Johan]] 16:44, 15 August 2007 (CEST)
:The variometer resolution from flytek variometers is 0.1 m/s, the SMD500 has a resolution of 0.25 m, which would make 0.25 m/s at 1 measurement per second, if averaged over a few seconds this could be increased. Also it may be possible to take measurements at a higher rate, since one measurement takes 34 ms from what I understand from the specs. I bet building and testing is the best way to find out, it wouldn't be that hard with only one chip to be added. [[User:PTT|PTT]] 21:05, 15 August 2007 (CEST)
I have a Flytec 4020 - I just played with it a bit. It registers vertical speed when you move it 10cm up or down - amazing. That means they must differentiate the analog signal or use very high resolution for the pressure signal. I do not think we want to replace our variometers with Openmoko devices - just have a device to share data within a group of pilots. You are right - we should probably start with a one chip solution and see how good we can get it. [[User:Johan|Johan]] 18:19, 16 August 2007 (CEST)

User talk:PTT

2007-08-15T14:44:07Z

Johan: Vario

Wishlist/BuiltInScriptingLanguage

2007-08-12T03:54:30Z

Johan: /* Feature matrix */ - make pretty

{{Wishlist}}
Many different scripting languages will be optionally available in the repository.
However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

All core applications and scripting languages must fit into the internal memory, along with some space for user data.

Otherwise it is very difficult for the user to swap the SD.

== Feature matrix ==
Since there are a lot of options, the main features of the candidates should be collected in a matrix.
Fill in and add to this if possible.
{| class="wikitable" style="background:#efefef;" cellspacing="0" cellpadding="3" border="1"
! align="center" |'''Language'''
! align="center" |'''Current Status'''
! align="center" |'''Disk Footprint'''
! align="center" |'''Memory Footprint'''
! align="center" |'''Compilable'''
! align="center" |'''Scriptable'''
|-style="background: #DDFFDD;"
! align="center" |Java
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT
|align="center" |?
|-
!align="center" |Python
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT(Psyco)
|align="center" |Y
|-style="background: #DDFFDD;"
!align="center" |C#/mono
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |JIT
|align="center" |N
|-
!align="center" |Perl
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |?
|-style="background: #DDFFDD;"
!align="center" |Haskell
|align="center" |?
|align="center" |?
|align="center" |?
|align="center" |Y
|align="center" |?
|-
!align="center" |LUA
|align="center" |?
|align="center" |Light
|align="center" |Light
|align="center" |JIT(Lua-JIT)
|align="center" |Y
|}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn. Reference the [http://www.lua.org/pil/ online book].
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using [http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG]/Boost, taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].
# Jython would make it almost 'free', but it's slower and [http://www.jython.org/docs/differences.html not identical] to CPython.

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Neo1973 Robustness

2007-08-06T20:27:51Z

Johan: out of the box

This is a list of stuff you've done to your neo.

{|border="1"
|+Drops
!User||Height fell || Horizontal velocity || Surface it hit || Damage?
|-
|Speedevil||1m||0||carpet||none
|-
|rwhitby||1.3m||0||pavement||none
|-
|Johan||1.2m||0||tiled floor || none
|}

Screen Shots

2007-08-05T18:46:22Z

Johan: typo

Talk:Supported microSD cards

2007-08-04T20:27:37Z

Johan:

Let it be known that 4Gb microSDHC cards have been announced by more than one company. Apparently these will not be supported by default in microSD devices. Does anyone know if the Neo will support these in theory? [[User:Wasp|Wasp]] 00:06, 16 February 2007 (CET)

: Also 8GB MicroSD cards have now been announced. Would be really nice to know if it's just a driver issue or something more.

== How to test ==

Can we please define repeatable tests?
atm I just copy stuff there and back - there is probably more to it.
Tested the Sandisk 512 and 1024 cards [[User:Johan|Johan]] 22:27, 4 August 2007 (CEST)

Talk:Supported microSD cards

2007-08-04T19:45:51Z

Johan: How to test

Screen Shots

2007-08-04T19:22:56Z

Johan:

Screen Shots

2007-08-04T19:21:58Z

Johan: /* Screen Grab, Screen Snapshot */

Screen Shots

2007-08-04T19:15:09Z

Johan:

[[Category:Guides]]

=Screen Grab, Screen Snapshot=
useful for filing bugs etc:
==From a Remote Connected Desktop==

[[Image:ScreenShotExample.png|left|Example Screenshot]]
:On the device: <pre>xhost 192.168.0.200</pre> Where 192.168.0.200 is the IP of your desktop.

:On the desktop: <pre>xwd -root -display 192.168.0.202:0 > dump.xwd</pre> Where 192.168.0.202 is the device IP.

:The xwd file can be read by the Gimp:

<br style="clear:both" />

'''Note on Screen orientation''':

'''xrandr -o 1''' turns screen to landscape mode (xrandr -o 0 to go back to ordinary portrait):

*xrandr -o 0 - defalt
*xrandr -o 1 - landscape - from right side
*xrandr -o 2 - upside down
*xrandr -o 3 - landscape - from left side

Screen Shots

2007-08-04T18:17:33Z

Johan: /* From a Remote Connected Desktop */

File:ScreenShotExample.png

2007-08-04T18:12:55Z

Johan: category:Images Guides

[[category:Images Guides]]

Screen Shots

2007-08-04T18:12:15Z

Johan:

[[Category:Guides]]

=Screen Grab, Screen Snapshot=
useful for filing bugs etc:
==From a Remote Connected Desktop==

On the device: <pre>xhost 192.168.0.200</pre> Where 192.168.0.200 is the IP of your desktop.

On the desktop: <pre>xwd -root -display 192.168.0.202:0 > dump.xwd</pre> Where 192.168.0.202 is the device IP.

The xwd file can be read by the Gimp:

[[Image:ScreenShotExample.png|thumb|left|400px|Example Screenshot]]

Screen Shots

2007-08-04T18:08:32Z

Johan:

Screen Shots

2007-08-04T18:07:39Z

Johan: quick howto screen snapshot - from the mailing list

Wiki Issues

2007-08-04T17:37:16Z

Johan: /* Wiki Mods */

==Wiki Pages==
===Pages capable of development===
* [[OpenMoko:Community Portal]]
* [[Documentation]]

===Redundant Pages===
* There are several pages concerning OpenMoko compatible service providers:
** [[Carriers]], most up-to-date, confirmed service providers.
*** [[Carriers/ATT]]
*** [[Carriers/TMobile]]
*** [[Carriers/Fido]]
*** [[Carriers/Rogers]]
** [[OpenMoko compatible cellphone providers]]
** [[Neo1973 compatible cellphone providers]]

* There are several pages concerning the Neo-iPhone comparison:
** [[IPhone]]
** [[IPhone (GTA01)]]

* <s>There are two pages concerning events</s> '''DONE'''
** [[Current events]]
** <s>[[Community Events]]</s>
** [[Community Events/it]]

===Tidy up===
* [[Wishlist:Text Input]] - tidy up/sort, give short feedback to each method

==Wiki Mods==
Can we please install/fix the following features for this wiki:
* '''Math''' - the Tex math markup does not work currently. Test:
** <math> z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122} </math>
** <math> P_{ind} </math>
* Sortable tables do not work [http://meta.wikimedia.org/wiki/Help:Sorting http://meta.wikimedia.org/wiki/Help:Sorting]
* [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi '''Syntax''' Highlighting - makes code much more readable]
* [http://www.mediawiki.org/wiki/Extension:GraphViz GraphViz] works with the commonly known dot language - it allows us to draw '''graphs''' using easy markup.
* [http://www.mediawiki.org/wiki/Extension:AnyWikiDraw AnyWikiDraw] allows us to draw svg '''diagrams''' directly on the wiki page.

==Wiki languages==
Translating ''this'' wiki into other languages does not make much sense:
* All translated pages need to be kept up-to-date. The people translating will not see every change made.
* A partly (and often quite badly) done translation is no good.
* People who use this wiki are sophisticated users, they are very likely to know English. They will not use localised pages as they do not trust them in matters of being up-to-date.
* Rather create another wiki/information page with more static information for regular mass-market purchaser that do not care about 20 ways to connect their OpenMoko device with their PC but just about one easy one.
--[[User:Minime|Minime]] 13:43, 3 August 2007 (CEST)

[[Category:Help]]

USB Networking

2007-08-04T05:18:52Z

Johan: usb networking /* Automatic method */

= Neo1973 side =

By default Neo1973 has usb0 interface working due to Ethernet gadget (g_ether) compiled into kernel.

= Desktop side =

== Manual method ==

Modprobe usbnet module and configure usb0 interface (as root):
<pre>
ifconfig usb0 192.168.0.200 netmask 255.255.255.0
</pre>
If your eth0 interface is also in the same 'range' (e.g. 192.168.0.105) then you can do the following:

1. ping the Neo with
# ping -I usb0 192.168.0.202
2. add a route to your Neo:
# /sbin/route add -host 192.168.0.202/32 dev usb0
3 log in to the Neo
# ssh root@192.168.0.202

== Automatic method ==

Took from [http://www.hrw.one.pl/2007/03/22/hotpluging-usbnet/ Hotplugging usbnet] post by Marcin 'Hrw' Juszkiewicz.

'''For Debian or similar distros:'''
Edit /etc/network/interfaces file ():
<pre>
allow-hotplug usb0
iface usb0 inet static
address 192.168.0.200
netmask 255.255.255.0
network 192.168.0.0
post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -P FORWARD ACCEPT
</pre>

'''For Red Hat or similar distros'''
Edit /etc/sysconfig/network-scripts/net.hotplug:

After this statement:
<pre>
case $INTERFACE in
# interfaces that are registered after being "up" (?)
</pre>

Add the following:
<pre>
usb0)
ifconfig usb0 192.168.0.200 netmask 255.255.255.0
route add 192.168.0.202 usb0
iptables -I INPUT 1 -s 192.168.0.202 -j ACCEPT
iptables -I OUTPUT 1 -s 192.168.0.200 -j ACCEPT
exit 0
;;
</pre>

And now when you connect phone (which has 192.168.0.202 IP) it gets connection to world automatically.

= Connecting to phone =

Then <tt>ssh root@192.168.0.202</tt> with empty password to get into phone.

<span id="bottom"></span>
{{Languages|USB Networking}}

[[Category:Hardware]]
[[Category:Implemented]]

Wiki Issues

2007-08-02T19:04:21Z

Johan: report wiki problem with sortable tables

[[Category:Help]]
Can we please install/fix the following features for this wiki:
* '''Math''' - the Tex math markup does not work currently.
* Sortable tables do not work [http://meta.wikimedia.org/wiki/Help:Sorting http://meta.wikimedia.org/wiki/Help:Sorting]
* [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi '''Syntax''' Highlighting - makes code much more readable]
* [http://www.mediawiki.org/wiki/Extension:GraphViz GraphViz] works with the commonly known dot language - it allows us to draw '''graphs''' using easy markup.
* [http://www.mediawiki.org/wiki/Extension:AnyWikiDraw AnyWikiDraw] allows us to draw svg '''diagrams''' directly on the wiki page.

Talk:Artwork

2007-07-28T16:51:59Z

Johan: great stuff

this came up on #openmoko: [http://62.75.157.44/openmoko/] --[[User:Minime|Minime]] 18:05, 28 July 2007 (CEST)

== great stuff ==

well done - this looks great [[User:Johan|Johan]] 18:51, 28 July 2007 (CEST)

User talk:Speedevil

2007-07-27T18:15:08Z

Johan: nvm - i like the master wishlist

== Modular phone ==

Your attitude is hindering more than helping.

I appreciate the approach I am suggesting may not produce the same result as the Neo1973, or be appealing to everybody, but it is something I believe has merit - particularly the modularity aspect. Your comment 'it is larger and heavier', and arguments over the price differences of one component (particularly when the price is revealed in a few hours) are not much use, unless they are quantified - they come off as negative and add no real value.

I've already said I will produce size comparisons when specs are released and these are now included - these will eventually include weight.

If you have something useful to add, please do. If you do not find the project worthwhile and cannot make the effort to do some research to back up what you say, move along.

Perhaps you could work out the exact weight? Or the size? [[User:Myfanwy|myfanwy]] 14:00, 16 July 2007 (CEST)

<hr>
I misread the date that pricing is released - I simply have doubts that a module with all the features - including GPS - where GPS is stated as an additional to the goliath platform - is going to be under $100, given that all GSM modules even bare that are available globally are >$100.
I do not think it is unreasonable to point out flaws in a design that may cause problems with its implementation.
For example, you state in the page "From Sketchup models supplied by Gumstix, the size will be around 120 x 67 x 17mm. This is the smallest cuboid into which the components will fit. The case will add approx. 2mm to this - battery, screen, microSD and other components should fit into voids between the main circuit boards." which is clearly impossible in the case of the screen, as it has to go on top, and is approximately the same size as the goliath board.
Consider also that you don't mention that you've missed out sound. As I understand it, the sound connectors on the Goliath board are solely for the GSM unit.
I would not have commented on the $100 - if you'd have put in any cites at all for that price. But I did look on the community mailing list for gumstix, and found no indications at all. I did not of course read every message.

130*70*26mm (17mm for Goliath,2mm for case bottom, 1mm chassis between the LCD and motherboard, 4mm for screen, 2mm for case over screen) is considerably larger than the Neo. I don't think it's unfair to raise this. It would also not provide a usable phone unless you add some sort of text/number entry solution, again, this is reasonable to raise on a page which is titled "modular phone".
The weight of the display alone is 50g,

I will add cites and rational on the talk page for any future edits.
----
Hi! - <nowiki>[[Category:InProgress]]</nowiki> is not needed anymore, because the category [[:Category:In progress]] has now been made - and the [[:template:InProgress]] automatically inserts the
[[:Category:In progress]]. kind regards, --[[User:Glenn|Glenn]] 18:20, 26 July 2007 (CEST)

User talk:Speedevil

2007-07-27T17:49:19Z

Johan: Wishlist Labels

Wishlist - Hardware - Novel Devices

2007-07-26T20:00:40Z

Johan: /* HMD */

This page details hardware some would like in future OpenMoko devices that are very different from the [[Neo1973]]. DVD/media players, cameras, ...

=== Hard Drive ===
Providing a hard drive, will allow storing music, movies, etc. Add USB storage device capability to use the device as an external hard drive.

=== OpenMoko-branded modem card ===

A 3G modem card for use with other computing hardware, in particular PCs. Probably an internal expansion card such as an ExpressCard or Compact Flash card, with an alternative external (USB) unit for computers without internal slots. (In fact, a PCI-factor internal card for desktop computers might be reasonable too; see below.)

There are already CardBus and external USB 3G modems available. In hardware terms, OpenMoko's modem could well be a simple rebranding of one of these existing products. But, at least in some areas, the 3G modem products available to end-users tend to be tied to a particular telco and bundled with that telco's software. They also have a mysterious tendency not to actually allow voice calls over the modem, even when the modem hardware appears to be quite capable of it. An OpenMoko modem that simply provided open drivers, no lock to a particular telco, good support for various operating systems, and simple support for voice and video calls over the modem, all out of the box, would already have some fairly unique selling points. (Since video conferencing is now taking off on personal computers, hardware that allows your desktop computer to make video calls to 3G mobile phones might well have a market, which is one reason why a PCI-factor card might not be so crazy.)

But more than that, any software or services that OpenMoko develops to overcome the tricky problems of juggling and integrating different Internet and phone connections and different email, IM, VoIP and telephone-number identities on Internet-enabled phones would be available to users of the OpenMoko modem too. That would be a powerful selling point for the modem if and when OpenMoko has compelling solutions to these problems. In fact, the increased integration with PCs would make all OpenMoko devices more attractive. ("Whenever I'm logged in to my laptop all my calls go there, even when I'm not in range of WiFi.")

Since [[FIC]] already has well-established relationships in the PC world, it could presumably make good use of those connections in selling the modems.

* Obviously the OpenMoko modem faces much the same problems with getting reasonably open access to 3G hardware that are delaying 3G for the [[Neo1973]] series

* Naturally a 3G Neo1973 or other OpenMoko phone would (or should) be able to provide many of the same advantages when acting as a modem for a PC. But there will still be a place for dedicated modems, if only because yoking a full mobile phone to your computer isn't always the best solution

* Just like full phones, modems would benefit from support for multiple SIMs (see [[Wish_List_-_Hardware#Ability_to_use_multiple_SIMs.2Fnetworks]]) if they're going to be used for (non-VoIP) voice

* Bonus points if the hardware provides a POTS landline connection and the software can juggle it along with 3G and Internet connections...

=== PCMCIA slot ===
Extensibility would be nice. Standard pcmcia would be great for allowing wireless too. And pcmcia cards tend to be very low power.
*1. can be used for a spare battery (is this possible?)
*3. i can use my [http://www.echoaudio.com/Products/CardBus/IndigoIO/index.php Echo Audio Indigo I/O]
*2. can be used for different cards around

This is certain not to happen in a production phone, it's simply far too large, and requires complex support in hardware, which does not exist in most system on a chip devices as are used in phones.
Even for the [[Expansion_Back]] it would be too large. --[[User:Speedevil|Speedevil]] 06:05, 28 February 2007 (CET)

== Cameras & Imaging ==
=== Interchangeable Camera Lenses ===
A camera phone with a [http://en.wikipedia.org/wiki/Lens_mount lens mount] would allow swappable camera lenses and filters. Camera phones are usually stuck with tiny fixed lenses that don't allow focusing. Imaging being able to swap out the default lens with one that provides a better focus... or even a zoom!

The C-Mount or [http://en.wikipedia.org/wiki/T-mount T-Mount] would be a good choice. Both are standard lens mount with many supporting lenses. Minolta, Canon, Nikon, Olympus, & most other lens manufacturers also have [http://www.bhphotovideo.com/c/shop/300/Lens_Adapters_Mounts.html mount adapters] for their proprietary lenses. Then share lenses between your camera & cell phone. The mount hole would need to be about 1 inch in diameter and go about 1/4 inch into the camera-phone (with the focal plane array chip at the bottom of this hole).

'''Added bonus If you work somewhere that doesn't allow cameras:'''
The lens could be removed and a blank insert could be screwed in.
The camera capability would be physically disabled!

=== Business Card Reader ===
This is probably technically difficult if not impossible, maybe you could do it with the embedded camera hardware & software

I want to be able to place a business card face down on the the screen, and have the device automatically read the card and enter the info in the contacts.
* There is no simple way of reading something placed on the screen, for the basic reason that the screen is in the way.
* Of course you could always just take a picture of the card with a camera-phone. Then store it as it is or image recognition software could do character recognition & extract the information.

=== Solar Panels ===
My old pocket calculator had solar panels, why not my phone?
See also: [[Expansion_Back#Ideas which require slight modifications of the phone.]]

=== Fuel Cell ===
Some people want to put them in laptops & fuel cells are the way of the future.
===Cork Screw===
Every multi-tool has to have a cork screw

===TV Out===
With help of mouse and keyboard, a TV output may be very useful.
Or to watch photos taken with a digital camera on holidays.
Or for showing a slide presentation off.

=== Larger Screen ===

A model with a larger screen would be of use to many, especially with multi-touch. Higher resolution is probably less important than size until the DPI drops below 150 or so.

=== Tiny Video Projector - "Beamer" ===

At the [http://www.sid.org/conf/sid2007/sid2007.html DisplayWeek2007] several embeded video projectors for phones were presented.
Those projecting devices are not much bigger than a cell phone. A LED-laser projects a sharp image at variable distance
Could such a device be connected by bluetooth?
[http://www.explay.co.il/ Explay] uses two a red and a green laser-LED as well as a conventional blue LED in its "oio".
Blue laser-LED are to expensive for customer products. The light passes a transmissive WVGA-LCD(640x480) and goes on to the screen. Its frequency is 60Hz and the projecting distance can be varied from 20cm(8inch) to 2m(80inch) with a sharp picture. It consumes about 5W and its light power is about 6 lumen.
As the sharpness does not depend on distance, one can project the image on screens that are not plane. Like someones t-shirt.

[http://www.microvision.com/ Microvistions] PicoProjektor however uses soley laser-LEDs. It is also 60Hz though 800x600px or 800x640.

Potential problems might become the approval of a laser class 3 device.

Final prices could be about $300.
Taken from: http://www.heise.de/newsticker/meldung/90141 (german)

===HMD===
Possibility to use something like [http://www.aeinnovations.com/projects/ver0/ Eyeglass Mounted Display].

Or a HUD for use in a car windscreen. Needs a small projector attached to the phone. The phone is placed in front of the steering wheel on the console and displays information projected against the windscreen.

===Multi I/O adapter===
*VGA, standard Jack (line in & out), standard USB

===Credit Card Swiper/Reader===
*A credit card swipe function on the device, so that business operators can use the device to accept payments. In some markets a 'chip+pin' card reader may be an alternative. Existing devices are very expensive. Transaction information is sent over the internet, transaction "hub" services like 1stData could receive the data and reply with email receipts to the merchant, who could then forward the receipt to customer's email, or print a receipt on a bluetooth printer.

===Modular hardware design / interchangeable components===
It would be great to have several interchangeable components on the 'bus' of the device. Imagine opening the case and being able to add GPS to an empty internal bay or swap an Accelerometer for 3G support.
Similar to the PCI hardware model of desktop PCs -- let savvy users swap and upgrade internal components by intentionally designing swappable components on some standardized bus.

Unfortunately, this is a big problem for compact devices.
To take the above examples. An accelerometer module may be 5mm*5mm*2mm. a 3G module 50mm*30mm*10mm, a GSM module 30mm*40mm*5mm and a GPS module 20mm*15mm*5mm.
Apart from the wasted space problems, this means also that each module has to be custom-built for FIC.
Then there is a second part - you have to have connectors and some way to clamp the module in place.

This adds yet more weight and volume.
--[[User:Speedevil|Speedevil]] 12:03, 29 June 2007 (CEST)

==Unsorted==

== Different Shapes & Styles ==
The current shape is great and many people love it (and I myself plan on getting one). Still, different strokes for different folks & we're allowed to muse about other options.

===Dump the '''''egg-shaped''''' case design and go '''''rectangular''''' for more screen space===
*I'm all for devices that look great and have great features - aside from that I really like the current design. Thus I'd like to comment that the design change request is probably not the majority's opinion. [[User:Abraxa|Abraxa]] 00:00, 18 February 2007 (CET)

There will be many OpenMoko devices, of different designs. --[[User:Speedevil|Speedevil]] 06:19, 28 February 2007 (CET)

===Clamshell===
Nuff said

===Twisting top===
Perfect for a multi-directional camera phone (for easier self photos & video conferencing)<br />
[[Image:Kg920phone.jpg]]<br />

===Alcohol Sensor===
Alcohol sensor adjacent to microphone. It doesn't have to be accurate, just has to detect any amount of alcohol on the speaker's breath. I understand this is a very narrow market, but alcohol is on every parent's mind.

I think those who drive cars might profit from this feature too. --[[User:Cedel|cedel]] 16:02, 20 February 2007 (CET)

:Although this is a good idea, you have to be very careful about liability here. If it gives a false positive (i.e. you're not over the limit), and you have an accident, the OpenMoko team might be liable.

===Bottle opener===
* including a bottle opener is very hard, but could be useful.
* [http://www.bokonzept.de/php/images/462.jpg example]
* It definitely is useful. A metal reinforced corner might be enough. While it is possible to open bottles with most cell phones, they don't look too good after opening a few cases.

[[Category:Hardware ideas]]

Talk:Neo 1973 GTA01 Power Management

2007-07-26T05:42:23Z

Johan: 5V power supply question

The SPI connected LCM asic (JBT6K74-AS(PI)) doesn't do any kind of drawing. It mainly controls the power states and the format in which data is shifted out to the LCD (timing), but also includes gamma correction and there are two unexplained parts called "built-in oscillator" and "booster".

Built in oscillator and booster probably together provide the required voltages to supply the LCD, which will typically require at least one supply other than 3.3V.
--[[User:Speedevil|Speedevil]] 01:27, 26 July 2007 (CEST)
== 5V supply ==

I need a 5V supply for [http://www.freescale.com/files/sensors/doc/data_sheet/MPX4100A.pdf this] and [http://datasheets.maxim-ic.com/en/ds/MAX1464.pdf this] - total power draw should be 730 mW (max).<br/>
Some advice (best practice) would be appreciated on where to do this and how?<br/>
[[User:Johan|Johan]] 19:24, 25 July 2007 (CEST)
----
You've misread the maxim parts datasheet.

Maximum power is an absolute maximum rating, it's not a normal operating condition.

You have to really abuse it to get it to dissipate that much power - for example supplying lots of current into the input pins trying to take them beyond the supply rails.
The actual power draw is low single digit milliamps at 5V, maybe 25mW or so when active.

I would suggest that rather than the complex sensor conditioner, you simply use a 3.3V ADC.

----
OK - thats good news. We still need 5V for the transducer though don't we?

Wishlist/BuiltInScriptingLanguage

2007-07-25T21:13:51Z

Johan: /* Lua */ example implementation

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn. Reference the [http://www.lua.org/pil/ online book].
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# [http://www.freepoc.org/viewapp.php?id=32 Example Implementation] for Symbian.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using [http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Wishlist/BuiltInScriptingLanguage

2007-07-25T20:50:34Z

Johan: /* Lua */

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn. Reference the [http://www.lua.org/pil/ online book].
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using [http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Wishlist/BuiltInScriptingLanguage

2007-07-25T20:49:10Z

Johan: /* Lua */ - added a reference to the Lua bindings and libraries page

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn.
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2. Reference the [http://lua-users.org/wiki/LibrariesAndBindings Lua Libraries and Bindings] page.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# Well [http://www.lua.org/pil/ documented]

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# By using [http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]/[http://scipy.org/Weave Weave]/[http://www.swig.org/ SWIG], taxing algorithms can get C-like performance. Nice benchmarks [http://scipy.org/PerformancePython here].
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on one JVM and nullifies it's value in this list.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Wishlist/BuiltInScriptingLanguage

2007-07-25T19:16:30Z

Johan: /* Lua */ - added reference to the online book for Lua

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn.
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.
# Well [http://www.lua.org/pil/ documented]

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# [http://codespeak.net/pypy/dist/pypy/doc/news.html PyPy], [http://scipy.org/Weave Weave], [http://www.swig.org/ SWIG] could speed up taxing algorithms in certain programs. PyPy could also improve/replace Psycho.
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on the JVM.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Wishlist/BuiltInScriptingLanguage

2007-07-25T19:09:48Z

Johan: /* Lua */ - added a reference to the main Lua site

{{Wishlist}}

== Discussion ==

[http://lists.openmoko.org/pipermail/community/2007-January/001909.html There was a discussion on the mailing list about choosing a built-in scripting language.]

Many different scripting languages will be optionally available in the repository. However, developers who choose one of these languages for their applications will not be able to see their applications included in the standard ROM nor available for use by those without an external microSD card.

[http://lists.openmoko.org/pipermail/community/2007-January/001945.html As expressed by Corey]:

''It's true that you have the ability to add anything to the phone.''

''There's another important consideration to remember: OpenMoko is a platform also; an inherent aspect of such a platform is that it always come shipped with X standard api's available for developers. This is why FIC had to select a group of components: gcc, glibc, xorg/kdrive, dbus and gtk, for instance.''

''They may decide that a scripting language would also be a necessary or beneficial feature to include in the base/standard platform''

...

''Choice is good.''

''And so is having a known/standard/default/static api and platform to build from; when I begin writting commercial and/or free software for the OpenMoko, I will design my software according the existing OpenMoko specs, and thereby circumvent the necessity of having to verify that my customers/end users have first installed the necessary scripting language, which would additionally circumvent the probability that your phone will end up with every scripting language known to man.''

''> So having lua on my system would be more or less pointless as I don't use it myself.''

''Less than one meg of space would be potentially wasted, true enough in your case. Know that there is probably plenty of other software on the OpenMoko platform that you, yourself, will not be using.''

''Also realize that though _you_ may not be directly using this hypothetical scripting language, it is more than likely that one or more of the standard apps that ship with the phone will be using it, and that other 3rd party software that you may or may not install may also be using it.''

[http://lists.openmoko.org/pipermail/community/2007-January/001947.html Derek Pressnall also expressed it well:]

''The reason is the same reason the device is being shipped with a given kernel (Linux), a given set of libraries (glibc, gtk), etc. So that when a developer writes an application, it will be known to be able to run on all shipped devices. So, in this light, it may be benificial to included a standard interpreted language that can be a known
target. ''

''The benefits to having an interpreter included (esp. one that has hooks into the gui and other phone functions) are that more apps will be made available -- there are more hackers that can code up quick scripts than ones that will learn & code for a specific gui accessible only from a compiled language. And, the benefit of having a particular interpreter is that when these little apps / scripts are packaged up, you don't have a dependancy nightmare (even though this can be somewhat mitigated by a good package management system, it is only as good as the backend repository, and having self-contained packages are the simplest of all). Also, by settling on a single standard, even if it is one that some developers may have to learn, it makes it more worthwhile to learn a new scripting environment that is widely deployed on your target platform. But for these same reasons, the interpreted language target will need careful consideration, lest we get stuck with something that doesn't adequetly meet most needs.''

''As a secondary issue, if the included interpreter is easily embeddable, then it would be nice to have it as the standard across all the included applets that can use it (i.e., it would be good if the email/sms client, phonebook manager, dialer, etc. were all scriptable).''

''But whatever is decided on (if a single language is picked), a function library should be developed for it that includes access to all the phone specific features (in addition to the gui hooks).''

[[http://lists.openmoko.org/pipermail/community/2007-January/001955.html and Ben Burdette:]]

''That's all well and good when everyone has SPACE for every scripting language known to man. But use 10mb here, 10mb there for scripting languages, and suddenly there's nothing left of my 64mb of flash. ''

''I'm all for allowing people to use whatever scripting language they want. But I'd like the peace of mind of knowing I can write a scripted app that will run on every OpenMoko phone out there, even if they have no memory expansion card. I don't want the situation where the poor user has to unload someone else's app and scripting environment in order to use mine, or vice versa. ''

Bryan Larsen adds:

''It'll be faster for me to develop my apps in Ruby-GTK2 and then port to C once the application stabilizes, since so much of the actual work involves playing with and discarding various ideas. Why should I have to go through the totally unnecessary step of transliterating my code into C just so it can be used by mainstream users? I don't really care if Ruby or Python or even Javascript is chosen, I just want something for rapid development that I can ship without translating!''

For all these reasons, a choice should be made, and it should be made quickly. A scripting language should be chosen and "blessed"; actual implementation on OpenMoko is a much lower priority as most people will likely be (or should be) prototyping their applications on a PC anyways.

== Factors to Consider ==

# '''How popular is it?''' The fewer people that need to learn a new language, the less whining we'll get on the list when it's chosen.
# '''How big is the run time environment?''' This is perhaps the most important question, since we are trying to fit into a very small fraction of the 64MB of space available in the OpenMoko ROM. We only need the run time environment; it is expected that developers will have a PC or microSD card to compile to the intermediate form used by the scripting language. It's also presumed that a stripped down, precompiled standard library will be included.
# '''Is it easy to learn?''' Assuming that the user has already learned some Algol influenced language, (ie pretty much every language in widespread current use except for Lisp and FORTRAN), how easy is it to learn?
# '''How advanced is it?''' We want to include a language that people will use. Specifically I'm going to look for "closures" and "meta-programming" as a measure of how "advanced" the language is. These are very arbitrary choices, but they are something I've found useful. If you have any other pet measures, let me know!
# '''Does it have bindings to GTK2, OpenMoko-libs and D-BUS?''' These three things will be required to write applications that look and feel like OpenMoko apps, as well as interact well with the built-in applications.
# '''How does it perform?''' Performance is usually not a major concern for a scripting language, but due to the limited horsepower available on phones, it is a concern.
# '''Is it embeddable?''' Traditionally in the Unix world, applications were small tools bound together by scripts and pipes. Traditionally in the Windows world, applications were huge monolothic beasts that were scriptable using a built-in scripting language such as Visual Basic for Applications. This model is also used in the Unix world, Emacs being the classic example. A hybrid model has emerged and become popular in modern Unix GUI's such as OSX, Gnome and KDE: applications expose a scripting friendly API via D-BUS, CORBA or Applescript so that external scripts can appear to act as internal scripts. If the scripting language chosen is easily embeddable, all three models become available on OpenMoko. It's expected that the third model will be the most popular, but the second model may have size/overhead advantages.
# '''What major applications of interest''' are available in the language and would be useful on OpenMoko?

== The Languages (already included) ==

=== BASH / Shell scripts ===

# already included, useful for most cases - [http://99-bottles-of-beer.net/language-bash-98.html example]
# Shell is a very popular scripting language.
# There will be a shell of some form available on OpenMoko, therefore it is "free".
# Shell is idiosyncratic, but all Unix developers know it in at least a very limited degree.
# Shell is a full language, but can hardly be compared to languages designed monolithically. :)
# D-BUS is usable from the command line. GTK2 may be used via [http://www.gtk-server.org/index.html gtk-server].

=== AWK ===

# already included, very powerful - [http://99-bottles-of-beer.net/language-awk-53.html example]

=== SED ===

# already included, useful together with bash / awk [http://99-bottles-of-beer.net/language-sed-1087.html example1],[http://www.student.northpark.edu/pemente/sed/sed1line.txt example2]

=== Javascript ===

# Javascript is a very popular scripting language because it's the defacto web user-side scripting language.
# Javascript will be available on whichever web browser is included in the project, therefore it is "free".
# Javascript has a straightforward C-style syntax. Core Javascript is actually a very nice language; it gets a bad rap because of inconsistencies in implementation and bugs in the various browsers.
# Closures are very popular in Javascript. Metaprogramming is possible; JSON is an example of a form of such.
# An incomplete set of bindings for GTK2 are [http://oss.mps.com.sg/GtkJavaScript available here.]. [http://www.gtk-server.org/index.html gtk-server] may be used instead if those bindings are insufficient.

== The Languages (not included) ==

''Warning: opinions ahead''

=== Lua ===

# [http://www.lua.org/ Lua] is a moderately popular scripting language popular in video games and in Brazil.
# It has a tiny footprint: 150K claimed, the run time environment takes up around 400K in OpenZaurus. It's been successfully shoehorned into tiny embedded platforms (<50Kb RAM).
# Lua has a simple syntax and is easy to learn.
# It has first class closures and coroutines (a.k.a. greenthreads). A fundamental building block of Lua is the ability to redefine any defined or undefined aspect of the language; this provides very good runtime metaprogramming ability. [http://metalua.luaforge.net/ metalua] provides full compile-time metaprogramming (a.k.a. Lisp-style macros), if such extremes are needed.
# Bindings are available for GTK2.
# Performance are substantially better than [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=python Python's] or [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua Perl's].
# It is very easy to embed: it's designed for seamless integration with C, in both Lua->C and C->Lua directions.

=== Python ===

# Python is an extremely popular scripting language.
# By stripping down the standard libraries to the edge of usability, it can be made to fit within 1MB. (claim unverified). I suspect that 3MB is a more usable number.
# Designed as an educational language, it is easy to learn.
# It has closures, although they were a late addition to the language. Metaprogramming is very difficult.
# Bindings are available for GTK2 and D-BUS. GTK bindings are part of the Gnome project.
# Performance is good. Psyco can make it extremely good, but that is unlikely to be available to OpenMoko.
# [http://codespeak.net/pypy/dist/pypy/doc/news.html PyPy], [http://scipy.org/Weave Weave], [http://www.swig.org/ SWIG] could speed up taxing algorithms in certain programs. PyPy could also improve/replace Psycho.
# Python can be embedded, although not trivially. [http://www.tucs.fi/magazin/output.php?ID=2000.N2.LilDeEmPy DePython] was a stripped-down version of python made for embedded systems, footprint <200k. Project unmaintained, but could be used as a staring point.
# OLPC uses Python heavily and may produce applications suitable for porting to OpenMoko
# Python is the only language besides C / C++ mentioned in GNOME Mobile & Embedded Initiative Mobile Platform
# Python has been successfully used to create well-working and fast programs for the Nokia 770/800 devices, such as [http://konttoristhoughts.blogspot.com/2007/03/uk-media-player-is-nearing-first-public.html this].

=== Ruby ===

# Ruby is a popular scripting language.
# Size is unknown, although comparable to Python, I suspect.
# Ruby is seen by many to be an excellent compromise between the terseness and power of Perl and the readability and ease of learning of Python.
# It has closures. Metaprogramming can be hairy, but Rails is an excellent example of the beautiful results it can acheive.
# Bindings are available for GTK2 and D-BUS.
# Performance is worse than Python or Perl in current versions, although the next version of Ruby is likely to be much better.

=== Perl ===

# Perl is an extremely popular scripting language.
# Sizewise, it is likely to be a little bit smaller than Python or Ruby.
# It is not generally considered an easy language to learn. This is probably mostly due to the idiosyncrasy of typical Perl programs. Perl is generally easier to write than to read or maintain, most other languages are the other way around.
# Perl has first class closures. Perl's metaprogramming abilities lie between that of Python and Ruby.
# Perl has existed for a considerable amount of time in comparison to other scripting languages, which means it is stable and boasts an extensive amount of third-party libraries/modules.
# Bindings are available to GTK2 and D-BUS. Gtk bindings are part of the GNOME project.

=== Lisp/Scheme/Guile ===

# There are a lot of Lisp variants available. It is the second oldest high-level programming language available, yet still retains moderate popularity for new projects.
# Lisp variants have been run on 16K computers. Usable variants are substantially larger, but will be significantly smaller than Python.
# Lisp syntax is very simple, and hated by many. :)
# Modern lisp variants are more "powerful" than every other language listed here.
# GTK2 and D-BUS bindings are available

=== Java ===

# Not a scripting language, but Java does offer garbage collection and a few features that make development slightly faster than C. A J2ME JVM is ubiquitous on competing cell phones so is likely to be included in OpenMoko for purely competitive reasons. (But if we're all lucky, a clear-minded concensus will prevail in everyone's understanding that Java just doesn't belong on an embedded device.)
# A full J2ME implementation takes about 2 Megabytes of space. [http://developers.sun.com/techtopics/mobility/getstart/articles/survey/ (reading in between the lines here. I could be very wrong)]. However since it's likely to be included in the phone for other reasons it can be considered "free". Also, there's the very small [http://jamvm.sourceforge.net/ JamVM] as an alternative.
# Java is very C-like.
# Java is not a scripting language and doesn't support advanced scripting language features. So why is it in this list?
# libswt-gtk provides uses GTK2 to display SWT java apps, and libgtk-java provides a direct binding.
# If we're really lucky, people will realize that Java Virtual Machine belongs on embedded devices and has great performance there.
# The Java API greatly reduces plumbing work and helps simplify application development greatly. In addition, we can add to it providing additional APIs for the mobile device and then these would be available to all of the applications.
# The JVM has built in support for adding scripting languages, so regardless which we choose, it _should_ be on Java Virtual Machine. Studies have shown that many features of the scripting languages actually run faster on the JVM. Currently there are many scripting languages that we can use, including: javascript, ruby, python, and javafx. This would be a huge win for the device.
# JavaFX is a Multimedia based scripting language that adds wow to devices
# The Neo1973 was demoed at JavaOne running the JavaFX Mobile so there is already a lot of reusable work in this area.
# Using gcj, java can be compiled to native binaries and there's no more need for a JVM. However, this means no multiple languages on the JVM.

=== JRuby ===

# JRuby is a version of ruby that runs on the JVM. Jython is also available although it appears that JRuby is being more actively supported by Sun.
# If a JVM is on the phone, then JRuby is "free".
# JRuby can use the Java bindings to GTK2.

=== Mono/C# ===

# Not a scripting language, but offers garbage collection and other nice features.
# Already used in a similar setup on Nokia 770/800.
# Nicely cross-platform; same binary could be run on OpenMoko, Nokia 770/800, Linux, Windows (see [http://www.mdk.org.pl/articles/2007/01/28/clone-wars here]).
# Has anyone got a good quote on runtime size? (One package was 1.7M for runtime, 1.3M for GTK#, and a whopping 22M for the full classlib.)

== Summary ==

If the space is available, the most popular choices will be Ruby and Python. Python is currently more popular, however Ruby is gaining ground fast. The choice between the two is political. Neither is wrong; you'll offend people making either choice. However, "both" is a very expensive option, so a choice will have to be made.

If the space is more limited, Lua and Scheme are probably the best choices. Unless your developers include a large number of grey-bearded Lisp hackers, Lua is probably the best choice. This may be unfortunate, but it is so.

If an appropriate amount of manpower is available to bring the bindings up to snuff, the "free" choice of Javascript may be the best choice of all.

JRuby is also an interesting choice. It's very likely that a J2ME JVM will be included in the standard installation for purely competitive reasons, so JRuby is very close to free with a little bit of work.

--[[User:Bryan Larsen|Bryan Larsen]] 21:44, 3 April 2007 (CEST)

Well, my beard is still red, and I prefer Common Lisp. Or Scheme. :) --[[User:hrapd|Dmitri Hrapof]] 18 April 2007

By looking at the [http://www.gnome.org/mobile/ GNOME Mobile & Embedded Initiative] page, I see that there is a picture of the [[Neo1973]] and a picture showing the GNOME Mobile Platform with C, C++ and Python mentioned. Is there a strong reason not to pick Python as the language for the device? --[[User:Nakedible|Nakedible]] 12:30, 30 April 2007 (CEST)

Talk:Neo 1973 GTA01 Power Management

2007-07-25T17:24:54Z

Johan: 5V supply

Neo 1973 hardware

2007-07-25T17:05:46Z

Johan: /* Power Management */ link to power management page

[[OpenMoko]] is a software distribution stack that sits on top of a [[hardware]] platform. The [[Neo1973]] phone is the first hardware platform to take advantage of OpenMoko. You can find specifics of the [[:Category:Neo1973 Hardware | Neo1973 Hardware]] by reviewing this introduction page and the pages in the category as shown at the bottom of this page.

[[Image:Gta01b v3 top.jpg|thumb|400px|display (top) side]]
[[Image:Gta01b v3 bottom.jpg|thumb|400px|component (back) side]]

==User experiences of Phase 0 hardware==
[[Wishlist:Neo1973_P0_Review]]

== Physical Dimensions ==
* 120.7 x 62 x 18.5 mm (4.75 x 2.44 x 0.728 inch)
* 184 +/- 5 g (6.5 ounces)

== Main components ==
=== Processor ===
The main Processor (CPU) of the Neo1973 is a Samsung S3C2410AL-26 (Capable of running up to 266 MHz)

* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C2410 S3C2410.htm]
* User Manual: [http://www.samsung.com/global/business/semiconductor/productRightMenuDown.do?doc_file=26537 2410UserManual.pdf]
* BSDL File: [http://www.samsung.com/global/business/semiconductor/productRightMenuDown.do?doc_file=26554 S3C2410_BGA_BSDLJTAGFILE.bsd]
* GPIO Assignments: https://svn.openmoko.org/trunk/doc/hardware/GTA01Bv3/gpio.txt

=== Flash ===
64MB Samsung NAND flash (K9F1208U0B) attached to S3C2410 NAND controller.

* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=158&partnum=K9F1208U0B]
* Data Sheet: [http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/NANDFlash/SLC_SmallBlock/512Mbit/K9F1208U0B/ds_k9f1208x0b_rev03.pdf]
* Connected to: S3C2410 NAND controller

This is the only flash memory in the device. The S3C2410 boots directly from nand, using the [[S3C2410 Steppingstone]].

We only use free software, no proprietary flash file systems. For a full description of how it is used, see [[NAND bad blocks]]

=== RAM ===
128MB SDRAM (2x Samsung K4M511633C) attached to S3C2410 SDRAM controller
* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=136&partnum=K4M511633C]
* Data Sheet: [http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/MobileSDRAM/MobileSDRSDRAM/512Mbit/K4M511633C/ds_k4m511633c.pdf]
* Connected to: S3C2410

=== GSM/GPRS ===
The [[GSM]] (including GPRS) modem is Texas Instruments Calypso based.

* Connected to: S3C2410 UART1 (full-uart, RxD, TxD, CTS, RTS), /dev/ttySAC0 in userspace
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch
* Accessible GSM/GPRS antenna jack (if battery cover is removed)

==== CALYPSO digital baseband ====
Unfortunately we cannot provide many details on the GSM chipset due to very tight NDAs. However, this is not neccessarily required, since it interfaces using a standard UART serial line with the S3C2410. On that interface, [http://www.3gpp.org/ftp/Specs/archive/07_series/07.05/ GSM 07.05], [http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/ GSM 07.10] and other standardized protocols are used.

==== TWL3014 analog baseband ====
Product Homepage: [http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12295&contentId=4703 TWL3014]

==== TRF6151 RF Transceiver ====
Product Homepage: [http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12296&contentId=4701 TRF6151] <br>
Quad-band support<br>
GPRS Class12/CS4 <br>

=== [[Hardware:AGPS|AGPS]] ===
Hammerhead PMB 2520 AGPS from Global Locate.

* Product Homepage: [http://www.globalocate.com/SEMICONDUCTORS/SEMI_HAMMER_Frameset.htm Hammerhead]
* Connected to: S3C2410 UART2 (full-uart, RxD, TxD, CTS, RTS) /dev/ttySAC1 in userspace
* Driver: Implemented as plugin for the gpsd daemon ([[gpsd]])
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch
* Externally-accessible GPS antenna connector of type MMCX

This will not have a working driver till at least mid April.

=== microSD-Card ===
The Neo1973 has one microSD aka Transflash slot.
It should support SDHC, but this has not been tested. If this works, cards >2G should work with no problems. As there are no microSD cards over 2G at the moment, it hasn't been tested. MicroSD slot is [[Disassembling_Neo1973#Opening_back_cover|under battery]].
* Connected to: S3C2410 MMC/SD controller
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c_mci.patch
* [[Supported microSD cards]]
* Specifications: [http://www.sdcard.org/confirm/confirm_memorycard.aspx SD Simplified Specification], [http://www.mmca.org/compliance/buy_spec/AN_MMCA050419.pdf MMC (partial)], [http://www.sandisk.com/Assets/File/OEM/Manuals/manual-rs-mmcv1.0.pdf MMC (product manual)]

=== LCD Module (LCM) ===
This is a 2.8" diagonal (1.7" x 2.27" - 43mm x 58mm) 480x640 toppoly (tpo) TD028TTEC1 module, using a Toshiba JBT6K74 TFT LCD Driver Chipset.
* Homepage: [http://www.tpo.biz/ENG/business-eng/Activer-Matrix-VGA.htm Activer-Matrix-VGA.htm]
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-jbt6k74.patch
* Backlight Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-backlight.patch
* Connected to: S3C2410 Display Controller and S3C2410 SPI Interface channel 1

==== Touch Screen ====
* Connected to: S3C2410 TS controller
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c2410_touchscreen.patch

==== Stylus ====

Seemingly identical to [http://cgi.ebay.com/4in1-PDA-Stylus-LED-Light-Torch-Laser-Pointer-Pen-h7_W0QQitemZ280089656134QQihZ018QQcategoryZ48677QQrdZ1QQcmdZViewItem this one on ebay]

=== Bluetooth ===
Delta DFBM-CS320 Class2 Module, using CSR BlueCore4

* Data Sheet: [http://www.delta.com.tw/product/cp/vco/BT/download/pdf/CS/2.DFBM-CS320.pdf 2.DFBM-CS320.pdf]
* CSR Data Sheet: [http://www.csrsupport.com/download/2302/CS-101564-DSP10%20BlueCore4-ROM%20Product%20Data%20Sheet.pdf CS-101564-DSP10 BlueCore4-ROM Product Data Sheet.pdf]
* Driver: Stock Linux Kernel BlueZ
* Connected to: S3C2410 USB Host controller (OHCI)
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch

=== Vibrator ===
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-vibrator.patch
* Connected to: S3C2410 GPIO

=== USB Host ===
The USB Host controller is inside the S3C2410
* Driver: Stock Linux kernel ohci_hcd

=== USB Device ===
The USB Device controller is inside the S3C2410
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c2410_udc.patch
* Please see [[USB Product IDs]] on information about which Vendor/Product IDs we use
* 1200mAh lithium battery charges when connected to powered host.
* Mini-AB connector similar to [http://www.cypressindustries.com/shoponline/proddetail.asp?prod=CCMUSBAB-32005-700&cat=34 this one].

=== Audio ===
See also: [[Neo1973 Audio Subsystem]]

==== Wolfson Codec ====
There's a WM8753 Wolfson Microelectronics CODEC (This is not a 'smart' codec that can interpret MP3/... it is a simple dumb 'sound card'.
* Product Homepage: http://www.wolfsonmicro.com/products/WM8753/
* Data Sheet: [http://www.wolfsonmicro.com/uploads/documents/en/WM8753.pdf WM8753.pdf]
* Connected to: S3C2410 IIS interface (PCM data), S3C2410 I2C (Control)
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/asoc.patch

==== Stereo Amplifier ====
There's a National Semiconductor [[LM4857]] Stereo Amplifier at the analog audio output of the WM8753

* Product Homepage: [http://www.national.com/pf/LM/LM4857.html LM4857.html]
* Data Sheet: [http://www.national.com/ds.cgi/LM/LM4857.pdf LM4857.pdf]
* Connects to: S3C2410 I2C (Control)

==== Analog wired Headset ====
There's a four-ring 2.5mm stereo jack which provides connectivity to old-fashioned wired headsets.

The headsets used by Motorola smartphones (A780,A1200, ...) and the V-360 have a compatible configuration.

==== Bluetooth Headset ====
This one is wired via PCM bus from the CSR Bluetooth chip to the Wolfson codec.

=== Power Management ===
A Philips PCF50606 is used for [[Neo1973_Power_Management|power management]].

* Data Sheet: [http://www.nxp.com/acrobat/literature/9397/75009763.pdf PCF50606/605]
* User Manual: [http://www.rockbox.org/twiki/pub/Main/DataSheets/pcf50606.pdf pcf50606.pdf]
* Connected to: S3C2410 via I2C, client address is 0x08.
* Driver Source: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-pcf50606.patch

=== Battery ===
The [[Neo1973 Battery]] is compatible with a Nokia BL5C battery.
According to [http://lists.openmoko.org/pipermail/community/2007-February/003758.html this] post on the mailinglist.
[http://wiki.openmoko.org/index.php?title=Image:Neo1973-with-BL5C-battery.png Photo] of the battery inside the Neo1973.

=== Buttons ===
The Neo1973 features two buttons:
# [[Neo1973 Power button|The Power Button]]
# [[Neo1973 AUX button|The "Aux" button]]

=== Alternate cases ===
A number of alternate case designs have been suggested and requested.

[[Neo1973 case schematics]]

[[Alternate Neo1973 case designs]]

== History ==
=== GTA01 ===
This is the most simple, non-bluetooth version of the prototype.

==== GTA01v3 ====
First generation of prototypes that was given to internal OpenMoko software developers.

Unfortunately not useful at all due to non-working touchscreen.

* ATAG_REVISION: 0x0000130

==== GTA01v4 ====
Second generation of prototypes that was given to [[User:HaraldWelte|Harald]] +[[User:Mickey|Mickey]].

Unfortunately still not useful due to half-working touchscreen.

* ATAG_REVISION: 0x00000140

=== GTA01B ===
This is the bluetooth-enabled fork of GTA01

==== GTA01Bv2 ====
This is the first produced version of the bluetooth-enabled version.

* ATAG_REVISION: 0x00000220

==== GTA01Bv3 ====
This is the second produced version of the bluetooth-enabled version. It contains mainly GPS-related fixes.

* ATAG_REVISION: 0x00000230

This is the version that is shipped in [[Neo1973#Phase_0_.28GTA01Bv3.29|Phase 0]].

===== GTA01Bv3 Errata =====
====== PMU unable to resume from suspend ======
Due to use of wrong GPIO/EINT pin, the PMU cannot wake-up the phone after suspend. This means, specifically, '''the following events can not bring the phone back from suspend-to-ram''':
* PMU RTC Alarm
* Power button press
* Charger events (charger insertion/removal/error)
* Low battery

====== Stand-by time extremely low ======
This is due to a design bug resulting in at least 30mA additional standby current, since we cannot properly switch off the power supply to the S3C2410 PLL's. There is nothing we can do to change this with post-production fixes. GTA01Bv4 will address this issue.

====== GSM doesn't resume phone from suspend ======
The GSM modem currently doesn't signalize a wakeup interrupt to the S3C2410 in case there's some noteworthy event, such as incoming call, loss of network, incoming SMS or the like.

This is a serious issue, but can be fixed with a GSM Modem Firmware update.

====== GSM Sidetone too loud ======
The local feedback sidetone (see [http://en.wikipedia.org/wiki/Sidetone]) is too loud. This will be addressed in a GSM firmware update

====== Bad block ======
Due to an error in the production process, the factory-programmed NAND bad block information has been lost. This means that some blocks in the flash will wear out rapidly, which might become as bad as rendering the device unusable.

==== GTA01Bv4 ====
This is the version that will be shipped in [[Neo1973#Phase_1_.28GTA01Bv4.29|Phase 1]]

===== Looks =====
This is what the GTA01Bv4 PCB looks like without the shielding cans, which will be fitted later.
[[Image:Gta01b_v4_front.png|thumb|400px|Component side]]
[[Image:Gta01b_v4_back.png|thumb|400px|Display side]]

===== Changes from GTA01Bv3 =====
# Fix all Errata items from GTA01Bv3
# Add I2C, SPI and one irq and wakeup capable GPIO pin to debug port plus have test pads for all these signals (for soldering wires directly on the pcb)
# Fix a number of production related details and minor hardware details that are not user-visible

===GTA02===
The [[GTA02#.22Phase_2.22_.28GTA02.2C_.22Mass_Market.22.29|GTA02]] is the device shipped starting October 2007 ("Mass Market launch").
It is a new main release with [[Neo1973:_GTA01Bv4_versus_GTA02_comparison|features added]]

===Debug Connector===
This is the connector used to connect the [[Debug Board]] and possibly other hardware.

Connections are:
* 39 - GND
* 38 - STDI
* 37 - _RESET
* 36 - STMS
* 35 - STCK
* 34 - STDO
* 33 - GSM_EN
* 29 - _STRST
* 19 - X_I2C_SCL (H-TP4703)
* 18 - X_I2C_SDA (H-TP4704)
* 17 - SPI_CLK0
* 16 - SPI_MOSI0
* 15 - SPI-MISO0
* 14 - SS0
* 13 - EINT3 (H-TP4705)
* 3 - MODEM_TXD (H-TP4701)
* 2 - MODEM_RXD (H-TP4702)

Information from [http://people.openmoko.org/roh/Debugport_P1.png].

== Distinguishing hardware revisions ==
=== Inside the [[Bootloader]] ===
Every hardware revision has its own u-boot image type. Thus, the bootloader has the revision hard-coded.
The hardware revision is passed on to the kernel via the ATAG mechanism (ATAG_REVISION)

=== Inside the [[Kernel]] ===
The kernel receives the ATAG_REVISION during bootup, and saves its contents in the "system_rev" global variable.

=== From Userspace ===
The kernel exports the system_rev variable in /proc/cpuinfo as "Revision :" line.

== Approval ==
*[http://www.cetest.nl/ CE] '''(Is this the proper site for CE?)'''
*[http://www.fcc.gov/ FCC]

{{Languages|Neo1973 Hardware}}

[[Category:Neo1973 Hardware| ]]

Variometer

2007-07-25T16:46:44Z

Johan: typo fix

[[Category:Hardware_ideas]]

===Variometer===
The variometer signal is simply the derivative of the barometer signal. It gives a much more accurate vertical speed signal than is possible with GPS. It would probably be best to filter and differentiate the analog pressure signal and then digitize. This kind of measurement is used by the flee flying community (hanggliding, paragliding, ballooning). A device that allows teams of pilots to share position and speed (with accurate vertical speed) data would be lots of fun.
[http://en.wikipedia.org/wiki/Variometer Variometer Reference]

====Hardware====

References to applicable transducers:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX4100 Freescale MPX4100 (was Motorola)]

====Signal Conditioning====

The absolute pressure signal needs to be:
#Differentiated
#Filtered

*Operational amplifiers in the following configuration:

See the signal conditioning example in this [http://www.freescale.com/files/sensors/doc/app_note/AN1326.pdf Application Note]<br \>
It might be best to use a single chip solution if we can find the right fit e.g.: [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4590 Max1464]

====A/D====
We would need two A/D channels:
#Absolute Pressure - 12 bit minimum (assuming a operating range of 0 - 12000 meter 12 bits would give resolution of 2.9304 m)
#Differential Pressure - 10 bit minimum (assuming a range of +-20m/s 10 bits would give a resolution of 0.0391 m/s)

[http://www.freescale.com/files/sensors/doc/app_note/AN1100.pdf Extending 8 bit sampling to a usable range for pressure sensing]

====Driver Code====
The driver code samples the input channels and converts the input values from pressure to altitude:

The relationship between static pressure and pressure altitude is defined in terms of the properties of the International Standard Atmosphere. Up to 36,090 ft this can be expressed as:

<math>
z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122}
</math>

Where:

*z = pressure altitude (meter)
*<math>P_{ind}</math> = static pressure (kPa)

These values are provided to listeners in multiple applications.
The sample rate should be application adjustable to conserve power.

====Application code====
Applications can use the altitude data or combine the data with GPS and accelerometer data.
Commonly Kalman filter/observer techniques are used to combine data from multiple sensor types into a robust(with respect to sensor noise), high accuracy estimate of position and speed in 3 axis.

'''References:'''
*[http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html The Kalman Filter: Navigation's Integration Workhorse]
*[http://www.cs.unc.edu/~welch/kalman/ Kalman Filter Portal from the University of North Carolina at Chapel Hill]
*[http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter article on Wikipedia]

=====Variometer Code=====
Combine measurements as described above.
Apply knowledge about the aircraft dynamics to increase accuracy:
*Total Energy compensation
*Relative Netto Compensation - use accelerometer data to sense when glider is turning in a thermal

'''User Interface'''

*Display speed data in ergonomic manner.
*Display speed for pilots in group.
*Visual and audible guidance to pilot with best climb rate (given reasonable proximity)
*Possible integration with mapping application

====Server Based Services====
Auto discovery service
*Pilots with OpenMoko based variometers can choose to publish their status on a central service.
*Based on location - the system will notify pilots of the presence of others that can participate in group flying.

Variometer

2007-07-25T16:46:02Z

Johan: moved vario to lower category

[[Category:Category:Hardware_ideas]]

===Variometer===
The variometer signal is simply the derivative of the barometer signal. It gives a much more accurate vertical speed signal than is possible with GPS. It would probably be best to filter and differentiate the analog pressure signal and then digitize. This kind of measurement is used by the flee flying community (hanggliding, paragliding, ballooning). A device that allows teams of pilots to share position and speed (with accurate vertical speed) data would be lots of fun.
[http://en.wikipedia.org/wiki/Variometer Variometer Reference]

====Hardware====

References to applicable transducers:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX4100 Freescale MPX4100 (was Motorola)]

====Signal Conditioning====

The absolute pressure signal needs to be:
#Differentiated
#Filtered

*Operational amplifiers in the following configuration:

See the signal conditioning example in this [http://www.freescale.com/files/sensors/doc/app_note/AN1326.pdf Application Note]<br \>
It might be best to use a single chip solution if we can find the right fit e.g.: [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4590 Max1464]

====A/D====
We would need two A/D channels:
#Absolute Pressure - 12 bit minimum (assuming a operating range of 0 - 12000 meter 12 bits would give resolution of 2.9304 m)
#Differential Pressure - 10 bit minimum (assuming a range of +-20m/s 10 bits would give a resolution of 0.0391 m/s)

[http://www.freescale.com/files/sensors/doc/app_note/AN1100.pdf Extending 8 bit sampling to a usable range for pressure sensing]

====Driver Code====
The driver code samples the input channels and converts the input values from pressure to altitude:

The relationship between static pressure and pressure altitude is defined in terms of the properties of the International Standard Atmosphere. Up to 36,090 ft this can be expressed as:

<math>
z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122}
</math>

Where:

*z = pressure altitude (meter)
*<math>P_{ind}</math> = static pressure (kPa)

These values are provided to listeners in multiple applications.
The sample rate should be application adjustable to conserve power.

====Application code====
Applications can use the altitude data or combine the data with GPS and accelerometer data.
Commonly Kalman filter/observer techniques are used to combine data from multiple sensor types into a robust(with respect to sensor noise), high accuracy estimate of position and speed in 3 axis.

'''References:'''
*[http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html The Kalman Filter: Navigation's Integration Workhorse]
*[http://www.cs.unc.edu/~welch/kalman/ Kalman Filter Portal from the University of North Carolina at Chapel Hill]
*[http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter article on Wikipedia]

=====Variometer Code=====
Combine measurements as described above.
Apply knowledge about the aircraft dynamics to increase accuracy:
*Total Energy compensation
*Relative Netto Compensation - use accelerometer data to sense when glider is turning in a thermal

'''User Interface'''

*Display speed data in ergonomic manner.
*Display speed for pilots in group.
*Visual and audible guidance to pilot with best climb rate (given reasonable proximity)
*Possible integration with mapping application

====Server Based Services====
Auto discovery service
*Pilots with OpenMoko based variometers can choose to publish their status on a central service.
*Based on location - the system will notify pilots of the presence of others that can participate in group flying.

Variometer

2007-07-25T15:44:30Z

Johan: /* Variometer Code */

[[Category:Hardware]]

===Variometer===
The variometer signal is simply the derivative of the barometer signal. It gives a much more accurate vertical speed signal than is possible with GPS. It would probably be best to filter and differentiate the analog pressure signal and then digitize. This kind of measurement is used by the flee flying community (hanggliding, paragliding, ballooning). A device that allows teams of pilots to share position and speed (with accurate vertical speed) data would be lots of fun.
[http://en.wikipedia.org/wiki/Variometer Variometer Reference]

====Hardware====

References to applicable transducers:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX4100 Freescale MPX4100 (was Motorola)]

====Signal Conditioning====

The absolute pressure signal needs to be:
#Differentiated
#Filtered

*Operational amplifiers in the following configuration:

See the signal conditioning example in this [http://www.freescale.com/files/sensors/doc/app_note/AN1326.pdf Application Note]<br \>
It might be best to use a single chip solution if we can find the right fit e.g.: [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4590 Max1464]

====A/D====
We would need two A/D channels:
#Absolute Pressure - 12 bit minimum (assuming a operating range of 0 - 12000 meter 12 bits would give resolution of 2.9304 m)
#Differential Pressure - 10 bit minimum (assuming a range of +-20m/s 10 bits would give a resolution of 0.0391 m/s)

[http://www.freescale.com/files/sensors/doc/app_note/AN1100.pdf Extending 8 bit sampling to a usable range for pressure sensing]

====Driver Code====
The driver code samples the input channels and converts the input values from pressure to altitude:

The relationship between static pressure and pressure altitude is defined in terms of the properties of the International Standard Atmosphere. Up to 36,090 ft this can be expressed as:

<math>
z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122}
</math>

Where:

*z = pressure altitude (meter)
*<math>P_{ind}</math> = static pressure (kPa)

These values are provided to listeners in multiple applications.
The sample rate should be application adjustable to conserve power.

====Application code====
Applications can use the altitude data or combine the data with GPS and accelerometer data.
Commonly Kalman filter/observer techniques are used to combine data from multiple sensor types into a robust(with respect to sensor noise), high accuracy estimate of position and speed in 3 axis.

'''References:'''
*[http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html The Kalman Filter: Navigation's Integration Workhorse]
*[http://www.cs.unc.edu/~welch/kalman/ Kalman Filter Portal from the University of North Carolina at Chapel Hill]
*[http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter article on Wikipedia]

=====Variometer Code=====
Combine measurements as described above.
Apply knowledge about the aircraft dynamics to increase accuracy:
*Total Energy compensation
*Relative Netto Compensation - use accelerometer data to sense when glider is turning in a thermal

'''User Interface'''

*Display speed data in ergonomic manner.
*Display speed for pilots in group.
*Visual and audible guidance to pilot with best climb rate (given reasonable proximity)
*Possible integration with mapping application

====Server Based Services====
Auto discovery service
*Pilots with OpenMoko based variometers can choose to publish their status on a central service.
*Based on location - the system will notify pilots of the presence of others that can participate in group flying.

Variometer

2007-07-25T15:42:25Z

Johan: /* Application code */ - notofication service

[[Category:Hardware]]

===Variometer===
The variometer signal is simply the derivative of the barometer signal. It gives a much more accurate vertical speed signal than is possible with GPS. It would probably be best to filter and differentiate the analog pressure signal and then digitize. This kind of measurement is used by the flee flying community (hanggliding, paragliding, ballooning). A device that allows teams of pilots to share position and speed (with accurate vertical speed) data would be lots of fun.
[http://en.wikipedia.org/wiki/Variometer Variometer Reference]

====Hardware====

References to applicable transducers:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX4100 Freescale MPX4100 (was Motorola)]

====Signal Conditioning====

The absolute pressure signal needs to be:
#Differentiated
#Filtered

*Operational amplifiers in the following configuration:

See the signal conditioning example in this [http://www.freescale.com/files/sensors/doc/app_note/AN1326.pdf Application Note]<br \>
It might be best to use a single chip solution if we can find the right fit e.g.: [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4590 Max1464]

====A/D====
We would need two A/D channels:
#Absolute Pressure - 12 bit minimum (assuming a operating range of 0 - 12000 meter 12 bits would give resolution of 2.9304 m)
#Differential Pressure - 10 bit minimum (assuming a range of +-20m/s 10 bits would give a resolution of 0.0391 m/s)

[http://www.freescale.com/files/sensors/doc/app_note/AN1100.pdf Extending 8 bit sampling to a usable range for pressure sensing]

====Driver Code====
The driver code samples the input channels and converts the input values from pressure to altitude:

The relationship between static pressure and pressure altitude is defined in terms of the properties of the International Standard Atmosphere. Up to 36,090 ft this can be expressed as:

<math>
z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122}
</math>

Where:

*z = pressure altitude (meter)
*<math>P_{ind}</math> = static pressure (kPa)

These values are provided to listeners in multiple applications.
The sample rate should be application adjustable to conserve power.

====Application code====
Applications can use the altitude data or combine the data with GPS and accelerometer data.
Commonly Kalman filter/observer techniques are used to combine data from multiple sensor types into a robust(with respect to sensor noise), high accuracy estimate of position and speed in 3 axis.

'''References:'''
*[http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html The Kalman Filter: Navigation's Integration Workhorse]
*[http://www.cs.unc.edu/~welch/kalman/ Kalman Filter Portal from the University of North Carolina at Chapel Hill]
*[http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter article on Wikipedia]

=====Variometer Code=====
Combine measurements as described above.
Apply knowledge about the aircraft dynamics to increase accuracy:
*Total Energy compensation
*Relative Netto Compensation - use accelerometer data to sense when glider is turning in a thermal

'''User Interface'''

*Display speed data in ergonomic manner.
*Display speed for pilots in group.
*Visual and audible guidance to pilot with best climb rate (given reasonable proximity)

====Server Based Services====
Auto discovery service
*Pilots with OpenMoko based variometers can choose to publish their status on a central service.
*Based on location - the system will notify pilots of the presence of others that can participate in group flying.

Wiki Issues

2007-07-24T17:03:13Z

Johan: Wiki Admin Requests

[[Category:Help]]
Can we please install/fix the following features for this wiki:
* '''Math''' - the Tex math markup does not work currently.
* [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi '''Syntax''' Highlighting - makes code much more readable]
* [http://www.mediawiki.org/wiki/Extension:GraphViz GraphViz] works with the commonly known dot language - it allows us to draw '''graphs''' using easy markup.
* [http://www.mediawiki.org/wiki/Extension:AnyWikiDraw AnyWikiDraw] allows us to draw svg '''diagrams''' directly on the wiki page.

Main Page

2007-07-24T17:00:14Z

Johan: /* Administrative / Organizational */

<big>'''Welcome to the [[OpenMoko]] public Wiki'''</big><br>
<small>For other languages see the </small>[[#bottom|bottom]]<small> of this page.</small>

[[Image:FIC-neo1973_small.jpg|200px|right|frontside]]
OpenMoko is an [http://en.wikipedia.org/wiki/Open_source Open Source] project to create the world's first free mobile phone operating system.

The [[OpenMoko]] project is a community that anyone can join, to help design their ideal phone.

Eventually, phone software won't be tied to any particular phone. You can install any OpenMoko software over the whole range of [[Supported Hardware|supported phones]], and if you upgrade your phone, you don't lose that software. Bugs fixed on any phone are fixed on all.

'''Currently it is not suitable for users.''' The state of the software at the moment is pre-alpha. If you order a Neo1973, DO NOT expect to be able to use it as an everyday phone for several months.

The [[Neo1973]] from [[FIC]] is the first of many phones that OpenMoko will run on; indeed, some people erroneously use the terms Neo1973 and OpenMoko as interchangeable. If you are willing to have the alpha test experience, you can order Neo1973 hardware now from the [https://direct.openmoko.com/ Openmoko Online Shop]. You may wish to see the [[SH1 FAQ|Shipment 1 FAQ]].

Please join us in collaborating on the OpenMoko project through any of the [[Development resources | project resources]] including this OpenMoko wiki. Please see the [[Help:Contents | wiki editing help]] page for information on making contributions to this wiki. A [[Meet the Core Team | core team]] of developers funded by FIC, Inc. leads the project.

An [[introduction]] page is available, with [[Introduction#Photos|photos]] and [[Introduction#Videos|videos]]. Moreover, the usual [[FAQ | Frequently Asked Questions] (FAQ) page might be helpful. Developers may find the [[ChangeLog | change log]] an important resource.

The members of the OpenMoko community would like to thank FIC Inc. for showing leadership and initiating the OpenMoko project.

== OpenMoko Areas of Interest ==
* [[Basic End-user]] - Information for end users that want basic functionality and no surprises
* [[Advanced End-user]] - Information for advanced end-users that want advanced and experimental functionality but who are not programmers
* [[Development resources | Project Resources]] page provides a centralized location of all resources such as [[Development resources#Mailing_Lists|mailing lists]], [[Development resources#IRC | communication tools]], and other software development oriented resources.
* [[Application Developer]] - Information for application developers, including ideas and specifications for applications, and tools to build them
* [[System Developer]] - Information for system developers, including bootloader, kernel, and libraries
* [[Hardware Developer]] - Information for hardware developers, including hardware specs and debug board
* [[Community Events]] - Information on both [[Community Events#Past Events | past ]] and [[Community Events#Past Events#FIC / OpenMoko at Events | future]] events where FIC or OpenMoko had or will have a presence.

== Developer's Documentation ==

=== Hands-on Guides ===
* [[Getting Started with your Neo1973]]
* [[MokoMakefile|Building OpenMoko using the MokoMakefile]]
* [[Building OpenMoko from scratch]]
** [[Building a hello world application]]
** Old [[Building OpenMoko from scratch (pre-BBT)]]
* [[Migration to bad block tolerant builds]]
* [[Running OpenMoko on PC]]
** [[Getting OpenMoko working on host with Xoo]]
** [[Getting OpenMoko working on host with Xephyr]]
** [[How to run OpenMoko Apps on PC]]
** [[OpenMoko under QEMU]]
** [[Test Openmoko Emulation with chroot image|Test Openmoko Emulation with a prebuilded chroot image]]
* [[Booting from SD]]

=== Hardware Reference Documentation ===
* All [[:Category:Hardware|Hardware]] related documentation and specifications are found on the [[:Category:Hardware|Hardware page]].
* The [[Neo1973 Hardware]] page provides an overview of the hardware components used by the [[:Category:Neo1973 Hardware|Neo1973 hardware platform]]. PCB Photographs are also included. A [[Disassembling Neo1973 | photo disassemble story]] may be an interesting starting place.
* [[:Category:Neo1973 Hardware Debugging | Neo1973 Hardware Debugging]] is assisted with the [[Debug Board | Neo1973 debug board]]. A page discussing [[Connecting Neo1973 with Debug Board v2 | debug board and Neo1973 configurations]] are also provided.

=== Software Reference Documentation ===
* Architectural
** [[OpenMokoFramework]] - The OpenMoko Application Framework
* [[Neo1973 host software]]
* Device Software
** Low-Level
*** [[u-boot]] - The bootloader we use, including documentation for our modifications
*** [[kernel]] - The Linux kernel we use, including documentation for our modifications
** Userspace
*** [[binary compatibility]]
*** [[gsmd]] - the GSM daemon managing the GSM Modem
*** [[gpsd]] - the AGPS (Assisted GPS) daemon

=== OpenMoko ===
* [[OpenEmbedded]] - The distribution-building framework
* [[Toolchain]] - The toolchain we use for compilation
* [[OpenMoko]] - The OpenMoko distribution
** [[OpenMoko2007]] - The first intended release of it
** [[Userspace root image]]

==== User Interface Related ====
* [[Look & Feel]]
* [[Applications]]
* [[Widgets]]
** [[Widget Inheritance Graph]]
* [[Application UI Design Recommendations]]

=== Misc. Development Related ===
* [[Freshman todo]]
* [[Templates]]
* [[PIM Storage]]
* [[Coding Guidelines]]
* [[OpenMoko#Setting_up_an_OpenMoko_SDK|How to setup the OpenMoko SDK]]
* [[License]] - How we license our code
* [[Development resources]] - Describes resources for developers (lists, svn, ...)
* [[Neo1973 Phase 0]] -- Information for Phase 0 device owners
* [[Wishlist:Neo1973 P0 Review]] -- Impressions of the Phase 0 hardware device, also the Phase 0 FAQ
* [[Neo1973 Phase 1]] -- Information for Phase 1 device owners
* [[Wishlist:Neo1973 P1 Review]] -- Impressions of the Phase 1 hardware device
* [[External Feeds]] -- List of feeds from people blogging about OpenMoko

== Administrative / Organizational ==

* [[Shipping Notes]] - Information to help FIC figure out how to ship products to you, and how much it might cost.
* [[My Account]] - Ideas for what sort of account-based services FIC should provide with the phone.
* [[Hear Me FIC]] - Information to help FIC know what the community wants.
* [[Wiki Issues]] - problems/requests regarding this Wiki

== Miscellaneous ==
* [[WiFi support in OpenMoko]]
* [[Neo1973 and Windows]] - If you want to commit that offence ;) (does not work, help!)
* [[Press Coverage]] - What the press says about the OpenMoko project
* [[mFAQ]] - The OpenMoko Misinformation FAQ ('''mFAQ''') - What the press '''''incorrectly''''' says about the OpenMoko project
* [[Wish List]] - A collection of ideas and ideals we'd like to see implemented some day
* [[Wish List - Hardware]] - A collection of ideas we'd like to see in the next Neo release
* [[Wishlist:BuiltInScriptingLanguage|Wish List - Built-in Scripting Language]] - Discussion on a suitable scripting language to be included
* [[Media Content]] - What types of media on the device can we use (that is non-software)?
* [[Testimonials]] - How did you get to OpenMoko?
* [[Buying Interest List]] - (Not official and not a pre-order page) Have you put money aside for Neo1973? Put your nick here.
* [[iPhone]] - Comparison between Apple iPhone and FIC Neo1973
* [[Translation]] - Translation of OpenMoko
* [[Summer of code]] - Our page with project applications for Googles Summer of Code
* [[SWAG]] - Where to purchase openmoko swag (T-Shirts!)

<span id="bottom"></span>
{{Languages|Main_Page}}

[[Category:Information| ]]
[[Category:Categories| ]]

Wiki Issues

2007-07-24T16:58:28Z

Johan:

Can we please install/fix the following features for this wiki:
* '''Math''' - the Tex math markup does not work currently.
* [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi '''Syntax''' Highlighting - makes code much more readable]
* [http://www.mediawiki.org/wiki/Extension:GraphViz GraphViz] works with the commonly known dot language - it allows us to draw '''graphs''' using easy markup.
* [http://www.mediawiki.org/wiki/Extension:AnyWikiDraw AnyWikiDraw] allows us to draw svg '''diagrams''' directly on the wiki page.

Variometer

2007-07-24T01:42:17Z

Johan: /* A/D */

Wish List - Hardware

2007-07-24T01:28:28Z

Johan: /* TouchKo's (now Wacom Company Ltd.) spatial capacitive "touchscreen" */

This page details hardware features which some would like to go into future phones similar to the [[Neo1973]].

Related pages are:
*[[Wishlist - Hardware - Novel Devices]] - openmoko will run on a large number of devices in the future, some of which may be DVD players, cameras, or convergance devices.
*[[Wishlist:Unlikely]] - Hardware that is unlikely to appear in any OpenMoko device, due to it being impossible to fabricate with near-term technology, or for other reasons.
*[[Wishlist:Accessories]] - Accessories that people would like, that connect easily to the phone - initially primarily for the Neo1973
*[[Wishlist:Expansion]] - add-ons to the phone, maybe involving hardware changes, and software and hardware protocols to implement these.

This page is rather long. Before adding a new idea, please read through this page and the above pages, to make sure your idea has not been suggested before.

==Processor==
===AT91CAP9S500A (ARM9 + FPGA-port)===
Take a look at this microcontroller, that integrates an ARM9 microcontroller and a dedicated FPGA port: AT91CAP9S500A. It has "only" a max. clock at 200MHz, but can use a FPGA for hardware acceleration, that could be used for video (de)compression, [http://en.wikipedia.org/wiki/AacPlus_v2 aacPlus v2]/[http://en.wikipedia.org/wiki/HE-AAC_v2 HE-AAC v2] sound (de)compression and many other things. HE-AAC v2 is better than [http://en.wikipedia.org/wiki/MP3 MP3].
*[http://www.atmel.com/dyn/products/product_card.asp?family_id=689&family_name=AT91CAP+Microcontrollers&part_id=4137 AT91CAP9S500A] Quote: "...The AT91CAP9S500A is built around a 12-layer bus matrix, allowing a maximum internal bandwidth of twelve 32-bit buses. Its distributed DMA architecture enables multiple data transfers to take place between the processor, memories and peripherals with minimal processor overhead...".
*[http://www.atmel.com/dyn/resources/prod_documents/doc6310.pdf GNU-Based Software Development on AT91SAM Microcontrollers]
*Maybe this is a good tool?: [http://www.jhdl.org/ BYU JHDL, Open Source FPGA CAD Tools]
*[http://www.eetimes.com/showArticle.jhtml;?articleID=197002705 02/05/2007, FPGA tool bottleneck stalls HPC] Quote: "...Current FPGA synthesis, placement and routing tools are written for hardware designers, not software programmers simply trying to accelerate an algorithm..."

This seems to be a good hardware mix (ARM+FPGA). It does [http://en.wikipedia.org/wiki/Theora Ogg Theora] or [http://en.wikipedia.org/wiki/MJPEG MJPEG] in the FPGA with 1 million gates:
*http://sourceforge.net/projects/elphel, [http://wiki.elphel.com/index.php?title=10353 board 10353], [http://wiki.elphel.com/index.php?title=Camera_hardware camera hardware], [http://wiki.elphel.com/index.php?title=Main_Page Main page], [http://www.elphel.com/articles/index.html Imaging solutions with Free software and open hardware]

Just another FPGA+microcontroller example:
*[http://melzer.ch/html/body_alya.html The Alya Project] ([http://home.nikocity.de/andymon/hfg/Alya/alya.html old page])
*[http://melzer.ch/ALYA.ASM PIC assembler source code], [http://melzer.ch/ALYA.TDF Altera FPGA code]. Schematic: [http://melzer.ch/Schaltplan1.gif], [http://melzer.ch/Schaltplan2.gif], [http://melzer.ch/Schaltplan3.gif]
*[http://hardware.silicon.com/servers/0,39024647,39166443,00.htm?r=1 20 March 2007 Green supercomputer is 'go' in Scotland]

==Possible FPGA==
This FPGA is just an example:
*[http://www.xilinx.com/products/silicon_solutions/fpgas/spartan_series/spartan3an_fpgas/capabilities/index.htm Spartan-3AN FPGA Capabilities] Quote: "...Simple and secure embedded application storage with up to 11Mb of integrated user Flash...Enable simple arithmetic and math functions as well as advanced DSP functions to derive over 330 Giga MACs/sec...Up to 32 18 x 18 embedded multipliers support 18-bit signed or 17-bit unsigned multiplication, and can be cascaded to support wider bits..."
**XC3S1400AN-4FGG676CES $91
**XC3S200AN-4FTG256CES $25.87

Tool for FPGAs:
*[http://www.xilinx.com/ise/logic_design_prod/webpack.htm xilinx.com: ISE WebPACK is the industry´s only FREE, fully featured front-to-back FPGA design solution for Linux, Windows XP, and Windows Vista]

==Wireless data networking==

===WiMAX support===
[http://en.wikipedia.org/wiki/Wimax WiMAX] is a high-speed data service, similar to wifi, though longer range and newer. Where service is available, this would complement WiFi. Unfortunately, unlike wifi, frequencies vary worldwide, so global usage may be complex.

===Emerging Protocols===
*[http://en.wikipedia.org/wiki/Near_Field_Communication Near Field Communication] has a few centimeter range, useable for keys, ID badges, pairing bluetooth devices and similar uses. Mentioned in newer bluetooth and SD standards. (No products.)
*[http://en.wikipedia.org/wiki/ZigBee ZigBee] is designed for connecting sensors and switches in buildings, with many options including mesh networks and aggressive power saving compared to bluetooth. (Almost no products available.)
*The [http://en.wikipedia.org/wiki/ANT_%28network%29 ANT network] is for connecting worn devices. Similar to ZigBee, but much simpler and maybe lower power. ([http://www.thisisant.com/?section=9 Short list] of products.)

==Camera==

* A camera that can take reasonable quality video and pictures is something many want. Applications vary from simple snapping, to gesture interfaces, video conferencing, barcode reading, buisness card reading, healthcare, servicing, and more.

* Some people can't take cameras into work - a model without the camera, or some way of removing the camera would be useful.

* See [[Wishlist:Camera]] for a more detailed wishlist.

==Display==
===Multitouch screen===

''Main article: [[Wishlist:Spell_weaving|Spell weaving]]''

See also [http://pogue.blogs.nytimes.com/2007/03/27/the-multi-touch-screen/ this page] containing a link to a video demonstration.

A history of multitouch implementations is [http://billbuxton.com/multitouchOverview.html here] ([http://google.com/search?q=cache:billbuxton.com/multitouchOverview.html google cache version])

===TouchKo's (now Wacom Company Ltd.) spatial capacitive "touchscreen"===

How about a TouchKo's (now Wacom Company Ltd.) spatial capacitive "touchscreen", so you do not grease your display, with your fingers. This also means the device can be operated with gloves.
*[http://www.touchko.com/capacitive.html touchko.com: Spatial Capacitive: Imagine getting a touch response from your display, without even touching it!], [http://www.touchko.com/ TouchKo] Quote: "... June, 2007, Wacom Company Ltd., acquired TouchKo and will add TouchKo's spatial capacitive and resistive touch technology into its components portfolio..."
*[http://www.wacom-components.com/english/index.html Wacom Company Ltd.]

I do not know how good or bad it works.

Thought educational example:
*If the Neo1973 detect a finger have pressed the screen, the Neo1973 should vibrate two short times and reply one of these:
**"You can touch my screen, but I also understand close proximity finger sign language.".
**"Do not touch my screen, I understand close proximity finger sign language.".

===Video acceleration===
Hardware acceleration for video playback.

===3D acceleration===
3D hardware acceleration for 3D games, GUIs, etc. (maybe a PowerVR MBX Lite ?).

===EPD===
Or electronic paper display, EPD is used in many new devices such as the new Motorola motofone, sonys new e-reader and Irex's iliad. The technology provides thin, lightweight, power saving screens using new eink technology. This technology could cut the weight of the phone and its power usage. For more info see: [http://www.eink.com eink's website].

Pro: laserprinter like quality, glossy, very stable image, easy on the eyes. Electronics are similar to TFT. Very low power consumption.

Con: Black and grey only (like a newspaper, but glossy), although there were already color prototypes in 2005. low framerate (5fps). Can reflect light (like paper), backlight is impossible.

===Transreflective===
It would be nice to have (the option of) a transreflective display, which while being less bright, is readable without needing to power the backlight. Then again, it depends on how much power the backlight uses compared to everything else...

==="Slightly" Larger Screen===
43mm x 57mm (2.8inch diagonal) is tiny. A 53mm x 71mm (3.5 inch diagonal) like on the TD035STEE1 would be a nice improvement. A widescreen format at about 53mm x 82.5mminstead of the 3:4 aspect ratio would be even cooler (if one could be found).

==Input devices==

===A laser projection keyboard===
Similar to [http://www.thinkgeek.com/computing/input/8193/ this], except the device would be integrated into the phone itself. Setting the Neo up on a stand on a flat surface (perhaps a stand could be built into the back of the Neo itself, or into a case) would turn the Neo into a micro-laptop. There may be several issues with the inclusion of this technology, including patents, the space required to project the laser grids, and the power consumption. If possible, however, it would make text input a breeze.

===Just a few more Buttons===

2 buttons more, 3 buttons total, mounted sideways would be enough. You could use them for play/pause and loudness controll while the phone remains in your pocket (display locked, ...), reading mails, rss, ebooks,... without wasting display space and so on.

With 5 buttons in total you could possibly emulate a keyboard (2^5 = 32 combinations) for those who know how to play a flute. Useable onehanded, not wasting display space and faster than t9. (It's not faster than T9 - I've used this system with the microwriter agenda --[[User:Speedevil|Speedevil]] 00:00, 2 July 2007 (CEST)) Hopefully this is not patented already.

===D-Pad and Buttons===
*Adding a D-pad (to the bottom of the phone) and 2 to 4 buttons (to the top) would provide some tactile input controls, in addition to the touchscreen. They could be used as shortcut keys in the menu, or playback control when playing media. When the phone is held sideways, they can be used as games controls. (With touchscreen alone, gameplay options are limited)

Game buttons would be best on both sides of the screen. The larger the buttons, the better. 2x 4 buttons in up-down-left-right configuration + some extra buttons separately a bit lower on the device would be good for many for emulation games.

Here is a concept drawing of a possible neo1973 gaming version:
(This has a 4-way direction pad, 8 way may be better for gaming)
<br/>
[[Image:Neogame90.jpg]]
<br/>
Shoulder buttons would be a great addition, too. It would be interesting if there was a total 4 of them, one for every corner. It would make the phone very flexible for rotating and 2 to 6 players playing on one device.
<br/>

===Thumb keyboard or keyboard attachment accessory===
*Could be slide out or clamshell (hinge on long side) design with an external OLED. The keyboard should be protected when not in use.
*Could be a clip on keyboard that attaches to the serial port or communicates by bluetooth (not preferred for permanent keyboard users).
*Cheap clippable miniusb keyboard
*One of the layouts proposed in [[Hardware:Keyboards]]
* What about virtual keyboard? [[http://www.extremetech.com/article2/0,3973,539778,00.asp Keyboard]]

===Analogue Controllers===

====Trackball====
A trackball would provide an efficient mouse-like interface in a very compact package. As exemplified in the newer Blackberry® models.
Maybe instead an optical sensor as are used in mice could be used so that the whole phone can be moved over a surface just like a mouse. (It could function as a Bluetooth mouse for other devices like laptop computers: see [[Bluetooth_Support#Acting_as_HID_device]]. Adding one other two-axis analogue input (possibly just the screen) would make the Neo usable as a TrackPoint or scroll-and-tilt mouse.) The same sensor might be usable as a barcode reader.

====Analog Joystick====
A joystick, or [http://www.extremetech.com/article2/0,1697,1772689,00.asp Rollermouse]-like device would provide additional control, compared with touchscreen only.
*A standard [http://en.wikipedia.org/wiki/Pointing_stick pointing stick (ie. TrackPoint)] might serve well. As a fairly standard part, might they be quite inexpensive?

====Dual analogues====
Dual analogue controllers (one trackball or joystick above, one below the screen, most likely) might even be feasible. That might be overkill since the accelerometers or touchscreen can be used to provide a second analogue input. But it would be nice to have four axes of analogue control without having to tilt the screen away from you or partly cover it with your hand.

===TV/radio receiver===
[[Digital Television]], [[Digital Radio]] or even normal analogue TV/radio is available widely in the world. Though unfortunately in various different forms. In markets where one standard is widespread, and hardware is suitable, it would be a great extension of the phone to a general entertainment device for when you're away from home. Multi standard devices would be ideal, but may not be small, low-power, or cheap.

===Accelerometer===
This enables the phone to sense which direction 'down' is, and to sense any movements the phone makes.

See [[Accelerometer Fundamentals]] for more information on accelerometers as they may be used in phones.

In some cases integrated gyroscopes may also be needed.

*[[Wishlist:3D Viewport|3D Viewport]]
*[[Wishlist:Computer Mouse|Computer Mouse]]
*[[Wishlist:Determine Position|Determine Position]]
*[[Wishlist:Dynamic Screen Orientation|Dynamic Screen Orientation]]
*Change media player playlist when jogging vs walking.
*Attempt to use to stabilise any future camera.

This feature is scheduled for inclusion in the phase 2 Neo1973, currently slated for release in October 2007.

===Side-Mounted Touch Strip===
Add a "touch strip" sensor onto the side of the phone which can be used to scroll. By having it on the side you can use your thumb to scroll comfortably while holding the phone one-handed. An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. The Analog Devices chip seems better suited due to it's smaller allowable element size. With the AD7143 you can have an 8-element (128-position) 25mm long strip - Perfect!.

Would it be possible to use the phone as a wiimote ?

===Heart Rate Compatibility===

An RF interface to receive data from popular heart rate straps (Polar, Garmin, Sigma, Suunto, etc.). This would go along well with the existing GPS functionality and possible future Accelerometer functionality to make for a full-blown workout tool.

Software can be written to track heart rate along a running, cycling, skiing, swimming loop, to monitor max and min heart rate, to match heart rate data to GPS coordinates and print map data w/ relevant data.

===Digital compass===
A digital compass is useful for orienting maps to the terrain and other location/direction/orientation based applications (... is 300 meter that way) when the user is standing still (regardless of GPS reception) and for following a bearing when GPS reception is poor or speed is low.

===Thermometer===
An electronic thermometer might become handy for some users.

There are very small [[I2C]] devices available, that could easily integrate to the existing bus. For example [http://focus.ti.com/docs/prod/folders/print/tmp100.html this one from ti].

===Barometer and Variometer===

A Barometer measures air pressure. This can be used to give weather information, and also as a variometer, to sense relative altitude. Variometers are commonly used in flying microlight and ultralight aircraft, to get accurate relative altitude.

See [[Wish List - Hardware - Atmospheric]] for more information.

===Finger print sensor===
A fingerprint sensor gives easy and fast access to the phone, could lock the touchscreen etc. An example of this device can be found at [http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_BrowseCatalog-Start?CategoryName=cpu_VAIONotebookComputers_UX_Series&Dept=computers Sony UX17].

Most fingerprint sensors in the embedded market include a navigation mode, where they work similar to either a touch-stick or touch-pad of a laptop.

===Barcode Scanner===
*less cpu intensive and more reliable than camera+ocr
*though, bluetooth-enabled readers are already available.

===Light Sensor===
Ability to sense ambient light, and act accordingly. i.e if it's 3am and LightValue<.1 then Ring Quietly.

===Wheel===
A navigation wheel like on a sony/ericsson 810i would be nice.

===Proximity Sensor===
Switch off backlight when you place the phone to your ear. Prevent accidental activation of speakerphone or other sounds when the phone is near the ear (prevent hearing damage). Possibly switch the speakerphone on or off automatically depending on if the phone is by your head or not.

==Expansion==

===MMC/SD/SDIO slot (rather than?) miniSD or microSD===
*Cheaper, more durable cards in a widely accepted format.
*Cards are harder to lose
*Wider selection of accessories, including SDIO accessories.
*Make externally available so that larger length SDIO cards can be used (thinking about SDIO WLAN here)
*[http://en.wikipedia.org/wiki/Secure_Digital_card#SDHC SDHC] compatible. It seems to already have the right hardware for it - see [[Neo1973_Hardware#microSD-Card]].

===Two SD slots===
*Micro SD for /home partition.
*Hot swappable mini or normal SD for movie, music etc.

=== USB ===
* USB 2.0
* Powered, to avoid having to carry around a hub for when you want to occasionally plug in a memory stick. Many powered hubs will not recognize a totally unpowered host.
* OTG (is this maybe supported already ?)
* Bootable USB device emulation: the possibility to boot any computer on a bootable flagged partition of the transflash.

===Wireless USB support===
[http://en.wikipedia.org/wiki/Wireless_USB Wireless USB] is the wireless version of USB offering data-rates up to 480 Mbit/s over short distances (<3 meter). Chipsets suitable for a phone are likely to take some time to be available.

===SIR/FIR transceiver (Serial Infrared) / IR remote control ===
*An infrared transceiver is cheap, small, and useful for sync with many laptops and mobile phones.
*Replace/emulate all IR-based remote controls used for your tv, vcr, etc on your neo cell phone.
** replaces multiple 'dumb' devices with a single intelligent device (your neo) that you will probably carry with you at all times anyway.
**Command sets should be retrieved from a database or learned from other less intelligent remote control devices with macros.
**reduces clutter, particularly in the living room.
**inceases the neo's practical status as an 'always-have' device.

Other uses.
*Detecting reflections from inside of a caddy, and switching from active mode.
*FIR would be a nice option, as it's some 40 times faster than SIR.

==Output devices==

===LED===
*A blinking LED would be a cheap, low power way to inform the user of new SMS/Email....
**An alternative to this would be for one small part of the LCD to be separately backlit.
**This requires the CPU and LCD to be somewhat active, to keep the LCD refreshed, but gives much more information.

*For example a multicolor LED which pulses yellow for GSM/GPRS transmit, blue for Bluetooth/Wifi, green to indicate non-urgent information - missed call etc, red to indicate battery low or other urgent notices.

**The LED and button ideas could be combined: illuminated buttons.
**It must be possible to completely disable the LED to save power or other personal preferences.

=== Flashlight ===
For finding keys, or any other application. May also optionally pulse in time with ring, to make phone more visible.
This is really well done in Nokia 5500.

=== FM transmitter ===
Small FM transmitter to output to car, and other nearby radios.

===HAC Compliance===
[http://quux.wiki.zoho.com/WhereAreHACphones.html Here] is some summary/discussion of how hearing aid compliance rules work in the US. Specifically it would be nice to see the phone include a [http://www.hearingresearch.org/Dr.Ross/telecoil_and_telephones.htm telecoil], which allows the phone to connect wirelessly to many standard hearing aids.

==Mobile Communication options==

===Generic Access Network / Unlicensed Mobile Access===
This technology requires cooperation from the cellular provider, but [http://en.wikipedia.org/wiki/Unlicensed_Mobile_Access UMA/GAN] is already offered by T-Mobile in the United States, and perhaps others in other countries. Allowing the user to roam from GSM to wifi, this technology can save the end user a significant amount of money, and also allow the user to deploy coverage where there was none before. There are only a few UMA capable phones currently, but it would be great if this could be made to work on a phase 2 type OpenMoko device.

===Faster/better mobile connectivity.===
[http://en.wikipedia.org/wiki/Gsm GSM]/[http://en.wikipedia.org/wiki/GPRS GPRS] is at best slow. Ideally supporting [http://en.wikipedia.org/wiki/EDGE EDGE ]- which is an evolved form of GPRS. [http://en.wikipedia.org/wiki/UMTS UMTS] - which is widespread in Europe, [http://en.wikipedia.org/wiki/HSDPA HSDPA] (asia) and any other mobile standards would be nice for faster data connectivity and coverage.
It is unlikely that all of these will be supported initially, but it is a goal.
Until that goal is reached, it is likely that some phones will be brought out for various specific markets - Europe, Asia, US.

===CDMA EV-DO support===
While multiple SIM support is really arguable, a SIM (GSM) + RIM (CDMA) support would generally be a great feature.
EVDO is a 3G standard and it's worth to get supported.

===Ability to use multiple SIMs/networks===
* External SIM sockets are widely available in China, a dual external socket would be a very good solution.
* [http://www.fonefunshop.co.uk/dualsim/digital.htm Dual SIM card kit] - two SIMs are trimmed and combined, software supportwould be needed, and both can't be used at once...
* Some networks support multiple numbers on one SIM. Unfortunately this won't allow split networks.
* A second/dual GSM module would allow full use of both sims at all times.
* As a hack, [http://wiki.openmoko.org/wiki/Wish_List#Bluetooth_powered_Multi-SIM_support use another mobile via BT].
** As many as three SIM slots would be genuinely useful, especially for a 3G phone - some 3G data tariffs are only available on data-only SIMs. A user could quite reasonably have one SIM for data, once SIM for his personal voice calls, and a third SIM for his business number.

===PMR446/FRS Radio===
* Include a PMR/FRS Radio.
* A two-way walkie talkie lets you use the phone to communicate with friends without requiring a GSM connection (crowded networks at festivals, at locations with no GSM coverage).

===DECT/GAP===
* Include a DECT/GAP transceiver so you can use your home and/or office PSTN line

==Casing==
See also: [[Alternate Neo1973 case designs]] for a list of cases being considered for design/manufacture by the community.

===[[Expansion Back]]===
* Replacement backs with additional features ranging from solar power, larger batteries, extra hardware, ...

===Space efficient Lanyard===
The hole at the bottom of the phone takes a lot of space. A Kensington Security Slot could be used instead.

=== Ruggedized version ===
We need something you can drop from 4 feet in to a puddle of dirty water on construction site. Sunlight readable display. The big ugly pseudo military version.

=== Transparent ===
Make a transparent, see-through casing. Why do we need a closed casing for open hardware and open software? Show the world it is a truly Free/Open source phone.

===[[Wishlist:Expansion Front|Expansion Front]]===
Replacement fronts with e.g. extra buttons.

==Misc==
===Galileo/GLONASS/GPS receiver===
*A multi-standard satellite positioning module would be nice eventually, it does not seem to be near-term due to chipset availability problems. Galileo is the to be launched (2011) European positioning system. GLONASS is the already existing Russian one.

===X10 RF Remote===
Many PC-based media centers are being equipped with an RF (433 MHz) / X10-based remote control. The [http://en.wikipedia.org/wiki/X10_(industry_standard) X10] protocol also facilitates home automation to control lamps, switches, etc.
The advantages of using RF for control instead of Infra-red this that it also works when furniture, walls, or doors are blocking the path between RF remote and the equipment or device. [http://www.lirc.org/ Lirc] supports X10-based RF remotes (but expects having an USB RF receiver attached to the media center).

===RFID tag/RFID Reader===
* Implementation/Cooperation with: [http://www.rfidguardian.org/ RFID-Guardian]
*An enable-able tag would be of use - for example being able to use the phone to open doors, or cars. Unfortunately, it's moderately hard to do secure programmable tags that are compatible with existing systems, for obvious reasons.

===Less weight===
* Work on the weight of the Neo1973 and following devices. At the present time the Neo1973 is just a moderate / normal business or multimedia phone. The ordinary "user" may want something lighter. Take a look at the following table, that's the Neo1973 compared with other common bussiness or multimedia phones.
{|border="1"
| Neo1973 || iPhone || Sony Ericsson P990i || Nokia E65
|-
| 184 g || 135 g || 150 g || 115 g
|-
|}

===Make it smaller===
* To stay within physical matters: Maybe the Neo1973 is also just a normal business/multimedia phone when looking at the size. It would be great the shrink it a bit. Especially the thickness of 18.5 mm could be worked on!

===Standard 3.5mm headphone jack===
The Neo1973 uses a 4-conductor 2.5mm jack for stereo headphones and a microphone. 2.5mm jacks are the commonest headset format.

Adapters to 2.5mm are of course available, but 3.5mm jacks are much more robust.

There is an emerging convention used in the Nokia N800 and some other devices. A 4-conductor 3.5mm jack that can use a microphone with special headsets, but can also be used with off-the-shelf 3.5mm stereo headphones.

Neglecting space limitations, multiple sockets - 2.5mm and 3.5mm would be nice. Probably not practical in a phone.
Other expanded plugs might allow remote controls.

Other uses might be better met using bluetooth, or USB audio.

===Laser Pointer===
Include a built in laser pointer. Everything is better with lasers.

===Completely free hardware===
Consider selling one device with absolutely no non-free components in it, even if that means dropping the GSM support. I believe having one such device available would be good, because then it could be recommended by organizations like the FSF which typically never recommends anything if it has even a little non-free code in it.

=== Consider economy / inexpensive / less featured edition ===
Some people want less features, because they do not need them. Leaving out some features either lets the phone get smaller or possibly enhances battery live.

One big suggestion in this area is a b/w lower res display instead of the big color display.

==Related Hardware==

These are consumer units that the Neo1973 can be considered to be in competition with, based on featureset and price point.

===PSP===

Portable Game System
Price: $170

Interfaces:
Wifi
IR
USB (terminal device only)
Headset (audio out + mic in)
Game keys
Memory Stick

Accessories:
GPS
Camera

Features:

Multimedia: MP3, MP4, jpg, AAC, ATRAC
Multimedia capability is adequate. Controls are not necessarily intuitive, given that it's a gaming unit, and not a media player, though third party and earphone jack media remote control is available. Memory is provided by removable flash (Sony Memory Stick, proprietary) up to 4Gb in size, which is plenty large enough for movies at full resolution. And the screen! My god, it's full of stars! The PSP screen is pretty much the best screen going, both in terms of size and clarity, unless the iPhone has done better. Unlike the iPhone and the Neo1973, no touchscreen. UMD is irrelevant to this discussion.

Networking:
TCP/IP over Wifi. Applications include network firmware update, RSS/Podcast downloading and streaming, internet video viewing using Sony's Location Free Base Station (ala Slingbox), VoIP, and a web browser.

Flaws:
No keyboard, and no keyboard support, neither infrared nor USB. And the text entry UI relies on, ahem, cellphone styled number keying. Too much Sony propriety.

===Sony Mylo===

Personal portable communicator
$300

Interfaces:
Qwerty keyboard
Game style function buttons
Wifi
USB
headset+mic
Memory Stick

Features:

Multimedia: MP3, MP4, jpg, AAC, ATRAC
Network: Skype VOIP, Yahoo, Google, and Skype IM.

===Palm TX===

PDA
$300

Interfaces:
Stylus
SD Card
Wifi
Bluetooth
Serial port
IR
Optional keyboard

Features:
Multimedia: jpg, mp3, mp4
Network: Wifi, Bluetooth. Wide range of third party TCP/IP apps available

===[[iPhone]]===

[[Category:Hardware ideas| ]]
[[Category:User]]

Variometer

2007-07-23T21:48:32Z

Johan: /* Signal Conditioning */

[[Category:Hardware]]

===Variometer===
The variometer signal is simply the derivative of the barometer signal. It gives a much more accurate vertical speed signal than is possible with GPS. It would probably be best to filter and differentiate the analog pressure signal and then digitize. This kind of measurement is used by the flee flying community (hanggliding, paragliding, ballooning). A device that allows teams of pilots to share position and speed (with accurate vertical speed) data would be lots of fun.
[http://en.wikipedia.org/wiki/Variometer Variometer Reference]

====Hardware====

References to applicable transducers:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX4100 Freescale MPX4100 (was Motorola)]

====Signal Conditioning====

The absolute pressure signal needs to be:
#Differentiated
#Filtered

*Operational amplifiers in the following configuration:

See the signal conditioning example in this [http://www.freescale.com/files/sensors/doc/app_note/AN1326.pdf Application Note]<br \>
It might be best to use a single chip solution if we can find the right fit e.g.: [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4590 Max1464]

====A/D====
We would need two A/D channels:
#Absolute Pressure - 12 bit minimum (calc needed)
#Differential Pressure - 10 bit minimum (calc needed)

[http://www.freescale.com/files/sensors/doc/app_note/AN1100.pdf Extending 8 bit sampling to a usable range for pressure sensing]

====Driver Code====
The driver code samples the input channels and converts the input values from pressure to altitude:

The relationship between static pressure and pressure altitude is defined in terms of the properties of the International Standard Atmosphere. Up to 36,090 ft this can be expressed as:

<math>
z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122}
</math>

Where:

*z = pressure altitude (meter)
*<math>P_{ind}</math> = static pressure (kPa)

These values are provided to listeners in multiple applications.
The sample rate should be application adjustable to conserve power.

====Application code====
Applications can use the altitude data or combine the data with GPS and accelerometer data.
Commonly Kalman filter/observer techniques are used to combine data from multiple sensor types into a robust(with respect to sensor noise), high accuracy estimate of position and speed in 3 axis.

'''References:'''
*[http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html The Kalman Filter: Navigation's Integration Workhorse]
*[http://www.cs.unc.edu/~welch/kalman/ Kalman Filter Portal from the University of North Carolina at Chapel Hill]
*[http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter article on Wikipedia]

=====Variometer Code=====
Combine measurements as described above.
Apply knowledge about the aircraft dynamics to increase accuracy:
*Total Energy compensation
*Relative Netto Compensation - use accelerometer data to sense when glider is turning in a thermal

'''User Interface'''

*Display speed data in ergonomic manner.
*Display speed for pilots in group.
*Visual and audible guidance to pilot with best climb rate (given reasonable proximity)

Variometer

2007-07-23T21:25:44Z

Johan: /* Signal Conditioning */

[[Category:Hardware]]

===Variometer===
The variometer signal is simply the derivative of the barometer signal. It gives a much more accurate vertical speed signal than is possible with GPS. It would probably be best to filter and differentiate the analog pressure signal and then digitize. This kind of measurement is used by the flee flying community (hanggliding, paragliding, ballooning). A device that allows teams of pilots to share position and speed (with accurate vertical speed) data would be lots of fun.
[http://en.wikipedia.org/wiki/Variometer Variometer Reference]

====Hardware====

References to applicable transducers:
*[http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX4100 Freescale MPX4100 (was Motorola)]

====Signal Conditioning====

The absolute pressure signal needs to be:
#Differentiated
#Filtered

*Operational amplifiers in the following configuration:

See the signal conditioning example in this [http://www.freescale.com/files/sensors/doc/app_note/AN1326.pdf Application Note]<br \>
It might be best to use a single chip solution if we can find the right fit e.g.: [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3482 Max1463]

====A/D====
We would need two A/D channels:
#Absolute Pressure - 12 bit minimum (calc needed)
#Differential Pressure - 10 bit minimum (calc needed)

[http://www.freescale.com/files/sensors/doc/app_note/AN1100.pdf Extending 8 bit sampling to a usable range for pressure sensing]

====Driver Code====
The driver code samples the input channels and converts the input values from pressure to altitude:

The relationship between static pressure and pressure altitude is defined in terms of the properties of the International Standard Atmosphere. Up to 36,090 ft this can be expressed as:

<math>
z =\left (1-\left(\frac{P_{ind}}{101.325}\right)^{0.190263} \right ) \times \frac{87.828}{0.00198122}
</math>

Where:

*z = pressure altitude (meter)
*<math>P_{ind}</math> = static pressure (kPa)

These values are provided to listeners in multiple applications.
The sample rate should be application adjustable to conserve power.

====Application code====
Applications can use the altitude data or combine the data with GPS and accelerometer data.
Commonly Kalman filter/observer techniques are used to combine data from multiple sensor types into a robust(with respect to sensor noise), high accuracy estimate of position and speed in 3 axis.

'''References:'''
*[http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html The Kalman Filter: Navigation's Integration Workhorse]
*[http://www.cs.unc.edu/~welch/kalman/ Kalman Filter Portal from the University of North Carolina at Chapel Hill]
*[http://en.wikipedia.org/wiki/Kalman_filter Kalman Filter article on Wikipedia]

=====Variometer Code=====
Combine measurements as described above.
Apply knowledge about the aircraft dynamics to increase accuracy:
*Total Energy compensation
*Relative Netto Compensation - use accelerometer data to sense when glider is turning in a thermal

'''User Interface'''

*Display speed data in ergonomic manner.
*Display speed for pilots in group.
*Visual and audible guidance to pilot with best climb rate (given reasonable proximity)

Openmoko Local Groups: San Diego

2007-07-22T21:40:39Z

Johan: SD user group

Please add your contact info here:

* Urivan Flores (saaib_at_ciberlinux.net)
* Brian Churchwell (bchurchwell_at_hotmail.com)
* [[User:Johan|Johan Prinsloo]] (johan_ at _ecohowl dot com)

[[Category:Community]]