Silicon Valley Redneck

Amazing how misdesigned things become standard

I mentioned as how the ARM SSP (synchronous serial port, for SPI and suchlike) lacks an "operation entirely complete" interrupt?

Well!

Turns out that, as an SPI slave (at least as observed in the NXP LPC13xx), it insists on having SSEL deasserted after each and every frame (byte).

This is severely annoying.

I'd observed long ago that SSEL in master mode was per frame, not per block, so the AGROS driver, by default, simply ignores the availability of SSEL and uses a GPIO pin as a per-block select, as required by most SPI peripherals, such as chained drivers, SPI memory devices, and so on.

The corresponding limitation in slave mode is seriously crippling, if one is trying to work with a master that uses SSEL to define a block transfer.  (The Aardvark does this.  I'm still waiting for the detailed specs on the gadget I need to work with.)

Oh, and the ARM implementation doesn't work in a daisy-chained setting either, so that's no justification.  Set the frame length to 8 bits, bring SSEL low, clock in 48 bits, and what comes out of the FIFO is the first 8 bits, not the last.  (Besides, were it daisy-chained, the next device in the chain would be getting the data loaded into the transmit FIFO, rather than the excess bits from the SPI frame.)

And yet, somehow, this cell has become The Standard for use in ARM-based MCUs.

Update:

• This malfeature is indeed baked into ARM PrimeCell PL022.
• Turns out ST doesn't use PL022; the STM32's SPI cell looks like it handles SSEL the way it's normally done in the real world.
• So, maybe I use an STM32 eval board for this gadget, instead of the LPC1xxx eval board.  (Or I could probably use an AVR, whose SPI looks to be simple and well-behaved.)
• But - and this is the fun part - I think the other side of the interface is an STM32, which may make life interesting, given that the side I'm trying to emulate is apparently built around an LPC, and their SPI implementations are incompatible.

Oh, well... the abovementioned fun part is Somebody Else's Fun, and a workaround is possible, albeit kludgey.

Another peripheral is short of interrupt options...!

I've been known to kvetch, from time to time, about the proliferation of 8250-descended UARTs, and how their lack of a "transmit complete" interrupt makes life difficult for those of us who sometimes have to deal with an old concept called "half duplex" (y'know, like some old-timey modems, or modern 2-wire RS-485).

Well, the ARM SSP (Synchronous Serial Port), as used by NXP, has a similar lack: while the status register has a "transmit FIFO empty" bit, it's not brought over to the interrupt status register... so there's no way to get an interrupt when the last of the data you'd loaded into the TX FIFO has been sent (or, at least, loaded into the shift register) and it's time to rescind the "data available" signal you're sending to the SPI master.

And, even when you are the master, it's highly convenient to have an interrupt for "the last byte you loaded into the TX FIFO has now been clocked out of the shift register, and the TX path is bare."  For, y'know, controlling SSEL outputs when you might have several or the built-in SSEL just doesn't do the right thing.  (In the AGROS driver, I ended up using the receive-timeout interrupt for end-of-transmission, though that's delayed by some unspecified "timeout period.")

So, another pollish driver.  Fortunately, the application at hand is a tiny standalone thing.

Good against remotes is one thing...

Stephen Fry rants about universal remote controls.

Those things have always struck me as being a bit like Esperanto, really: universally pointless.  The concept seems good enough, but when it comes to implementing it, well....

You'd think a multi-function remote with soft controls implemented using a touchscreen ought to be useful, though expensive.  (Isn't there a Palm app for this?)  Apparently, though, they're not.  Useful, that is.  Expensive, they are.

But, then: a lot of the non-universal remotes provided with appliances are hard to use... because they try to be more than one thing.

I have (pops off to living room for a moment) five remotes, plus the cordless keyboard/trackball.  They are:

• Projector: 22 buttons, of which I routinely use ON/OFF; the three input-select buttons see occasional use, and the rest are for setup and maintenance.  This one is pretty well designed, just for the projector.
• Receiver: 51 buttons, of which I routinely use four.  Three others get occasional use.  Six of the buttons select which device it's controlling... which might be handy if I had a bunch of gadgets all made by Onkyo, which I don't (just this receiver and my old one from college, which has no remote-control capability whatsoever).  Were I to venture beyond the few buttons I actually use, this remote would become horribly confusing.
• VCR: 24 buttons, reasonably well set up for controlling a VCR... though it also has modes for controlling a TV set, a cable box, and something or other else.  As a control for those other things, I expect it would be a horrible mismatch.
• DVD player: 33 buttons, 17 of which have more or less obvious uses.  Only controls the DVD player.
• Computer: this is one of the ATI RF remotes, and I've set Xine up to understand it reasonably well.  52 buttons, not well suited to any particular real-world usage, but I've mapped about 20 of them to useful functions.

