| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| code:code [2024/02/17 16:23] – [Firmware Versioning evolution] Igor Yefmov | code:code [2024/04/02 08:41] – Igor Yefmov |
|---|
| Controlling the camera is done via writing "registers" - think of them as address locations. There are generally 4 ways to interface with the camera from a host: | ====== Preface ====== |
| - standard UVC - this one is automagically supported by any UVC 1.1 compliant OS, which in the year 2017 would be "any modern OS". This interface covers the universally standardized controls for [[https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-driver-implementation-checklist|USB Video Class]] | |
| - (Gen 3 and Gen 4) direct I²C access via Cypress's FX3 interface, using control port ''0x20''. This allows access to all sensor's registers (at your own risk!). For more information search the web for documentation on the sensor in your camera (as of October 2017 that would be [[http://lmgtfy.com/?q=OmniVision+10823+sensor+documentation|OmniVision 10823 sensor]]) | |
| - FX3 Host Vendor Command Interface - this interfaces with the Cypress's FX3 and is the [[fx3_api|primary FX3 API]] | |
| - FPGA I²C Access - a "window" into a host of additional commands that are performed on FPGA, this is highly dependent on the FPGA model used and camera's generation and is not exactly intended for direct use outside of developing FX3 APIs and during development cycle of GUI implementation. The FPGA register maps are defined [[fpga_registers_map|on this page]] | |
| |
| The last two ([[code:fx3_hvci_and_fpga_i_c_commands#fx3_host_vendor_command_reference|FX3 HVCI]] and [[code:fx3_hvci_and_fpga_i_c_commands#fpga_i_c_bridge|FPGA I²C]]) are described in [[code:FX3 HVCI and FPGA I²C commands]]. | Controlling the camera is done via writing "registers" - think of them as address locations. There are generally 4 ways to interface with the camera from a host: |
| | - [[https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-driver-implementation-checklist|standard UVC]] - this one is automagically supported by any UVC 1.1 compliant OS, which in the year 2017 would be "any modern OS". This interface covers the universally standardized controls for USB Video Class |
| | - [[fx3_api|FX3 Host Vendor Command Interface]] - this interfaces with the Cypress's FX3 and is the primary [[fx3_api|FX3 API]] |
| | - [[fpga_registers_map|FPGA I²C Access]] - a "window" into a host of additional commands that are performed on FPGA, this is highly dependent on the FPGA model used and camera's generation and is not exactly intended for direct use outside of developing FX3 APIs and during development cycle of GUI implementation. The FPGA register maps are defined [[fpga_registers_map|on this page]] |
| | - (Gen 3 and Gen 4) direct I²C access via Cypress's FX3 interface, using control port ''0x20''. This allows access to all sensor's registers (at your own risk!). For more information search the web for documentation on the sensor in your camera (as of October 2017 that would be [[http://lmgtfy.com/?q=OmniVision+10823+sensor+documentation|OmniVision 10823 sensor]]). Gen5 is using a sensor via an SLVS-EC interface which doesn't provide direct I²C access so one should use [[fx3_api|FX3 API]] (or, better yet - rely on [[code:SUB2r-lib]] for all your camera control needs) |
| |
| If you are set on writing your own UI and don't want to be bothered too much with figuring out how to communicate with the camera you have an option of using the [[code:SUB2r-lib]] library (which should be your preference anyways). | If you are set on writing your own UI and don't want to be bothered too much with figuring out how to communicate with the camera you have an option of using the [[code:SUB2r-lib]] library (which should be your preference anyways). |
| |
| ---- | ---- |
| ====== Firmware Versioning evolution ====== | Previous iterations had different bit layout for the Version Info, see details here: [[Firmware Versioning Evolution]] |
| | ---- |
| ====== FX3 Version Info ====== | |
| The version id is also encoded into the firmware image file name as: | |
| <code><VendorID>_<HardwareID>_<ProductID>_<ReleaseType>_<BuildNumber></code> | |
| | |
| ===== FX3 version info C/C++-struct ===== | |
| The FX3 version structure is as follows (little-endian memory layout): | |
| | |
| <code cpp firmware-version.h> | |
| struct FwVersion{ | |
| unsigned vendorId : 3; | |
| unsigned hwCfgId : 5; | |
| unsigned productId : 8; | |
| #ifdef OLD_VER_FMT | |
| unsigned releaseType : 5; | |
| unsigned buildNo : 11; | |
| #else | |
| unsigned releaseType : 3; | |
| unsigned buildNo : 13; | |
| #endif | |
| }; | |
| static_assert(sizeof(FwVersion) == 4); | |
| </code> | |
| | |
| Prior to FPGA v. 89 there was no standard-compliant way of representing the version info in a C struct though (which is exactly what prompted the rework in the first place). | |
| ==== Bit layout ==== | |
| The bits are laid out in 4 sequential bytes as follows (depending on the version): | |
| ^ version ^ 3 ^^^^^^^^ 2 ^^^^^^^^ 1 ^^^^^^^^ 0 ^^^^^^^^ | |
| ^ ::: ^ 7 ^ 6 ^ 5 ^ 4 ^ 3 ^ 2 ^ 1 ^ 0 ^ 7 ^ 6 ^ 5 ^ 4 ^ 3 ^ 2 ^ 1 ^ 0 ^ 7 ^ 6 ^ 5 ^ 4 ^ 3 ^ 2 ^ 1 ^ 0 ^ 7 ^ 6 ^ 5 ^ 4 ^ 3 ^ 2 ^ 1 ^ 0 ^ | |
| | fx3<102\\ fpga<77 | buildNo[7:0] |||||||| releaseType ||||| buildNo[10:8] ||| productId |||||||| vendorId ||| hwCfgId ||||| | |
| | fx3<103 | buildNo[10:3] |||||||| buildNo[2:0] ||| releaseType ||||| productId |||||||| hwCfgId ||||| vendorId ||| | |
| | fx3>=103\\ fpga>=77 | buildNo[12:5] |||||||| buildNo[4:0] ||||| releaseType ||| productId |||||||| hwCfgId ||||| vendorId ||| | |
| | |
| Because of the change in bit layout different byte sequences shown below are needed to produce the same result (exact same component values for the sake of simplicity and only as an illustration): | |
| ^ version ^ byte sequence (API return buffer) | <code cpp> | |
| .vendorId = 1 | |
| .hwCfgId = 1 | |
| .productId = 5 | |
| .releaseType = 3 | |
| .buildNo = 0x67</code> | | |
| | fx3>=102\\ fpga<77 |''0x21 0x05 0x18 0x67''|:::| | |
| | fx3<103 |''0x09 0x05 0xE3 0x0C''|:::| | |
| | fx3>=103\\ fpga>=77 |''0x09 0x05 0x3B 0x03''|:::| | |
| ===== Vendor ID ===== | ===== Vendor ID ===== |
| ^Code ^Value ^ | ^Code ^Value ^ |
| |#|Increments on each build| | |#|Increments on each build| |
| |
| | ====== FPGA config status - SPI codes ====== |
| | These are the status bits that indicate the FPGA programming (reconfiguring) process: |
| | ^ Bit name ^ Description ^ |
| | |''15'' Program %%SwitchWord%% OK| | |
| | |''14'' Verify OK| Verification succeeded | |
| | |''13'' Program OK| Programming completed successfully | |
| | |''12'' Erase OK| SPI erase was successful | |
| | |''11'' Erase %%SwitchWord%% OK| | |
| | |''10'' Check ID OK| | |
| | |''9'' Initialize OK| | |
| | |''8'' Config started| Config operation has started | |
| | |''7'' CRC error| | |
| | |''6'' Timeout error| | |
| | |''5'' Program error| Error while programming the SPI | |
| | |''4'' Erase error| Encountered an error while erasing SPI | |
| | |''3'' %%IdCode%% error| | |
| | |''2'' Config error| Configuration operation errored out | |
| | |''1'' Config done| Configuration operation is complete | |
| | |''0'' Config not busy|Set to ''1'' while the config is not busy| |
| |
