uzi_hs I was hoping that there is a proper communication protocol doc, with all the details needed for implementation from scratch.
yeah there's not really such a thing, but you can see that the communication is pretty straightforward. These are two sets of constants you need to know about:
https://github.com/BelaPlatform/Trill-Linux/blob/master/lib/Trill.cpp#L16-L32
enum {
kCommandNone = 0,
kCommandMode = 1,
kCommandScanSettings = 2,
kCommandPrescaler = 3,
kCommandNoiseThreshold = 4,
kCommandIdac = 5,
kCommandBaselineUpdate = 6,
kCommandMinimumSize = 7,
kCommandAutoScanInterval = 16,
kCommandIdentify = 255
};
enum {
kOffsetCommand = 0,
kOffsetData = 4
};
and https://github.com/BelaPlatform/Trill-Linux/blob/master/lib/Trill.h#L31-L40
typedef enum {
NONE = -1, ///< No device
UNKNOWN = 0, ///< A valid device of unknown type
BAR = 1, ///< %Trill Bar
SQUARE = 2, ///< %Trill Square
CRAFT = 3, ///< %Trill Craft
RING = 4, ///< %Trill Ring
HEX = 5, ///< %Trill Hex
FLEX = 6, ///< %Trill Flex
} Device;
and then figure out from the code which and how many parameter bytes are passed to each command.
Then every time you write a command, the first byte you write is kOffsetCommand, followed by a kCommand constant and zero to two argument bytes. Always wait 10ms after writing command. The only command that produces a response is kCommandIdentify: write it (it takes no arguments, so it's just {kOffsetCommand, kCommandIdentify, wait 10ms and then read back four bytes. The first and last are ignored, the second is the Device and the third is the firmware version.
Once you are done with commands and want to start reading data, write a single byte containing kOffsetData and so all future reads will return data. Depending on which mode and which device you are in, the number of bytes to read may vary. Refer to table 5.2.1 of the datasheet for data length and format.
