The most exciting thing about this world is its ever changing quality.

Wednesday, April 29, 2009

ARM Cross Compiler on Windows

Instead of using commercial suite such as RealView, I decided to set up my own cross compiler and development enviroment. The target ARM device has a > 2.6 linux kernel running, and host as usual is on Windows.
  • Install Cygwin with gcc packages and other make tools selected.
  • Get the source for cross compiler
Dan Kegel's crosstool project provides a fully automated build script covering plenty of different architectures and compiler versions. The latest stable version can be found at http://www.kegel.com/crosstool/ or svn from googlecode:

svn checkout http://crosstool.googlecode.com/svn/trunk crosstool

There is a good reference on wikipage for other options.
  • Build the cross compiler in your enviroment for your target device
After checking out the source code, you will find several shell scripts named demo-*.sh under /src. Open the file for the architecture you require, in this case ARM, thus I chosed the demo-arm.sh file. This script has one line for each known working toolchain for this architecture. An example of the demo-arm.sh looks like this:

RESULT_TOP=/opt/crosstool
[...]
#eval `cat arm.dat gcc-4.1.0-glibc-2.2.2.dat` sh all.sh --notest
eval `cat arm.dat gcc-4.1.0-glibc-2.3.2.dat` sh all.sh --notest

If you require a gdbserver to build, you need to add --gdb to the end of the eval command. Running this shell script will build the cross compiler and gcc binaries for you under /opt/crosstool/gcc-4.1.0-glibc-2.3.2/arm-unknown-linux-gnu/bin. You will be likely to get errors as crosstool shell script won't support space in windows style directory in your HOME enviroment setting, however with not so helpful error message "...incorrect number of arguments". To get over this, 

$ printenv HOME
/cygdrive/c/Documents and Settings/
$ HOME=/cygdrive/c/DOCUME~1/
$ ./demo-arm-softfloat.sh
  • It seems a neat idea to install remote file system plugins on Eclipse (+ CDT package as I am using C++). It turned out to be quite a hurdle! I will try to post my tuning on Eclipse (on Windows) to use the cross compiler we just had and transfer binary across to remote Linux OS.

Thursday, April 23, 2009

Android and device computing

I have been playing all the sample code from Android SDK in the last couple of weeks. Being voted as the best supported plugin for Eclipse, ADT works very well for me. (Just for the sake of completeness, you can find the set up using emacs for Android here.) What I particularly like about is the debugging and testing support. The emulator looks pretty cool and you can view all the live process in the Device window. Other than the standard, basic thread monitoring, you can monitor and trace the heap memory after you triggered the heap update on the selected process, similarly for threads contained in that process. You can trace the call stack on each thread. The only pity is that you do not have the full source code for Android library with the SDK, although you can get them from here. LogCat seems to pretty handy as well for dumping the system messages. The other debugging tools have been summarised in developer guide.

I quite like the simple view designer comes with ADT and how xml files are organised as resources. The magic AndroidManifest.xml has also a nice application editing view where you can define your activities, process, tasks and permissions etc. Although there are a few low priority usability bugs such as adding nodes.

As far as testing is concerned, it does not seem to be that straight forward to automate test other than via host os scripts using adb shell command. There are some good discussions on test project on emulator, and here. Within SDK, there are a built-in test framework and mock templates to be used which come quite handy with additional support tools such as emulator control. It would be really helpful to have the full support for all the other peripheral I/O as well, such as USB, Bluetooth, motion sensor etc. At the moment emulator control only offers interface for test input to telephony (with options could be set for different network latency and speed settings) and location based service.

There was one incidence while I was playing with the thread creation. The notepad sample project failed with an exception telling me that thread has stopped from updating UI unexpectedly (I have always had difficulties in understanding what exceptions are expected.). Again, Eric has already caught this out.

In general, HW test for me for Android is quite nice. With another big player joining in the mobile device platform, there is no question that much more interesting applications will come out fairy soon. Although it might need some smart minds to create profitable products. There are news already that manufacturers like Samsung, Skystone and others are looking to adopt open source platform like Android in other embedded system products. The mobile computing device should be able to benefit from this significantly, I think. Apparently, Android has been successfully ported to X86 architecture as well for ASUS.

