Length Oriented Protocol

For stand-alone microprocessors

Length Oriented Protocol

Postby Doug Coulter » Sun Oct 31, 2010 3:20 pm

This is a name for a protocol we came up with (C-Lab, my old outfit) for general use in communications between a PC and an embedded processor in some product we were developing. We used it for real time debugging, and later in development, as a way for the PC to tell the product what to do, and the product to tell the PC what was going on. We found this approach vastly superior to any sort of debugger with breakpoints and such, which are in general nearly useless for realtime multi-threaded applications, as by the time you hit one, and go looking, of course you've lost realtime, all the com ports have overflowed from lack of service, and so on. Far better to be able to stream out some data as the thing runs.

The limit was usually the PC! Even in the days when our fast ones were PIII at a Ghz. A PIC running full speed can easily stream out 155kbaud continuously, and no PC on earth (Still!) can take that and not overflow the hardware uart buffers. Although the serial ports were always thought of as slow, it seems that the exigencies of most GUI operating systems and ring 3 prevented someone from writing really good ring 0 serial port drivers as well -- no good reason for that other than slovenly systems programmers, but there it is, like it or not. In fact, for most of our commercial product developments, the customers would limit us to 19.2 kbaud so even a crummy laptop could take it (if the other code we wrote was really good, which of course it was).

And this is assuming using a real language on the PC side -- C and ASM, not some monkey-easy wasteful "new age" interpreted or otherwise inefficient junk. If web and java programming is ditch digging, this was actually more like brain surgery.

As originally envisioned, this was mainly done for PC is master, product is slave, but it can adapt and go both ways fairly easily, it's just that "push mode" from the product often doesn't fly for situations where an "ack" is required before moving on. To solve the slow (but fast, look at those clock speeds! Read the BS marketing brochures!) PC, we decided to make this mostly a short-message thing, so no matter how poorly the PC was programmed, we wouldn't have so many troubles with the "pentium pause" or the "windows going off on some demented errand on it's own, like memory cleanup for one of the aforementioned stupid HLLs and not servicing the "slow" serial port quick enough. So in general, we limited actual message sizes to the 10-32 byte range going either way, to support the PC and to allow for smaller buffers on the product side (usually a PIC, but not always -- we did them all).

So, we came up with LOP, which later became a much fancier DALOP for other applications where hot plugging, address discovery, and other things were needed, that provided most of the functionality of ethernet and the lower parts of the TCP/IP stack -- but for less than 50 cents a unit and not requiring fast nodes to work, or a lot of memory.

Simply, LOP is a byte oriented protocol with the following format.

The first byte is always "bytes to follow" allowing the other end to know how much buffer will be needed, and to define message boundaries, as well as allow error recovery.
The next byte is always "command". This specifies what any other bytes are to be used for, which is completely defined by the command itself.
Further bytes are data for a command, as required.
All commands from a PC are "acked" which is simply sending the command back, this time with any results data required in the response.

If a message takes too long to complete from first to last byte, it's ditched and the state of the protocol is set to "Expect new message" for error recovery, so error recovery is "didn't get an ack? retry!" -- and nothing more. Too long is defined on a per application basis, but is usually half a second or so -- even a slug of a PC can usually get a whole message pushed out in that time, and any line noise error then only holds things off for that half second or so.


The upshot is that the device software to handle this can be very simple, and if the command numbers are defined in a standard .H file, that file can be included in both softwares to keep things in sync.

For our use, we defined the lower 64 or so of command space for things like "peek this address in the target" or "poke" or "jump to" or "reset" or things like that -- stuff that's valuable in all developments. Above that number were product-specific commands and responses like "give me the map between names and phone numbers" if it was a PBX or similar, or "set so when I page this number, it actually pages this group of numbers" kinds of things.

As the embedded opsys thread grows, I'll have more to say about this one, but it's really not that complex, or if it is, it's because it DOESN'T take a lot of code to implement, and by design, it's the code not needed anymore where the actual smarts live in this. Good design has as a hallmark apparent simplicity. It may actually be fairly complex as threads interact, but again, with good design, rather than needing fancy tools like semaphores, it can often be done so that things can't get in each other's way; at least until a dumb programmer at the customer misses the point and thinks he can "improve" a too-simple (in his mind) design.


So it looks like this, and in most cases, though this will support 255 bytes total, we limited it to either 16 or 32 for the benefit of the PC end (and less ram in the product end).
byte1: number of bytes to follow
byte2: command parser to pass this message to (eg index in a switch statement)
bytes3 and up -- any data for that command.

Of course, in the message array, what I show above as byte1 is really message[0], the old fencepost thing.
Looks too simple to even bother writing up, eh? Like a Bstring in basic? Well, when you see the code, and how it handles all the possible error conditions gracefully, and with very little code and very few CPU cycles, you might think differently.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Return to Embedded software

Who is online

Users browsing this forum: No registered users and 2 guests

cron