Great Experience with Toshiba Laptop Repair

This is a bit off my regular topics, but I just wanted to thank Toshiba publicly for the amazingly fast repair they performed on my daughters laptop.

My daughters CD/DVD driver was skipping on her laptop. Thinking back to my previous experience with warranty repairs to anything electronic, I told her to kiss her laptop good bye for a few months. So I reluctantly phoned the Toshiba service centre on Wednesday, and the call centre told me to hit their warranty repairs web site. About 20 minutes after I filled in the form a guy phoned me and said their would be a courier arriving shortly. They even had a PDF address label that I just downloaded and printed. Fortunately I had the original packing so it was easy to get it ready. Sure enough, a few hours later a courier turned up and off it went. I waved it a teary fair well, wondering if I would ever see it again! The repair depot was in Perth, about 3000km away.

A day later I get an email that says the repair is complete! WTF?

At 9am Friday morning the laptop is back, about 40 hours after it left my house, despite a round trip of 6000 km. And the repair was completed and it worked fine. I must admit I was amazed at this sort of service.

Well done Toshiba!
eroticas Chicas Fotoskostenlos Asian scatBehaarte hegenLehre Mom zu teen fuckpics Ebony kostenlos pussyPissing verstecktBilder Transsexuelle Vaginaxxx Clits reife Mappics alia shawkat sexyrumble essex 1929 seattgp 3dpornteen model alekanymph sex allentown101 positons sexanalysis strategic alditeen fiction amputee Mapchemistry accredited onlineaccredited colleges hampshire in newcredit sol report accountaccredited buyers representative coursecard merchant account credit casino internetwashington merchant credit account card cheapachieve care in accreditation agedforce air joint tour credit Mapon credit purchases 1940 scredit carpet abbeyace credit program recoverycourses credits students degree institution accreditedave auto sales mass credit 1258derivatives isda credit 2003 definitionsloans wheel 5thaccredited credits degree institution courses students Mapcartoon free movies pornprivate movies pornsexy stars moviehorse free movie sexaebn movies streamingmovies porn cartoon freemovies free asian sexmovie job hand Map

The Louder Router – a low cost PC for the Blind

This post describes a project to build a very low cost PC for the blind using commodity router hardware. It has the potential to dramatically improve the lives of millions of blind people, especially in developing countries. We need some OpenWRT gurus and embedded hardware hackers to help this very worthwhile project!


A few months ago I attended BarCampAdelaide, down in the lovely sea-side suburb of Moana.

Moana beach

I was flicking through a pile of Make magazines that I think Kim Hawtin had brought along. Having never seen a Make magazine before it was a fascinating read – especially in the laid back, geeky atmosphere of a BarCamp.

I came across an article by the remarkable Fernando Botelho. Fernando has a dream – a $200 PC for the blind. Blind people currently need to pay close to $2000 to get a PC, speech synthesiser, and the commercial software they need to use a PC and connect to the Internet. So Fernando came up with the concept of a dedicated PC design just for the blind, that could be built for $200.

Light bulbs went on in my head. Hey – I know how to do this! So I contacted Fernando and with a small team we have been brainstorming this project and even prototyping some of the software on a WRT54GL router.

Blind PC Concept

This is the concept:

  1. There is a range of open source software for the blind, for example screen readers such as YASR, and extensions to emacs such as such as SpeechD-el and Emacspeak that provide a complete “Audio Desktop”. With these packages and a speech synthesiser a blind person can browse the web, use email, chat, and perform text editing.
  2. There are open speech synthesisers such as Festival and Flite that can be used instead of dedicated hardware synthesisers. Software synthesizers do not sound as pleasant as commercial hardware units however the price is right!
  3. Here is the cool bit. A PC for a blind person does not need a screen. Sounds obvious but this has several important implications. A screen is the most expensive part in any PC. No screen means no GUI, which is a major consumer of system resources such as memory, CPU cycles and dedicated hardware. No GUI means console-based applications – a perfect match for free and open source software. The low system requirements mean we can build a Blind PC for less than $50 using hardware similar to that in a commodity router, i.e. much cheaper than a conventional PC!