It would kinda-sorta make sense to have a single remote to handle the "usual" functions for the projector, receiver, and computer.  (Actually, if I added an IRDA transceiver to the computer, this could be a use for an old Palmoid device... I think there's a Grand Vizier still in working order around here.  If I learned to write little Palm apps, it could be a nice refinement to the home theater.  Also, it could, when talking to the computer, receive context menus over the IRDA... assuming I wrote context menu software for Linux.  Which I'm not likely to do.  So much for that idea.)

Anyway, what I was about to write, before I started counting remotes and buttons, is this: the remotes which come with appliances are often confusing in their own right.  I sometimes find myself trying to explain, to one older person or another, how to turn the TV on.

Now, you might think that turning the TV on would be simple.  But, when you look at the typical basic home TV setup these days, you have four components: the TV, the VCR, the DVD player, and the cable or satellite box.

Each of these components comes with a remote.

Each of these remotes has features for controlling the other three components.  Only those features don't work, because they're not all the same brand, nor the same vintage.

So the first order of business is to determine, and explain, which remote controls which device.  In so doing, it is not helpful that, for example, the DVD-player remote has a button which purports to turn the TV on and off.

The next thing to explain is that pressing certain buttons on any of these remotes will cause it to cease controlling the device with which it arrived, and instead attempt to control some other device which you don't have.  You may find the remote for your Zenith TV set is sending messages to someone else's Zenith DVD player, while your Panasonic DVD player ignores it.  This necessitates a recovery plan: if it stops working, push this button to make it start controlling the TV again.

Then there's the whole business of finding the input-select button on the TV remote, figuring out how it works on that model, and explaining how to use it.  It doesn't help that the VCR and cable box have their own input-select functions, which generally don't do what you want, and are labeled based on a topology that doesn't match anyone's actual installation.  (Yeah, of course you route the video from the DVD player through the VCR.  It's the obvious thing to do, when the VCR was there first.  Then you learn about Macrovision.)

So, yeah, remotes are a serious aggravation... but the universal ones are neither the solution nor the problem.

Why is it...

...that USB gadgets meant to be installed in floppy-drive bays of PCs have connectors meant to mate with the internal-USB headers found on motherboards...

...and yet add-on USB 2.0 cards that provide an internal connector have a standard USB "A" connector on the top of the board, and never a motherboard-style header?

Another half-baked design becomes a standard

Continuing with AGROS development, I'm now getting around to supporting the SSP (synchronous serial port) on the LPC21xx, having used the SPI port for quite some time now.

The spec for the SSP is a tad confusing, but I've got it pretty well deciphered now.  It's the ARM SSP PrimeCell, PL022, except that the LPC21xx version lacks the DMA control register... something about not having a DMA controller to connect it to.

So now I've got the official ARM PL022 spec in front of me, and there are some definite crocks graven in stone:

First, though not very important, there's the business of breaking the clock division into an 8-bit prescale register and an 8-bit divider register.  Why not just have one, 16-bit register?  I suspect evolutionary heritage here, as the control register is also broken into two 8-bit registers, with the divider register occupying the high byte of the first control register's address.

Then there's the SSEL signal.  In SPI mode, SSEL is automatically generated; it goes low at the beginning of a frame (frame = one write to the data register = 4 to 16 bits), and high again at the end of the frame.

Well, that's fine if you're talking to a really simple peripheral, like an LED driver... and there's only one of it... and it's not more than 16 bits long.  Typically, though, you need to clock out more than 16 bits - consider, for example, an SPI memory device, which wants a command byte followed by a whole bunch of data bytes, all under a single chip select.  This means you're back to manual control of SSEL.

The need for manual control of SSEL, whether for long frames or for some other reason like supporting multiple slave devices, leads us to the third problem: the completion interrupt, or, rather, the lack thereof.  There are four interrupt conditions available: receiver overrun, transmit FIFO half empty, receive FIFO half full, and receiver timeout.

Now, can anyone familiar with SPI tell me what's wrong with that choice of interrupt conditions?  No, not all at once!  Yes, that's right.  Transmit and receive are inherently simultaneous conditions, so having separate transmit and receive interrupts makes little sense.  Having an interrupt for receiver overrun makes even less sense.  Then there's the receive timeout... er... I suppose that might make sense in slave mode, but, since this cell is basically used in microcontrollers and likely to be the master, the whole "timeout" concept isn't especially useful.