Rebuild Android kernel seems to be only possible on Linux yet claimed on this well-referenced post. What I have not realised that there are crazy folks actually re-built Mono for Android, to which I would really want to try. It would be fun to see me recompile some of the MS .Net apps using Mono and port to Android. You might have noticed by now that Android is not just a SDK from which you can build smart phone apps. The Linux nature of Android actually offers OS level support for apps development. To enable on-target development, HTC has recently published Android system image (1.5) to help curious developer build a device from scratch. Although there is a discrepancy between developer phone (Android Dev Phone 1) and real one, the latest SDK was setting to reconcile this. I guess I would never know until I try!

Tuesday, April 21, 2009

C++ Test Framework

I am in the process of helping my team to get a grip on test-driven development, with most of them have no experience nor exposure to automation test framework. In the middle of hunting, thanks to Jiayao, (who seems to determinate to save the digital resource for the planet hence not to update his blog anymore) an alternative light weight test framework is introduced - GTest, another xUnit type of testing package. (Is there anything those people do not do?) However, if you only prepare to spend 10 minutes on this subject, you should be looking at Olve's QUnit right now and shut this tab down. Olve has a pretty concise TDD presentation on his blog. Officially you do not have agree with his attitude to all other frameworks :-). There is a quite comprehensive in wiki.

Anyway, what I need is a simple test framework for cross-platform c++ projects. And I put my hands up to say I am a crappy tester and programmer. So this is really just an attempt to clear my own threads. So do not be surprised if you saw some terms you never heard before - it has to be my invention. Candidates on the short list finally come down to:


There was a good summary from Snappy Touch about using unit test framework in game and iPhone development. My list is much simpler:

  • Licensce free (I am sorry, but this has to be on top of my list. It is not about price; it is the principle :-))
  • Passed my 30 mins HW test. (30 minutes for me to run a Hello World program successfully, officially in this case is Hello Test World.)
  • Robust. I REALLY do not want to spend a second in debugging the framework itself!
  • Most of test framework is about predefined macros, fixtures etc. To me, it has to be just as easy as using a probe. Minimum code snippets required for invoking the actually test and output test results. 
  • Support good test template for input of expected results (whether it is a value, condition check, status machine transition, whatever). This is actually the most tricky one, in my opinion.
  • Test code itself MUST be easy to port. In addition to the no-dependencies on non-standard libraries contraint, I found it is extremely important to leave those compiler-dependent features out, otherwise, we will spend awful a lot of time in figuring out what the heck has went wrong when test failed miserably after you come out from Microsoft illusion to the reality, on target device, not mention after tools such as Lint is applied to assure the code quality itself.
  • Handles exceptions well. Remember my days in Symbian, one thing I really loved is the replacement concept to exception as in Panic!
  • It would be very nice if it comes with some scripts available to kick off the automated build and run process.
Maybe I should cook out my own test framework someday, just for fun...

Monday, April 20, 2009

When all these are over

I still remember one of interviews I had few years ago with DataConnection. It is one of these companies that appears really attractive with its growth graph. The reason was quite simple, I failed, which does not happen very often. DC has been known as a company has the lowest attrition rate while most strict interview process. Anyway, I failed the second round.

I can't remember the guy's name but what I do remember is the question. We (5 of us sitting in a small teeny room, and I bet someone was peeking us through the window) were asked to present a solution to resolve TCP transmission for ancient Greek philosophers. What I have had is an unforgettable session with this guy in another 'interrogating' room. I was pretty sure that I would get that job at that point, until he helped me to rip all the fuzzy part of my brain apart. Surely I still appreciate what he has done there. I quit convincing myself that I got a grip on something I did not really see through.

What is rather interesting to me is that DC has really spent significant amount of time, efforts in looking for the best people, not about what kind of experience they have, but the way they approach things. Officially I was not the right person at that time. The fact they have managed to maintain a consective growth ever since they kicked off in 1982 owes to their dedication and determination to only take the best on board. It is quite easy and convenient to get over with every recruitment, every personnel change, every up and down phase of a business unit. I have seen quite often people shrugging their shoulders and admitted that there is nothing more we can do and it just happened. It seems like we have done nothing incorrect and just bad luck. I can't help thinking that if luck is really about probability, how come the damn thing just keeps hitting us all the time!

During one conversation I have just had with our HR director, I have tried to subtlely expressed my opinion - 2, 3 years is a short period of a company's history, probably in one's whole career life. However, every compromise we made has an impact on what we would like to shape the team into. Flexibility becomes such an easy excuse for lack of capability for making decision.

What I have realised so far is, you can not really tell the fact nor the future from what has happend (in one's cv for instance), just like you have no idea which cycle path I have just taken to get here; while you will have pretty good chance to guess where I would be heading to from the way I took from here.