So the proposed PC will be a box like a small router or Ipod. It will have a headphone jack and possibly a speaker, and a socket for a full size keyboard. It will have a router-class CPU (say 200MHz), and possibly a wireless connection. We need plenty of flash (256 Mbytes minimum) to store the applications and data, but just a modest amount of RAM, say 16-32Mbytes. This sort of box could be mass produced for less than $50 using the same production lines as todays routers.

A Day in the Life of a Blind PC User

A blind person will be able to sit down at work and connect via the wireless or Ethernet. They can then answer email, use chat, and access the web. Imagine communicating with some one who owns one of these boxes. If your were chatting or emailing with them you would not know they are blind. In fact, I will guarantee they would outperform you in many tasks such as typing, memory, and comprehension of verbal information. This simple example shows how this device could make a blind person highly productive in an office environment. That means a job, and an income. All for just $50 and some open software.

When they leave work for the day they pick up their box and hop on the bus. While they are travelling they can play “audio books” or maybe listen to their email. When they get home they associate with their home wireless network and they can use the device to pay a few bills and catch up with friends on line.

A low cost PC for the blind can change the lives of many people. The $2,000 cost for the current solutions is simply impossible for blind children in developing countries. Worldwide there around 6 million blind children who will never be educated using todays expensive technology. A low cost blind PC will get them connected. Get them connected and they can communicate and be educated. They can raise their standard of living, have a great future, and the ability to earn a living.

Ported Software

To test the concept I have implemented chunks of the software on a WRT54G router using the OpenWRT kamikaze build environment. To get around the lack of audio I/O on a WRT I used various techniques to pipe the audio to my x86 laptop over a LAN. An alternative is to use a router with a USB port and a USB sound card.

Thank you very much to the OpenWRT community – I have had a lot of fun working with your software and found it well written and easy to use and modify.

Fortunately Flite (the Festival light speech synthesiser) was already supported. It runs at about 5 times real time on the WRT, which is fast enough for our needs. The speed of execution of Flite was a major concern as this is likely to be the most CPU cycle hungry part of the system.

