Essentially, as the (embedded) software systems we are developing get more and more complex, we need to update our debuggers to keep up with the times. This means moving beyond looking at single processors, threads, programs, or even nodes – and making debuggers that support working with multiple contexts at once. For example, debugging a couple of different boards in a rack from a single debug session. This would mean supporting multiple processor architectures, execution modes, and operating systems inside a single debugger session. Debuggers need to orient themselves towards handling software that is already running in a target, rather than starting the target software. The debugger becomes more of a passive observer of the target system than an active component.

Take a look!

It is pretty very nice demo in which you first start a period program A, which prints the value of an incrementing counter every target second.  You then run a supposedly unrelated program B, resulting in the values that program A prints to become corrupted.  Perfect to show off reverse execution and data breakpoints in reverse as you go from the point where the corrupted value is printed to the piece of code that overwrote the variable.

But then I ported the demo to a new platform… and the bug didn’t work anymore. My bug had caught a bug and was now not working, or at least not they way I expected it to. What had happened?

Very simple. I changed the compiler I used. Since my bug relied on an unspecified behavior in C, the change was totally valid and really expected.  Still, it was interesting to see how things played out… in the end, we got a different bug from the same code thanks to the change.

The code is essentially the following, with some simplifications that make it easier to read for those not familiar with VxWorks, and ignoring all the code to start tasks initially.

// Global variables
int     iDataArray[100];
int     myWdISRcount;
WDOG_ID myWatchDogId;

// Periodic task - program A
void myWdISR(void)
{
  /* Increment ISR invocation count */
  myWdISRcount = myWdISRcount+1;
  printf("wd Fired %d times\n",myWdISRcount);

  /* Start off next invocation */
  wdStart (
    myWatchDogId,
    WD_INTERVAL,
    (FUNCPTR) myWdISR,
    (int) NULL
  );   
}

// Overwrite code - program B
int myCompletelySafeRoutine(void)
{
  uint32_t *a,i;
  a = iDataArray;   
  // This loop writes one word beyond the
  // limit of the iDataArray
  for (i=0; i<=100; i++) {
     a[i] = 0x7fffffff;
   }   
   return OK;
}

In the original setup, compiled for a Power Architecture target, iDataArray ended up right before myWdISRcount in memory.  Thus, the buffer overflow changed the value of the counter from something like 10 to 0x7fffffff.  Very noticeable in the printouts from the periodic task.

When I changed to an x86 target (using a compiler from the same family, but obviously with a different code generator since the target was different), the variable order in memory changed and it seems that we got iDataArray placed last.  Suddenly, the effect of running the safe code was that nothing happened at all.  A bit annoying for a demo.  Some small source-code changes and a recompile later, the effect was instead to crash the target with a triple fault (page fault inside a page fault handler). Seems the program now managed to corrupt some kernel state. While impressive as a bug, it was not quite what I was looking for.

I then changed the compiler type to compiler 2, and the data layout changed once more.  This produced a very useful bug, but it took me a while to actually understand this.  Now, when program B was run, program A stopped.  This looked like a bug in my program, and I actually started trying to fix this – until I realized that this was the bug I was looking for.  Running program B kills program A is just as good a bug as corrupting a counter value, after all.  In this case, the array overrun hits the myWatchDogId variable, and when that gets corrupted, the wdStart call ignores the request since it does not recognize the ID it gets.

So, in the end, I got a bug that was just as good as the first, and arguably a bit more intruiging. It is still obviously a contrived example – but I think that a good demo or lab exercise can be artificial as long as it gets the point across.  Judging from how people who have done the lab reacts, the goal seems to have been
achieved.

The moral of the story is really that compilers are free to change things which are explicitly implementation-defined or not specified at all in the C standard. That is a good thing as it gives the compiler freedom to optimize the code. If you want to control how variables are laid out in memory, I guess you have to resort to linker scripts or similar – but that was too much pain for me in this case. Just changing things around until I got a good bug, and then freezing the binary (and not recompiling it ever again) is a sufficient strategy.

Software is Concrete. Once poured it becomes extremely difficult and very expensive to change.

It comes from a blog post by Robert Howe, CEO of Verum, a company selling formal-methods-based and model-based programming tools. It does capture something of the phenomenon we all know: that software can be pretty darn hard to change, once it has shipped and is in use. It fits well with the fact that the later bugs are found, the more expensive they are to fix.

But it also provoked quite a bit of opposition when I put the quote up on Facebook, and I have to agree that maybe not all is as simple as that blog makes it out to be.

The main problem as I see it is that it compares the development of software to the construction phase of a bridge (or other civil engineering structure). When software development is really much more like the architecture and exploration work that goes on long before the bridge is starting to be built. The blog post recognizes this in a way, I admit that. But you cannot escape the feeling that the fundamental thinking behind it all is waterfall-based. It never says so, but it feels like that.

Which is a shame – I cannot see that there is any fundamental dichotomy between being iterative, agile, and changing things as requirements clarify, and using model-based development and formal methods.  The idea of model-based development is to program at a higher level of abstraction to get more efficiency. And programming at a higher level of abstraction fundamentally supports agile and iterative development, since the amount of “code” you must change is smaller. Model-based development ought to support drastic and quick changes to software just like modern dynamic programming languages and powerful frameworks support it. Add in some model checking to find important classes of bugs (like deadlocks and dead-end states) automatically, and you have a very agile programming environment.

In software development, I don’t think there needs to be a great step from design and architecture to implementation. It seems to be more gradual, you build code as you go along and ideas get more and more detailed, and slowly you get to something fairly concrete and indeed fixed. The trick is to make this process gradual and find issues early, so that they are cheap to fix.

Overall, it seems that software is more like clay than concrete. It slowly goes from soft to hard… but you have a chance to make changes during the process.

I also have to apologize for the slow blogging in January of 2011. There was too much going on at work and quite a few days taking care of sick kids. Hopefully, the pace can improve going forward.

I made some cocky comments about just how stupid the current implementations of this idea are a few years ago, but in my discussions with Tennessee I have realized that things are not that simple. Essentially, you are caught between the structures and strictures of the certification agencies, and the complexity of the hardware with its many shared resources making predictability and programming very difficult.

It is a field which touches to my old work on WCET, but with a target system that is much less amenable to analysis. I still think it is a good idea to try to use seas of simple cores and separate work physically rather than virtually, but that might be a battle that will never be won. If nothing else, even on a massive spatially-divided multicore device, there will be some shared resources that make life difficult when very low levels of jitter are tolerated.

Read the interview, and read Tennessee’s own blog – he has done some pretty cool things both in hardware, software, and virtual hardware.

It is at http://blog.regehr.org/ and covers a range of embedded topics relevant to his academic research (which is more embedded that most).

Barry Lock

Barry lock gave a very entertaining keynote, from his viewpoint as essentially the champion of physical hardware debug. Lauterbach is clearly focused on debugging using hardware assists in real systems, with not much to do with high-level programming or virtual platforms. Barry has been working with computers longer than I have lived, and have seen both the semiconductor and software side of things.

His main message was that you have to take debuggability into account when buying chips for your embedded project. Saving a few cents by buying a chip with no or limited debug features will come back to haunt you, many times, in many nightmares. He had had grown men crying over the phone, asking for a miracle to save their projects after debugging had utterly failed for many months. He had seen startup companies go under, burning all their money chasing the last bug… and claimed that 75% of all product starts never got to market, blaming debug problems for a large proportion of that.

The most important debug feature is trace - which follows the theme of this being the S4D of trace. After trace, you want hardware breakpoints. Apparently, you need at least two to breakpoints to debug a system with a virtual memory RTOS. One to keep a look at the MMU, and one to actually debug code. More are better, but it is rare to see silicon vendors include many more breakpoints.

Barry gave  a number of examples of projects which had failed by not buying the right hardware. He put the blame both on the buyers chasing a few cents of costs in the end product, but also on the poor quality of silicon salespeople who rather took the price route than the quality route when selling chips.

He also noted that there seemed to be a positive correlation between industry leaders and buying debuggable hardware. Companies like Bosch, Ericsson, and Nokia always spend the extra money to get hardware that can be debugged, and have results to show for it.

Philosophy of Debug

During our two panel discussions on debug, there were two ways to look at debugging that stood out from the crowd.

The first was the observation that debugging today is very much a craft. When things go really bad, you go to the proven expert. Debugging is a craft you learn by apprenticeship with a master, and master debuggers are incredibly valuable for their organizations. This reliance on masters indicate that general programming education to a large extent overlooks debugging as a crucial skill for programmers. It also means that, in the words of one member of the audience, debug cannot scale. As problems become more complex, we still rely on single individuals, which reduces our ability to tackle problems.

The second observation was to liken debugging to the diagnosis of human diseases. As systems become more complex, their behavior gets so complicated and rich that it is hard to even precisely identify what a bug is. A simple crash or illegal operation is clear-cut – but when results of programs are just a bit off? When control loops don’t quite do the right thing, but almost? When the quality of a picture of a television just feels wrong? In those cases, we might be looking at composite measurements of many different parameters and factors in a system, and making a diagnosis of error based on the whole picture rather than each factor in isolation.

Based on these observations, I can envision a somewhat weird future where we train computer doctors (as in medical doctor, not PhD)  to diagnose computer problems based on holistic, systematic, approaches. Such education could be separate from the training of programmers and testers, as their specialty would be the diagnosis of system outputs against the expected outcomes at a high level, rather than the details of code.

There are two important aspects to this worm, as I see it.

First, it only works due to the fact that the software in question is running on regular Windows PCs.  An attack on a real embedded OS like Wind River VxWorks or Enea OSE would be more interesting, and much scarier since that would mean a much more devoted enemy. In this case, the attackers are opportunistic, using the window of vulnerability of a new Windows flaw to attack Windows-based plant control systems. They also use signed Windows drivers, which is apparently a new development in malware. All quite interesting in its own right, and worth reading about for those interested in security.

Second, the malware spreads using physical movement of USB memory sticks rather than attacks over the Internet or other networks. This makes the very important point that even if systems are not connected to the Internet, they can still be attacked if something crosses the “air gap” that separates them from the outside world. In this case, a plant would be infected by using social engineering to make some employee carry an infected USB stick into the plant and putting it into some internal PC. Once the infection is inside the plant, it might spread over networks or by USB sticks moving around inside the presumably protected perimeter.

The lesson I think we can draw from this is that using general-purpose desktop operating systems for critical systems is a bad idea. Using a more obscure real-time OS (or even Linux) would probably reduce the number of vulnerabilities – but more importantly, it would make it much more difficult to make an infection hop from computer to computer until it reaches its target.

In this particular case, all Windows machines are potential bearers and spreaders of the infection. An attacker can rely on that fact to seed the Windows ecosystems at some place, hoping to get the infection hopping from machine to machine until it reaches something interesting. There is no real need to seed the infection directly into the target plant. If the target systems had been running a different OS, the attackers would have had to get really close to the target, making them easier to stop.

Overall, embedded systems security is something that we need to take much more seriously going forward. As we rely on embedded control systems to run much of the modern infrastructure and economy, we really need to be concerned about how to secure these systems. Security needs to be part of the architecture of embedded systems, including their operating systems (please make them as robust as possible), application designs, and networking systems. Unfortunately, current embedded technology tends to be designed to work, with little care for how they could be broken by an intentional attack. One scary example of this was provided in the SecurityNow podcast episode #251, where a listener shows how easy it could be to take remote control over a car due to carelessly designed fleet management units.

Updated information

I found some more in-depth information on the issue at Infoworld. It notes that the software that is attacked is vulnerable since all installations use the same password to login – changing it is likely to break it. That is totally ridiculous as a security solution, period.

And almost inevitably, as you play around with a complex modern piece of software (which is what most of the phone is, after all), you find some obvious things which are just plain broken. You wonder, “why didn’t they think of this”, and “how could this ever escape testing?” My current best example is that the built-in web browser does not render the pages from Blackberry’s own support knowledgebase.

This is something that they have control over from both sides, so the only reasonable explanation is that they just have not thought to test that site with the browser. It seems strange that  a new user would uncover such holes after a few hours, when presumably thousands of planned and spontaneous testing hours are being spent at Blackberry on each device they release.

To be fair, this is not a showstopper for me, it is just a good example of how users tend to poke holes in all modern software products. Blackberry is not unique in this regard, and I fully admit that the software that I have worked on over the years did not always fulfill the requirement of being bulletproof. There is a classic saying that if you think something is foolproof, you just haven’t found the right fool yet.

So what is this telling us about software development? I think the main lesson is that you need people who just use your product and do so creatively, as part of the development process. Software developers usually lack the destructive imagination necessary to really poke holes in what they have created, and are usually not given time to develop elaborate test cases.

The moment you put code into the hands of users, you can expect them to find “obvious” issues in your product – simply because their “normal” use is something you yourself never dreamt could happen. In my example, I presume that Blackberry assumed that people will use the support forum when their phones don’t work – and therefore not surf to them from a phone. Sounds reasonable, until you press on a bit and ask if someone might not look at a friend’s broken phone out in the field and need to search support… or check for solutions to non-fatal errors.

