Close

Using the board #1: Lino "protocol"

A project log for Lino

An Arduino-compatible board to master the power. The first attempt of a compact dev-board capable to drive 10W loads.

enricoEnrico 06/25/2016 at 18:060 Comments

The "Lino protocol" - Board demo interface

To have the board working, I setup a simple protocol used over the serial, but other physical line can be used, like I2C. I need to master even complex variations of the PWM sequence, also in a scalable way. For this reason I needed a proper protocol, with expansion potential, to open the possibilities to develop a proper higher level application in a simple way on a PC or any master controller side.

Moreover, as it will be explained, the data handled by this protocol is conceived to be developer friendly, where the developer is someone who will generate a proper software to achieve the desired data exchanged.

What is important here, is that we have 255 combination per each color, plus an algorithm to emulate in RGB and pure white combination to generate pastel colors or shades of white. With such assumption, I do not use any LUT but instead I generate the color according to the HTML encoding executed on the Lino microcontroller.

Physical Layer

It consist in an array of 18 bytes sent from a master PC or device (over serial/USB) made by the following sequence, from the first to the last byte sent, MSB to LSB:

[StartChar] [CTRL#00] [CTRL#01] [R#0] [R#1] [G#0] [G#1] [B#0] [B#1] [W#0] [W#1] [INT#0] [INT#1] [RES#00] [RES#01] [RES#10] [RES#11] [EndChar]

Where each byte is represented from LSB to MSB, the data is sent using UART (8 bits, 1 Start + 1 Stop bits, no parity), but can be transferred using any other simple protocol (I2C, SPI ecc).

Serial voltage levels swings are on 0V-3.3V.

Data handling

The values inserted by the application or the user through the terminal are written in ASCII, but representing an hex format coded to save bytes. In other words, if the sender wants to send the value 254(decimal) to Lino, it will send the chars "F"(character) and "E"(character) or "f"(character) and "e"(character) on text terminal, representing the intention to send the 0xFE hex value. The first char sent is the MSB of the hex number; how each bit is transmitted is no more concerned here, but hidden in the physical layer described before, handled in UART. The chars sent are corresponding to ASCII codes, so on the serial lines are physically sent, in this example, the ASCII "70"(decimal) (for letter f)+"69"(decimal) for letter e.

On the board is made all the conversion reversed to actually compose the number 254. To ease the software front-end, the serial is completely case insensitive and look only for characters that can represent the hex numvers, so any character sent outside the range "0" to "9" and from "a" (or "A") to "f" (or "F") can be used in the firmware for synchronization, or can be discarded at run time but used by the user when sending data manually over the terminal for testing purposes.

Here below is listed the meaning of each byte:

  1. StartChar: the char used to discriminate a begin of transmission after startup, or a StopChar, after a timeout or any subsequent StartChar in case of line issues
  2. CTRL#00/#01: The combination of characters reserved for any auxiliary command. #00 is the MSB, #01 the LSB.
  3. R#0/#1: channel Red data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  4. G#0/#1: channel Green data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  5. B#0/#1: channel Blue data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  6. W#0/#1: channel White data (from 0 to 0xFF). #0 is the MSB, #1 the LSB.
  7. INT#0/#1: intensity which is applied to the RGBW channels (from 0 to 0x64 [100% in decimal]). #0 is the MSB, #1 the LSB.
  8. RES#00/#01: reserved byte for any further necessity. #00 is the MSB, #01 the LSB.
  9. RES#10/#11: reserved byte for any further necessity. #10 is the MSB, #11 the LSB.
  10. EndChar: the char used to end the transmission and call the command interpreter on the receiver (Lino).

Each group of byte (numbered as #0#1, #00#01, #10#11) can be divided using a mark char (here the ".", a dot) to make it more human readable the text on a terminal emulator, when debugging, testing and so on. These chars will enlarge the data transmission because it is a data overhead, but on the receiver side are completely invisible since are discarded, at run time.

These 3 examples can be actually copied in a terminal and sent as a text on Lino, moreover, these three commands are equivalent:

$00.Aa.20.FF.bC.64.00.00#
$00Aa20FFbc640000#
$00AA20FFBC640000#

In which:

- start char "$"

- the CTRL field is CTRL#00 = 0, CTRL#01 = 0

- the R field is R#0 = 0xA, R#1 = 0xA

- the G field is G#0 = 0x2, G#1 = 0x0

- the B field is B#0 = 0xF, B#1 = 0xF

- the W field is W#0 = 0xB, W#1 = 0xC

- the INT field is INT#0 = 0x6, INT#1 = 0x4

- the RES field is RES#00 = 0x0, RES#01 = 0x0, RES#10 = 0x0, RES#11 = 0x0

- stop char "#"

The colors are therefore represented adopting the HTML color compatibility 24bit coded. As example, the above frame will represent the following color:

at maximum intensity, and the additional pure white set to 87% to make the white component more realistic.

Discussions