This post this Part 4 in the Multi part Series of the , Part1 we Compared sensor, Part2 was Hardware and Mechanical Design, Part3 about Sensor Solution. This part 4 going in details about SW Design, FPGA/PL Pipeline. This Part primarily focus how software is implemented where boundary between Software are defined. Why we decide to make make whole system around Linux.
![]() |
| CHC5 X-Ray Soldering Test Verification |
Software Architecture
System is Running around Linux on Zynq 7000 SoC PS, We Linux make life easier, because it already bring standard frame work for system design, Specifically Driver and Media Pipelines. If any other mythology over Linux , They would have to resort to either RTOS or Absolute bare metal. These Absolute custom solution bright lot of flexibility and performance over Linux. Specially in boot time. But this Flexibility is available in tradeoff he Reliability and time spent in development especially defining driver framework, application management, Memory Management and Network Stack. in sort Linux already have most the work already laid out we just need to program our custom drivers application and optimization to it.
There are few Major Components of the Software that is running on the ARM CPU
1. platformd, a daemon that manages whole system platform. It Manages Sensor Driver loading, Network configuration, Loading of Bitstream onto PL, Firmware Programming to FX3 EEPROM, System Upload. Board hardware Config, XML Provisioning for both GigE vision and U3V System. LED Status and Error Logging and reporting. Sensor, USB, Bitstream Archive Management, Validation of Manifest and other house keeping stuff with help of System Config Script. even thoug platformd knows which sensor is active what system config is but still platformd is fully sensor agnostic. any change of sensor does not change anything in platformd code and at run time platformd can adapt to different sensors. platformd take care of the firmware stores for all 3 type of binary/Firmwares for USB, Bitstream and Sensor archives are managed by platformd, when new components need be added or deleted activated for individual user request its managed by platformd.
2. camcgfd, a daemon that manages Camera configuration, It monitors camera sensor directly with camera sensor standard V4L2 Driver. camcfgd directly handles Image specific request form gvcp server, with gvcp server communication is IPC and camcgfd also talked to USB FX3 Device over I2C communication. I2C driver provide framed config messages to camcfgd. camcfgd configures camera sensor as per request/limits and bound of platform and camcgfd. watching sensor limits and Interface speed limits. camcfgd also have complete understanding of media pipeline, all PL ISP blocks are standard V4l2 Components, camcgfd configures V4L2 pipeline as per requests. Camcgfd also take care of standardized exposure and gain control making this camera universal and sensor agnostic. camcfgd is fully sensor agnostic. any change of sensor does not change anything in camcfgd code and at run time camcfgd can adapt to different sensors. camcgfd is running primary Auto exposure look it received image statistics from FPGA and Calculates estimated Image Brightness and color balance. And needed change apply to Camera and AWB PL blocks.
3. gvcp, a daemon that runs to service as gvcp server and manages all GigE Vision requirements. gvcp hosts a standard gvcp server make camera available to standard GigE Vision standard. gvcp also manages ethernet data and Zynq ETH GEM DMA directly. There was lot of challenge work to get full Gigabit of Data bandwidth out of Zynq7000 DMA. gvcp talkes to camcgfd for camera sensor configuration and streaming control. gvcp is fully sensor agnostic. any change of sensor does not change anything in gvcp code and at run time gvcp can adapt to different sensors.
4.webd, its a webserver deamon, it serves a full-fledged web user interface, webd serves first level of hmi, All controls that camera has to offer can be programmed over GigE vision and USB 3 Vision Interface as well but web offer great view of system state and control for human users. It offers dashboard to view all system software components , Direct ISP component control. Direct HDMI Control, Control of AUX IO pins. Firmware Library Management , Reprogramming of USB firmware, Swapping camera sensor driver and Bitstream selection for Custom and standard pipeline. System Update interface for Complete System firmware including kernel and other Linux system Library and components. Device Control to backup user data , factory restore setting and reboot setting. Ethernet Config and Device time setting for Verification of System date and time.
![]() |
| CHC5 System Arch Design |
Webd UI
webd make dashboard showing camera individual camera versions and absolute version control with sha. dashboard shows flash wear level and also camera identification control just incase you need to identify specific in environment where multiple camera are available and you need to point to specifc camera. Flipping this will blink/strobe led on camera and show you which exact camera it webd is being offered from.
![]() |
| Dashboard Showing a Development Device dashboard |
ISP even though directly controlled by GigE Vision and USB3 Vision Interface There a manual Control and Status Display is exposed to help user developed there applications , You can Control Auto exposure and Auto Gain and There Parameter such as Auto Exposure Target, Speed Auto Exposure Metering mode , For example Center-Weighted. and Priority for the AE Algo to use gain or exposure (like slow down camera to get better light or let image noisy be to get faster frame rate ), There are different methods to perform highlight protection, Also option to Run AE once. Web UI also allow control override for force AWB enable and AWB Specifc Lighting target such as daylight, Tungsten, Live AWB gain are displayed to monitor what AWB algo is calculating the background and what results are.
![]() |
| ISP Control Showing AE and AWB Control |
HDMI Control Page allow setting of HDMI Enable Disable . Or Allow HDMI to Run in Standalone mode. Camera has feature will allow it to run as standard Camera in this mode it automatically starts streaming from sensor and output to HDMI without need of USB or ethernet host. HDMI is not a primary interface so USB and Ethernet Always over ride Stream control even in standalone mode. HDMI Frame rate control that only apply to HDMI Image frame rate not HDMI Interface frame rate. HDMI Interface Frame rate/Wire clock/Blanking is absolute standard. While To save bandwidth on DDR UI allows setting of image frame rate for HDMI. So if user selects 30FPS . Regardless of sensor read FPS only 30FPS worth of image data gets written to HDMI Frame buffers and Transmitted over HDMI output at fix Standard rate if Camera/User Config Slow FPS , HDMI still standard FPS repeating same frame multiple time. HDMI is Fix max resolution to 1080p so crop and crop positioning is available.
![]() |
| HDMI Control window Showing HDMI Off |
Camera Features Two AUX I/O pins which allows Camera to Camera sync. Flash and Strobe and Sync Input and output these all can be configured over web interface will full flexibility. Both Signal are Optically isolated. Status display is available to show state of actual HW pins.
![]() |
| Aux I/O control Page |
Sensor Library page is really Special, Even though is embedded camera system it sill allow Sensor Interchanablity. This worlds first camera that allow Interchangeable sensor. System is linux based user can upload sensor archive package with sensor driver alog with some settings in manifest file alog with ccm tuning file and sensor specific gamma correction table. Seprate blog post provide detailed description about how to make these driver /sensor archive. User with just click of button activate/iinstall sensor. Install/activation process is shown on progress bar and restart is required to get the new sensor working.
Bitstream library is similar to senor library page. it allow user to store multiple bitstream on the camera itself and activate and use bitstream what is needed. Archive/package contains standard bitstream bin along with manifest file info about bitstream. to be displayed on web these manifest info is compared against sensor driver during activation basic validation such max resolution of sensor is compared if bitstream can achieve this resolution or not. few validation are performed and user is served with warning or error depending on error type.
USB Firmware library is similar to other library, store of multiple USB firmware. similar to bitstream standard FX3 firmware packed along with manifest. USB firmware comes in two flavors U3V and UVC. U3V for Standard USB 3 vision application and as WebCam UVC standard on Windows, Linux, Mac and even On Android. Camera with work as is in USB UVC mode. USB firmware is little more special than bitstream and sensor drive. because this firmware need to be programmed onto FX3's EEPROM. Because FX3 configured to load firmware from EEPROM directly. FX3 works pretty much independently only interface is GPIF for image data and I2C for Sensor/U3V/UVC stream/config request.
System update page allow User to Flash new firmware to system. this primarily update system base like Linux , rootfs and core library. Sensor driver, PL Bitstream and FX3 Firmware is have dedicated path of update and upgrade while Linux kernel/Driver are part of base system so can be upgraded using this System firmware update. System is well designed wit Dual Dedicated kernel Rootfs and stuff so issues during and after update are secure and any issue during upgrade will auto roll back to the old previous version so that user still have option to flash new firmware.
System Storage Map
System for reliability , System update, Guaranteed graceful degradation and fallback we have Dual Boot Config, Dual Kernel, dual rootfs so that camera is Guaranteed be in working order even if bad firmware is flashed or storage is broken, system is always in a working order so that user can fix by just always flashing a nice firmware over the web.



.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)

Comments
Post a Comment