SDK - SDK Fundamentals

From edgertronic high speed video camera
Jump to: navigation, search




Home

SDK Deep dive







Software overview

The software in the edgertronic camera is 99% Open Source software (Linux,busybox, lighttpd, GStreamer, python, etc) with the specific high speed camera application written as a series of python modules. Once the camera has booted (described later),the lighttpd web server is started, and initializes the camera using the settings from the last saved video.When the user browses to the camera, the user can adjust the camera settings,to see a live preview. If you are familiar with HTML,JavaScript, and python, you should be able to modify the camera's behavior to meet your particular needs.

The Open Source software in the edgertronic camera is made available under the terms of the package's specific Open Source license.If you need to rebuild any of the non-python code,you will need to setup a cross-compilation environment.The DM368 Linux SDK used in the camera is from RidgeRun.You can use their professional services if you need any assistance.

Hardware overview

For this discussion, the hardware of interest is an FPGA, high speed CMOS sensor,large SDRAM for holding unencoded (RAW) video frames, and DM368 System-on-Chip (SoC) that supports hardware accelerated JPEG and H.264 encoding.

During operation, the FPGA controls the CMOS sensor, and continuously stores frames into a large SDRAM ring buffer.

Periodically, a frame from this buffer is sent to the DM368, JPEG encoded, and displayed as a live preview frame.

After a trigger occurs, the FPGA will continue storing a programable number of posttrigger frames into the buffer.Once this number is reached,the FPGA stops storing further frames and the buffer holds a combination of pre and posttrigger frames.The capture is now complete, and the FPGA is reconfigured to transfer the stored frames from the large SDRAM buffer to the DM368, where they will be encoded and saved to the user's SD card.

Storage devices

The edgertronic camera supports several storage devices

SD card Main device to hold user captured videos. Also can contain the default settings used by the camera when it powers on and a file whose name contains the current IP address.
micro SD card Partition into 3 file system.
  • First file system is VFAT containing the Linux kernel image file and the u-boot environment values. This file system is not mounted when Linux is running.
  • Second file system is ext3 containing the Linux root file system. It is mounted at '/' and is a read-only file system.
  • Third file system is a VFAT containing user settings (like network settings) and critical software error logs. The file system is mounted at /mnt/rw.
USB storage device
(user supplied)
If you rather store video to a USB storage device, the camera will auto-switch to use USB storage device if attached (and if there is no SD card installed). USB storage is an experimental feature and thus is not supported.
I2C EEPROM Small device containing the make, model, serial number, Ethernet MAC address, etc. You can read the decoded values held in I2C EEPROM using
  • caminfo.py package

The I2C EEPROM is locked during the manufacturing process and is read-only thereafter for the life of the camera.

SPI EEPROM FPGA algorithm. May be reprogrammed when you do a software update. Only digitally signed bits can be used.
RTC chip The real time clock chip contains a small amount of non-volatile memory with nearly infinite write cycle support. All camera history statistics are stored in the RTC memory.

Since the camera has two potential locations to store videos, namely the SD card and a USB storage device, either the camera has to decide where to store the video or the user has to explicitly configure the camera. The design choice was for the camera to favor USB storage if available and use SD card if a USB storage device is unusable.

Closed software

The high speed sensor control and its coupling to the main processor is not documented and the source is not available. The functionality is exposed by CAMAPI. The goal is to keep the external interfaces to CAMAPI stable, but changes may occur. Refer to the change log before updating your camera software if you have modified any software on the camera. Of course a camera update will overwrite your changes so practice good software engineering and use a revision control system outside the camera.

In addition, Texas Instruments libraries are used to access the hardware accelerators for H.264 and JPEG encoding. The source code for these libraries is not available.




Home

SDK Deep dive