Developing LISA Pathfinder

Lisa Since last June, i’m working on a project called LISA Pathfinder, a forerunner of the future space-based LISA Gravitational Wave Detector. Pathfinder is a joint NASA/ESA effort, and Spain is in charge of developing both the hardware and software for the so-called Data Management Unit flying in the mission’s only satellite.

I’m mostly on the software part. The team is small and we have no architecture astronauts around: everyone’s is trying its very best to make this fly, instead of playing the corporate naming game. And i even have some old good friend in the team.

As for the more techie stuff, the good news is that this is a pretty challenging project: we’re programming an embedded system that will be running on a 14MHz ERC32 chip and one of its components must fit in a mere 32K PROM; a second component will have at its disposal the huge amount of 1Mb RAM, enough to run a real-time kernel with leisure. The not-so-good news is that this is the realm of C, so, in principle, one does not expect dynamic languages all over the place. And yet, we have managed to sneak into our tool chain some cool stuff.

C++ was discarded very early, and with it all the associated UML, RUP, XML and object-oriented-as-the-cure-of-all fanfare. Been there, done that. All this industry-standard nonsense serves mostly, in my experience, to convey a warm fuzzy feeling to incompetent managers who hear about technology in cool IT sites for the Enterprise Professionals and the Architect in you. Fortunately, my immediate bosses are not that clueless, and we opted for old good C and a Yourdon-like design methodology (PDF) invented by Ward and Mellor in the eighties to model real-time systems. Funny how some people look at you over their shoulder, almost with contempt, for your using such obviously outdated stuff. Architecture Astronauts. Again.

But don’t let me started. As i was saying, C makes for a good high-level assembly when used properly, and we’re trying hard to use it properly. Since we’re very close to the metal, we have also, every now and then, very interesting excursions into RISC assembly. I cannot possibly overstate how enriching working this close to the hardware is for any programmer. Don’t miss the chance when it appears. An assembly language, specially if it is of the RISC family, belongs into your toolbox, even if you’re programming in Lisp.

Emacs is all around. We have used its almost boundless plasticity to automate every imaginable development task, tailored to the tiniest detail. Writing a handful of Elisp functions is usually all that’s needed to adapt the environment to you exact necessities. It’s like having an IDE written for you and your project’s needs. You adapt your environment to your problem, not the other way around, gluing together all the tools you use (version control, document generators, linting tools, you name it) in the smoothest way. No other IDE of jour, however flashy or dead-on-easy-to-use.

As for version control, we bobbed between darcs and bazaar for a while, and finally chose the latter. I’m not sure it was the right decision. Since then, i’ve grown fonder of darcs’ elegance, its simplicity without sacrificing power. Moreover it has some features than i miss in bazaar, most notably the ability to record patches on a per hunk basis. In its day, we opted for bazaar because of its capacity of versioning symbolic links and, mostly, its great Emacs integration via xtla. CVS and svn where discarded from the start because we think that distribution and patch-oriented commits are indispensable in any decent SCM.

I would have loved using Conjure as our build system, but, unfortunately, we are by no means there yet. So we opted for Scons, which makes for a pretty good Make replacement in terms of versatility and abstraction power (which boils down, at the end of the day, to reusability). Besides, albeit not as beautiful as Scheme, Python is a decent language and we already have some knowhow in our team (the rest of us have now the excuse for learning it—let me say in passing than a continuous itch for learning is top on my list of the Top Ten Qualities of Good Programmers). Python also is our language for the infrastructure chores that Emacs does not handle, namely, all the batch tasks like automatic test suite running and reporting or our nightly build.

We also use Python to program the hardware simulators needed for the integration and system tests. As a matter of fact, our test cases are Python scripts. The degree of flexibility we gain by writing them in a dynamic language is so huge and evident that i cannot help getting upset everytime an astronaut passing by asks me, with an skeptical look and suspicion laden undertones, why aren’t we using C or C++.

Last but not least, all our documents are written in LaTeX. Those of you working in corporate environments involving lots of companies will surely understand how happy i feel about this. I spent a weekend writing a LaTeX document class that mimics the Word style everyone else in the project is using. Now, our documents not only look better. We have them in version control, like the rest of the code, and a growing library of scripts takes care of generating cross-indexes, synchronising code and documentation, checking for untraced requirements, generating the proverbial traceability matrices, maintaining centralised lists of acronyms and bibliography, and so on and so forth. And of course, i don’t have to leave Emacs to write my docs.

I can think of better projects, and better ways of getting things done, but, all in all, this one is not that bad.

Thanks for reading.

Tags: , ,

4 Responses to “Developing LISA Pathfinder”

  1. arakyd Says:

    Bare metal embedded systems: ahh, now that’s real programming.

    Did you consider using Forth, or are you familiar with it? It’s nice for embedded systems, and it even has a history at NASA.[1] If you’re not familiar with it, it’s sort of like assembly language with powerful abstraction capabilities, somewhat similar to Lisp’s actually; it’s got a REPL, you write programs by extending the language, and all parts of the system are available to the programmer at all times, and can be modified on the fly, including the compiler.

    A couple notes to (hopefully) pique your curiosity:

    If you’ve seen Paul Graham’s page of quotes about Lisp,[2] you’ve probably seen the one that says “Lisp is a programmer amplifier”, and maybe you noticed that he’s got in parenthesis that this was first said by Chuck Moore about Forth. (Philip Koopman also makes this statement when he talks about Forth in his book about stack machines.[3])

    Forth was invented by Chuck Moore in the 60’s,[4] and he’s still using and evolving it for his own purposes, according to his philosophy of brutal simplicity. (There are other Forths of varying interest floating around, and you can always roll your own.) To me he’s a little like Alan Kay: both of them were around in the early days of computing, both were highly impressed by Lisp, and both have very low opinions of the current state of the field.[5] They’ve gone in very different directions though; it would be fascinating to hear them have a conversation. It’ll never happen though.


  2. jao Says:

    arakyd, thanks for the recommendation and pointers. I’ve never used Forth, and much of what you say is news to me (specially, i didn’t know about the REPL). Albeit it’s a little late to consider it for LISA, i will definitely take a look at it for future projects.

    Thanks for sharing!

  3. physics musings » Blog Archive » You’re never too old Says:

    […] Until this fall, my work at IEEC is centered on software development. But once our application enters the testing and validation phases, i’ll have time to work on physics again. The Institute being a primarily a scientific institution, the plan is to get involved in LISA at a scientific level. Let me say that again: i’ll work on physics again. Who said dreams never come true? At first, a nagging doubt clouded my mind every now and then, a little devil whispering “you’re too old, you missed that train,” but i remembered a quote by one of my favourite authors: It is never too late to be what you might have been. […]

  4. gavenkoa Says:

    Nice project with nice tools.

    Forth is not very good lang for embedded as always turn into DSL and if some fail all blame Forth rather then own mistake.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: