The cool thing about connected devices is that… well, they’re connected. Which, these days, means that they have access to immeasurable amounts of… whatever is out there to be connected to. Word is that that stuff is pretty useful. Proof of that is playing out as the Internet of Things (IoT) rolls out.
Having electronics connected to the internet is nothing new. We’ve had connected computers for far longer than the internet has even been around. That was enabled by special hardware – a separate network card made by a different company – plugged into the computer.
More recently, phones have data connectivity riding alongside the voice information. Oh, and then they may have a WiFi or BlueTooth connection on top of that. Specific ICs made by specialists help there.
But now, seems like everything short of dirt will get a connection to the internet. Unlike the past, when you could delegate connectivity stuff to some specialist, it’s entirely likely that ambitious inventors, whose attention is focused mostly on what they’re inventing, will need to confront the communication beast face to face.
The problem boils down to one of tying the network to your processor, which implements your awesome high-level algorithmic engine. You’ve got an RJ-45 connector all set up; all you need is to get that network signal to join up with the processor. Sounds trivial, right?
Well, just like a riverboat may have a hard time accessing the shore if it has to work its way through reeds and thickets and mangroves between the channel and dry land, so the network data has to come off the wire and, somehow, get through a morass of processing to be turned into data that’s relevant to something going on inside the processor.
This is a problem that Lava Computer Mfg. is addressing with a dedicated chip that will magically make all of the futzing with TCP/IP (as well as related protocols like UDP) disappear. It can take data from some process and, just like your shipping department, package it all up and send it out onto the network. (Yes, it’s not your imagination. We just did a metaphor jump. It’ll be fine…)
“What’s so hard about shipping?” you ask. Well, if you’re up on the 9th floor fulfilling an order of widgets for a customer, the last thing you want to do is run downstairs and figure out which box size is needed and how much postage is required and what kinds of labels and fasteners are allowed and what the postal restrictions are and… and… Likewise, if you’re a Thing designer trying to get some cool new functionality going, the last thing you need is to take six months off to study TCP/IP so that you can package up and ship your data.
That’s the goal of the Lava chip: it buries TCP/IP – and a bunch of other stuff – for you. That’s great in theory, but how, in practice, do you manage this in a way that’s going to make sense to the person writing software on the processor? How do you cross this last centimeter between the Lava chip and your processor?
The Lava IP System (LIPS) includes a simple protocol for getting data onto the network without futzing with the network details. Actually, the protocol doesn’t get you onto the network; it lets you set the system up and then deliver data to the Lava chip. The Lava chip then handles getting the data out onto the network.
This is about more than simply formatting data for one of the network protocols. Yeah, UDP is simple enough, but it’s tantamount to tossing data over the fence and hoping someone is around to get it. TCP, by contrast, can involve persistent sessions – actual data conversations. Not only is there formatting going on; the system has to manage multiple sessions that may be in play.
From a designer’s perspective, the LIPS system gives you up to twelve processes to play with. The protocol lets you set these processes up in the Lava chip. For each of those processes, there is a simple packet that you use to send data from the processor to the Lava chip. The packet is based on the old SLIP format, bounded by BRK, and consisting solely of a process number and the arbitrary payload.
So from a software standpoint, you simply package up your data and send it off. Special process IDs can be used to configure and maintain the states in the LIPS engine (process IDs 128 and higher are used for system control functions; process IDs under 128 are used for data going to or from the network).
Interaction with the Lava chip happens via low-level code; they expect that developers will bury that under headers and wrappers and what-not for better code maintainability and abstraction – depending on the amount of code space available (some of these systems may be resource-stingy).
The Lava chip also contains support for other higher-level protocols (not shown in the simplified figure above). For instance, data and variables and such can be automatically extracted from an HTTP request for passing to the processor.
Lava makes a module that carries this; it provides a 10/100 Ethernet connection. They’re also working on one for WiFi. The Lava chip contains everything down to the physical layer; the Ethernet module supplies a transformer and RJ-45 connector. The WiFi module will use a different processor, with the appropriate wireless pieces rather than an Ethernet plug.
Why might you use this solution? Simply to cut off a goodly chunk of development time. Their claim is that connectivity work that would normally take 4-5 months can now be handled in 2-5 days – and in some cases, even in just a few hours.
It competes, of course, with other solutions aiming to get your Thing connected easily (we’ll be looking at another one shortly). What’s different about the Lava solution is the fact that, at the programming level, it’s not just a single stream of data to be packaged up for the net; it’s an intermingling of up to twelve streams. Hence the need for the simple protocol.
It may also be useful to place this into the perspective introduced the other day, where I postulated three communication levels (protocol/generic data/business object) between a Thing and the cloud. The LIPS setup implements the generic data level.
I have to admit that hearing about a new “protocol” caught my attention – and I suppose it’s a little disappointing to learn that it exists only over a very short distance between two chips on a board. That’s a rather limited scope. But if it makes the difference of several months in crossing that last centimeter, then there may well be some folks that are pretty happy that the protocol – and system – exists.