I guess the key lesson for me, one which I apply in my daily work, is that product management, marketing, or testing, has to work through use cases with the software they create. Really work them through, and when sidetrack ideas appear, follow through on them, not ignore them to focus on the main task at hand. We have to combine features, and do more than what’s in typical tutorials.

Feature combination is especially powerful, I still recall the sense of “aha” I got when as a PhD student I talked to some colleagues researching the field of feature interaction. It sounds like quite an interesting field, even though I am not sure how you could formally capture something that will generate the test case “read our support site using the phone browser”…

This post used to end in “I guess this counts as a software development rant”. Now, I classify this as a “tester’s lament”…

The first movie is just the robot driving around using its MEPROM programming unit. I think this movie is slightly clearer than the old one I posted.

Next, here is how a program loop can be created in this system. By removing the white end marker from the program, the motor will just keep spinning the program until it spots a program step. This is a very mechanical infinite loop.

Finally, we have the emergency stop bumper that was added to the robot to make it stop when it hits something. It does not take effect immediately due to the latencies involved in the NXT programming environment, but at least the robot does not proceed to the next programming step.

It turned out that trying to show a group of ten impatient kids that the robot read instruction codes and moved accordingly failed. Using a chaser program, where the robot drove around waiting for something to show up close in front of it and then drove full speed forward to try to hit it, was much easier to appreciate.  Classics like driving around avoiding to hit walls was also just as much fun as ever. Like my previous attempts, the kids piled up on the robot and tried to make it turn the way they wanted.

Clearly, physical exercise is easier to sell than cerebral exercise.

That said, I did manage to get some more thoughtful kids interested in getting the robot to go particular places. The setup I used was to put the robot on a starting square marked on the floor, and then putting a red bucket out on the floor some distance away. The kids were asked to help me program the robot to either hit the bucket or drive around it. I explained what the robot did as taking steps forward and turning, and actually the approximately 50 cm long runs it did for each blue programming tile was fairly similar to a serious step by a five-year-old (some kids instead started tip-toeing forward, which did not quite provide the correct stride).

As a safety device and to retain a semblance on intelligence on the part of the robot, I equipped it with a bumper in front. As soon as the bumper is hit, the robot is supposed to say “stop” and stop all activities.

The problems we tried were:

• Put the bucket down in front and try to hit it, needing three forward to get there
• Drive around said bucket, which required a program like blue, green, blue, yellow, blue, blue, yellow, blue, green (forward, right, forward, left, forward, forward, left, forward, right).
• Leave the base and drive to the back instead of front.

I sat down with a group of three kids who really got into this part (even with ten other kids running around playing cops and robbers at a very high level of intensity). They did get the idea and did propose steps towards the solution. However, it is clear that at least initially; one cannot expect them to plan out an entire program in their heads.

Rather, we ended up in a style quite familiar to anyone learning a new programming language or taking their first programming course. Try one step, see where it takes us, add another step or two to the program, and try again. Very much how I myself solve programming and scripting problems where I interact with a complex and possibly unpredictable environment. In this way, we did manage to solve some problems, and I do think the kids understood what was going on.

To me, I feel the idea of the Lego-programmable robot as a preschool-level programming course is at least partially proven. As in most other educational ventures, what is needed is a good overall teaching environment. Next time, I will have to try this with a small group of kids, just after they have had a snack so that they are alert and fresh. I will also make sure to break up the hard work with some simple play, since that is needed to keep the kids from being bored.

As discussed in my previous blog post about Kindergarten robots, I wanted to see if I can teach kids the core idea of programming. This project has now progressed to the point that I have a working prototype of a programmable robot.

Essentially, the robot is programmed by putting colored Lego bricks in a sequence on top of the robot. This should be accessible and direct enough to work with kids — and with no computer needed, just direct physical interaction with the system. For some reason, I think the extra level of abstraction from a screen to a robot is just an unnecessary obstacle at this level.

For an example run, see the Youtube video linked below:

The robot is shown in the picture below. Since I use the same base as a fast chaser robot, it uses the large wheels from a Technic kit I happened to have around, and a decent swiveling rear wheel. Using treads for the drive would probably have given me a bit more precision, but this is faster and simply feels more fun.

The inspiration for the programming method came from the boardgame Roborally, where you are dealt a set of card with meanings like “forward”, “back”, “turn right”, “turn around”, etc., and have to make your robot navigate a hazardous landscape to get to a destination. In my kindergarten robot, I simplified the programming to just forward, left, and right. And there are no conveyor belts, lasers, pits, or other hazards on the field.

