chili-chips-ba / openeye-CamSI

A truly opensource camera serial interface. No frills. No backdoors that compromise security. Outstanding signal integrity. Hi-rez video pipeline with remote connectivity. For Sony, Series7 & open FPGA makers on limited budget. Augments openXC7 CI/CD, challenging its timing-savvy. Promotes the lesser-known EU boards.
https://nlnet.nl/project/TISG
BSD 3-Clause "New" or "Revised" License
25 stars 5 forks source link

I2C #3

Closed Juninho99 closed 2 months ago

Juninho99 commented 6 months ago

Overview: In our project, we are utilizing standard I2C communication to configure camera registers for various functionalities. Currently, only a partial implementation for writing values to registers one at a time (Option 5, page 19 IMX219 ) has been incorporated. However, the camera offers a broader range of I2C communication options, including single and sequential reads, as well as sequential writes. This issue aims to expand the existing I2C implementation to support all available communication modes and enhance the configurability of camera registers.

Background: I2C (Inter-Integrated Circuit) is a widely used serial communication protocol for interfacing with peripheral devices, such as cameras, sensors, and memory modules. It facilitates the exchange of data between a master device (e.g. FPGA) and one or more slave devices (e.g. camera) over a two-wire interface.

Current Implementation: At present, our implementation supports single writes to camera registers, enabling the configuration of individual register values. The FPGA reads the acknowledge bit from the camera, indicating successful register configuration.

Objective: The objective of this issue is to enhance the existing I2C communication module to support all available modes for configuring camera registers. By implementing comprehensive I2C functionality, we aim to maximize the configurability and performance of the camera within the project.

Next Steps:

chili-chips-ba commented 5 months ago

These port names in _i2cctrl.sv are the mirror image of what they should have been:

input  logic        scl_do,
output logic        scl_di,

input  logic        sda_do,
output logic        sda_di

They seem to be given from the perspective of IOBUF. Consider changing them so that _do is for module outputs, and _di for module inputs.