Prius cruise control problems?

As an embedded enthusiast, I'll admit I've been a little skeptical about the recent complaints about spontaneous acceleration problems on the Toyota Prius. I don't have one myself (can't afford anything that new yet), but I've been impressed by the ideas behind the design. The "spontaneous acceleration" complaints sounded to me more like either people's imagination running away with them, people who don't understand their cars and/or can't drive, or people looking for a quick buck or cheap publicity out of all of this.

This changes my opinion. If Steve Wozniak, who owns a Prius, says that he's experienced problems with the cruise control system causing uncommanded acceleration, I believe him. This guy designed the original Apple computer system way back when, and truly understands digital electronics. He also has nothing to gain from badmouthing Toyota, and being a typical engineer, has never been one to look for publicity (unlike that "other" Steve.) He's just an engineer who noticed an important problem and is trying to help get it solved. (Good for you, Woz.)

I hope Toyota is taking these reports seriously, and comes up with a good, solid fix for them. Were it me, I would suggest a paleo-tech solution: Install a hardwired killswitch which cuts power to the electric propulsion and forces the transmission into Neutral. (The engine *does* already have an RPM defenser, yes?)

Hopefully Toyota can solve the problem and get this behind them. They have done a lot to popularize hybrid cars (and fuel efficiency in general); I would hate for such a good idea to get more bad press just because of some engineering glitches which should have been caught long ago.

ROMfoolery

"I spy, with my little eye, a ROM address beginning with the sequence 0001010000011001..."

I've recently been playing with DS18B20 One-Wire digital temperature sensors (from Sparkfun -- big surprise there). They're fun little devices -- accurate and cheap. They're also insanely easy to wire up, having only three leads (they look just like 2N2222 transistors).

When Maxim says "one wire," they mean it (not counting ground); you can even power it using the data line if you're careful about timings and provide a strong pull-up when needed. Developing microcontroller code to drive them is nontrivial, though (various layers include bit timings, commands and ROM codes etc), but once it's working, they're very reliable.

Temperature A-to-D conversion takes up to 750ms, but you can issue a broadcast command to get all devices on the line to start a conversion at once, then read the results back at your leisure.

Here's the first interesting part.

With a one-wire interface, timing and coordination of reliable two-way communications gets tricky. There's no synchronization line -- and from the description in the datasheet, the timing accuracy of these sensors isn't all that wonderful, anyway. The scheme that Maxim worked out was that a short low pulse represents a one, and a longer low pulse represents a zero. A really long (more than 480 microseconds long) pulse resets the bus altogether.

But wait, there's more.

The interface is specified so that multiple slave devices (I.E. multiple sensors) can share the bus. This takes not only coordination, but implementing the bus with an open-drain configuration (in other words, you use a fairly weak resistor to put 5V on the bus -- and devices are only allowed to short the bus to ground, not pull it high.) This keeps communication collisions between devices on the bus from causing short circuits and burning up output transistors -- but it also complicates timings and the basic communications protocol.

Now for the really interesting part.

Each sensor has a unique 64-bit serial number, which you need to know in order to interface with it. It's not marked on the package (too small) or in the literature you get when you order the part (that would make too much sense), so Maxim provides a "Search ROM" feature, which uses a bizarre take on Manchester coding to send the address back. Two bits are read out at a time for each bit position in the 64-digit ROM code. 01 means the bit is a 0; 10 means it's a 1; 00 means a conflict (someone on the bus sent a 1 and someone else -- maybe a lot of someone elses -- sent a 0); and 11 means that nobody is listening (check the circuit?). By going through bit by bit (with a lot of backtracking, if addressing a lot of these on one line), you can eventually determine the ROM codes for all devices on the line. It's very Byzantine -- but when you think about it, that's really a result of the one-wire interface.

Here's an example of how it would work with simpler devices that only had 4-bit ROM codes.

Suppose you had three devices on the bus, with ROM codes 0110, 1110, and 0101.