What I really want, so I can deassert SSEL and pull the next request out of the queue, is a "done" interrupt.  There's a "busy" bit over in the status register, but no way to get an interrupt based on its having gone inactive.  So, I guess I'm stuck with waiting 32 bit times for the receive timeout interrupt to happen so I can check the status register, find BUSY to be false, and deassert SSEL.  Foo.

Grumble grumble Windows grumble

Here I am, still trying to figure out how to simple I/O on a serial port under Windows.

I've just perused Microsoft's lengthy official article entitled "Serial Communications in Win32," and I remain no wiser.  Oh, except for this gem:

"The Win32 API does not provide any mechanism for determining what ports exist on a system."

Yikes!  I'd sort of assumed there would be such a mechanism, and I just didn't have a clue what it was.  No mechanism???? [But see Update 2.]

I guess the article might be enlightening if I were already a Windows programming guru.  To someone coming from another world, whether *nix or programming on the bare metal, it's a mixture of baby talk and arcane Windows-specific jargon.  Kind of like a VMS manual.

(Oh, and those existing libraries that are supposed to enable Ruby to talk to Windows serial ports?  I guess I could compile one of them.  If I had a copy of VC++.  Which costs... SEVEN HUNDRED BUCKS???  I don't think so.  See why hackers like *nix?  Shipping a *nix system without development tools is nigh-well unthinkable.  Unless you're SCO, of course.)

When I first met UNIX, back in the 1970s, tty devices were treated like files.  You'd open /dev/tty3 or whatever, use ioctl to set it the way you wanted it, and then use read and write to receive and send data.  Simple.  It worked.

MS-DOS also let you open a serial port as a file, using the magic name COM1: or similar.  Unfortunately, you couldn't actually use the port this way, which is why every DOS application that did meaningful serial I/O talked directly to the hardware.

...Which is why, in turn, every general-purpose UART made since that time has had to emulate the register set of the NS8250.  Which is why today's super-advanced UARTS are such a pain to use, being as how they're stuck with a crippled interface, multiple registers hidden at shared I/O addresses, and so forth.

(Microsoft was seriously Unclear On The Concept of device drivers.  Back in the DOS days, I invented a new kind of mouse.  Writing a device driver for a mouse ought to be easy, right?  Just listen to the serial port, update internal data structures, and report movement to the operating system, no?  No.  The official Microsoft definition for a mouse driver called for the mouse driver, among its other duties, to draw the cursor on the screen.  Which meant that a mouse driver had to know the details not only of the mouse and the port to which it connected, but also of every video card that ever had been or ever would be.)

The non-handling of serial ports was inherited by 16-bit Windows, and persisted at least up through Windows for Warehouses.  I have a vague recollection that Win95 programs also commonly needed to talk to the hardware directly (though I may be conflating two projects here).

Anyway, it seems that the latest and greatest Windows still doesn't correctly handle serial-ports-as-files, and it's necessary to get intimate with the Windows API to use such ports meaningfully.  The article seems to show the port being opened as a file, maybe with an extra flag set... and then the actual I/O descends into mystery.  And even if I could make heads or tails of it, I still wouldn't know how to translate it into Ruby (especially as the various Win32 API modules for Ruby seem to be rather undocumented, but that's a topic for another rant).

Update: Oh, this just gets cuter and cuter!  I decide to see what I can do with a serial port as a file, so I write a simple little-bitty Ruby script to open COM7, and loop reading and printing characters (the serial port being used only for input).

Then I run it.  It wedges the interpreter, requiring application of the Task Manager to stop it.

OK.  Is the port itself working?  Launch TeraTerm, set it for COM7, set parameters, test function.  Yup.  Exit TeraTerm.  Run program again.

Now the program buzzes around receiving EOFs on the serial port.  When I send actual data from the other computer, it receives it.  Hey!  I can live with that!

Now I'm recalling what I saw with an earlier program that tried to read a serial port in Scheme.  Sometimes it worked (EOF if the port was idle, character if there was one), and sometimes it didn't (interpreter wedged).  Maybe the difference was whether or not some other program had previously used the port.

Unplugging and replugging the USB dongle that is COM7 returns it to wedgie mode.

Checking status before and after use of TeraTerm reveals that TeraTerm is leaving timeouts enabled.  That makes sense, but didn't I try that already?  Unplug, replug, set parameters (with timeouts enabled) with MODE command.  Wedgie mode.  Run TeraTerm.  Mode COM7:/STATUS shows the same as before TeraTerm was run, and yet it works now.

So: programs that know how to use the serial port set some sticky property that's unknown to the MODE command.  Isn't that just the cutest thing you ever heard of?

