The Microship Status Reports

Microship Status 2/15/94 by Steven K. Roberts

In This Issue:

Control Network Flickering To Life
ECE-190B REDUX!!!
Cdt List
Quick Notes
Aaagggh! Keeping up with documentation is impossible -- not only this series of project status reports, but also the BIG BOOK of specifications. I am making lab notes, but somehow they all have to make it to clean documents before I forget their context... <panic>

(The reason for that outburst is actually good news -- so much progress is happening that I agonize over the difficulty of keeping track of it. That's far better than keeping careful track of NO progress, however...)

Control Network Flickering To Life

Soon this topic will move into the background where it belongs, since it is, after all, just the infrastructure. Paying too much attention to it is akin to buying a computer as a book-writing tool and then spending the next two years fiddling with the computer. But we gotta get it right, and that's happening.

The "obscure and confusing bug" I mentioned last time is now just history, though it didn't fall without a fight. Two things were happening -- fast high-level coded datacomm was trying to coexist with the multitasker, swapping out on every occurrence of ?TERMINAL or KEY. The overrun conditions from the network appeared as missing characters, which became spacier the more tasks were running. The high weirdness occurred when we hit reset to get out of that and found the board forever inaccessible... requiring the WIPE utility (we thought) to erase the EEPROM. As it turned out, we just needed an extra instruction in the startup routine to point at the right user area... something unlikely when leftover task-switching pointers are still there after a crash. It's fixed, and the lesson is that RAM doesn't necessarily forget completely upon a power cycle. New autostart code immediately initializes all pointers.

The original problem that smoked that out is still there, however, and that is the difficulty of dealing with high-speed serial datacomm via software while a multitasker is active. There are a couple of kluges that could fix it (like disabling tasking during comm strings), but we're implementing the correct solution: another interrupt service routine for the network interface, complete with ring buffer. Bill Muench is writing the serious code, and we should be integrating it in a day or so.

All that aside, it's really amazing. We've been installing the new BeeLine comm protocol in various boards, hanging them on the net, then downloading the tasker and a file of test code. We can select any board by simply clicking a button on the MicroPhone screen on the Mac (or via Hub code, of course).
I'm also adding a cluster of three LEDs to each node, and the two completed so far are already proving to be useful:

YELLOW (Net): lit whenever the node is enabled onto the multidrop bus via PA3 (port A bit 3), providing a visual indication of network activity and node scanning. The catch here is that the 75176 drivers are power-hogging NMOS (35mA!) and soak all the power the poor HC11 pin can muster... driving the LED without taking the board offline took not only the traditional low-side NPN switch but also an emitter follower AND a pullup! (Anybody know of a CMOS pin-compatible equivalent?)
GREEN (Health): controlled by PA4, and owned by a dedicated task in each node that combines health and watchdog (COP) functions. A flicker about once a second will indicate a working board, and we might arrange things so that the frequency reflects tasker loading. This same task also provides the values (board ID and health code) returned to an ALIVE? query from the Hub.
RED (Prog): controlled by PA5 and used by each application for debugging, status indication, error conditions, etc. Examples include a brief flash on each receipt of a GPS string in the Nav processor, security mode status, all-buses-busy on a crossbar, autopilot corrections, etc.

Now that things are waking up and feeling stable, we're seeing the project teams making additional progress. Today Henry (GPS), Carl (Ultrasonic), and Chris (Hub) worked together for about 3 hours on the NMEA nav sentence array and parser, making great progress in FORTH understanding as well as problem clarification. Michael (Hub) whipped up a 20-key keypad the other day for the helm controller, Isaac (AuXBAR) is working on the initial Hub-response code, and as I write this at 11 PM, Jeff (SeXBAR) is in there wiring the crossbar board. I started playing with an LM335 temperature sensor and the A/D system last night, and Prof Guest helped today with op amp level shifter design. I designed a "tri-state detector" that will let the Hub easily determine whether the net is responding appropriately to node-select commands. And I mounted a pair of the New Micros level converter boards on the Hub chassis along with a big honkin' 4PDT switch, allowing the entire network to be toggled between the Hub serial port and an external RS-232 device like a PC.

The Hubfolk and I have been defining a suite of standard commands that will have to be handled by all nodes on the net. Much of it has to do with robustness and error-handling -- we're cooking up a protocol that should allow failures at just about any system level to be detected and, hopefully, handled automatically. (We will be able to issue a master reset to the entire network, cold-start any truly ailing node, then restart all taskers and applications in a single utility.) We're also defining words like ALIVE?, SHOW, and NEWS?, which serve respectively to yield health and ID data, a snapshot of current activity, or routine status and internode mail. In addition to all this, of course, the Hub will transparently pass application-specific traffic to and from the various subsystems.
ECE-190B REDUX!!!

Speaking of the ECE-190B project class, HOT NEWS in case you missed it earlier today! Clark Guest notified me that the Electrical and Control Engineering Dept here at UCSD has approved a Spring quarter session of the senior project class -- meaning that in March we'll be able to start another whole team on control system design. There's still plenty to do -- packet radio links, battery management, power distribution, security, bay pressure control, bilge control, more nav processing, autopilot, graphic front-end tools, environmental data collection, and more. Now that the network is reasonably stable and there's an emerging FORTH-literate culture producing working systems, a good design context is established and this is a GREAT time to jump in.

So if you're an advanced (senior, beyond, or *experienced*) engineering student here and want to get involved in a somewhat more formal context than the scarce 199 technical electives, this is the time to act... please contact me ASAP. Also, since these postings are to a relatively small mailing list of 100 or so people, please forward as necessary to any creative people who might be interested.

Cdt List

Rembember the CDT list? If you're around campus and want to help out, but aren't ready to take on a full-scale project, here's how. I'm maintaining a "clearly defined task" list as a stack of 3x5 cards in a box in the lab (a sort of old-fashioned database method, for those of you who've never seen such a thing). Here's a quick one-liner summary of what's in there at the moment -- if anything sounds amusing, please let me know:

Build rack for wire spools Contact database updates Photo scanning for the WWW server Research equipment bay connector standards Clone BEHEMOTH's LED matrix scanner Self-scan analog mux and digital panel meter Choose pressure sensors Pack and ship a few things Find and repair leak in kayak flotation bag Resistor and Capacitor inventory organization IC inventory organization Woodworking for solar still project Build kayak support cradles

Quick Notes

Progress on the Ampro PC! Frank and Dan have repackaged the hardware over the past couple of days, now that we have gotten the system working with a SCSI hard drive borrowed from the bike. The IDE controller must not be well -- we tried it with three drives, but SCSI came up easily and also runs the 3.5" floppy that wouldn't work earlier. I'm looking forward to packaging the new Sharp color display and firing it up...

Silicon Valley Bus Company shipped the Keystone, which is a magical little box designed by Jay Hamlin. Plugged into a Mac ADB port, it allows a standard PC keyboard and mouse to run the Mac. Ain't technology wonderful? This is of great value here, since it will allow one waterproof suite of console devices to run all on-board systems.

The Digi-Key shipment arrived, containing the horrendously expensive SeXBAR connectors, 60 nifty little LEDs with internal resistors, 50 2N3904s, the temperature sensors, and a universal PLCC removal tool.
Luke is continuing to capture project video, and we're hoping to head down to Scripps this weekend to unwrap the new kayaks for posterity (unless that happens during an upcoming meeting with Drew from Nelson/Marek on Thursday).

Those are the headlines! Cheers from the lab....

Steve