We have ported (well partially ported) several new packages to OpenWRT:

  1. A full Emacs implementation. That’s right – full blown emacs operating on a WRT! You can even play tetris (M-x tetris) through a terminal! This was tricky to port – emacs uses a bootstrap method during the build procedure which doesn’t map well to a cross compilation environment. So at the moment I just run temacs, which takes a while to start as all the .el files need to be loaded. I also place temacs and the LISP files on a nfs drive, as the internal WRT flash is too small.
  2. Eflite. This is a middleware server that glues applications like Flite and EmacsSpeak together.
  3. Yasr (Yet another Screen Reader). This is a screen reader developed by Michael P. Gorse. It actually works quite well on the WRT. It also uses eflite to access the speech synthesiser. I actually cheated a little bit here and ran the eflite server on my desktop. This was because I couldn’t get the speech samples from eflite to net-cat over my LAN correctly, it worked out easier to run eflite on my PC. I feel comfortable with this hack, as I had already demonstrated eflite and Flite operating on the WRT OK, it’s more a configuration issue that I needed to work around.
  4. I attempted to get EmacsSpeak working on the WRT. The build process for emacspeak requires a bunch of LISP code to be compiled using emacs. Now this is fine when you are building Emacspeak on the same machine as where it will run. However in our case we need to build it on a PC and run on the WRT. So I need to work out a way to run part of the build process on the target WRT system. Tricky, but not impossible. I am sure with some help we can get EmacsSpeak running on the WRT.
  5. Speech-D-el

    Speech-D-el requires a server/middleware package called Speech Dispatcher. However I ran into a snag here – glib version 2 is required for Speech Dispatcher which hasn’t been ported to the WRT (at least not yet). Porting the actual speechd-el code looks straight forward.

    By using the trick of running the speech-dispatcher server on my laptop, I managed to get speechd-el running on the WRT. As explained above this gets us around porting a big library to the WRT (glib 2), which is OK for proving the concept.
    The current problem is that speechd-el runs slooooowly, you press a key and have to a few seconds for the speech. I am not exactly sure why but I have some ideas:

    1. The router processor might not be up to the job.
    2. I may not have built emacs correctly.
    3. I haven’t byte-compiled the speechd-el lisp code (it is suggested in the docs that I do).
    4. Perhaps the fact that I am running the speech dispatcher remotely, there some unwanted buffering going on. Or perhaps the use of NFS for the LISP files.
    5. Emacs by itself runs OK, I can type at normal speed, e.g. I can play games like the built in tetris OK.

    Curiously, Yasr was fast enough. So I guess the speed issue is probably a configuration problem, I can use emacs fine on my old 133MHz Pentium and this router has a faster processor. How much CPU can be involved in processing emacs code for one key stroke?

    Of course more testing is required, I have just typed a few things and not really explored the functionality of speechd-el yet.


    So we have demonstrated the viability of building a low cost Blind PC using commodity, router-class hardware. Several important packages have been partially ported and important functionality (Flite, emacs etc) has been demonstrated.

    Now we would like to open the project for community input. To progress the project further we would really appreciate some help from some people with skills in OpenWRT and embedded hardware.

    Development Plan

    We have three phases planned:

    In Phase 1 we would like to plug together a commodity router, USB sound card, USB memory stick, and a USB keyboard. This is the fastest path to getting a useful product deployed. OpenWRT configuration and software gurus are really need here. We have named this device the Louder Router.

    In Phase 2 we would like to develop a small USB or Ethernet peripheral (e.g. a dongle) that combines sound output, 256M of flash memory, and a keyboard interface. This would reduce the “number of boxes” required to build the system to just two (the router and the dongle). People experienced in microcontroller development would be very useful in this phase – I think a small PIC or Atmel would do the job.

    In Phase 3 we intend to develop a full-custom product and put it into mass production. This will be a neat single box solution at the lowest possible price. Given my experience with similar board-level designs on the Free Telephony Project I am sure such a box can be built for less that $50 in modest volume. Would any hardware/embedded linux people out there like to work on developing this hardware?

    Getting Involved

    We are adopting an open hardware and software approach. This technology can and should be free to all.

    The Blind PC project is hosted on the LouderLinux site (cool name I think). LouderLinux is a community supporting the development of assistive technologies for the blind.

    What we really need are OpenWRT, C, and hardware developers who can can help us integrate and develop the current prototype code into a Louder Router that is deployable to Beta users over the next few months.

    Please email Fernando Botelho for general enquiries and especially if you would like to help out. For technical questions, please contact David Rowe.


    Louder Router Blind PC Project

How To Make Your Kids Rich

This page describes a simple plan to generate $150,000 for your child by the time they turn 21.

The Plan

What you need to supply is:

  • Time: About 20 years is great, more or less time can work if you adjust the plan. The plan works very well if you start when your child is born.
  • Saving. You need to save $8 each work-day. You get weekends off so thats $40 a week. This is the tough bit. Most people can spare $8/day but very few can save it over the long term.

It works like this:

  1. You save $8 a day, $40 a week, or around $2000 a year.
  2. You invest this in a managed share fund that is indexed to the share market. Based on historical performance this will mean an average of around 10% appreciation every year. The share market has many ups and downs, but over the long term, 10% is about right if you reinvest dividends. You are interested in the long term, so all the swings will average out. If you don’t like the share market you could choose some other investment with similar returns like a property fund.
  3. You increase your savings each year based on inflation. For example if the average inflation is 3%, you increase your savings from $40/week in the first year to $41.20 a week in the second year.
  4. You keep this up for 20 years. Your saving and the magic of compound interest means your child now has over $150,000 at age 21. Even with inflation, that still a lot of money, just when they need it the most. Invested wisely, it could make a big difference to your childs life. The cool thing is that unlike you and me kids have a pretty long time horizon, which lets compound interest go to work with a vengeance.

The Spreadsheet

Here is an Excel spreadsheet that shows you how it all works. Here is the same table in PDF form. I wanted to put the table directly in this post but couldn’t work out a nice way of getting a formatted spreadsheet table into WordPress.

