The Microship Status Reports

Microship Status 12/12/93 by Steven K. Roberts

In This Issue:

Still Alive!
General Updates
Microship Network Overview

Still Alive!
Hey, I bet you thought I bailed out of this whole project and got a job in industry, huh? I mean, this is the first issue of the status report in almost 2 weeks!
Actually, since about 2/3 of this mailing list consists of UCSD students, I decided to ease up on update volume for awile. This past week was finals, and the feeling of stress was pervasive on campus. Now it's vacation, which is really quite awful -- the whole place is practically shut down, with such fundamental essentials as capuccino and pizza increasingly difficult to acquire.
But the Microship project has been churning along despite all this, and here's a quick update on the news...

General Updates
I've spent much of the time since the past update working on the Microship Control System specifications -- a document that will hopefully be complete enough by early January that returning students will have a cohesive reference on the overall system design. More on that in the next section.

Lots of news on the sponsor front. Paravant, a maker of military waterproof keyboards, is out of the picture, but I'm now in encouraging negotiation with IEE in Van Nuys (proposal almost done). They have submersible OEM full-travel keyboards for the DOS world, and with the Silicon Valley Bus Company's "Keystone" product coming, we'll be able to point one PC keyboard at either Mac or DOS platforms. I'm also looking into making a back-to-back pair of UAR/Ts with different clocks, which should allow the keyboard to connect directly to the FORTH hub's console port when a minimal terminal is necessary (the local 2-line LCD would be the display). Anyone want to take that on as an exercise in small-scale logic design and packaging?

No-go on the Compaq 486, also, though now that I've been configuring the I/O-rich Ampro system it's not as critical. They're having economic woes and downsizing. The Ampro is looking great, and should be shipping next week: a 286 Core Module, the FSI board for floppy-IDE-serial interface, an ethernet (thin coax) board, and the LCD driver. I already have a VGA card left over from bike development. During development we'll hang an IDE hard disk on there, and when it comes to packaging in the ship we'll change to PCMCIA flash memory and possibly upgrade to 386 if it seems justified.
The display for the Ampro is looking good -- I spoke with Sharp and they will be donating an LQ6 color LCD for development, probably to be replaced in a few months with an industrial version of the same product (wider temperature range). This display accepts NTSC video as well as computer-generated display data, so it will be the console video monitor for the on-board cameras.
The spec for the FORTH boards is undergoing continuous evolution, and New Micros is shipping an NMIT-0020 for the Hub system immediately (including a 2-line LCD to go with it). I'll also need a 20-key keypad for the low-level user interface.

The ailing Mac, damaged mysteriously by the SCSI hard disk, is now back in LA thanks to Dave Yao who dropped it off enroute home for the holidays. Mike Clark will find out what happened to it, and it should be back in a couple of weeks.

Luke Abbott has begun the Microship video project -- in the past few days we've captured raw footage of Vincent Lui playing Liszt (piano) and Isaac Chu playing Bach (violin), since in the video production we want to show that the project participants are not just interchangeable student-modules. We've also started filming meetings, drawings, subassemblies, and anything else relevant -- with the intent of turning it all into an ongoing subscription video series on the project that will continue after launch. Luke is becoming enthusiastic about the prospect of building a video production system into a boat, so the flotilla concept is of interest here as well... we had a good talk over sushi last night. Everyone working on the project will be on camera -- I really regret NOT doing this during the 3.5-year BEHEMOTH project.

I had a good meeting last week with David Crane, whose company develops and markets a wide range of products for the marine marketplace (nautical computing and communications products). We're exploring equipment sponsorship and Microship-spinoff ideas... I'll keep you posted.

Finally, I'm changing living environments tonight, moving in with TJ so we can work around the clock. He's spending the next week here to get a serious start on the mechanical specs, and we're meeting with Robb Walker tomorrow.

Microship Network Overview
Most of my keyboard time in the last week has been devoted to writing specs, with the Intro, Hub, Audio Crossbar, and Serial Crossbar sections now complete along with related drawings. The full document is a bit much for inclusion in these reports, but the general introduction is appropriate:
(begin included text)
---------------------
Every system design is a function of its environment. In few places is this more obviously true than in the Microship, and before going into detail about subsystems I need to explain a few things.
First, one of the most frequent questions concerns the number of computers. Look at the MCS overall drawing in the back of this binder, and you'll see over 20 processors (not including embedded controllers associated with products, which would at least double that number). With robust multitasking systems like the SPARC available, why trouble ourselves with so many machines? There are five good reasons...

1. Minimizing single-point failure potential A central computer system that runs everything means that a single equipment failure can shut down the whole ship. Considering that there are survival and safety issues at stake here, this would be unacceptable.
2. Conserving scarce power resources Large, fast, capable machines tend to draw a lot of power supply current. When power is precious -- as in a solar/battery powered system -- it makes more sense to match resources to tasks and only power them when necessary. Monitoring a few security status bits overnight with a heavy-duty system would require a continuous draw of an amp or more -- with a little CMOS micro, we can do it for 1% of that, and save the power-hungry machines for navigation, graphics, boat-top publishing, and so on.
3. Simplicity At first glance, the MCS looks anything but simple -- but consider that each computer on the control network is a small, dedicated machine, operating in a very local region and focused on one or two tasks. Building a multi-tasking real-time system that also incorporates a graphic user interface and file support is non-trivial, and hard to get 100% correct.
4. Development team management See above. I'd rather break up a project into 20 groups and give each one their own computer than try to manage 20 groups writing code and competing for hardware resources on the same machine.
5. Cable reduction Finally, computers can be cheaper than wire, especially where waterproof connectors and critical packaging are involved. It is MUCH more cost-effective to run a single network and power cable around the ship than to distribute complex, device-specific I/O from a central panel. We're probably reducing ship-wide cabling by a factor of 10 or more by taking this approach.
Now that that issue is out of the way, I'll make a few general comments about architecture and then start discussing specifics. As you read this document, it will be helpful to fold out the MCS overall block diagram and keep it in view for reference.

The heart of the system, if there can be said to be one, is not a computer but a network. Actually, there are two of them -- the high-speed Ethernet that links the console systems and file server, and the low-speed multidrop network that connects all the microcontrollers. The former has been well-documented elsewhere, and can be compared to a LAN that links all the machines around a building (complete with gateways to the Internet). The latter is where most of the people on this project will spend their time, so let's look at it more closely.

The protocol I've chosen is called Easy-A, defined by New Micros of Dallas, TX. The name is appropriate, since this is about as simple as you can get and still call a linked assemblage of microprocessors a network. Electrically, it's 4-wire "modified RS-422," with one pair dedicated to transmission from the hub to all remotes, and the second shared by all remotes for their transmissions to the hub. Only one remote can talk at a time, and the others are simply tri-stated (high-impedance). This completely eliminates the need for collision-detection and the other complexities that add processing overhead (power) to the more familiar networks such as Ethernet.

The hub, of course, decides who gets to talk, and it does so by transmitting a control-A over the net. At this point, all the remotes take notice, and, with bated breath, await the address character to follow. The hub then sends a single-byte select code, and all remotes except the Chosen One leave their transmitters tri-stated, in effect remaining invisible to the network.

The selected unit simply enables its transmitter, and the net effect, so to speak, is a direct connection between the hub and the console port of that processor. There is thus no overhead of any consequence, meaning that the hub can be a dumb terminal with a human at the helm. If you want to connect yourself to device F, for example, just hit control-A, then F. It's that simple.

One of the implications of this is that individual remotes cannot initiate communication on their own over the network, and are thus incommunicado unless the hub takes the initiative and polls them for activity. If extreme power-saving economy is indicated, we may shut down the hub and allow certain critical remotes to yank a wake-up line if something serious is happening -- but the basic approach is to depend on the hub to perform a periodic scan of all connected devices to see if any of them have anything interesting to report.

I mentioned a moment ago that the hub could just as well be a human with a terminal. I should point out that this extends to remote, wireless logins as well, whether via a UHF packet radio link from my backpack or a terminal here on campus, logging into the Microship via Internet and satellite or cellular phone. A key design goal is accessibility of all connected systems, and you may one day find yourself talking to the microprocessor system you designed via a 30,000-mile communication link... which should feel about the same as having it sitting on your desk.

One final point. The processors we are using are New Micros 68HC11s with FORTH in ROM. FORTH is quite unlike the normal assembler- or compiler-based devlopment environment, for when you are talking to the machine you are talking to an compiling interpreter... or maybe an interpreting compiler. Writing programs is a matter of adding "words" to the language, building on the low-level vocabulary that's already on-chip. Since command-line actions can directly address all the machine's resources, it is conceivable that some of the "controllers" on the network will not even need to run "programs." The hub can simply connect, and issue a FORTH command to read or write a port...

With that, let's move on to the specific definitions of the various systems on the control network. In each case, I will name the machine and its network address, give a text description of its role on the boat, and then summarize the required software functions and hardware interfaces. This document will undergo revisions as the project evolves, and may be considered the complete working specification for the Microship Control System.

Cheers! Steve