FX3 API specification has been moved to this location

The following tables provide information on how to access the camera's functionality for an FPGA I²C bridge.

Here's a sample code (skipping all error checking) that sets the LED to bright-yellow color :

S2R::FX3 dev; // auto-open device #0
using S2R::FX3;
dev.vrCmd(FX3Cmd::i2c_bridge, VrCmdOpType::write, 255, 0x08); // red
dev.vrCmd(FX3Cmd::i2c_bridge, VrCmdOpType::write, 255, 0x0A); // green
dev.vrCmd(FX3Cmd::i2c_bridge, VrCmdOpType::write, 0, 0x0C);   // blue

The address space is broken down into smaller chunks, grouped by common functionality:

Info for performing Auto White-Balance adjustments on the image

Name	Offset	Bytes	Access	Notes
AWB Red adjustment	0x08	2	R/W	a signed 16-bit value of an adjustment to apply to every pixel in Red channel. Default is \(0\)
AWB Green adjustment	0x09	2	R/W	a signed 16-bit value of an adjustment to apply to every pixel in Green channel. Default is \(0\)
AWB Blue adjustment	0x0A	2	R/W	a signed 16-bit value of an adjustment to apply to every pixel in Blue channel. Default is \(0\)
Reserved	0x0B
AWB Red total	0x0C	4	R/O
AWB Green total	0x0D	4	R/O
AWB Blue total	0x0E	4	R/O
AWB count total	0x0F	4	R/O	A count of pixels that were used to calculate the \(R/G/B\) totals

See Color correction matrix article in this Wiki's ISP section for more details. The 16-bit (MSB-LSB) value is defined as 7+9 bits, where MSB[7:1] are the integer part and MSB[0]LSB[7:0] is the fractional part (effectively that value is 512 times larger than the original fractional part)

Name	Offset	Bytes	Access	Notes
CCM_00	0x25	2	R/W	\(CCM_{00}\)
CCM_01	0x26	2	R/W	\(CCM_{01}\)
CCM_02	0x27	2	R/W	\(CCM_{02}\)
CCM_10	0x28	2	R/W	\(CCM_{10}\)
CCM_11	0x29	2	R/W	\(CCM_{11}\)
CCM_12	0x2A	2	R/W	\(CCM_{12}\)
CCM_20	0x2B	2	R/W	\(CCM_{20}\)
CCM_21	0x2C	2	R/W	\(CCM_{21}\)
CCM_22	0x2D	2	R/W	\(CCM_{22}\)

A combination of data in 0x0033[1:0] (pixel bit depth) and 0x32[7:4] (video format) used for UVC is mapped into standard FOURCC codes as summarized in the following table:

0x0033[1:0]\0x0032[7:4]	0 (RAW)	1 (RGB)	2 (packed YUV 4:4:41))	3 (packed YUV 4:2:22))	7 (planar YUV 4:2:03))
0 (8 bit)	BA81/BYR1/GREY/Y8/Y800 (8bpp)	BI_RGB/RGB (24bpp)	Y444/IYU2 (24bpp)	YUY2/YUYV (16 bpp)	NV12 (12bpp)
1 (10 bit)	Y104) (16bpp5))	BI_BITFIELDS (48bpp)	Y410 (32bpp6))	Y210 (32bpp) YUVP?/Y42T (24bpp?)	P010 (32bpp)
2 (12 bit)	BYR2 (16pbb7))	BI_BITFIELDS (48bpp)	Y4128) (40bpp9))	Y21210) (32bpp11))	P01212) (32bpp13))
3 (14 bit)	Y1614) (16bpp15))	BI_BITFIELDS (48bpp)	Y41416) (48bpp17))	Y21418) (32bpp19))	P01420) (32bpp21))

Below is the table that lists codes for supported SDI FPS settings set in 0x0032[3:0]:

“Green screen”, a.k.a. “Chroma Key” on-board optimization is designed to replace a range of colors with a single solid one

If enabled these setting take precedence over other 3 bands

Name	Offset	Bytes	Access	Notes
CK control	0x80	1	R/W	7:1 reserved 0 enable/disable Chroma Key control
CK saturation min	0x81	1	R/W	[0..255] to specify the minimum saturation threshold
CK saturation max	0x82	1	R/W	[0..255] to specify the maximum saturation threshold
CK luma min	0x83	1	R/W	[0..255] to specify the minimum brightness threshold
CK luma max	0x84	1	R/W	[0..255] to specify the maximum brightness threshold
CK hue	0x85	2	R/W	14 bits of a signed hue value, its [-8K..+8K] range is mapped into [-180°..+180°]
CK tolerance	0x86	2	R/W	13 bits of an unsigned hue tolerance value, valid range is [0..8K], which is mapped into [0°..180°]. That value specifies how far to stretch the CK hue value both ways (symmetrically). If the CK tolerance is above 90° the covered color space is over 50% of values
CK red	0x87	2	R/W
CK green	0x88	2	R/W
CK blue	0x89	2	R/W
Reserved	0x8A-0x8F

Color substitution (if enabled) takes place after the first band had a chance to process the pixels

The layout of the settings is identical to that of band #0 just shifted down by a paragraph and occupying address block 0x0090-0x009F

Color substitution (if enabled) takes place after the first and second bands had a chance to process the pixels

The layout of the settings is identical to that of band #0 just shifted down by 2 paragraphs and occupying address block 0x00A0-0x00AF

Color substitution (if enabled) takes place after other bands had a chance to process the pixels

The layout of the settings is identical to that of band #0 just shifted down by 3 paragraphs and occupying address block 0xB0-0xBF

Name	Offset	Bytes	Access	Notes
mFT control register	0xC0	1	R/W	7:2 returned data count 1: (R/O) command completion flag 0: (W/O) setting this to 1 sends the command to mFT
mFT command setup	0xC1	1	W/O	See below for the 32-bit command structure
mFT returned data	0xC2	1	R/O	Once the command completion flag is set in control register returned data can be retrieved through this register

FPGA “register” 0xC1 serves as a service point to access mFT protocol and allows FX3 to communicate with the mFT by forwarding requests and replies between the two.

Micro Four Thirds System (mFT) defines a communication protocol in which the “body” (host) issues 4 bytes of data (command type, command code, and two 1-byte parameters) and gets a response of variable number of bytes, depending on the command (including a 0-length data response). See the mFT spec for each individual command's request/response.

FPGA acts as a two-way command repeater and in such capacity it expects a 4 byte command supplied to it as part of an I²C “write” operation and responds with the appropriate return data buffer to a subsequent “read” I²C operation on the same address.

The 4 bytes of the command are laid out as follows:

struct MftCmd{
  uint8_t cmd_type;
  uint8_t cmd_code;
  uint8_t param1, param2;
};

or in a more visual format (taking into consideration the little-endian memory layout typical of the architectures we use):

which is the equivalent of this code:

MftCmd cmd{1, 2, 3, 4};
static_assert(std::bit_cast<uint32_t>(cmd) == 0x04030201);