Update 2: Hmmm, the API may not know what COM ports exist, but it turns out the MODE command, sans parameters, does.  This leaves only the problem of piping its output back into the application, and doing a bit of pattern searching.  Oh, and setting the mysterious "make it start working" bit.

Update 3: Mayhap I've found the mysterious sticky attribute.  According to an article I found at aspfree.com, there's a five-DWORD timeout array associated with each serial port, and it's persistent between applications.  This seems to match what's going on.  Now I just need to sort out how to make the necessary Win32API calls from Ruby, oh joy.

Update 4: Following much puzzlement, I've successfully retrieved and changed Windows serial port attributes with a Ruby script.  Part of the trouble was lack of documentation, and part was a bonehead error in my test program.

I'll publish real live working code in a few days (got a busy weekend ahead, so probably no time to polish it now).  Here's a snippet:

require 'dl/win32'

get_osfhandle =  Win32API.new("msvcrt","_get_osfhandle", %w{i}, 'I')
setCommTimeouts = Win32API.new("kernel32", "SetCommTimeouts", %w{i p}, 'N')
getCommTimeouts = Win32API.new("kernel32", "GetCommTimeouts", %w{i p}, 'V')
getCommState = Win32API.new("kernel32", "GetCommState", %w{i p}, 'N')
setCommState = Win32API.new("kernel32", "SetCommState", %w{i p}, 'N')

$sp = File.open("\\\\.\\COM7","rb+")
$fn = $sp.fileno
$fh = get_osfhandle.call($fn)

# Get DCB; change any parameters that need fiddling; set DCB
dcb = "\0"*80
getCommState.call($fh,dcb)
dcb_u = dcb.unpack("L2B4B2B6B2BB17S3C8S")
printf("DCB:")
dcb_u.each {|v| printf(" %d",v)}
printf("\n")
dcb_u[1] = 9600   # Baud rate
dcb = dcb_u.pack("L2B4B2B6B2BB17S3C8S")
setCommState.call($fh,dcb)

# Set the timeout array to the values TeraTerm uses
params = [-1,0,0,0,0x1A4].pack('LLLLL')
setCommTimeouts.Call($fh,params)

No, this isn't very good Ruby, what with the global variables and everything.  When I have time, I'll wrap it in a class that extends File, and also have a POSIX version (require the module, and get whichever applies to your system), and have proper methods for converting comm parameter structures to and from hashes with symbolic keys.  I'll probably also use the (undocumented) struct mechanism that seems to be part of the dl module, instead of cryptically-packed arrays.

[Missing links filled in from various places on the web, and in particular an unfortunately truncated comment by Derek Hans at Ruby Inside.]

Snazzle fratz!

This isn't a Soviet washing machine in the strictest sense; it appears to be more a case of a de facto standard (i.e., a grand game of follow the lemming) having preserved half of a useful feature - presumably because it had always been there - but lost the other half - perhaps because nobody remembered what it was for - thereby becoming more of a defective standard.

Yes, today's gripe is the UART in the LPC21xx microcontrollers, and in particular the way it was copied from the ubiquitous 16C550, which was copied... well, eventually it goes back to the 8250, and before that to the old 40-pin UARTs (AY-n-nnnn, whatever the numbers were).

Y'see, there are basically two transmitter status bits.  One says it's time to feed the transmitter (originally THRE, Transmitter Holding Register Empty); the other says the transmitter has actually run dry (TEMT, Transmitter EMpTy).

Now, on a full-duplex line, all you need is the THRE bit, which tells you that you can stuff more bytes into the transmitter.  All the current UARTs provide an interrupt on this condition.  This works nicely.

For half-duplex, though, it's really useful to know when the last bit has been transmitted, so that you can turn the channel around.  Doing this when the transmitter has just started shifting out the last character (the THRE interrupt) is simply not acceptable.

And so it comes to pass that I, attempting to implement a half-duplex line discipline, wish to receive an interrupt on TEMT.

Oops.

It appears that a TEMT status interrupt isn't available.

Somewhere along the line - and I'm looking at you, Mr. National Semiconductor, and your INS82C50A, and your Series 32000 Databook for June 1985 - the canonical UART with microprocessor bus interface was designed with a TEMT status bit that can be polled, but no ability to get an interrupt when it goes active.

Grrrr.

This means that, for the half-duplex scenario, I need to set an alarm after loading the buffer for the last time (which may be up to 16 characters), and poll for the freakin' TEMT bit, at system-timer intervals.

Life just got a whole bunch more complicated.

