Green and red channels are swapped when setting color in RGB registers

[banchan86]

Description

When using the RGB0, and RGB1 and RGBAll registers to set the color of a WS2812B addressable RGB LED, the green and red channels are flipped, so when setting a payload like this:

`Blue0` : 0
`Red0`: 0
`Green0`: 255 

The LED will turn out Red and vice versa. The blue channel is unaffected.

Probable cause

WS2812 uses GRB instead of RGB order encoding for the signal, so the payload is formatted as such in device.yml and the generated Bonsai interface:

device.behavior/device.yml

Lines 184 to 202 in 704d2a9

	payloadSpec:
	Green0:
	offset: 0
	description: The intensity of the green channel in the RGB0 LED.
	Red0:
	offset: 1
	description: The intensity of the red channel in the RGB0 LED.
	Blue0:
	offset: 2
	description: The intensity of the blue channel in the RGB0 LED.
	Green1:
	offset: 3
	description: The intensity of the green channel in the RGB1 LED.
	Red1:
	offset: 4
	description: The intensity of the red channel in the RGB1 LED.
	Blue1:
	offset: 5
	description: The intensity of the blue channel in the RGB1 LED.

On bootup, the device also sets an initial RGB color payload using GRB order, so the firmware registers also seem to be formatted as GRB:

device.behavior/Firmware/Behavior/app.c

Lines 207 to 212 in 704d2a9

	app_regs.REG_RGB_ALL[0] = 255; // Green
	app_regs.REG_RGB_ALL[1] = 0; // Red
	app_regs.REG_RGB_ALL[2] = 0; // Blue
	app_regs.REG_RGB_ALL[3] = 0; // Green
	app_regs.REG_RGB_ALL[4] = 0; // Red
	app_regs.REG_RGB_ALL[5] = 255; // Blue

However, when setting the colors through a harp write message, the write handler does a swap for the green and red channels (perhaps because it is expecting a RGB formatted message payload, might have been how it was organized previously):

device.behavior/Firmware/Behavior/app_funcs.c

Lines 1114 to 1123 in 704d2a9

	bool app_write_REG_RGB_ALL(void *a)
	{
	uint8_t *reg = ((uint8_t*)a);
	app_regs.REG_RGB_ALL[0] = reg[1];
	app_regs.REG_RGB_ALL[1] = reg[0];
	app_regs.REG_RGB_ALL[2] = reg[2];
	app_regs.REG_RGB_ALL[3] = reg[4];
	app_regs.REG_RGB_ALL[4] = reg[3];
	app_regs.REG_RGB_ALL[5] = reg[5];

Probable Solution

Undoing the swap for the write handlers for RGB0, RGB1 and RGBALL payloads should restore the correct order and remove the erroneous conversion.

Tested with

Behavior board 2.1 with firmware v3.3 and a Ywrobot WS2812 Neopixel Rainbow LED Module