BTW I find Excel (or the spreadsheet of your choice) really cool for basic financial modelling like this. It’s a lot of fun to experiment with. If you think part of my model is wrong, try entering your own parameters and see what develops. What is the effect of 5% inflation, or putting $80/week into the plan?

The Results

Does it work? I think so. I started it about 8 years ago (when my first son was born and my daughter was 2) and while not exactly matching the model results both of them could now buy a (small) new car outright. My 8 year old probably has more savings than many 28 year olds. Still, my kids are a few years behind the curves in the spreadsheet which makes me wish I had put in more money earlier. Doh!

On problem is that I am struggling to put the $40/week in. I like to do it in lump sums of a couple of $k a year and my wife often objects when I suggest it. It’s kind of hard to visualise the compounded effect $2k can have over 20 years for many people, especially if you are focussed on paying down a mortgage or have bills to pay. However I can’t think of a better use for my money that my kids future. Can you?

In Australia the government is giving $4,000 to the parents of every new baby born. So when our 3rd child was born last year I invested this baby bonus it in my newborn sons name. I am not sure what most parents do with their baby bonus however I suspect a lot of it ends up being used for flat screen TVs. Now my 11 month old son needs to file a tax return as he made a few hundred dollars in dividends! As my daughter says “he can’t even talk and he is making money”!

capitalization of loan rate interest amountcompanies 100 top loan direct worldstafford 2008 rules loan texasadrienne sloanealberta legal default student loans courtaba loan calculator autoloan bad auto for credit $9,000payday collection loan ambassadorarticles loan adjustable postcard clients rateamerican microloan3 g ringtonetime 1 ringtones purchase100 free downloads ringtone100 free download ringtonetv ringtone 24 seriesmobile to phone ringtones add24 mp3 ringtoneg ringtone for free 3 Mappayoffs loanporthole loanmissouri quarters loanag loans minnesota loan on ratesrepayment formula loanrescue loanuk search loanloan industry servicing Map

Roads and Wealth Creation

For years I have been interested in travel to some of the more remote areas of Australia. Recently I bought an old (but tough) 4WD, and with my children Amy and William we set out for the Flinders Ranges, about 500km north of our home in Adelaide, to spend a few days camping and doing a little off road driving.

One day we visited Arkaba Station, a private property where for $35 we could spend a few hours on a self guided 4WD tour through the station. There was a mixture of terrains; creeks, some very steep (at least for me) and very rough roads. I was really an ideal trip for me, just right for my (very basic) 4WD skill level. We were the only ones on the track for the entire time, and the scenery was very nice, although I was focused mostly on the road. The kids really liked the steep bits and being shaken to pieces on some of the rough roads. They also spotted lots of wild life (Emus and Kangaroos, as well as sheep that are run on the station).

One section was covered with large rocks sticking out at all angles. Our speed was limited to about 5km/hr, and inside the car we were shaking and bouncing all over the place. We could have got out and walked faster. It occurred to me that this was probably a typical road for 99% of history, and that travel at walking pace (and being shaken to pieces if in a vehicle) was probably the norm. This must have made communications very difficult, expensive and therefore very rare.

Driving off road made me appreciate that a simple flat ribbon of bitumen that enables us to travel at highway speeds really is a miracle. The distances we can cover in a few hours on a modern road must have taken days 100 years ago using the poor roads and horse and carts of the time.

Roads as a creater of wealth

One question I have been thinking about lately is “where does wealth come from”. I mean, we all talk about economic growth, which to me means more money in a country/region as a whole, but if an economy grows, we all get richer, so where does the wealth come from? Who is pumping the money in? If we are getting richer, is some one else getting poorer?

Thinking about roads gave me a good example of wealth creation.

Roads allow us to move more efficiently, less effort is required than without them. The government took our taxes and invested them in this infrastructure, now it costs much less to get from A to B. The cost of travel has been reduced.

Lets look at an example. In 1850 Farmer Joe needs to travel a round trip of 100km. He uses his horse and cart and spends two days to travel. In those two days he cannot be doing any other work. Now in 2006 Farmer Joe jumps in his car and travels the 100km in 1 hour. He returns to the farm and can work for 2 full days (minus the 1 hour). That 2 days of extra work that Joe earns income from. This is additional wealth that has been created by the road.

