advertisement

Lumi Communication This namespace contains the serial device management functions. The goal is to have two abstract classes that define the interaction between the main device and the peripheral. These two classes will be responsible for searching, connecting, exchanging data, closing connections, and handling device failures. To start, I'm going to follow some advice from Mythical Man Month: "Show me your flowcharts and hide your tables, and I'll still be baffled. Show me your tables, and I usually won't need your flowcharts; they'll be obvious." Well, I don't have tables, so I guess my graphs will suffice. LumiCommunication relies heavily on Apple's CoreBluetooth API. It has abstractions that represent local and remote devices. These abstractions are inherited in concrete classes for different types of devices. Currently, the API focuses on two types of devices, BluetoothLE and WiFi (ESP8266). However, if the abstraction is effective, it should not be difficult to provide support for both classic and wired serial Bluetooth connections. The main responsibilities of the CentralManager are to monitor the PC device status, initiate searches, and connect to devices. I'm adding a bit to the CoreBluetooth model; I'm writing this code to be hacker-friendly, since one of my biggest problems with frameworks intended to interact with embedded devices is that they often don't allow for easy modification of the device's behavior. For example, most SoC-centric device modules (HM-10, ESP8266, etc.) that control radio hardware have firmware that allows the behavior of the module to be modified. These are often modified using AT commands. One day it occurred to me: why don't I write code that way? For example, instead of writing concrete code within classes that handle BluetoothLE searching to automatically connect to known devices, why not create a static object that defines these behaviors? Then when I want to change the behavior of my hardware, I simply pass in a new behavior definition object. I have described this in my BehavioralBluetooth project (abandoned for the moment). LumiCommunication classes will have an object that defines the behavior of the hardware. The PeripheralManager is responsible for representing the states and delivered data of peripheral devices. There are events associated with data received from the device, confirmation of data sent, device state changes. Like CentralManager, PeripheralManager will have a PeripheralBehavior object that will define its actions. There are receive and send buffers to monitor the successful flow of data between the local and remote device.

advertisement

advertisement