Difference between revisions of "Control Daemon"

From apertus wiki
Jump to: navigation, search
Line 56: Line 56:


=== Setup WebUI ===
=== Setup WebUI ===
=== CLI ===
To set/get parameters from command line, '''DaemonCLI''' can be used:
'''Syntax''': DaemonCLI <module>  set_/get_<parameter> <value>
Prepend '''set_''' or '''get_''' to parameter, to tell daemon if parameter should be read or set.
$ DaemonCLI image_sensor set_gain 2
'''Available modules:'''
{|
|general||General methods, like getting available parameters through get_available_methods
|-
|image_sensor||CMV12000 (currently)
|}
==== Available parameters (per module)====
'''image_sensor'''
{|
|gain||Digital gain
|}





Revision as of 07:57, 7 October 2018

1 Overview

>>>>TODO Overview text.


Currently, booting up the camera is as follows:

  • A systemd service is activated which runs a shell script.
  • This script then loads a bitstream into the FPGA and uses other scripts and C programs to train LVDS channels and set up the HDMI output

When the service is disabled, the user can run this script manually, which:

  • Does not keep the user from running if it has already been activated by systemd.
  • And on the other hand, simple scripts which query the registers (e.g. to get the temperature of the sensor) can be activated even if the FPGA bitstream didn't load.

All of those lead to a solid lockup of the Beta, because if you write to one of those memory addresses which are used for communicating with the PL, and there is no handler in the FPGA, the ARM cores lock up solid, no recovery possible they basically wait for an ACK/NACK forever.

Research is taking place in the Labs here.


2 Structure

TODO: Add image which shows structure of module communication (WebGUI -> RESTServer > Daemon, and back)


The control daemon project currently consists of three different modules:

  • Web UI - HTML5, sends REST requests to the backend, currently by using JQuery (still evaluating alternatives).
  • RESTServer - receives REST requests, converts them to Flatbuffers packages and sends them to the daemon, through socket.
  • WSServer - receives WebSocket requests, converts them to Flatbuffers packages and sends them to the daemon, through socket.
  • Daemon - processes received packages and calls suitable handler.


TODO: Add JSON/REST package description from Lab (https://lab.apertus.org/T865)

3 Build

Required packages (names are varying between Linux distributions):

  • cmake
  • libsystemd-dev
  • libssl-dev


Steps:

  • Install required packages
  • Clone beta-software repo
  • cd into cloned repo
  • cd software/control_daemon
  • mkdir build
  • cd build
  • cmake ..
  • make -j4

4 Setup daemon

5 Setup WebUI

6 CLI

To set/get parameters from command line, DaemonCLI can be used:

Syntax: DaemonCLI <module> set_/get_<parameter> <value>

Prepend set_ or get_ to parameter, to tell daemon if parameter should be read or set.

$ DaemonCLI image_sensor set_gain 2


Available modules:

general General methods, like getting available parameters through get_available_methods
image_sensor CMV12000 (currently)

6.1 Available parameters (per module)

image_sensor

gain Digital gain


7 Unit tests

Unit tests have been added to the project to verify correct functionality. Catch2 framework is used because it's single-header only and utilizes the C++11 way of doing things.

Note: (for development on PC) - RAM access of the camera is different from x86/x64 CPUs, modified classes have to be used to bypass this, otherwise SEGFAULT would be the result.

In the CMake scripts a switch called ENABLE_MOCK was added so that users can disable any code which won't work on a regular PC (see CMV12000AdapterTests.cpp for an example). While running the build on camera cmake .. is sufficient, but for development one should use:

$ cmake -DENABLE_MOCK=ON ..