h# 25 to node h# 290a8 cmd \ high-pass filter, semi-manual mode, 600Hz cutoff h# 34001 cmd \ speaker power 1 dB gain h# 38001 cmd \ over-current / short-circuit protection, 2.6A threshold h# 39019 cmd \ temperature protection at 130C h# 42011 cmd \ over-temperature shutdown of class-Dand, for once, I actually see why this is the (firmware) device driver's responsibility.
You see, this code is performing pre-setup of a Conexant HDAudio Codec chip to suit the physical peculiarities of the OLPC 1.5's motherboard and other components. The chip itself has no prior knowledge of the machine it's being used in, so some other component has to provide it with useful information like the power of the speakers, their frequency range, the maximum safe level of current, and so on. And so I've adopted these "magic numbers" into my firmware code quite happily -- it's information peculiar to this PC/motherboard and so the firmware is the place to put it.
Here's some more amusing code that's in the firmware: telling the audio chip what it's many and varied pins are connected to on the motherboard, so that it can repeat this information to Linux's audio driver. Once more -- this information can't be baked into the chip, because it's specific to the use of that chip on this particular motherboard.
: port-a ( -- u ) 19 config( 1/8" green left hp-out jack )config ; : port-b ( -- u ) 1a config( 1/8" pink left mic-in jack )config ; : port-c ( -- u ) 1b config( builtin front mic-in )config ; : port-d ( -- u ) 1c config( unused line-out )config ; : port-e ( -- u ) 1d config( unused line-out )config ; : port-f ( -- u ) 1e config( 1/8" pink left line-in jack )config ; : port-g ( -- u ) 1f config( builtin front speaker )config ; : port-h ( -- u ) 20 config( unused spdiff-out )config ; : port-i ( -- u ) 22 config( unused spdiff-out )config ; : port-j ( -- u ) 23 config( unused mic-in )config ;I wonder if anyone will make use of this knowledge of what colour the audio jacks are!
So I've somewhat improved my mental model of the appropriate ways to factor information between chips, boards, firmwares, and operating systems.
That doesn't mean I'm happy about seeing this kind of information pass over USB. I'd still like to see gadgets designed for simple on-the-wire protocols, as we do on the internet, and take responsibility for as much of their own configuration as possible. I wonder whether I'll change my mind when I start building USB gadgets.. :-)