Embedded Software Bus¶
ESWB is a portable pub/sub middleware that creates a uniform way of functions to communicate between each other: inside thread, between threads, between processes. ESWB is designed to be the major and the only candidate to do inter process communication inside project. Its purpose is to define architecture template, engage reusability and provide tools to build and debug complex embedded systems like drones and the rest of the robotics.
ESWB adresses the following problems:
software connectivity and IPC calls are too diverse, and diversity rises over time, architecture drifts;
eventually project might get into OS jail;
functions are coupled together, and it is hard to test them anywhere but the target device with a limited debugging scope;
developers have to create own data logging and telemetry services.
Diagram above presents internal structure of the ESWB. A local bus registry is a data structure allocated with corresponding calls to register, contain, and group published topics into directories or combined records. Term local means local to the process address, e.i. the registry is allocated inside the process’s memory space. Broker facility represents external process containing its own local topics registry, and reusing local busses behavior, same time being wrapped inside an infrastructure to have access via external calls. The bottom is in charge of reading and writing topic’s data and performing mutual exclusion in case topics are allocated for inter-thread bus.
Warning
Use case for Inter-process communication via broker is planned, but not implemented at the moment.
Related materials:
- Event Queue
Bus’s event queue
- The ESWB API Reference
API reference