The program steps available are the following (the color sensor can only distinguish a few primary colors):

• Black – start bit
• Blue – move forward
• Green – turn right
• Yellow – turn left
• Red – honk the horn (beep)
• White – stop bit

As a programming language, this is definitely not Turing-complete and nothing that you could program anything useful with. In particular, the programming model lacks decision statements, loops, and variables. However, it conveys what I feel is at the heart of programming: obtaining a goal by putting together a sequence of very small and simple steps. If you cannot grasp the idea of many small steps, you will never be able to program in any meaningful way.

User Testing

I have not tested this with a group of kids yet, but only with myself and my five-year-old son. So far, it seems to work. After some initial confusion, he is starting to get the idea of putting steps in order and having the robot execute them.

Here are some very simple missions that can be used to get the programming thinking going:

• Turn around a corner (of the fridge in this case)
• Move to hit a balloon lying on the floor some distance away
• Move in a square pattern to get back where it started

I am sure I will think of more as I go along. I will blog some more once I have more experience with the robot.

Details of the Program Memory

The major problem that had to be solved to build this robot was creating a working program memory. I have decided to call the program memory MEPROM, for “Mechanically Erasable Programmable Read-Only Memory”. It is a ROM, since the robot itself cannot change it.  Since you can both remove program steps and put in new steps using mechanical means (human hands, typically), it is definitely an M-EPROM.

The idea for the memory is simple: use Lego bricks to represent moves. It took a while to come up with the current form, as there are many ways to move colored bricks past a sensor.

Two of the program steps can be seen below: I used 3×1 standard lego bricks (which I borrowed from my son’s Legos, since  it seems very hard to find good kits containing this particular type of brick):

To move these programming blocks past the color sensor in order to read them, I used some classic Lego treads (which seems to have been in use since the late 1970s!). Today, these can be best obtained by buying the Mini Bulldozer kit (8259). The program steps are put on alternate tread elements:

The Mindstorms color sensor only sees six colors, as discussed above. Worse, it tends to see black in dark shadows. For this reason, it needs to read the bricks head-on to be reliable. I have tried in vain to make the system self-adjusting, so currently, the program start has to be manually aligning the start bit (black brick) in front of  the sensor. For the rest of the run, turning the driving motor 90 degrees reliably puts the next brick in place in front of the sensor.

The program turns out to be quite simple in the NXT programming environment. Turn program motor 90 degrees, sample the color sensor, and act accordingly using a “switch statement”:

When I was a PhD student in Uppsala back around 2000, we bought a pile of the Lego Mindstorms RCX kits, for use in real-time courses. Obviously, the students loved the opportunity to play with Lego (including the few females). What was less obvious and much more interesting was what happened when we brought in a bunch of children from a local kindergarten to visit — they really took a liking to our little yellow robots running around a classroom. They treated the robots as little animals, wondering what they were doing and why…

With that in mind, I decided to try to reprise this myself with my own son and his kindergarten friends. Last week, I took my robot kit with me and went to meet the kids.

My top-level goal with exercise was really to get the kids interested in technology as a future field of study and venture… you have to start early to counteract the prevalent tendency of people to want to be famous and work in media or something… Only time will tell if this had any effect at all (I doubt it).

In addition to the top-level goal, I wanted to communicate some about how things work. Make technology more understandable and less magical, and more accessible. In particular:

• Autonomy: the robot is not under remote control, it acts autonomously based on its programming.
• Sense-compute-actuate: the robot perceives the world and makes decisions that get sent to the motors.
• Limited sensors: the robot does not see like we do, it uses far simpler sensing.
• Programmability: the same physical setup can do a lot of different things just by switching to a different program.
• Concurrency: the robot can do several unrelated things at once.
• Stupidity: the robot is really dumb and just reacts very predictably to its environment.

I think these points can be brought across using an indirect approach. You cannot tell a four-year-old about programmability. But you can show that if you go to the robot’s control unit and press some buttons it does something different.

Note that some of the points above are artificial, in that you could build much smarter programs with more complex behaviors and less direct reactions. But that would make things more magical and “human-like”, which is not what I wanted to communicate.

Anyway, in the end I used two configurations of a driving base, with a few different programs.

The first configuration is shown below, using a color sensor pointing downwards and an ultrasound sensor pointing forward.It also had a shooter pointing forward (in this picture, the organic styling of the Lego Bionicle Zamor-derived shooter comes across very nicely, as well as the apparently quite special silver- and gold-colored balls I picked up on a sale).