The interesting thing is that no one else had lost anything to make Joe richer. It is a win-win situation. Communications infrastructure (the road) has created wealth, and no one loses.

What about the cost of the road? Well I am assuming that the government paid for this out of the same taxes Joe would have paid anyway. They just decided to spend the taxes on a road rather than a warship or new town hall or something. I am also guessing that the cost of the road is far less than it’s economic benefit to those who use it over the years.

Wealth Creation

Looking around at the people around me I notice that most of are much better off in a material sense that we were say 20 years ago. Much of the stuff we buy (especially consumer goods) is also much cheaper than it was 20 years ago. For example in 1989 I bought a VCR for $1100, I just bought a combined VCR/DVD player in 2006 for $150. Adjusting for inflation thats a cost reduction of about 15 times! Fifteen VCRs for the price on one.

Somehow, wealth has been created. We all have a lot more money. My mother tells my stories about “stretching” the food money to last until pay day in the early 70’s. Now our biggest problem is when are we going to get a flat screen LCD TV?

The only exception to this rule seems to be real estate. My theory here is that real estate prices have been pushed up by demand as people have enough discretionary money now to cover huge interest repayments. Real estate has soaked up excess wealth through the laws of supply and demand.

But I digress. The question I was looking into is “how is wealth created”?

The best answer I have worked out so far (worked out in discussions with several friends) is that: we all get richer as the cost of producing stuff is reduced.

So I think it works like this:

  • Technology is developed that allows something to be produced cheaper than before. For example fertilisers make food production more efficient. Silicon chips lower the cost of electronics.
  • This makes some product or service cheaper to deliver.
  • So we spend less to obtain a given product or service, and have more money free for other things. Like flat screen TVs, or huge interest payments on your mortgage. Or sending our kids to expensive private schools.

Advancing technology is not good for everybody. Some industries get displaced. The development or roads and cars probably put a lot of the horse and cart industry out of business. This must have caused a small group of people a lot of distress, despite the huge benefit to a large number of other people. And yet the world is clearly a better place for having efficient transport.

It is also interesting to see what we do with our increased material wealth. Somehow soaking it up in big interest payments or mobile phone bills doesn’t seem right when there are 10,000 children dying each day from preventable disease. But thats another story. I am currently reading a couple of books on these subjects, and recommend them to you:

Communications Technology for Wealth Creation

I see a lot of parallels in physical communications assets like roads and communications technologies like VOIP and the Internet. They all let us communicate faster and better.

They are engines for wealth creation.

So reducing the cost of communications is a good thing. It lets us communicate faster and cheaper. Reduce the cost enough and maybe some kid in a disadvantaged country can make his first telephone call or obtain an education over the web.


So on balance I think “decreasing the cost of stuff” is a good thing. It is a mechanism for creating wealth. Like the example of roads, it can be win-win – wealth can be created like magic without disadvantaging a large group of others.

I must admit I find this pretty cool. It suggests that we can actually increase wealth (and the material well being of everyone on the planet) in a win-win situation. For us fortunate people in the 1st world this means more gadgets or a nicer house. For the less fortunate it means hope that one day they will be able to eat 3 meals a day and not die of Malaria.
ringtone para nokia 11083589i ringtone nokiasprint free sanyo 4900 ringtonefree sanyo ringtone sprint pcs 8200ringtones vx3200 lg alltelalex etheringtonalltel ringtones lg vx3200composable free ringtone motorola 120e Mapfamosas actrices pornoadvantages analysis gravimetric ofteen porn videos amatuarsex photos amputeesex adora35p phone sexalicia machado porn3movies porn Mapfree porn cartoon moviesmovies porn privatesexy stars moviefree movie horse sexaebn streaming moviesporn movies cartoon freeasian free movies sexjob movie hand Mapnipples youngshemale analpussy bareflintstones hentaiphotos peniscock cummingunderage preteenmature wives Map

A Bit Exact DSP Fairy Tale

Once upon a time in a far off land there was an underpaid pale skinny guy working in an impoverished start up who wanted to build products with fixed point DSP chips in them. The problem was he had just about killed himself doing the same thing many times in the past.