The least-significant bit is sent first; this comes back in two-bit Manchester coding as an "00." (I.E. there's at least one of each variety.)

The master (microcontroller) makes a decision at this point, and sends a one or zero. Any devices which match this bit in the first position keep listening; all others go idle and wait for a bus reset. In this case, we'll default to zeros first. The master notes a conflict here, and sends a zero.

Sensor 0101 reads the zero and goes idle. Sensors 0110 and 1110 read the zero and continue, since it matches the least-significant bit in their ROM code.

The master then continues with reading the second bit. This comes back as a "10" -- apparently all remaining devices agree that there is a "1" here. The master records a "1" and continues.

The master reads a third bit, which comes back as another 10. Another "1" is recorded and transmitted.

The master reads a fourth bit, which reads "00". (Another conflict.) The master sends a zero; device 1110 goes idle, while 0110 is made active (having passed all the way through its ROM code). The master records 0110 as the ROM code of one of the devices on the bus -- and records 1110, since it can deduce that; this being the last bit, that's the only possibility.

The master then resets the bus, starts the ROM search process again, but sends a "1" this time when it reaches the conflict in the first bit. Device 0101 remains active this time while 1110 and 0110 go idle. The master then continues with the process; since 0101 is the only device left on the bus, no more conflicts occur.

Think of this process, expanded to 64 bits, and you have an idea of the situation. And not only that -- you then have to figure out which sensor is which, if they are in different positions!

The amazing part is, once the code for this is written, it's all over in a few milliseconds, and the ROM codes appear on the LCD...

PIC programming, Cadillac style!

I've been working with the PIC18F4620, and am impressed by how easy it is to program, compared to the smaller PICs. I think I'm in love. Or at least in lust.

Here are some of the improvements from an embedded developer's point of view, as contrasted to the (still very cool) 16F887.

32MHz max internal clock speed instead of 8MHz
This alone would be worth it -- a PIC running at 8MIPS! It will go to 10MIPS with an external 10MHz clock, but 32MHz with no external parts needed is very cool. For us PIC16 afficionados, it's like finding out that your new car can go 400km/hr on the freeway, legally, when the old one only did 100.

MULWF and MULLW instructions
You can tell the PIC16 programmers in the audience; they just started drooling. Hardware multiply -- and not only that, but hardware multiply that executes in a single instruction cycle. I see a re-writing of some of my math libraries in the cards!

(almost) NO MORE PCLATH!
Ding, dong, the witch is (almost) dead! GOTOs and CALLs on PIC18s access the entire memory space directly. So, unless you're doing a computed GOTO, you don't have to worry anymore about the value of the high bits of the program counter. No more save-the-old-PCLATH-value-then-set-the-new-one-then-call-the-routine-then-return-then-restore-the-old-PCLATH business. Just GOTO or CALL your routine! And with PIC18s, you really don't want to do computed GOTOs anyway, because now, you have...


TBLRD* and TBLWRT* instructions
PICs are Harvard architecture parts -- meaning they have separate memory spaces for instructions and data. Before the PIC18s, there was no way to access the program memory at runtime -- lookup tables were handled by a series of RETLW statements, whether specific or produced by the assembler from "dt" statements. The TBLRD* and TBLWRT* instructions allow PIC18s to read from and write to program memory. One use of this is to use the (relatively huge) 64kB of program space Flash memory (32 kWords, but addressable as bytes for data use). Large, verbose diagnostic messages can now be programmed relatively easily, with just a little more work than calling printf() from C.

ADDWFC
Add W to F with Carry. This is a bigger deal than it sounds. It will speed up the ADD32 and SUB32 libraries quite a bit, I think.

MOVFF instruction
With MOVFF (which takes two instruction cycles), you can copy a byte directly from one memory location to another, without going through the W register. This doesn't always save time (although it's always at least as fast as the old way), but not having to go through the W register can be very helpful.

Branch instructions
Branch-if-zero. Branch-if-not-zero. Branch-if-carry. Branch-if-not-carry. Branch-if-the-moon-is-in-the-seventh-house, for all I know. Well, maybe not that last, but PICs now have more branch statements than just BTFSS and BTFSC. This doesn't quite rank up there with MULWF or TBLRD as far as I'm concerned, but I'm told it makes the compiler guys happy.

RRNCF and RLNCF
Rotates that don't go through carry. Huh. And RRF/RLF are now RRCF/RLCF, just to break older code, I suppose.

TSTFSZ
Test F, Skip if Zero. Sounds like it could be useful.

DCFSNZ and INFSNZ
Now you can increment or decrement and skip if *not* zero. I'm confused now; this is backwards from how these are normally used. This smells like something a compiler would like to have available.

CPFSEQ/CPFSGT/CPFSLT
Compare F with W, Skip if equal, greater-than, or less-than. Hmm. Equality tests sound useful.

BTG
Bit Toggle, to go with BSF and BCF. Well, I guess it was the missing option...

DAW
Decimal Adjust W. Something to do with BCD math. Sounds possibly useful.

PUSH and POP
More to the point, there's a real, honest-to-goodness stack now! This is a good thing. Low-range and mid-range 8-bit PICs have an 8-entry hardware stack. Except in simulation, it was anybody's guess just how deep into the stack a program already was when a particular subroutine was called. This made for very conservative use of the CALL statement -- and has prompted me more than once to do things with macros that I really shouldn't have.

RCALL
Relative Call. This sounds like a segfault waiting to happen. I hope it's not what I think it is...

Two NOP opcodes
To quote Bob from Frontier: First Encounters, "My, oh my, what happened here?"

RESET
There's probably a legit reason for this, but it escapes me at the moment. Why not just GOTO 0x0000?

MOVLB

Move Literal to BSR? *looks up what BSR is, anyway*

LFSR
Move Literal to FSR? *looks up what FSR is, too*



OK, now for some of the drawbacks:
Nonhomogenous instruction size
In other words, some instructions are two words long, and others are one. This means that you can't just cavalierly do a GOTO $-5 to jump back five instructions anymore, without at least thinking about which instructions are which. If you inadvertently point to a location in the middle of an instruction, the assembler will tell you. If it happens to line up on another one, it won't know anything is wrong until you run it and it doesn't work as intended. Best is to come up with a consistent labeling scheme and make liberal use of good, mnemonic labels, aiming the GOTOs at them instead of using relative jumps. This will also stop you from breaking the code when you add more lines in the middle of the loop, later. (Anyone else been bit by this one?)

They're a bit more expensive
Waah. They're worth it.