First, I had this robot follow a black line on the floor. Putting the line down was fun, watching the robot follow the line did not work out as intended. Too hard to explain the algorithm for following the contrast between black and not-black. Adding the behavior to stop when the robot hit a red line was also too subtle.

Next, I tried to put the robot on a table with the program “stay within black lines”. Or rather “reverse and turn if you hit a black line”. Problem was that the table had a spotted pattern that included small specks of black, and the robot just kept doing avoidance maneuvers… so that failed. I still want to do a table-dancing robot, but I guess relying on an ultrasound sensor pointing downwards to detect the chasm at the edge will work better.

What was fun though was when I activated the ultrasound sensor and the shooter: the robot would crawl along the line, and if something got in the way, it would fire a ball. That was huge fun! All the kids crowded around to get the robot to shoot and collect the balls. Note for future attempts: dramatic actions are great!

It was even better when I set the robot to rove freely, using the ultrasound sensor to turn when something got in its way. This was an easy-to-understand behavior that the kids appreciated, putting feet and hands in the way of the robot to make it turn. The poor robot was often the center of a pile of kids that were all trying to make it turn.

I also tried a configuration using bumper sensors:

Here, the robot only had one program, to move forward until it hit something, and based on the side that hit, back up and turn to avoid hitting the same obstacle again. This was a very successful configuration. The kids started to play “don’t touch the robot” with it, having it drive between their legs or bending over the robot to make a bridge – but not touching it and making it turn.

Note that I did not bring any computer with me, all programs were preloaded on the NXT brick. Very handy, actually.

In summary, I had a great time doing this, and I will be back with new configurations and programs. Creating the programs was very quick and easy in the Mindstorms environment, proving the value of domain-specific programming.

The kids have hopefully learned that you can play with and control technology, and that you should not be too respectful. Maybe someone also picked up some of the ideas I presented at the start of this blog post.

Gender-Theoretical Notes

I do have to end with a slightly sad note.

It was surprising to me just how differently the boys and the girls reacted and behaved. I had assumed that kids would just be kids at this age (three to five years old), with no gender-related differences. It was very striking that this was not the case in reality. The boys just ran in and started playing, and very quite hard to get to listen to anything I had to say. The girls walked in and quietly waited for instructions, and took some warming-up before they would interact with the robot.

I cannot blame our kindergarten for this, they are definitely trying to avoid gender-based stereotypes.I guess it shows that fighting societal norms is just as hard as everyone says it is.

It was also interesting that the kids were surprised to see a parent build with Lego and have a great time. For some reason, that was not expected behavior from a dad. Sad too.

I have seen the “write 1 clears” solution before in real hardware, but I was not aware of the other two variants. The idea of having a “write mask” in one half of a 32-bit word is really clever.

However, this got me thinking about what the fundamental issue here really is.

As I see it, it is the fact that the processor cannot address small enough units atomically. The read-modify-write that was used to start the discussion in the Embedded Bridge #37 was needed in order to get the current state of a configuration register, change some setting that only occupied a few bits in it, and write back the result to the register. The way most configuration registers that I have seen in practice works.

But if each setting could be given its own register, the problem would go away. Each operation would target a unique address, achieving the same effect as the bit-wise masks or write-1 solutions proposed. The core problem is that hardware tends to share settings into registers, as it has been considered too expensive to put information that might cover a range as small as [0,1] into a 32-bit register. Probably, since there is a lack of addresses for registers, you cannot have 1000 settings cause each simple device to use up 1000 words of physical addresses.

But is that really an issue, if we look forward?

It seems to me that, as 64-bit instruction sets and addressing systems penetrate down into more and more embedded systems, a simple solution would be to throw address space at the problem. I don’t think it is uneconomical to allocate huge chunks of memory space to each device, giving each setting its own register, when you have 64 bit virtual addresses to work with. There is no way you can fill up a physical memory system (guess that will some day come back to haunt me)… even the highest-end machines today only use something like 40 bits for actually addressing physical memories.

The software would be simpler and more robust, with virtually no cost.

Another solution that I have also seen starting to appear is to dispense with register settings altogether, and rather define a command API that the processor “calls” by putting in command packets into some memory area. This does require quite a bit of silicon for a decoder, but it provides for a much higher level of interaction with devices. As hardware devices get defined in successively higher-level languages (C, C++, UML, MatLab, …), and their programming interfaces and associated drivers get autogenerated, this solution makes eminent sense.