FPGA I²C bridge (registers' map)

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

Intel-based FPGA utilizes an Avalon interface bus to facilitate access to FPGA's “registers”. We have reserved addresses beginning with \(0x5000'0000\) for the FX3↔FPGA communication.

Note that one of the limitations of Avalon is that addressing is done on a 4-byte boundary.

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:

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)

CMX
Address	Name	Bytes	Access	Notes
0x5000'0500	CCM_00	2	R/W	\(CCM_{00}\)
0x5000'0504	CCM_01	2	R/W	\(CCM_{01}\)
0x5000'0508	CCM_02	2	R/W	\(CCM_{02}\)
0x5000'050C	CCM_10	2	R/W	\(CCM_{10}\)
0x5000'0510	CCM_11	2	R/W	\(CCM_{11}\)
0x5000'0514	CCM_12	2	R/W	\(CCM_{12}\)
0x5000'0518	CCM_20	2	R/W	\(CCM_{20}\)
0x5000'051C	CCM_21	2	R/W	\(CCM_{21}\)
0x5000'0520	CCM_22	2	R/W	\(CCM_{22}\)

Move all that out into its very own big block of address space

Name	Address	Access	Bit mapping	Notes
switch	0x2E	W	15:10 reserved	Controls what information is being read/written by accessing the register 0x002F
			9:7 table switch	000 - Hue vs. Hue (14 bits) 001 - Hue vs. Saturation (12 bits) 010 - Lightness vs. Saturation (12 bits) 011 - Saturation vs. Saturation (12 bits) 100 - Lightness vs. Lightness (12 bits) 101 - Hue vs. Lightness (12 bits) 110-111 - reserved
			6:1 index LSB	index into a page in the table
			0 access mode	0: “normal mode”, in which all the subsequent accesses to the register 0x002F are governed by the values in 0x002E 1: “bulk access”, where after a read or write access to register 0x002F the “Index” value will auto-increment by one so that the next read/wrie will access the subsequent table slot
Value	0x2F	R/W	15:0 value	16 bits of either signed or unsigned integer value - for a “Hue vs. Hue” table the 14 bits signed value is in range [-8192..+8192] which maps linearly into a Hue angle range -180°..+180° - for a “Hue vs. Saturation” table (as well as for similar tables LvS and SvS) the 12 bit unsigned value in range [0..+1280] maps linearly into a Saturation range [0%..1000%] where 100% is the neutral position and 0% produces a greyscale image - for a “Lightness vs. Lightness” table (as well as for similar table HvL) the 13 bit signed value in range [-4096..+4095] maps linearly into a Lightness *relative* (adjustment) range [-256..255] where 0 is no adjustment to pixel luminosity value

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

Move out into its own large address block

If enabled these setting take precedence over other 3 bands

Name	Address	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

struct MftCmd final{
    uint8_t param2, param1;
    uint8_t cmd_code;
    uint8_t cmd_type;
};
static_assert(std::bit_cast<uint32_t>(MftCmd{1, 2, 3, 4}) == 0x04030201);

struct MftCtrl final{
    bool start          : 1; // start command (type, code, param1, param2)
    bool pop_input_fifo : 1; // increments the read pointer on input FIFO
    uint8_t res0        : 5;
    bool reset          : 1; // reset MFT block (must clear after set) 
    uint8_t res1, res2, res3;
};

struct MftStatus final{
    bool ready         : 1; // MFT lens ready (attached) 
    bool cmd_done      : 1; // command done (finished) 
    bool in_fifo_empty : 1; // Input FIFO empty
    bool in_fifo_full  : 1; // Input FIFO full
    bool crc_error     : 1; // CRC error occurred 
    bool to_error      : 1; // MFT Bus timeout error occurred
    uint8_t res0       : 2;
    uint8_t res1;
    uint8_t in_fifo_data_count; // Input FIFO data count
    uint8_t res2;
};

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 mb427 MFT block implements MFT protocol providing communication between the camera body and lens (lens accessories are not yet supported). The current hardware supports type A0,B0 and C0 commands.

The hardware automatically senses the lens and will immediately attach to the lens. Firmware can tell if a lens is attached by checking the mft_status bit 0 (ready). If set (1), a lens has successfully attached to the body and is ready to accept a command.

When a lens is removed, hardware automatically initiates the detach MFT sequence. When detached, mft_status bit 0 (ready) will be clear (0).

1. Check ready status. If ready goto 2
2. Load mft_command register
3. Set start bit in mft_command register
4. Check status bit 1 (command_done). If set goto 5
5. If read command, check input_fifo_data_count in mft_status register (bits 23:16)
6. For each byte in fifo:
   1. Read mft_rx_data_port and save the data
   2. Write mft_control bit 1 (pop_input_fifo). This increments the FIFO address pointer and decrements the input_fifo_data_count
   3. Clear mft_control bit 1 (pop_input_fifo)
7. For read commands, the last byte of data is a checksum. To verify the checksum, simply add all (N-1) bytes and compare the sum to last byte (N) returned
   1. Remember to use unsigned arithmetic
8. Finally, clear start bit and pop_input_fifo bits in the control register