In particular, he seemed to spend a zillion hours debugging intricate fixed point DSP assembler to get products working. All while some project manager who hadn’t written a line of code for 10 years was hovering behind him asking questions like “is it ready” and mumbling something about milestone dates that were ridiculous when proposed, and soon became hilarious after the project started.

So, our hero wondered, “is there a better way”.

How to Build a DSP Based Product

Many DSP products are developed like this:

The academics “brains trust” guys work out a clever new algorithm. Now these guys are way-smart, but tend to express themselves in algebra with lots of Greek letters. They usually have PhDs, and cost a lot, and there aren’t many of them. They might test their brain-child in a simulation algorithm like Matlab:

x = [1.1 2.0 3.0];
y = [2.5 3.0 4.0];
dot = x * y’;

Now this lets them test the algorithm quickly (dot = 20.75), but you can’t run code like this on a real world product due to (a) it runs 10 million times slower than real time and (b) Matlab licences cost $5,000 each and only run on $3000 PCs. Which is a shame when u are building a $99 product.

So some poor engineer then has to make the DSP algorithm work in real time (i.e. fast) on the “target” hardware, a $10 DSP chip. Actually, in general, these guys actually like the detail work this involves. The first step they might do is convert to floating point C:
float x = {1.1,2.0,3.0};
float y = {2.5,3.0,4.0};

