Wednesday, 8 September 2010
Monday, 30 August 2010
Axdroid 2010-08-31 release 2, get it whilst it's hot.
Axdroid 2010-08-31, get it whilst it's hot.
Axdroid 2010-08-30 release 2, get it whilst it's hot.
Axdroid 2010-08-30, get it whilst it's hot.
So, there's nothing major in here, but I figured I'd update everyone with the current build.
Changes I can remember:
- Android should actually fit on the screen properly for QVGA devices.
- Back/menu keys swapped, so that back is on the end. It just seems right.
- The menu key will now actually let you use the unlock screen. I'm still unsure about it, it seems pointless for Axims since they have a lock switch. Anyway, thanks to Danilo Riso for figuring this one out.
- QVGA setup on X51 hopefully fixed, thanks Max for the updated pixclock value.
- Tweaked some kernel config options etc, perhaps (hopefully) slightly faster.
- EDIT: hopefully fixed the touchscreen for the X50, and hopefully didn't break any X51s. If you happened to download the first release, please try out the second. It would be great if people would run this tool and let me know what it outputs and which device they ran it on.
About my previous post: yes, it refers to WiFi, which I have been working on for the past couple of days. I've figured out how to power WiFI on/off, and added some Axim-specific code to the code from the acx100 driver project. The driver is able to load firmware and communicate with the acx100 successfully. My work on it is in this build, and you can turn WiFi on/off in the settings (usually, it's kinda flaky). However, it scans but never finds any networks. I'll need to find more time to look into it. Hopefully soon, we'll have WiFi working and Axdroid might even become useful :)
Sunday, 29 August 2010
wlan0 Link encap:Ethernet HWaddr 00:09:2D:83:B0:85 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
That is all.
Saturday, 28 August 2010
I believe open source is the right way to do software. If it weren't for open source I certainly wouldn't know as much about computers as I do, and I'm certain it will teach me much more in the future. Plus, we wouldn't have Linux and therefore wouldn't have Android! So, it only seems right that AxDroid also be open :) In theory, you can now build AxDroid (if you have all the tools setup) with the following:
git clone git://github.com/paulburton/axdroid.git cd axdroid ./build.sh
I'm testing building from a clean checkout now, if you hit any problems in building then do let me know. This is the current script as I'm using, and will be updated as I go, so please don't use the scripts I posted a while ago as they're missing certain things.
EDIT 2010-08-29: Fixed git URL
Tuesday, 10 August 2010
Changes since Saturdays build:
- JIT is enabled. It turns out the fancy new JIT compiler Android 2.2 introduced was disabled for ARMv5TE devices for some reason. This build has it enabled (actually I'm now using the dalvik code from the CyanogenMod ROMs).
- CompCache is included. This takes a chunk of RAM and uses it as a compressed swap device, so essentially you can fit more in there at the expense of a little processor time doing the (de)compression. I think on the Axim with so little RAM it will be worthwhile.
- The system apps/frameworks are pre-optimized. This means the Axim doesn't have to do so much work on first boot, so speeds things up a bit. Google for odex or dexpreopt if you want to find out more about that.
- The MMS and camera apps were removed, they don't make much sense on the Axim.
- SD card mount permissions have been fixed - Android can write to your SD card and it couldn't before. This means things like album art in the music app now work.
- I added some code to attempt to figure out which touchscreen model is in use. If X50/X50v users could let me know how it goes that would be great. Basically it looks at the first 100 values it gets and if they look like a X51 series device it assumes that's what it is, otherwise it assumes X50 series. However, having never seen the data from an X50 series device I'm guessing what it will be based on the existing code, so it might be that I'm completely wrong. Also I'm not sure if 100 values will be too few/too many/just right. You might find that it doesn't work for a few seconds then suddenly does work when it decides it's an X50.
- I changed the key mapping, now it goes:
- Calendar = menu
- Contacts = back (I'm considering swapping Calendar/Contacts)
- Email = end call (not sure if this one is of any use)
- Home = home (yay!)
- Wireless = volume up
- Voice record = volume down
- Root FS is now using ext4 rather than ext3. Not sure why I chose ext3 to begin with to be honest :s
- Small tweaks like a boot logo
It seems to me that the speed on my device is now limited by my SD card rather than running out of RAM or anything else. My card is a pretty standard class 2 2GiB one, I may have to invest in a faster one to see if it makes much of a difference. I've also been looking at the internal flash which I think would be much faster than the SD card to read from, but at least for the X51(v) NAND flash it doesn't seem like anyone has ever managed to use the chip with Linux. I've not given in yet though :)
Saturday, 7 August 2010
So, changes since the last one:
- LCD setup should hopefully be fixed. On the X51v the LCD will no longer flicker, and the X51 should no longer be offset. Hopefully this doesn't break the X50/X50v. Thanks to Max Fierke for the QVGA settings from an X51 :)
- The 2700g in the X51v and X50v is never going to be truly useful to us, the only thing we can use it for is an unaccelerated framebuffer - which we already have from the PXA270. However - it has 16MiB of RAM that would sure be handy. Now video RAM for us isn't identical to system RAM - generally it's much slower to read from, but it should hopefully be faster than the SD card anyway. So, I've written code that will initialize the 2700g to the point that we can access it's RAM and make use of it as swap space. So now VGA devices have 2 tiers of swap - when system RAM is full the 2700g RAM will be used, and when that fills up the SD card swap.img file will be used. Hopefully this will help speed things up a little for the X51v & X50v.
- Various small tweaks to maybe help speed it up a little, such as mounting with the noatime option.
Sunday, 1 August 2010
|Axdroid Rocking Out!|
Changes since the last build:
- I rewrote my build scripts. Doesn't mean much to you as a user, although the initial hit on the startup time is much reduced now. Dalvik still has to do it's thing and compile everything the first time you boot, but there's no more copying files around.
- Minor changes/tweaks that might help speed things up a little.
- You should no longer need to enable mirror mode before booting :)
- In theory, the LCD should be detected and VGA or QVGA setup as appropriate. That means this build should work on any of X50/X50v/X51/X51v. Though bear in mind that I only own an X51v so that's all it's been tested on.
- Audio support! I finally figured out the audio setup, and it's quite happily playing me some Paramore :) Headphones do work with the kernel code, but I haven't written the jack detect code yet and I don't think Android provides any manual way to use headphones. So basically: speaker only for now.
Sunday, 27 June 2010
Also, for anyone interested, the source for the kernel is now at http://github.com/paulburton/axdroid_kernel
Saturday, 26 June 2010
- Download axdroid_20100625.zip
- Unpack the files from there into the root of an SD card
- Enable mirror mode on your Axim
- Open file explorer on your Axim, navigate to the SD card and run haret
- Click run
- Wait - for quite a long time
Things to do:
- Power button
- Keyguard won't unlock...
- which makes the Axim a fairly pretty clock if you run Android after the initial boot
- disable it? Axim has the lock switch anyway
- SD card mountpoint
- / is loopback to root.img on the SD card, possible to have the SD card under /mnt/sdcard despite that?
- Speed it up if possible
- user rather than eng build may make a difference
Friday, 25 June 2010
Tuesday, 20 April 2010
It's nice and simple to use, the direction buttons at the top left move the scope at the slew rate selected below. Information about the Autostar system is shown along the top. I'm not sure how much functionality I'm going to implement on the mbed itself, but I definitely don't want it to sit there as a dumb translator between the PC & Autostar - that just seems wasteful, but it doesn't hurt to have control from the PC in addition to whatever I do on the mbed.
I even came up with a crazy scheme which might solve the problems with my mounts tracking - stick my webcam in front of the scopes finder and implement something which would watch for movement and move to compensate and keep things in the same positions in the finder. But that would probably be pretty difficult to get working properly and not 100% exact anyway.
Still, I think it's cool to be able to press a button on the PC and have the scope move around, especially considering how long it took me to get it to work :)
Code for the PC app is at http://github.com/paulburton/autostarcontrol It's built with WebKit/Gtk+ and currently very basic. I'll make the mbed code available at some point soon too.
Thursday, 15 April 2010
I just got this to work after many hours of coffee fueled hacking :) The mbed can now speak the Autostars kinda-i2c-but-kinda-not language, and in the pic there has asked the Autostar to report the scopes product name and firmware date.
Next I need to look into how interrupts work on the mbed, as currently as soon as the mbed leaves the scope alone to do anything else (such as writing to the LCD) it will lose sync with the clock signal the Autostar outputs and communicating won't work anymore.
Then I need to look at the commands for moving the scope and reporting its position, and eventually write the locations of some interesting targets onto the microSD card that you can see there in the top right and hook up some buttons to select one and slew the scope to the correct position :)
I'm definitely a fan of the mbed - it feels much more powerful than the arduino I was using previously, there's a lot of example code and libraries for doing things like the LCD output and SD card read/write, and it's nice to be using a proper C++ compiler. The compiler's web based and seems to fail to save at times, though that could be the fault of the dodgy net connection I'm on at the moment... Still, I've developed a game where I try to guess how many attempts it will take to save the code so it's all good fun :P
Also, it's the day before I go to the star party - so I'm not sure if this counts as a success in my planned timing. It does technically work, even if it doesn't do anything useful yet :)
Wednesday, 3 March 2010
Sunday, 24 January 2010
In case you can't read the text on the box in the bad camera-phone photo there, that's an mbed NXP LPC1768 microcontroller. I look forward to playing with it after my current exams end (6 exams is too many by the way...), I'm sure it'll prove to be a fair bit more powerful than my dodgy only-programmable-by-parallel-port arduino which is just visible in the background there. Currently my idea is to rebase my telescope control project around the mbed rather than the arduino and hopefully get some results before the next star party I attend - which gives me about 3 months to get something working.
Anyway, if whomever it was at mbed/ARM that's responsible for sending the mbed ever reads this thank you very much!