Huh? What?
An E-playground for members of Bebear.net

Subscribe
Receive the RSS Feed of Samsara updates.

Links
People's pages that live on this server

How to make a DSP hardware project be on time

Here is an article describing a fairy tale (sadly) idea of how one would run a project for creating a product from DSP chips. I'll have to say it makes a lot of sense but what would be more interesting is some hard data on anyone that has actually managed to apply this idea:

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.

Read it yourself
Kudos to Joel's Reddit page for this one.

[/al] permanent link

The state of software engineering

If you're curious on one person's viewpoint on software engineering as a discipline (academic and professional) this is a very nice summary / rant on it. One minor niggling point is that I think the author could spend a little time fixing small grammatical mistakes. Since the mistakes make a serious criticism like this look a little childish. But only on the surface. Here's a choice snippet:

First, let's touch on requirements gathering. No where in the book did Pressman illustrate how most engineers actually get their requirements. He presented some idealized scenarios, and correctly illustrated the benefits of use cases. But in the real world, most requirements come from emails and rough wireframes. Assuming that we can start by writing the specification is folly. What we should be studying is how to turn a screen shot created in Photoshop in to a real specification. Engineers need to learn how to annotate a screen shot with input validation rules. They also need to error messages and edge cases. And they need to do it with the understanding that their stakeholders don't know or care about such matters unless you bring it up to them first.

Read it yourself
Kudos to Joel's Reddit page for this one

[/al] permanent link

Bruce Eckel takes another look at Ruby

Bruce Eckel of Thinking in Java fame takes a second look at Ruby. This time he has far less harsh words than his previous look at it (Note that the original post that Eckel made on Ruby seems to be MIA on his website. I'm a little miffed at that...)

His second time around he seems a little more impressed but I have to agree with some readers who pointed out that if he bothered to read the Pickaxe book he would have found a good portion of these features in Ruby. Although for a counterpoint, I've tried reading some comparisons of Python and Ruby and most of them end up in a 'mine is bigger' argument rather than try to really see what is different. Mr. Eckel has spent some time summarizing the differences. The reason it's easier to believe him is because he is staunch follower of Python.

Read his second look yourself

[/al/ruby] permanent link