Openmoko - User contributions [en]

Talk:I2C Compass

2009-07-27T02:28:05Z

Kagee: /* Ready-made module */

= Pre-Orders =
Pre-orders of anything are non-binding so far and are to evaluate interest by the community. Please sign your name in the appropriate section.
== PCB only ==

== DIY-Kit ==

== Ready-made module ==
[[User:Kagee|Kagee]] 02:28, 27 July 2009 (UTC)

=Updates=
As I proceed through the project, updates on my progress will show up here
== Userspace vs kernel module ==
Initial research in Linux I2C implementation (yes, believe it or not, I dived into this head-first without any prior knowledge of how linux i2c worked) revealed that besides direct kernel-space adressing, I2C devices can also be adressed from userspace via the device file system by means of the i2c-dev module. Since it will apparently be quite easy to actually bake together the contraption once I uncover a source of parts (which I haven't really looked into much so far), be ready to access the module from userspace for the time being, because actually writing a dedicated kernel module for the chip will definitely be the trickier part of the project. --[[User:Drdeath|Drdeath]] 00:14, 26 July 2009 (UTC)
== HMC6352 vs HMC5843 ==
The 6352 has the simpler peripheral circuitry, which means less space consumption, but is considerably bigger itself.
The 5843 is smaller on its own, but has the disadvantage of needing a rather big capacitor in the periphery, which will be as big as the chip itself. The real advantage of the 5843 is that is is 3-axis, meaning that the device will not need to be held horizontal for accurate measurements. Currently I am leaning heavily towards the 5843. initial experiments will have to show how we can pull off stuffing the (in comparison) monstrous capacitor into the space available and still have enough room for wiring and chip plus all the other little gadgets and gizmos that are needed to make the whole contraption work.--[[User:Drdeath|Drdeath]] 00:32, 26 July 2009 (UTC)
== Pricing Update ==
Supply of the HMC5843 is secured, digikey.com has them, and surprise! they are waaay cheaper than expected. Expect cost for the module and diy kit to be on the low end of the initial prediction, or maybe even a bit below!--[[User:Drdeath|Drdeath]] 01:30, 26 July 2009 (UTC)

=== Distribution Hubs to lower prices for everybody ===
One last idea before I turn in (it is past four am here): If enough pre-orders can be scraped together, we can all save money by having people in different countries handle the procurement/distribution of modules and PCBs for their area, thus eliminating the customs fees that would otherwise apply twice (once on me importing the modules into Germany, once more on you importing it to your country). Did I neglect to mention I'm gonna put PCB files and all public domain? Sloppy me. --[[User:Drdeath|Drdeath]] 02:20, 26 July 2009 (UTC)

PS: Even if I have the PCBs made (which is not the best idea since I am subject to VAT) a handfull of PCBs for a few Euros sent in a single package to a single adress are more likely to pass by the customs bloodhounds unnoticed than a constant stream of modules at 40+USD (or more likely 30+ taking into account the more recent developments but I'm not making promises).

I2C Compass

2009-07-27T01:55:23Z

Kagee: /* Links and Resources */

== Announcement ==
I intend to build a I2C Compass module that fits into the cavity upwards the sim card holder and right of the battery.

'''That being said I'd like to explicitly state that everything said below is so far a mere ''' '''''brainstorm''''' '''and nothing more. I'm still evaluating feasibility and make''' ''''' no promises whatsoever!!!'''''

Further announcements and updates can be found on the discussion page.

===Benefits===
While the gps does provide heading information, it computes said by drawing a line between the current and last position generated. Thus it is obvious that the heading generated will
* a) Fall behind increasingly with tightness of turn
* b) Be increasingly jittery and inaccurate with decreasing forward speed, as the gps-inherent jitter will be more and more pronounced.
Therefore it is desirable to have a device installed which generates heading directly from the earth magnetic field instead of by comparison of position.

=== Limitations ===
Unlike the gps, the magnetic compass module is affected by magnetic variation. Also the module will be next to useless pending implementation of it's use by software ad hoc.

== Details ==
The module will most likely consist of a HMC6352 or preferably the 3-axis HMC5843 module on a tiny PCB.
The HMC6352 in principle does not need any additional periphery to function. If the nearby radio circuits should turn out to interfere with the compass function, the addition of two resistors and two capacitors may prove necessary, which should have ample room in the space available. The HMC5843 needs a little more periphery but it should still be manageable in the space available Connections will be made by soldering wires to the test points on top of the main FR PCB.

=== Caveats ===
*It is possible if unlikely that the compass module could itself throw interference into the gps module. In this case, a decoupling capacitor in the power circuit of the compass module may be necessary.
*It is possible that the shielding of the nearby gps and gsm modules renders the magnetic field unusable to a HMC6352, or that the HMC6352, even decoupled, emits interferrence that render either the GPS or the GSM unusable if mounted in that position, either of which would lead to the project having to be given up since there is no other place inside the casing where the chip could be mounted.

=== Request for Contributions ===
I would appreciate contributions in the form of software, especially patches to frontends and gpsd to have them make use of the module. I intend to try and write a module myself, but I don't make any promises yet. '''See first and next paragraph!'''

== Status ==
The module is currently in planning stage.
=== Next Step(s) ===
In that order
* Find out about how the i2c bus can be made use of in linux
* <strike>Find out if a kernel module exists for this chip</strike> I've checked and came up blank.
* Order one or more ICs for testing purposes
* Etch a test board
* If none exists, get started on the kernel module

== Purchase ==
The module is (obviously) not available for purchase yet.

''' Wether or not I proceed to production state with this project depends largely on expression of interest by the community. '''

=== Pricing ===
Please note that these are preliminary figures which may well go either up or down. I will try to find volume discount prices on ICs and post more accurate price/order count relations asap.
*The end price for the complete module will probably be in the range of 40-60 USD exc S/H.
*Bare PCBs will range in the area of 1.50 to 2.00 USD + S/H.
*DIY-Kits with IC and PCB will range between 30 and 50 USD depending on order count.

=== Minimum Order Count ===
Preliminary minimum order counts are in the range of 40 PCBs. Ordering less PCBs is uneconomical.
=== Pre-Order ===
Non-binding pre-order is open effective immediately in the discussion thread of this page.

== Links and Resources ==
*[http://www.magneticsensors.com/datasheets/HMC5843.pdf HMC5843 Datasheet]
*[http://www.sparkfun.com/datasheets/Components/HMC6352.pdf HMC6352 Datasheet]

[[Category:Hardware]]

User:Kagee

2009-07-25T23:37:41Z

Kagee: nobody knows

==Bluetooth Networking==
This really says it all:
<pre>
http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/bluetooth-guide.xml
Thu Jul 16 23:02:01 2009 UTC (9 days ago) by nightmorph
Branch: MAIN
CVS Tags: HEAD
Changes since 1.15: +12 -125 lines
Diff to previous 1.15

updated bluetooth guide, emergency fixes, bug 266690.
we now no longer have a chapter on setting up a PAN,
since nobody knows how the hell to do this.
</pre>

* org.freesmartphone.Usage - method - ListResources ( ) → as - description: List available resources.

*cli-framework will report that that it could not coeenct to bluez - you have to usageiface.RequestResource('Bluetooth') in another cli-framwork session for it to work

Removed several:
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged

<pre>
>>> usageiface.ListResources()
['WiFi', 'Display', 'Bluetooth', 'TEST', 'GSM', 'CPU', 'GPS']

>>> usageiface.GetResourcePolicy('Bluetooth')
'auto'

>>> usageiface.GetResourceState('Bluetooth')
False

>>> usageiface.RequestResource('Bluetooth')

>>> a = usageiface.RequestResource('Bluetooth')
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 622, in call_blocking
message, timeout)
DBusException: org.freesmartphone.Usage.UserExists: User :1.25 already requested Bluetooth

>>> usageiface.GetResourceState('Bluetooth')
True

>>> a = usageiface.ReleaseResource('Bluetooth')

>>> a = usageiface.RequestResource('Bluetooth')

>>> usageiface.GetResourceState('Bluetooth')

>>> a = usageiface.ReleaseResource('Bluetooth')

>>> usageiface.GetResourceState('Bluetooth')
False

>>> a = usageiface.RequestResource('Bluetooth')
</pre>

*cli
<pre>
root@om-gta02:~# hcitool dev
Devices:
hci0 00:06:6E:17:84:32
root@om-gta02:~# hciconfig
hci0: Type: USB
BD Address: 00:06:6E:17:84:32 ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:1111 acl:0 sco:0 events:47 errors:0
TX bytes:449 acl:0 sco:0 commands:47 errors:0

cd ~
cp /etc/default/dropbear .
nano /etc/default/dropbear # DROPBEAR_PORT=22
/etc/init.d/dropbear restart

/etc/bluetooth/main.conf # aaded pass="1234"
</pre>
* http://bluez.sourceforge.net/contrib/HOWTO-PAN (old)

User:Kagee

2009-07-25T23:08:03Z

Kagee:

* org.freesmartphone.Usage - method - ListResources ( ) → as - description: List available resources.

*cli-framework will report that that it could not coeenct to bluez - you have to usageiface.RequestResource('Bluetooth') in another cli-framwork session for it to work

Removed several:
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged

<pre>
>>> usageiface.ListResources()
['WiFi', 'Display', 'Bluetooth', 'TEST', 'GSM', 'CPU', 'GPS']

>>> usageiface.GetResourcePolicy('Bluetooth')
'auto'

>>> usageiface.GetResourceState('Bluetooth')
False

>>> usageiface.RequestResource('Bluetooth')

>>> a = usageiface.RequestResource('Bluetooth')
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 622, in call_blocking
message, timeout)
DBusException: org.freesmartphone.Usage.UserExists: User :1.25 already requested Bluetooth

>>> usageiface.GetResourceState('Bluetooth')
True

>>> a = usageiface.ReleaseResource('Bluetooth')

>>> a = usageiface.RequestResource('Bluetooth')

>>> usageiface.GetResourceState('Bluetooth')

>>> a = usageiface.ReleaseResource('Bluetooth')

>>> usageiface.GetResourceState('Bluetooth')
False

>>> a = usageiface.RequestResource('Bluetooth')
</pre>

*cli
<pre>
root@om-gta02:~# hcitool dev
Devices:
hci0 00:06:6E:17:84:32
root@om-gta02:~# hciconfig
hci0: Type: USB
BD Address: 00:06:6E:17:84:32 ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:1111 acl:0 sco:0 events:47 errors:0
TX bytes:449 acl:0 sco:0 commands:47 errors:0

cd ~
cp /etc/default/dropbear .
nano /etc/default/dropbear # DROPBEAR_PORT=22
/etc/init.d/dropbear restart

/etc/bluetooth/main.conf # aaded pass="1234"
</pre>

User:Kagee

2009-07-25T22:26:12Z

Kagee:

* org.freesmartphone.Usage - method - ListResources ( ) → as - description: List available resources.

*cli-framework
Removed several:
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged

<pre>
>>> usageiface.ListResources()
['WiFi', 'Display', 'Bluetooth', 'TEST', 'GSM', 'CPU', 'GPS']

>>> usageiface.GetResourcePolicy('Bluetooth')
'auto'

>>> usageiface.GetResourceState('Bluetooth')
False

>>> usageiface.RequestResource('Bluetooth')

>>> a = usageiface.RequestResource('Bluetooth')
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 622, in call_blocking
message, timeout)
DBusException: org.freesmartphone.Usage.UserExists: User :1.25 already requested Bluetooth

>>> usageiface.GetResourceState('Bluetooth')
True

>>> a = usageiface.ReleaseResource('Bluetooth')

>>> a = usageiface.RequestResource('Bluetooth')

>>> usageiface.GetResourceState('Bluetooth')

>>> a = usageiface.ReleaseResource('Bluetooth')

>>> usageiface.GetResourceState('Bluetooth')
False

>>> a = usageiface.RequestResource('Bluetooth')
</pre>

*cli
<pre>
root@om-gta02:~# hcitool dev
Devices:
hci0 00:06:6E:17:84:32
root@om-gta02:~# hciconfig
hci0: Type: USB
BD Address: 00:06:6E:17:84:32 ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:1111 acl:0 sco:0 events:47 errors:0
TX bytes:449 acl:0 sco:0 commands:47 errors:0

cd ~
cp /etc/default/dropbear .
nano /etc/default/dropbear # DROPBEAR_PORT=22
/etc/init.d/dropbear restart

/etc/bluetooth/main.conf # aaded pass="1234"
</pre>

User:Kagee

2009-07-25T21:24:40Z

Kagee: New page: org.freesmartphone.Usage Method: ListResources ( ) → as Description: List available resources. Returns as: resources An array of resource names. cli-framework >>> usageiface....

org.freesmartphone.Usage

Method:
ListResources ( ) → as

Description: List available resources.
Returns
as: resources

An array of resource names.

cli-framework
>>> usageiface.ListResources()
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
['WiFi', 'Display', 'Bluetooth', 'TEST', 'GSM', 'CPU', 'GPS']

>>> usageiface.ListResources()
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
['WiFi', 'Display', 'Bluetooth', 'TEST', 'GSM', 'CPU', 'GPS']
>>> usageiface.GetResourcePolicy('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
'auto'
>>> usageiface.GetResourceState('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
False
>>> usageiface.RequestResource('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
>>> a = usageiface.RequestResource('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 622, in call_blocking
message, timeout)
DBusException: org.freesmartphone.Usage.UserExists: User :1.25 already requested Bluetooth
>>> usageiface.GetResourceState('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
True
>>> a = usageiface.ReleaseResource('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
>>> a = usageiface.RequestResource('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
>>> usageiface.GetResourceState('Bluetooth')
>>> a = usageiface.ReleaseResource('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
>>> usageiface.GetResourceState('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
False
>>> a = usageiface.RequestResource('Bluetooth')
Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged
>>>

Ipkg

2008-10-15T18:56:15Z

Kagee: adding pre's around code

'''NB:''' Current (2008-04-04+) builds of Openmoko now come with the syntax compatible [[Opkg]] tool, not ipkg.

{{Todo|Integrate useful content into [[Opkg]] as a usage section.}}

The practical way to install software on Openmoko is with the [http://handhelds.org/moin/moin.cgi/Ipkg Ipkg package manager], possibly via the graphical Application Manager. Naturally, you need to have obtained an Openmoko system by other means initially.

In the shell, "opkg update" will update the list of available packages, "opkg upgrade" will download and install all packages that have a newer version available and "ipkg install new-app" will download and install "new-app".

Have a look at [[Users Repositories]] to get addresses of alternative software repositories, e.g. ScaredyCat's ipkg repository.

== History ==

Ipkg re-implements for embedded systems the functionality of Debian tools dpkg, apt, and apt-get. For example, it uses much less disk space for the package metadata.

== Installing Packages to the Memory Card ==

You can use ipkg to install packages to a folder on the memory card. To do this you'll need the following:

=== Ext2 Formatted Memory Card ===

By default, the memory card comes formated with VFAT (Windows Format). You need to re-format the card with EXT2. You will not be able to view the files on the card using a windows system after this.

To check if your card is using vfat or ext, run the 'mount' command, and look for: /dev/mmcblk0p1 on /media/card.

On the NEO, run the following:
''' This will erase everything on your memory card '''
<pre>
umount /media/card
fdisk /dev/mmcblk0
t
83
w
mke2fs /dev/mmcblk0p1
mount /media/card
</pre>

=== Entry in opkg.conf File ===

In your /etc/opkg.conf file, after "dest root /" add a new line:
<pre>dest card /media/card/opkg</pre>

Create /media/card/opkg folder
<pre>mkdir /media/card/opkg</pre>

=== Installing Packages on the Card ===

When installing a package, use the -d option to have the package installed into the "card" destination:
<pre>opkg install -d card python-core</pre>

This will put all files (binaries and libraries) on the card, under the folder specified in the ipkg.conf file.

=== Linking/Using Packages on the Card ===

Your system will not be able to see the packages that you just added to your card. There are two ways to remedy this.
The better solution is to use ipkg-link from the 'ipkg-utils' package, but 'better' is always subjective - YMMV.

==== 1: Ipkg Utils and ipkg-link ====

Ipkg-utils is a package that provides some additional functionality for ipkg. A very useful tool is ipkg-link, which creates symbolic links for packages installed in non-root locations (such as a card) back to the root file system.

To make this working with Opkg, you've simply to do:
<pre>ln -s /etc/opkg.conf /etc/ipkg.conf
ln -s /media/card/opkg/usr/lib/opkg /media/card/opkg/usr/lib/ipkg</pre>

To get ipkg-utils, run:
<pre>ipkg install ipkg-utils</pre>

To create symbolic links to your root system for a specific package, run: ipkg-link add <package>. For example, for python-core use:
<pre>ipkg-link add python-core</pre>

To create symbolic links for all packages installed in a location, run:
<pre>ipkg-link mount /media/card/ipkg</pre>

The ''ipkg-link remove'' and ''ipkg-link unmount'' commands remove the symlinks for a package or all packages.

There is a list of the options for the ipkg command under "How do I use it?" [http://handhelds.org/moin/moin.cgi/Ipkg here.]

==== 2: Adding the card PATH and LIB directories to your path ====
Another way to add bin and lib files to your system is by modifying your environment variables in /etc/profile as follows:

On the line that defines the PATH variable, add:
<pre>PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin:/media/card/ipkg/usr/bin</pre>

Then, before the 'export' line add:
<pre>LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/media/card/ipkg/usr/lib</pre>

Then modify the 'export' line and add LD_LIBRARY_PATH to the end.

This will let the system see the binary and library files, but it will not see other resources, such as images, configuration files, desktop files, etc. For this reason, ipkg-link is preferred.

Ipkg

2008-10-15T18:54:39Z

Kagee: /* Ext2 Formatted Memory Card */ pre-tags around code

'''NB:''' Current (2008-04-04+) builds of Openmoko now come with the syntax compatible [[Opkg]] tool, not ipkg.

{{Todo|Integrate useful content into [[Opkg]] as a usage section.}}

The practical way to install software on Openmoko is with the [http://handhelds.org/moin/moin.cgi/Ipkg Ipkg package manager], possibly via the graphical Application Manager. Naturally, you need to have obtained an Openmoko system by other means initially.

In the shell, "opkg update" will update the list of available packages, "opkg upgrade" will download and install all packages that have a newer version available and "ipkg install new-app" will download and install "new-app".

Have a look at [[Users Repositories]] to get addresses of alternative software repositories, e.g. ScaredyCat's ipkg repository.

== History ==

Ipkg re-implements for embedded systems the functionality of Debian tools dpkg, apt, and apt-get. For example, it uses much less disk space for the package metadata.

== Installing Packages to the Memory Card ==

You can use ipkg to install packages to a folder on the memory card. To do this you'll need the following:

=== Ext2 Formatted Memory Card ===

By default, the memory card comes formated with VFAT (Windows Format). You need to re-format the card with EXT2. You will not be able to view the files on the card using a windows system after this.

To check if your card is using vfat or ext, run the 'mount' command, and look for: /dev/mmcblk0p1 on /media/card.

On the NEO, run the following:
''' This will erase everything on your memory card '''
<pre>
umount /media/card
fdisk /dev/mmcblk0
t
83
w
mke2fs /dev/mmcblk0p1
mount /media/card
</pre>

=== Entry in opkg.conf File ===

In your /etc/opkg.conf file, after "dest root /" add a new line:
dest card /media/card/opkg

Create /media/card/opkg folder
mkdir /media/card/opkg

=== Installing Packages on the Card ===

When installing a package, use the -d option to have the package installed into the "card" destination:
opkg install -d card python-core

This will put all files (binaries and libraries) on the card, under the folder specified in the ipkg.conf file.

=== Linking/Using Packages on the Card ===

Your system will not be able to see the packages that you just added to your card. There are two ways to remedy this.
The better solution is to use ipkg-link from the 'ipkg-utils' package, but 'better' is always subjective - YMMV.

==== 1: Ipkg Utils and ipkg-link ====

Ipkg-utils is a package that provides some additional functionality for ipkg. A very useful tool is ipkg-link, which creates symbolic links for packages installed in non-root locations (such as a card) back to the root file system.

To make this working with Opkg, you've simply to do:
ln -s /etc/opkg.conf /etc/ipkg.conf
ln -s /media/card/opkg/usr/lib/opkg /media/card/opkg/usr/lib/ipkg

To get ipkg-utils, run:
ipkg install ipkg-utils

To create symbolic links to your root system for a specific package, run: ipkg-link add <package>. For example, for python-core use:
ipkg-link add python-core

To create symbolic links for all packages installed in a location, run:
ipkg-link mount /media/card/ipkg

The ''ipkg-link remove'' and ''ipkg-link unmount'' commands remove the symlinks for a package or all packages.

There is a list of the options for the ipkg command under "How do I use it?" [http://handhelds.org/moin/moin.cgi/Ipkg here.]

==== 2: Adding the card PATH and LIB directories to your path ====
Another way to add bin and lib files to your system is by modifying your environment variables in /etc/profile as follows:

On the line that defines the PATH variable, add:
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin:/media/card/ipkg/usr/bin

Then, before the 'export' line add:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/media/card/ipkg/usr/lib

Then modify the 'export' line and add LD_LIBRARY_PATH to the end.

This will let the system see the binary and library files, but it will not see other resources, such as images, configuration files, desktop files, etc. For this reason, ipkg-link is preferred.

OpenmokoFramework

2008-09-10T18:01:47Z

Kagee: /* Timeline */ update links, ms3

{{Languages|OpenmokoFramework}}
{{FSO}}
{{Distributions|FSO}}

FSO is an abbreviation for FreeSmartphone.Org. With FSO, Openmoko is working on a stable system services software back-end. The framework will be used in forthcoming Openmoko distributions -- a demonstration one is available as FSO-image. For more information see http://www.freesmartphone.org and http://trac.freesmartphone.org .

=Q/A=
* ''Question'': Is this an Openmoko-only thing?
* ''Answer'': No. It's going to be available for all kinds of mobile hardware running Linux, i.e. OpenEZX, XanaduX, HTC/iPAQ, ...
* ''Question'': Is this a part of the current images yet? Is it perhaps the mystic ASU?
* ''Answer'': No.
* ''Question'': When can I see this as part of an image?
* ''Answer'': Not before spring 2009.
* ''Question'': What's the current status?
* ''Answer'': See right below or hop over to http://trac.freesmartphone.org .
** [[OpenmokoFramework/Status Update 1|Status Update 1]]
** [[OpenmokoFramework/Status Update 2|Status Update 2]]
** [[OpenmokoFramework/Status Update 3|Status Update 3]]
** [[OpenmokoFramework/Status Update 4|Status Update 4]]
* ''Question'': How do I work the Zhone (FSO demo app) UI?
* ''Answer'': [[FSO UI Tutorial]]
* ''Question'': What is the easiest way to build it?
* ''Answer'': <pre>wget http://shr.bearstech.com/Makefile; make fso-testing-image</pre> See [[Building_FSO]] for more information.

= Timeline=
* Unknown: milestone 4
* 10/09/2008: [[OpenmokoFramework/Status Update 4|milestone 3]] achieved
* 01/07/2008: [[OpenmokoFramework/Status Update 3|milestone 2]] achieved
* 01/06/2008: [[OpenmokoFramework/Status Update 2|milestone 1]] achieved

=Purposes=
* Give people the infrastructure to create solid and exciting software products based on the Openmoko platform
* Support competing UIs while collaborating on developing services
* Encourage framework users (e.g. application developers) to also contribute to the framework

=Requirements=
* Make it simple
* Concentrate on core services
* Be programming language agnostic
* Be UI toolkit agnostic
* Try to reuse existing technologies as much as possible, but not at the cost of a bad API

=How to achieve that technically=
* Choose [[Dbus|dbus]] as the collaboration line. Below dbus, we can work together. Above dbus, we can differentiate
* Expose features through dbus APIs implemented by UI-agnostic and language-agnostic services (daemons)
* Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms
* By not being afraid of reinventing the wheel for a wheelbarrow if all the existing wheels are made for sports cars

=Mandatory Reading=
* [http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/ Frameworks exist for conceptual integrity]
* [http://humanized.com/weblog/2007/10/05/make_oss_humane/ Ten ways to make more humane open source software]
* [http://www.freesmartphone.org FreeSmartPhone.org Wiki]

=What this is NOT about=
This initiative does not cover low level services such as
* Bootloader, Kernel, or System Init.

This initiative does not cover high level services such as
* X-Window-System, Window Manager, UI Toolkits,
* Application Launchers, Applications, or Fancy UIs.

=Architectural Overview=
[[Image:OpenmokoFramework08.png |823px|frontside]]

=Software Components=

We differentiate between low-level and high-level services -- dbus will be used to communicate horizontally and vertically.

===Low-Level Services===

====Device Control====
The low level device control service manages peripheral control, i.e. controlling power for individual subsystems such as
* GSM, WiFi, Bluetooth, GPS, as well as
* Backlight brightness and power,
* Turning LEDs on and off, etc.
It also deals with
* Charging, suspend/resume,
* Accelerometers, and buttons.
Last but not least, it sends notifications about the user's activity so that listeners have a chance to
* Change to powersaving modes, or
* Lock the device.
We implement the following software for that:
* [http://www.freesmartphone.org/index.php/Implementations/OpenDeviceDaemon odeviced]

====Audio====
The low level audio service relies on a working ALSA device driver with the dmix software mixing plugin (*). On top of that, there is the GStreamer streaming media framework:
* [http://gstreamer.freedesktop.org/ gstreamer]

'''Gstreamer''' is to be used for all kinds of event sounds where a) multiple audio formats need to be supported and b) a latency of about one second is acceptable. This goes for e.g. ring tones, welcome tones, plug indication.

*) Initially, we wanted to use PulseAudio on top of ALSA, howver currently it has serious performance problems on this hardware. [http://lists.openmoko.org/pipermail/devel/2008-July/000253.html]
====GSM====
The low level GSM services expect a modem complying to GSM 07.07, GSM 07.05, and assorted GSM specifications, talking an AT-protocol over a serial line. If GSM 07.10 is supported, we use the multiplexing daemon to export virtual serial lines over which -- again -- AT-protocol can be spoken:
* [http://www.freesmartphone.org/index.php/Implementations/gsm0710muxd gsm0710muxd]

====Bluetooth====
The low level Bluetooth services rely on the official Linux Bluetooth subsystem:
* [http://www.bluez.org BlueZ].

====GPS====
The low level GPS services assume a GPS device that talks NMEA over a device node. We implemented an ogpsd daemon speaking an extended Gypsy API:
* [http://gypsy.freedesktop.org Gypsy]

====Network====
The low level networking service assumes network interfaces, such as USB, Ethernet, Wifi, etc. We rely on the following software here:
* Intel Connection Manager
* PPP

===High Level===

====Usage====
The Usage subsystem is concerned with coordinating application I/O requirements. Applications are not supposed to turn on or off devices, since they do not have any knowledge about concurrent applications that may be also using the device -- think ''reference counting'' for I/O requirements.

With this added layer, we could later think about monitoring subsystems, subsystem usage statistics, or accounting.

See discussion page about PolicyKit.

====Events====
* Signalling events via I/O (ringing, blinking, vibrating)
* Might use fd.o notification API

====PIM====
An intelligent storage database server. This is being carried out as a Google Summer of Code project. See complete description [http://www.neo1973-germany.de/wiki/pyPimd here].

====Context====
* Intelligent context API, integrating location as one -- among other -- sources
* Geoclue?

====[http://www.freesmartphone.org/index.php/Standards/PhoneAPI Phone]====
The phone subsystem can be used to create and manage voices communications. It makes abstraction of the protocol used.

=== [http://www.freesmartphone.org/index.php/Implementations/OpenPreferencesDaemon Preferences] ===
* Settings database

====Network====
* High-level networking queries

=Implementation=

===Completion Status===

====Low-Level====
* Device control: 75%
* Audio: 90%
* GSM: 95%
* GPRS: 95%
* Bluetooth: 80%
* GPS: 95%
* Network: 50%

====High Level====
* Usage: 50%
* Event: 70%
* [http://www.freesmartphone.org/index.php/Implementations/OpenPreferencesDaemon Preferences]: 50%
* Context: 0%
* [[Roadmap/Telephony|Telephony]]: 95%
* Networking: 0%
* PIM: 0%

=Tools=
* [[OpenmokoFramework/mdbus|mdbus]] -- a dbus introspection and interaction utility,
* [[OpenmokoFramework/cli|cli-framework]] -- a python dbus command line interface.
* [[OpenmokoFramework/mickeyterm|mickeyterm]] -- a MUXer-aware minimal terminal emulator.

=The role of Python=

Where we write new code, we will use Python to implement the dbus services. The reason for that being the rapid prototyping nature of Python and the emphasis on the [[Dbus|dbus]] APIs. Using Python, the turnaround times to experiment with APIs are incredibly faster than for using a compiled language such as C or C++.

Once the APIs have been used by application programmers, we can start profiling and possibly reimplement some of the services with daemons written in Vala, ''if'' necessary. We might as well succeed in improving performance by using Pyrex/Cython/Ctypes to keep the benefits of Python.

=Team & Roadmap=

==Team==

* [[User:Mickey|Michael 'Mickey' Lauer]] (team leader) -- Openmoko freelancer, working in Frankfurt/Main, Germany.
* [[User:Charlie| Guillaume 'Charlie' Chereau]] -- Openmoko employee, working fulltime in the Openmoko office, Taipei, Taiwan.
* [[User:Shoragan|Jan 'Shoragan' Luebbe]] -- Openmoko student, working part-time in Brunswick, Germany.
* [[User:DanielWillmann|Daniel 'Alphaone' Willmann]] -- Openmoko student, working part-time in Brunswick, Germany.
* [[User:StefanSchmidt|Stefan Schmidt]] -- Openmoko student, working part-time in Brunswick, Germany.

==Roadmap==

The milestone releases are combined Openmoko Framework and [[Zhone]] releases. Remember: A feature that isn't visible, working, and tested in our framework testing application (Zhone) does ''not'' exist. Until Framework 1.0.0 (later this year), we will not use any versioning in components. Afterwards, individual components may see individual releases.

'''Note: The milestones and tasks moved over to our [http://trac.freesmartphone.org issue tracker].'''

[[Category:Framework| ]]
[[Category:FSO]]