I recently read quite a bit of FUD and really felt that it was worth comment even if only as a counter to the points made when someone Google’s the Neo 1973 / Openmoko. I’ll take on each of the points made and correct what is needed. Oh, and just for the record, this text represents my opinions – no-one else’s.
“First of all OpenEmbedded based systems are harder to build, due to the dependency of monotone and the properitary, OE-only, bitbake, and then even another MokoMakefile build wrapper.”
First of all any system that you know nothing about it hard to use. The use of monotone is not an issue, I use a version just for building my OE stuff. Calling bitbake propriatory is like suggesting that every kernel module is propriatory. Bitbake is used to ‘bake’ (make) the recipes (.bb files) and is “derived from Portage, which is the package management system used by the Gentoo Linux distribution.” The source is freely available at berlios – why is there an issue here? It also appears that this author doesn’t understand the role that the MokoMakefile plays. The MokoMakefile was developed by Rod Whitby to help people who are new to OE and OM build and setup it is not part of Openmoko or OpenEmbedded. Really, if they had even bothered to read the wiki entry for it they would have seen this. I guess it’s easier to spout bile than be accurate.
“OpenMoko also is glibc and sysvinit based…”
Ok, I’ll let this slide since it’s true and just the author’s opinion on what is or is not suitable. I’ll come to the speed issue later.
“Forthermore OpenMoko comes with custom Gtk+ widgets and custom Moko libraries and applications, where Gtk+ PDA / phone applications are already available”
For a start “So what?”. Are you suggesting that no one develops anything that already exists? Should we have one email application, one word processor? What about one operating system? Clearly that gripe at Openmoko is just irrelavant. Furthermore you can actually build gpe applications for the Openmoko platform if you want. Take a quick look at what’s installed and you’ll even see that gpe-scap – what we use for screenshots is installed by default.
“yet another Gtk+ PDA / phone application stack equals reinventing the wheel.”
Actually, this is how progress is made. Take a look at the recent work on the moko underground stuff for an example. What’s more in the very next paragraph…
“We therefore started to create a saner, smaller, fully functional T2 based target”
So you decided to reinvent the wheel? Now to your bullet points
“T2 based, no bitbake…”
So you swapped one ‘propriatory’ build system for another?
“uClibC based, frees your phone’s…”
This, we agree on, but it does make building applications outside the tree a lot easier to not use uclibc.
“not sysvinit, bootup in less than 2 minutes…”
My Neo boots in less that 2 minutes all the time.
“GPE based GUI, to re-use existing applications…”
Did you actually write anything yourself then?
“focus on UI functionality early, no endless tinkering and rewriting, “
Wow, someone who writes perfect code and a perfect interface straight off! Oh, wait.. you’re actually using other people’s code so you’re not really doing anything yourself.
“includes just one embeded scripting language…”
Openmoko doesn’t include a scripting language by default, unless you count the shell, but you can install any number of them – including lua.
“just one… …webkit.”
Openmoko uses webkit.
Nothing you have said would inspire me to even take a look at your ‘T2 based’ project, least of all your attitude. Your main gripe seems to be that FIC didn’t use your T2 build system – that and a belief that everything not written by you is crap, as evidenced by your faq.
Builds have been broken again recently, for about 5 days or so due to this,
../../libkoto/libkoto.a(koto-task-view.o): In function `on_note_activated’:
undefined reference to `koto_platform_edit_task’
(just in case someone feels the need to fix it – hint hint )
but that has given me a chance to start poking about with other things. One of those things happened to be smstools3. SMS Server Tools 3 (smstools3) can take an ordinary phone or gsm modem and turn it into an SMS gateway that can send and receive SMS messages. Now, I don’t have a gsm modem but I do have a Neo 1973. Within 5 minutes I had SMS Tools compiled using the Openmoko toolchain. I’ve taken to using the toolchain quite a bit for testing before I create the .bb files so I can do proper building. Once I’d got a compiled smsd, I put together a simple /etc/smsd.conf file for the Neo (listed below).
devices = NEO logfile = /var/log/smsd.log loglevel = 6 outgoing = /var/spool/sms/outgoing checked = /var/spool/sms/checked failed = /var/spool/sms/failed incoming = /var/spool/sms/incoming [NEO] device = /dev/ttySAC0 baudrate=115200 incoming = yes regular_run_interval=3600 regular_run_cmd=AT+CFUN=1 regular_run_cmd=AT+COPS pin = 1234
Obviously the /var/spool/sms directories needed to be created too. Before you start up smsd though you need to kill off gsmd by simply issuing the command
gsmd will then stop and, from what I gather, power off the gsm chip. This bit is fairly important to know, since you actually need the chip to be powered up. We can do this simply by using the command
echo 1 > /sys/devices/platform/neo1973-pm-gsm.0/power_on
smsd can then be started, if you want to stop it forking use the -t switch on the command line. Incidentally, if you want to use the regular_run_xxx commands in your configuration you need to use the latest beta of smstools3. I needed to use them to get the Neo to register with the network, particularly as I’m actually roaming while doing this. To send an sms you simply copy a text file into the /var/spool/sms/outgoing directory – The format of the file in its simplest form is
To: destination-number message-text
That’s its most basic form, you can get much more complex. There are some very nice features in smstools particularly that you can trigger actions on the receipt of SMS messages.
I recently came across a little project which would turn on an LED box when there was mail your gmail account. I thought it was quite interesting and, since I’d had an Arduino Diecimila in my laptop bag for about 6 months and not touched it, I decided to replicate it. The idea was simply to get used to how the Arduino board worked, the project in itself isn’t exactly going to push anyone to their limit. I was right, the code was basically in the examples there was nothing to do. Since we’re selling our house lots of my electronics development stuff has ended up in the loft. I went for a rummage and found some little RGB light globes that a local garden centre had been trying to sell off cheaply at a couple of Euros each. Undoing the screws on the base of the globe revealed a very simple
design, I’d just need to tap into the LEDs and disconnect the chip they used. Before any of this was going to happen I needed to build some sort of prototype to at least be sure that the concept was going to work. Since I didn’t have any RGB LEDs or even one of each red, green and blue I had to settle for a small LED board that had come from an old piece of equipment that I’d bought, literally, just for the parts. There was a slight problem. The led board was red, green and errm… orange. It didn’t really matter at this stage, I was only proving the code and making sure that I could get the whole idea to work before destroying the perfectly useless light globes.
The software side was also fairly straight forward too. In the end I used the SimpleMessageSystem library to handle the serial data since I kept running into issues with the standard serial I/O routines. The SimpleMessageSystem routines basically use white space as variable separators and a <CR> to signify the end of input.
Each of the colour channels can have a value between 0 (zero) and 255 which gives a lot of variation. There’s also the option to pulse the mixed colours.
Initially I was just going to have the 3 LEDs change to their relative brightness but then I hit on the idea of having them fade up and down to the correct value. I have to say it looks much better with the gradual change, although I might just add the option of selecting either gradual or instant to the parameter list.
Now, with a simple command, I can set the RGB value of my light globe.
./rgb-globe -l -b 9600 -p/dev/ttyUSB0 -s “1 255 50 0”
The original code for the command line application came from Tod Kurt and was written to be able to send serial data to the Arduino. I did make some modifications, including a couple of virtual slappings of Tod for using strcpy – I still don’t understand why people don’t pretend that function just does not exist.
I’m considering writing a small GTK application that just has a colour picker to select colours, but that would be in addition to the command line application since this is designed to be used from things like scripts or mail and IM notifications or, as I suspect mine will, build status information for my Openmoko buildhost. The only real issue at the moment is that it’s really not bright enough, I think I need to rethink the orb – maybe it’ll be better at night…
Somone has just directed me to Miro a free, opensource video player and downloader. What’s even better is that it runs on Mac’s Windows PC’s and Linux.This could well be a huge kick in the backside for the likes of Joost who offer a similar experience. The differences are important though. Miro is free, opensource and doesn’t use DRM – although in the long run the lack of DRM may actually hurt Miro. Miro has some good introductory channels for you to browse, you can even download screencasts of how to use it. My problem now is to find more disk space for all those youtube videos of talking cats.. 😉
I look forward to finding an Openmoko channel there soon.
« go back — keep looking »
Current Electricity Use (15min)
- automated home
- Automated It Technology News
- My Acer page
- My Asterisk pages
- My Work in progress (old)
- Noble Race Car
- openmoko / neo 1973 wiki
- planet openmoko
- Spadgecock Cumpants