Skip to content

W
White Rabbit Trigger Distribution
Commit ccf58c66 authored by Dimitris Lampridis's avatar Dimitris Lampridis
Browse files
Options

[doc] update documentation and examples

parent bc224077
Hide whitespace changes
Inline Side-by-side
Showing with 26 additions and 22 deletions
doc/devel.rst
View file @ ccf58c66
......@@ -304,5 +304,7 @@ matching, event forwarding, etc.) will be handled by WRTD.
.. doxygenfunction:: wrtd_route_in
.. hint:: Contrary to the rest of the functions presented in :numref:`fw_dev`,
:cpp:func:`wrtd_route_in` is not a user-defined function. It is provided by WRTD. Users
should simply call this function whenever an incoming :ref:`event` is detected.
:cpp:func:`wrtd_route_in` is not a user-defined function. It is already provided by the
WRTD firmware development framework. Users should simply create and fill in the
:cpp:class:`wrtd_event` ``ev`` structure with the details of the received :ref:`event` and
then pass it on to WRTD by calling this function.
doc/ref_spec_fmc_adc.rst
View file @ ccf58c66
......@@ -18,9 +18,9 @@ SPEC150T-based FMC-ADC
+----------------------------------------+------------+
| Maximum :ref:`Alarms <alarm>` | 1 |
+----------------------------------------+------------+
| Average input to Message latency | 10μs (TBC) |
| Average input to Message latency | 12μs |
+----------------------------------------+------------+
| Average Message to output latency | 10μs (TBC) |
| Average Message to output latency | 12μs |
+----------------------------------------+------------+
| Can receive Messages over WR | YES |
+----------------------------------------+------------+
......
doc/ref_svec_tdc_fd.rst
View file @ ccf58c66
......@@ -20,9 +20,9 @@ SVEC-based TDC+FD
+----------------------------------------+------------+------------+
| Maximum :ref:`Alarms <alarm>` | 0 | 1 |
+----------------------------------------+------------+------------+
| Average input to Message latency | 20μs (TBC) | N.A. |
| Average input to Message latency | 20μs | N.A. |
+----------------------------------------+------------+------------+
| Average Message to output latency | N.A. | 40μs (TBC) |
| Average Message to output latency | N.A. | 40μs |
+----------------------------------------+------------+------------+
| Can receive Messages over WR | NO | YES |
+----------------------------------------+------------+------------+
......@@ -56,9 +56,10 @@ fields of pulse distribution, trigger synchronisation, etc.
SVEC-based TDC+FD reference WRTD Node
The architecture of the :ref:`node` can be seen in :numref:`fig-ref_svec_list`. The user
communicates with the :ref:`node` using one of the methods mentioned in :numref:`usage`. Internally,
the :ref:`node` is running two :ref:`Applications <application>`, each on a dedicated CPU. One is
responsible for the FMC-TDC peripheral, while the other handles the FMC-FD.
communicates with the :ref:`node` via the WRTD library, using one of the methods mentioned in
:numref:`usage`. Internally, the :ref:`node` is running two :ref:`Applications <application>`, each
on a dedicated CPU. One is responsible for the FMC-TDC peripheral, while the other handles the
FMC-FD.
The five :ref:`Local Input Channels <local_channel>` are mapped to the five inputs of the
FMC-TDC. Thus, :ref:`event_id` ``LC-I1`` corresponds to the first FMC-TDC channel, ``LC-I2`` to the
......@@ -69,7 +70,8 @@ FMC-FD. :ref:`event_id` ``LC-O1`` corresponds to the first FMC-FD output, and so
``LC-O4``.
.. hint:: It is possible for the User Application in :numref:`fig-ref_svec_list` to access directly
the FMC-TDC and FMC-FD cores by means of their respective libraries (not shown in
:numref:`fig-ref_svec_list`), in order to fine-tune them and/or change their default
behaviour. However this should be done with extreme care, as it could lead to a race
condition between the User Application and the WRTD Applications running inside the FPGA.
the FMC-TDC and FMC-FD cores by means of their respective libraries (shown in
:numref:`fig-ref_svec_list` with dotted lines), in order to fine-tune them and/or change
their default behaviour. However this should be done with extreme care, as it could lead
to a race condition between the User Application and the WRTD Applications running inside
the FPGA.
doc/usage_clib.rst
View file @ ccf58c66
......@@ -55,7 +55,7 @@ Functions
char *err_msg;
int buf_size;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
if (status != WRTD_SUCCESS) {
/* use wrtd_error_message because wrtd_init failed
and the wrtd pointer is not valid. */
......@@ -190,7 +190,7 @@ parameter should be set to :c:macro:`WRTD_GLOBAL_REP_CAP_ID`.
wrtd_status status;
bool log_empty;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
status = wrtd_get_attr_bool(wrtd, WRTD_GLOBAL_REP_CAP_ID,
WRTD_ATTR_EVENT_LOG_EMPTY,
......@@ -234,7 +234,7 @@ Functions
wrtd_tstamp ts;
bool log_empty;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
/* check if the event log is empty (global attribute) */
status = wrtd_get_attr_bool(wrtd, WRTD_GLOBAL_REP_CAP_ID,
......@@ -295,7 +295,7 @@ The Event Logging API provides functions for accessing the :ref:`event_log`.
char *log_msg;
int buf_size;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
/* clear the event log */
status = wrtd_clean_event_log_entries(wrtd);
......@@ -331,7 +331,7 @@ The Event Logging API provides functions for accessing the :ref:`event_log`.
wrtd_dev *wrtd;
char log_msg[WRTD_LOG_ENTRY_SIZE];
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
/* retrieve the next event log message */
status = wrtd_get_next_event_log_entry(wrtd, WRTD_LOG_ENTRY_SIZE, log_msg);
......@@ -366,7 +366,7 @@ Configuration of an Alarm happens by setting the relevant :ref:`Attributes <attr
char rep_cap_id[16];
wrtd_dev *wrtd;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
/* disable and then remove any declared alarms */
status = wrtd_disable_all_alarms(wrtd);
......@@ -425,7 +425,7 @@ Configuration of a Rule happens by setting the relevant :ref:`Attributes <attrib
char rep_cap_id[16];
wrtd_dev *wrtd;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
/* disable and then remove any declared rules */
status = wrtd_disable_all_rules(wrtd);
......@@ -466,7 +466,7 @@ Configuration of a Rule happens by setting the relevant :ref:`Attributes <attrib
int main(void) {
wrtd_dev *wrtd;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
/* Add a rule */
status = wrtd_add_rule(wrtd, "rule1");
......@@ -514,7 +514,7 @@ relevant :ref:`Attributes <attribute>` via the :ref:`api_attr`.
char rep_cap_id[16];
wrtd_dev *wrtd;
status = wrtd_init("MT01", false, NULL, &wrtd);
status = wrtd_init(1, false, NULL, &wrtd);
/* Get number of defined applications */
status = wrtd_get_attr_int32(wrtd, WRTD_GLOBAL_REP_CAP_ID,
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment