Years ago I started creating a Venturii module coined
Modshell that was designed to be a generic code base from which to easily whip up new modules as I encountered additional systems to integrate Verturii with. Modshell has trailed behind the leading edge of development, though it's concept has recently been revitalized by the development of Buscom. Among other things, Buscom essentially accomplishes one of the same goals Modshell was supposed to.
Buscom is a generic Venturii module. Unlike every other Venturii module which was created to interface with a specific system or piece of hardware, Buscom has been designed to interface with
interfaces, not
devices. What that means is that Buscom includes all of the code necessary to set up the following connection types:
- TCP Server (Remote device connects to a listening TCP socket served by Buscom)
- TCP Client (Buscom connects to a listening TCP socket served by some external host
- UDP Server (Remote device connects to a listening UDP socket served by Buscom)
- UDP Client (Buscom connects to a listening UDP socket served by some external host
- Serial Port (Buscom connects to an external device over a native (16550 or similar based UART) or USB-based Serial Port
- (Unix) Named Pipe (Buscom connects to another service running on the same host that can communicate over a named pipe
Having established a connection to one or more of these connection
types, data can be sent directly to and from that device through Decider. One of the first simple uses I had in mind for this was to set up a dot matrix printer that recorded a log of sorts, printing one line at a time as it was received from Decider. All Decider needs to do is generate a string of text and send it to the appropriate channel on the corresponding Buscom module, and that string will be delivered verbatim to that printer. This, as it turns out, has many other practical uses as well. It turns out that many systems utilize a simple yet powerful system for providing API's to their inner workings. This will actually be the basis for both the Pelco Endura integration and the Harding DXL Intercom System integration, both of which use simple, low level serial protocols for allowing external control of their workings.
Today I have begun returning my focus on Buscom, with the plan being to clean up it's code, run it through a series of tests (including both functional and performance & memory usage - IE: Valgrind) before I begin to fork this project and create a new one, the first child of Buscom, which will be a Modbus module for talking to RTU devices using the protocol already named.
