Bitty Controller uses Bluetooth to communicate with a microcontroller such as a BBC micro:bit or Arduino or with a computer such as a Raspberry Pi. Here, we'll use the term remote device to refer to the thing Bitty Controller is connected to over Bluetooth or sometimes, just device.
Bitty Controller sends special data values to the remote device over Bluetooth to indicate something the user just did, such as pressing or releasing one of the pads in the D-Pad controller user interface (UI) or sliding the trackball up the touchpad with a finger. It is then up to the code on the micro:bit to decide what to do with the data it receives. Perhaps a motor will be started or a light flashed.
Writing code for a remote device to respond to Bitty Controller falls into two parts therefore.
Bitty Controller does not know what is electrically connected to the remote device. What it sends to the remote device varies only according to the action taken by the user when interacting with the UI and is not affected by what the remote device is connected to.
Code on the remote device will therefore need to ensure that it handles relevant communication from Bitty Controller and then use appropriate logic to initiate the required action.
Having determined what it is that the user just did, by examining the data received from Bitty Controller, the remote device code will need to perform some kind of action to instigate the required type of control. Maybe this means rotating a servo through 90 degrees. Maybe it means speeding a motor up to full speed. Or maybe it means flashing a series of LEDs. It could mean anything and this is where you, the firmware developer will need to know what it is that you want to do and how to go about accomplishing it with your device's APIs or graphical programming blocks. This will require you to have some information about your device such as which pins its motors are connected to.
The Bitty Controller example code here at bittysoftware.com is a good source of information on the details of controlling a variety of popular bots and other maker kits.
Bitty Controller supports two styles of communication or to be more technically accurate, two distinct Bluetooth profiles. You will need to decide which of these is best for the type of remote device you are using.
If you are unfamiliar with terms like profile or Bluetooth characteristic, you should take 5 minutes to read our Bluetooth Low Energy for Beginners page.
The micro:bit profile is, per the name was originally designed for the BBC micro:bit and tools like MakeCode support it. It uses a system of micro:bit events to indicate user interactions and micro:bit code must register to receive and handle particular event types.
The micro:bit profile also allows pins to be written to directly, without the need for special micro:bit code written by you (the code is standard and included within the micro:bit base firmware, known as the DAL).
There's nothing to stop you using the micro:bit profile on a device which is not a BBC micro:bit. If your device allows custom Bluetooth profiles to be created using APIs, then you can implement the micro:bit profile, and Bitty Controller will think it's communicating with a micro:bit.
The micro:bit profile is documented at https://lancaster-university.github.io/microbit-docs/ble/profile/. Bitty Controller uses the Event Service for most interactions and the IOPin Service for the on/off switch UI.
Now review details of how communication from Bitty Controller works when using the micro:bit profile.
Some Bluetooth modules such as the popular (and cheap) HM-10 provide a very simple Bluetooth profile which mimics a serial interface, allowing a connected device to read or write arbitrary sequences of byte values in much the way you would if the connection was formed from a physical, serial cable.
The profile consists of a single custom service with a single characteristic. To send data to the remote device, Bitty Controller writes to this characteristic. To receive data from the remote device, the code on the remote device must send it as a Bluetooth notification on this single characteristic.
The serial profile has the following design. Note that the 128-bit UUIDs can be configured in the Bitty Controller Options screen so it is not necessary to use the examples shown here, which are the values used by an HM-10 module by default.
Service: serial service Characteristic: serial_buffer Properties: NOTIFY, READ, WRITE, WRITE NO RESPONSE Descriptor: Client Characteristic Configuration
The service and its characteristic, as implemented on an HM-10 module is shown here. The screenshot is from the nRF Connect mobile application.
Now review details of how communication from Bitty Controller works when using the serial profile.