float dot(float x[], float y[], int n) {
float d = 0.0;
int i;

for(i=0; i<n; i )
d = x[i]*y[i];

return d;

But the guys & gals in Marketing (they are a breed closely related to Managers, but tend to be more attractive and use airports more) have decided that this must be a low cost product, so a $10 fixed point DSP is chosen.

Now a fixed point DSP is a chip that can perform multiplies and adds quickly, as long as you only use integers. They don’t do floats. So the engineer converts the algorithm to fixed point:
short x = {11,20,30}; /* x*10 */
short y = {25,30,40}; /* x*10 */

int dot(short x[], short y[], int n) {
int d = 0; int i;

for(i=0; i<n; i ) d = x[i]*y[i];

return d; /* returns dot*100 */

Now look what has happened to the x[] and y[] arrays. We have multiplied each number by 10 so we can use an integer to hold the value. If we didn’t scale each number then we would lose information (for example converting the 1.1 to 1) which on certain algorithms would cause problems.

However because each input value is multiplied by 10, that means the result is multiplied by 100 ( 10x * 10y = 100xy ). So we need to take this output scaling into account in any other stages of the algorithm. One more piece of information we need carry around with us as we code. One more source of bugs.

This is a very simple scaling example. In practice it gets much scarier and means you need to hold a lot more information in your head when you program in fixed point (see complex sample below).

There is also the potential of overflow problems. As the output is scaled up by 100, it is easy to overflow the 32 bit range of the integer output, for example if we used x[] and y[] arrays with larger numbers.

I Feel the Need for Speed

The product requires that this routine must run as fast as possible on the DSP chips. So we need to code an optimised version of this routine in assembler:
int dot(short *x, short *y, int len)
int d;

"I0 = %3;\n\t"
"I1 = %4;\n\t"
"A1 = A0 = 0;\n\t"
"R0 = [I0 ] || R1 = [I1 ];\n\t"
"LOOP dot%= LC0 = %5 >> 1;\n\t"
"LOOP_BEGIN dot%=;\n\t"
"A1 = R0.H * R1.H, A0 = R0.L * R1.L
|| R0 = [I0 ]
|| R1 = [I1 ];\n\t"
"LOOP_END dot%=;\n\t"
"R0 = (A0 = A1);\n\t"
"%0 = R0 >> 1;\n\t"
: "=&d" (d), "=&d" (before), "=&d" (after)
: "a" (x), "a" (y), "a" (len)
: "I0", "I1", "A1", "A0", "R0", "R1"

return d;

This is assembler for the Blackfin DSP, the actual code will of course vary for different DSP chips. The important bit is this:
A1 = R0.H * R1.H, A0 = R0.L * R1.L
|| R0 = [I0 ]
|| R1 = [I1 ]

In a single clock cycle, our intrepid DSP performs two parallel 16-bit multiplies, two 16-bit adds, and fetches 2 32 bit words from memory, post incrementing the pointers after each fetch. It does all this 500 million times a second, and sometimes it even gives you the right answer.

But not often. First you need to spend a lot of time getting it all to work right. The assembler is much harder to grok than the previous versions of the algorithm, and you use up a lot of brain power on a myriad of fine details. Get any one of the details wrong and the product is a dud.

The target development environment is also tough. In many cases the feedback you use to debug might be an analogue signal flowing into or out of the product (that is processed internally by the DSP). Or a blinking LED. Sometimes you don’t even know when its really working, bugs can simply slip through. You can’t always stop the code and single step using a debugger as parts of the algorithm depend on real-time activity.

It’s a development/testing/maintenance nightmare.

Bit Exact Assembler

There is a way to ease the pain a little. Lets say there is a bug in the assembler version. The problem is that to debug the algorithm you may need to understand both the assembler and the DSP algorithm, I mean to debug something you need to know how it works, right?

This is OK for a simple algorithm, but what if it is even moderately complex? Then you are dealing with (i) a very complex algorithm and (ii) very complex assembler all at the same time. This is usually too much for mere mortals (and even minor deities). The result is long, painful development, failed projects, late nights, angry spouses, and lots of pizza (well its not all bad I guess).

The trick is to divide and conquer. Make sure we are only hitting one tough problem at any given time.

One approach I have found very useful is bit exact porting to assembler. There are two important steps:

1. At the fixed point C stage, you test very very carefully. Run batteries of tests and simulations. These can be performed on a regular PC in non real time, using powerful debuggers. The idea is to verify that (i) the algorithm is OK and (ii) the fixed point port works OK. In particular (ii) is very tough, so its nice to handle this in a relatively benign environment like a PC or workstation.

2. Port each function to real time assembler one by one. Test each function against the fixed point C reference. Make sure the functions give IDENTICAL output – right down to the last bit. This takes a lot of discipline – near enough is NOT good enough.

The benefits of bit exact coding are:

1. When coding assembler, you don’t have to worry or even understand the algorithm. You just have to make sure that the C version matches the assembler version. When they do, you know that the overall system will perform as expected. This lightens the load on your brain, leading to less bugs.

2. As you integrate modules of code together, problems are easy to spot, just look for where the output doesn’t match the fixed point C simulation. This is much simpler that performing batteries of tests in a real time environment.

3. A less senior engineer can be used to perform the assembly coding, as they don’t need algorithm knowledge. This makes it easier to find people for the project, lowering costs. Adding people to the project is less of an issue, as they can get up to speed and be productive quickly.

4. Any bugs are exposed early (while unit testing), rather than late (after integration). You get an honest measure of progress, rather than nasty surprises late in the project.

Where it fails:

1. It takes a lot of discipline to perform (1) CAREFULLY. There is a lot of pressure from managers (and engineers) to jump onto the sexy real time/hardware integration stage. If you are part way through (1), and there is a milestone due, it is very tempting to “declare victory” and move onto the next stage, WAY before you are ready. The results are predictable…

2. It takes discipline to make the assembler bit exact. I mean, look, it’s nearly the same, just a few bits are different? The problem is these little errors may lead to much bigger flaws in performance later on. Try changing a single bit in your operating system binary image and see how well it runs. In some (most) cases bit-exactness matters!

3. It is honest. It gives you a black and white go/no-go indication at various stages of the project. For example the fixed point C stage is not complete until it has shown perfect performance against the spec. This reduces the “room to move” managers have, you can’t declare a phase “complete” just to suit a milestone date. It really has to work. This sort of honesty doesn’t sit well with some managers, for example they may have to admit problems to a customer early on in a project.

Case Study – Non Bit Exact

Now here is what typically happens. Our hero is under pressure from his manager to progress, so he short circuits the fixed point C simulation stage and codes straight into assembler. The C simulation and bit exact assembler have results that are “close” but not really the same. No effort is made to synchronise the results, there isn’t enough time!

Time is also short so he can’t “waste time” on unit testing, there is a milestone with a big fat cash payment attached.

The assembly code is loaded into flash on some brand-new, untested hardware, power is applied, and some basic tests performed.

Damn. It doesn’t work.

So our hero and his team start trying to debug the real time assembler code. However debugging in real time is very time consuming. The best brains in the company spend months tracking down bugs that end up being simple one line fixes. Bugs constantly interact with each other, leading the team off in false directions.

He doesn’t go back to the C simulation as it now gives different results to the assembler and “we don’t have enough time” to make them match.

As the project falls behind, there is no one who can be added, as only people who understand both the algorithms and the assembler can be used. The team is debugging leading edge algorithms in assembler.

A year passes. Senior management is fuming. They keep getting told “real soon now”. However no-one really knows how long it will be, because no one really knows just how many bugs there are. Frustration and stress is very high all around.

Eventually the company runs out of funds and the project is cancelled. There are mass departures of some of the best and most capable people from the company. Our hero leaves to join another start up where he repeats the same process.

Case Study – Bit Exact

Our hero and some members of the brains trust spend many months carefully porting the algorithm to fixed point and testing the entire product in a robust simulation. This apparent lack of progress is tough for the managers to handle, but they understand the benefits and bravely support the team.

Lots of complex bugs are thrown up, and the team works through them one by one. They don’t take too long to fix because these tough problems are at least occurring in a PC environment, where it easy to track them down.

In parallel, the fixed point C modules are passed to a team to perform the assembler coding. This team is made of up many junior engineers, who are instructed to make sure each module is bit exact with the reference C simulation. A few of them don’t like this, but the more senior members keep them on track. The junior members do a good job, as all they need to focus on is the assembler, not the algorithm details.

A few bugs slip through unit testing to integration. A senior member who is a veteran of previous “death march” DSP projects is assigned to fix the bug. She discovers that the the problem was due to an exceptional case not covered in the unit test and sure enough the assembler module wasn’t bit-exact under that case. She had previously been a critic of the extra effort required for bit exactness but the speed in which this bug was found and fixed impresses her.

Early in the project some unforeseen problems are discovered during the work on the fixed point C simulation. Some parts are running slower than expected which means more assembler may be required in the final product. This throws up an early indication that the project is at risk of falling behind.

This critical management information is flagged early, while there was time to do something about it. It is decided to add some extra engineers to the assembler side. As soon as they learn the DSP instruction set they quickly come up to speed. They don’t need to know or understand the algorithm details.

The schedule still slips by a few weeks, but all the stakeholders understand that this is a better outcome than delivering a lemon on time. No further slips occur, and the project manager earns a great deal of trust and respect by delivering “bad news early” rather than trying to hit arbitrary milestone dates and risking the entire project.

When the real-time DSP software is integrated with the hardware there are still a few bugs to find. However by this stage the real time software is at a very high quality level so the bug count is low. Integration actually proceeds on schedule, amazing everybody, especially veterans of past projects.

The product is a success, the start up has a great IPO, and the pale skinny guy retires at 28 years old.

Complex Example

Here is a rather more complex example of fixed point C code from the Speex project:
static inline spx_word32_t cheb_poly_eva(
spx_word16_t *coef,
spx_word16_t x,
int m,
char *stack
int i;
spx_word16_t b0, b1;
spx_word32_t sum;

/*Prevents overflows*/
if (x>16383)
x = 16383;
if (x<-16383)
x = -16383;

/* Initialise values */

/* Evaluate Chebyshev series formulation
using an iterative approach */
sum = ADD32(EXTEND32(coef[m]),
for(i=2;i<=m;i )
spx_word16_t tmp=b0;
b0 = SUB16(MULT16_16_Q13(x,b0), b1);
b1 = tmp;
sum = ADD32(sum,

return sum;

In English (sort of), this function works the value of a polynomial at various points around a circle. Don’t ask me why. DSP engineers just like doing things like that. For more information/punishment see the file lsp.c from the Speex project.

Macros like ADD32() simulate the instruction set of the DSP chip in the simulation code, which makes porting this function actual DSP assembler a simpler step. However they also make the code much harder to read.