Update: not as complicated as I'd feared.  Add a static variable containing the line status register contents for each UART as of the last TX or line-status interrupt, and a routine (should be an optionally-linked-in module, really) called from the 1ms polling task to check for TEMT having changed for the higher, and in any case to update the old-LSR variable.

I'm not crazy about the up-to-1ms turnaround time after transmission, but, since the RS-485 interface in the application at hand will only be running at 9600 Baud, that's only one character time, and it so happens that the other side is expected to transmit infrequently.

Bad industrial design: the PC power supply

Continuing on the subject of perpetually bad design... consider the PC power supply.

The basic mainstream fungible PC power supply is on its third generation: PC(/XT), AT, ATX.  Small-form-factor PCs are on a fourth generation: micro-ATX.

The mounting arrangements (unless you buy some name-brand PC that doesn't follow the industry conventions) are well standardized, so, when (not if) you have to replace your PC's supply because it's gone bad or (more likely) the fan in the supply has worn out, you can run down to the local Comp-U-Mart for a replacement, and be pretty sure it'll fit and work.

Now, here's the trouble: the standardized form factor mounts on the inside of the case, with all the power distribution cables permanently attached to the supply.  So, when (not if) you have to replace the supply, you have to take the covers off the case, disconnect the far ends of all the power cables from the motherboard & drives, dismount the old supply, install the new one, connect all the new cables....

Why is it that whatever committee that came up with the ATX configuration - or the micro-ATX - didn't take maintainability into account?

The proper way to handle it is to select a suitable blind-mate bulkhead connector set, and have the power supply module plug into the chassis wiring, which would hook up the motherboard, drives, chassis fans, and bling-bling.  The power supply module could then slide in from the outside of the case, without pulling any covers off, and be secured to the chassis with screws through a flange on the supply.

I guess that would make maintenance too easy, huh?  And add about $8 to the price of the chassis... while shaving $5 of the price of the supply.  Figure in the labor savings, and it's probably a wash for pre-assembled systems, and a huge win after the first power-supply replacement.

Yes, there are a few ATX power supplies out there with detachable cables, which theoretically could offer a partial labor saving on replacement... assuming a replacement with matching receptacles is still on the market when the original dies.  This is no substitute for standardizing on a proper design.

Dumb ideas: the rack-mount industrial PC

The tale was told, many years ago, of the time the Soviet Union first made washing machines.

Soviet women, so the story goes, were demanding Western-style washing machines to make their lives easier.  After much discussion, the Kremlin decided to authorize production of washing machines.

The factory was set up, and, to save on design effort, a sample washing machine ordered out of the Sears Roebuck catalog.  The machine arrived, and the team set to work copying it.

After an unexpectedly long time, the first Soviet-made washing machines started coming off the production line.

They didn't work.

After months of investigation, someone had the bright idea of plugging in the Sears machine.

It didn't work either.  It had a broken gear.

They'd had a heck of a time duplicating that broken gear!

So...

What, you may ask, does this have to do with rack-mount industrial PCs?

Well, the whole PC industry has been playing the Soviet washing machine game ever since the beginning.  Look at the bizarre quirks, the active-high IRQ/DMARQ lines, the strange hacks involving A20 and the keyboard controller....

The PCI bus corrects some of the worst weirdness introduced by the original PC bus and continued by the AT bus.  It preserves, however, a great design crock: the perpendicular I/O card.

Take a look at one of the cards for your PC.  It has the faceplate and I/O connectors on one side, the bus connector on an adjacent side, and the other two sides flapping in the breeze.

Now look at a real industrial I/O card... VMEbus, say, or a plugin module for telecom equipment.  Notice the difference?  The faceplate and I/O connectors are at one end, the bus connector is at the opposite end, and, when it's inserted into the chassis, the other two sides are supported by card guides.  This is the way it was always done, before the PC appeared on the scene: faceplate at one end, bus connector on the other, and I/O either through the faceplate or through the backplane.

With the PC-style perpendicular card, you can't swap a card out without removing the cover from the chassis.  This is no big deal if it's a desktop machine sitting on the top of an uncluttered desk (yeah, right).  In a rackmount machine, it means that, in order to replace a card, you have to pull the whole freakin' system apart - disconnect all the cables from the PC, unbolt it from the rack, pull it out, and, finally, open the chassis and change the card.

There's also the problem of getting the faceplate to line up, and the problem of persuading the I/O connectors to go through the slot in the chassis... neither of which is an issue with a proper industrial design.

Yeah, I know, the perpendicular format allows variable-length cards, which allows manufacturers to save a couple of bucks on fiberglass on simple I/O cards.  Look at the retail pricing of simple PCI bus I/O cards and tell me why I, the consumer, should be excited about this.

No more Soviet washing machines!