Epics@GSI Webhome

Multi-purpose control API implementation on HadCon2

Table of Content

(short)

Introduction

HadCon2 is a credit-card sized general purpose I/O module for detector and experiment controls as well as for small data acquisition systems.

hadcon2

It is the successor of the discontinued first version HadCon ( HADControl/HadShoPoMo general purpose board, HadCon @ Epics Wiki).

The module has an ATMEL AT90CAN128 microcontroller providing a multitude of connectivity:
I2C (8/4 fold (intern/extern) multiplexer), 6 channel 1-wire master, 8-channel 8bit DAC, galvanically isolated CAN - high-speed transceiver, 8-channel 10-bit SAR ADC, byte-oriented SPI, in total up-to 53 programmable I/O lines and optionally a Lattice MachX02 FPGA for fast data processing tasks.

While the discontinued precursor HadCon had an SoC on-board, its successor HadCon2 has broken up this concept in favour of a more open access:
It doesn't have any CPU on board, but a USB connector to directly allow communication with any type and size of computer (e.g. PC, raspberry PI, dreamplug, ...) having an USB port on one side and at the other end the microcontroller and the FGPA. This communication is based on an ASCII-based protocol in view of easy implementation in detector control systems like e.g. EPICS and LabVIEW.

  • Summarizing:
    • Microcontroller: ATMEL AT90CAN128
      • I2C
      • CANbus
      • SPI
      • ADCs
      • ...
    • FPGA: Lattice MachX02-1200-HC
    • FTDI USB to serial UART interface
      • USB 2.0 connector
      • Power over USB
    • I2C devices
      • 6 × Single-Channel 1-Wire Master
      • 1 × 8-channel I2C-bus multiplexer with reset
      • 2 × 4-channel 8-Bit DAC - Digital-to-Analog Converter
    • galvanically isolated CAN - High-speed CAN Transceiver
      • optional external power supply
    • 2 × Rotary Code Switches, hexadecimal coding
    • Reset Button for ATMEL
    • 11 × LED's, free programmable

-- PeterZumbruch - 2014-02-07

Objective

This project's objective is to adopt the project specification made for the API for multi-purpose control implementation on HadCon to the new but very similar hardware of HadCon2. This includes the access to the different devices via an ASCII based protocol. This provides:

  • ATMEL's internal
    • ADC, SPI, CANbus, I2C, Registers
  • Communication with MachX02
  • I2C
    • 1-Wire bus implementation via I2C
      to access 1-wire sensors and actuators:
      • ADCs
      • Temperature sensors
      • Switches
    • DACs
  • Relay applications
  • ...

Setup

Hardware

  • HadCon2
    • Power supply, via USB
  • Devices to connect to
    • CAN
    • I2C
      • 1-Wire via I2C
      • DAC via I2C
    • Registers
    • ...
  • ! Only needed for programming

    Documentation

      HadCon2 - Documentation



Software

    Code Repositories

    git
      git.gsi.de
        The code is available on the gitlab repository of GSI
        • repository: https://git.gsi.de/HadCon2/Firmware/HadCon2
          • !HadCon2 : Microcontroller Code
            • Branches: (q.v. Git Workflow)
              • 4.x.y: version
              • master: (link to subversion)
              • dev: branch to consolidate before committing/merging into master
        • Access
          • read: https
          • further access on request, ask P.Zumbruch
            • needs login access to git.gsi.de to become a member


Tar Balls & ELFs
    Tar ball, including ELFs
        x.0 x.1 x.2 x.3 x.4 x.5 x.6
      1.x 1.0
      2.x 2.0 2.1
      3.x 3.0 3.1
      4.x 4.0 4.1 4.2 4.3 4.4 4.5  
            4.3.1 4.4.1 4.5.1 4.6.1
            4.3.2 4.4.2   4.6.2
                  4.6.2.1
            4.3.2    
            4.3.3    
                  4.6.3-Apfel
                  4.6.3_MM

    HadCon2 - ELF 32-bit LSB executable, Atmel AVR 8-bit, version 1 (SYSV), statically linked, not stripped
        x.0 x.1 x.2 x.3 x.4 x.5 x.6
      1.x    
      2.x    
      3.x    
      4.x       4.3.2 - hadcon1      
            4.3.2 - hadcon2      
            4.3.3 - hadcon1      
            4.3.3 - hadcon2      
              4.4.1 - hadcon1    
              4.4.1 - hadcon2    
                  4.6.2
                  4.6.2.1
                 
                 
                  4.6.3-Apfel
                  4.6.3_MM

      • Programming:
        • using avrdude you can program: (asuming HadCon2 jtag chain)
          $> avrdude -v -P /dev/ttyUSBx -pc128 -c jtagmkI -x jtagchain=0,1,0,8 -Uflash:w:<hadcon>.elf
          • Don't forget setting fuses, to be done when HadCon2 is programmed the first time:
            $> avrdude -v -P /dev/ttyUSBx -pc128 -c jtagmkI -x jtagchain=0,1,0,8 -Uefuse:w:0xff:m -Uhfuse:w:0x19:m -Ulfuse:w:0xe0:m
        HadCon Note
        In case of HadCon(1) use jtagchain=0,1,0,4 instead
        • using obsolete avarice you can program: (asuming HadCon2 jtag chain)
          avarice -c 0,1,0,8 --jtag /dev/ttyUSBx -B 1000000 --erase --program --file <hadcon>.elf
          • Don't forget setting fuses, to be done when HadCon2 is programmed the first time:
            avarice -c 0,1,0,8 --jtag /dev/ttyUSBx -B 1000000 -W ff19e0
        HadCon Note
        In case of HadCon(1) use jtagchain=0,1,0,4 instead


-- PeterZumbruch - 2020-12-11


ATMEL

Supported devices
    1-wire
    Family code Device and datasheet
    10h pdf DS18S20 1-Wire Parasite-Power Digital Thermometer
    28h pdf DS18B20 1-Wire Programmable Resolution 1-Wire Digital Thermometer
    20h pdf DS2450 1-Wire Quad A/D Converter
    3Ah pdf DS2413 1-Wire Dual Channel Addressable Switch
    05h pdf DS2405 1-Wire Addressable Switch
    29h pdf DS2408 1-Wire 8-Channel Addressable Switch

Tweaks

-- PeterZumbruch - 2020-08-04

-- PeterZumbruch - 2020-12-10


Operation

Basic Operation Principles

The basic operation principle is that
  • Any device communicates via the USB interface with the μController sending and receiving keyword based ASCII streams/strings (see Protocol for details)
    • input string is terminated by <LF> or <CR>
  • μController provides the communication with the (external) devices

  • In general a command and its possible response e.g. HELP is sent/retrieved from the master to the ATMEL with e.g. by listening to /dev/ttyUSBx while sending the command to the same device, i.e. in the easiest case (including an endless while loop for an automatic reconnect)
    $> while :; do sleep 1; cat /dev/ttyUSBx; done &
    $> echo "HELP" >/dev/ttyUSBx
    replace x by the corresponding integer
  • To access the device the user has to have the right permissions, e.g. dialout, use ls and groups to find out current settings
    $> ls -l /dev/ttyUSB*
    crw-rw-rwT 1 root users 188, 0 Jan 21 10:38 /dev/ttyUSB0
    crw-rw---T 1 root dialout 188, 1 Jan 21 10:38 /dev/ttyUSB1

    $> groups epics
    epics : epics dialout epicsadm
  • It might be necessary that the properties of the serial devices has to be changed. Currently these stty are working
    $> stty -F /dev/ttyUSBx -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke 115200

    • Output settings:
      -opost
      do not post-process output
      -onlcr
      do not translate newline to carriage return-newline
    • Local settings:
      -isig
      do not enable interrupt, quit, and suspend special characters
      -icanon
      do not enable erase, kill, werase, and rprnt special characters
      -iexten
      do not enable non-POSIX special characters
      -echo
      do not echo input characters
      -echoe
      do not echo erase characters as backspace-space-backspace
      -echok
      do not echo a newline after a kill character
      -echoctl
      do not echo control characters in hat notation ('^c')
      -echoke
      kill all line by obeying the echoctl and echok setting
      115200
      sets the speed to 115200 Bit/s

    Summarizing the settings prevent any additional manipulation of input or output.

Communication Tools

Linux

cat / echo
$> stty -F /dev/ttyUSBx -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke 115200
$> while :; do sleep 1; cat /dev/ttyUSBx; done &
$> echo "HELP" >/dev/ttyUSBx
replace x by the corresponding integer
hadcon

IRC-like environment with command history (over several sessions) and command line editing all included

$> stty -F /dev/ttyUSBx -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke 115200
$> hadcon /dev/ttyUSBx
replace x by the corresponding integer

picocom
picocom --b 115200 -l /dev/ttyUSBx -d 8 -p n -f n --echo --omap crlf --imap lfcrlf

replace x by the corresponding integer

Prerequisites
you have to have admin rights.

How to
  • edit/create /etc/udev/rules.d/99-serial-permissions.rules
    • add the follwing line for general includes
      SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", SYMLINK+="$env{ID_SERIAL}", GROUP="users", MODE="0666"
      creates for every connected device of vendor id 0403 a symbolic link /dev/ to the connected device
    • for special devices those lines can be added in addition
      SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ENV{ID_SERIAL}=="FTDI_FT232R_USB_UART_A100dQ2B", SYMLINK+="hadcon2", GROUP="users", MODE="0666"
      SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ENV{ID_SERIAL}=="FTDI_FT232R_USB_UART_A600801P", SYMLINK+="olimex", GROUP="users", MODE="0666"

    • for special devices (e.g. HadCon2) those lines can be added in addition
      • SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ENV{ID_SERIAL}=="FTDI_FT232R_USB_UART_A100*", RUN+="/usr/bin/stty -F /dev/$kernel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke 115200 "
      • SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ENV{ID_SERIAL}=="FTDI_FT232R_USB_UART_A801*", RUN+="/usr/bin/stty -F /dev/$kernel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke 115200 "
  • to find out the IDs of connected systems
    udevadm info --export-db| grep FTDI| grep ID_SERIAL

  • Finally reload rules and trigger a reconnect:
    udevadm control --reload-rules
    udevadm trigger

Links
"Writing udev rules"
http://reactivated.net/writing_udev_rules.html
udev
https://wiki.ubuntuusers.de/udev/
"Tutorial on how to write basic udev rules in Linux"
https://linuxconfig.org/tutorial-on-how-to-write-basic-udev-rules-in-linux

-- PeterZumbruch - 2020-11-09

Windows

Beginning with version 4.6.2 a fix provides also direct access for Windows.

PuTTY: A Free Telnet/SSH Client
  1. http://www.chiark.greenend.org.uk/~sgtatham/putty
    • @GSI: use the "Softwarecenter" to install Putty.
  2. you have to find out which COM port the HadCon2 is connected to: e.g. COM14
    • e.g. "Windows+R" → "devmgmt.msc" → (COM & LPT), before and after connecting HadCon2
  3. settings:
    • basic options:

      putty basic settings
    • connection options:

      putty connection settings
    • terminal options:

      putty terminal options
  4. then open a serial session to the COM port, e.g. COM14

LabVIEW

-- PeterZumbruch - 2020-11-10

Protocol

General

    CPU → μController
    The communication consists of short command keywords, e.g. HELP, SEND, SPI, etc, followed by (optional) arguments or sub commands

    Structure
    <Keyword, 3-5 letters, (capital letters)> <Message>

    • NOTE: from version 4.6.1 on all command keywords are case insensitive
    • string termination (automatically) by <LF> or <CR>

    μController → CPU

    The following answers can occur
    • RECV followed by the sent command keyword and the 'result'
    • nothing, usually send actions
      • can be made more verbose by increasing the debug level via DEBG <debug level>, <debug level> > 0
        • RECV <literal acknowledge>*
    • ERRx in case of an error
      • ERRx <Error number> <Error description>
      • ERRx <Error number> <Error description> *** "<Additional Information>"
      • ERRx "<Command>" <Error number> <Error description>
      • ERRx "<Command>" <Error number> <Error description> *** "<Additional Information>"
      • where 'x' can be
        • G : global errors
        • A : api errors, e.g. typos, wrong arguments, inputs, syntax, out of limits, etc.
        • C : CAN related global errors
        • M : CAN related message box errors
        • T : I²C errors, Two-Wire-Interface
        • U : undefined

HELP



    $ HELP : will give an overview list of available commands, e.g. :
        RECV HELP --- available commands are:
        RECV HELP --- SEND : send can message
        RECV HELP ---           SEND CAN-ID ID-Range [RTR <nBytes> D0 .. D7]
        RECV HELP --- SUBS : unsubscribe can id/mask
        RECV HELP ---           SUBS CAN-ID ID-Range
        RECV HELP --- USUB : unsubscribe can id/mask
        RECV HELP ---           USUB CAN-ID ID-Range
        RECV HELP --- RGWR : write register
        RECV HELP ---           RGWR <Register> <Value>
        RECV HELP --- RGRE : read register
        RECV HELP ---           RGRE <Register>
        RECV HELP --- RADC : AVR ADCs
        RECV HELP ---           RADC [<ADC Channel>]
        RECV HELP --- OWAD : 1-wire ADC
        RECV HELP ---           OWAD [ID [flag_conv [flag_init]]]
        RECV HELP --- OWDS : 1-wire double switch
        RECV HELP ---           OWDS [ID]
        RECV HELP --- INIT : (re)init of system
        RECV HELP --- OWLS : 1-wire list devices
        RECV HELP ---           OWLS [<Family Code>]
        RECV HELP --- OWSS : 1-wire single switch ([ID] not implemented)
        RECV HELP ---           OWSS [ID]
        RECV HELP --- RSET : reset via watchdog
        RECV HELP --- PING : 
        RECV HELP --- OWTP : 1-wire temperature
        RECV HELP ---           OWTP [ID [flag_conv [flag_init]]
        RECV HELP ---           OWTP <command_keyword> [arguments]]
        RECV HELP --- OWSP : one-wire set active pins/bus mask
        RECV HELP ---           OWSP <bus mask>
        RECV HELP --- CANT : CAN send message
        RECV HELP ---           CANT CAN-ID ID-Range [RTR <nBytes> D0 .. D7]
        RECV HELP --- CANS : CAN subscribe
        RECV HELP ---           CANS CAN-ID ID-Range
        RECV HELP --- CANU : CAN unsubscribe
        RECV HELP ---           CANU CAN-ID ID-Range
        RECV HELP --- DBGL : set/get debug level
        RECV HELP ---           DBGL [level]
        RECV HELP --- DBGM : set/get debug system mask
        RECV HELP ---           DBGM [mask]
        RECV HELP --- JTAG : set/get JTAG availability, switch off/enable 4 more ADC channels
        RECV HELP ---           JTAG [0|1]
        RECV HELP --- HELP : help
        RECV HELP ---           HELP [CMND]
        RECV HELP ---           HELP <mode>
        RECV HELP --- OWRP : 1-wire read active pins/bus mask
        RECV HELP --- DEBG : set/get debug level and mask
        RECV HELP ---           DEBG [level [mask]]
        RECV HELP --- PARA : parasitic device presence test
        RECV HELP --- SHOW : show (internal) settings
        RECV HELP ---           SHOW [key_word]
        RECV HELP --- OWSA : 1-wire API settings
        RECV HELP ---           OWSA <command_key_word> [arguments] 
        RECV HELP --- TWIS : I2C access
        RECV HELP ---           TWIS <0|1> <I2C address> <data length> <byte1 ... byte8>
        RECV HELP --- I2C  : I2C access
        RECV HELP ---           I2C <0|1> <I2C address> <data length> <byte1 ... byte8>
        RECV HELP --- RLTH : relay threshold
        RECV HELP ---           RLTH [command_key_word] <value>
        RECV HELP --- SPI  : experimental SPI master (slave)
        RECV HELP ---           SPI [data]
        RECV HELP ---           SPI <cmd> <arguments>
        RECV HELP --- GNWR : waveform generator write data
        RECV HELP ---           GNWR <address> <data>
        RECV HELP --- GNRE : waveform generator read data
        RECV HELP ---           GNRE <address>
        RECV HELP --- OW8S : 1-wire octal switches
        RECV HELP ---           OW8S [ID [value]]
        RECV HELP --- VERS : code version
    

    A more detailed command description you'll get by using the command:
    HELP <command>

-- PeterZumbruch - 2020-11-09 - 12:09

CAN



      Keyword Action Format Description Comments
      SEND
      CANT
      Send CAN Message SEND <CAN Message-ID> <ID-Range> [<RTR> <Length> <Data0 ... Data7>]
      CANT <CAN Message-ID> <ID-Range> [<RTR> <Length> <Data0 ... Data7>]

      response:
      RECV <MOB-number> <CAN Message-ID> <ID-Range> [<RTR> <Length> <Data0 ... Data7>]

      future response:
      RECV <CAN Message-ID> <ID-Range> [<RTR> <Length> <Data0 ... Data7>]
      Message-ID: CAN Message Identifier (hex)
      ID-Range: used as mask on Message IDs (hex)
      RTR: sets Remote Transmission Request Mode
      Length: number of data bytes to send (max: 8)
      Data 0...7: 0 to 8 data bytes (hex) MOB-number: index of receiving MOB (Message Object Blocks) in CAN controller
       
      SUBS
      CANS
      Subscribe to Message-IDs SUBS <CAN Message-ID> <ID-Range>
      CANS <CAN Message-ID> <ID-Range>

      response:
      nothing
      Subscribe to react on (a range of) CAN Messages
      Message-ID: CAN Message Identifier (hex)
      ID-Range: used as mask on Message IDs (hex)
      TODO: look to code, has to be clarified
      USUB
      CANU
      Unsubscribe from Message-IDs USUB <CAN Message-ID> <ID-Range>
      CANU <CAN Message-ID> <ID-Range>

      response:
      nothing
      Unsubscribe from reacting on (a range of) CAN Messages
      Message-ID: CAN Message Identifier (hex)
      ID-Range: used as mask on Message IDs (hex)
      TODO: look to code, has to be clarified
      CAN CAN commands CAN <sub command> [ <arguments>> ... ]

      response:
      ...
      Replacing above commands by sub commoands TODO:

-- PeterZumbruch - 2020-11-09 - 12:08

SPI

-- PeterZumbruch - 2020-11-09 - 12:15

DAC



      Availablity
      available since version: 4.6.3
      Channel numbers
      The Channel numbers 0..7 follow the signal naming (DACOUTx, q.v. HadCon2/DAC) and are therefore shifted by -1 compared to the connector pin numeration from pin 1 to pin 8. The remaining pin 9 and 10 are ground. (q.v. connector assignment)
      Commands

      1. DAC : return all DACs value
      2. DAC <CHANNEL> : return current DAC value
        • <CHANNEL>: 0 - 7
      3. DAC: <CHANNEL> <VALUE_mV> : set current DAC output to (approx.) wanted voltage
        • <CHANNEL>: 0 - 7
        • <VALUE_mV> - 0 - 3300 mV
          • alert: The actual resulting value might differ, due to the 8bit conversion binning of 3300mV / 255 ≈ 12,94 mV


      Output
        The output is the same for all commands:
        RECV DAC <CHANNEL> <VALUE_mV> <VALUE_HEX> [undefined]
        with
        • <CHANNEL> : 0 - 7
        • <VALUE_mV> : 0 - 3300 mV, undefined → -1
        • <VALUE_HEX> : 0x00 - 0xFF, undefined → 0x100
        • undefined: since there is no readback, values are undefined until a value is set,
          • exception: after a power up, channels are set to 0V.
        In case you are using the command DAC , you will get the above for each channel from 0 to 7 in a separate line.



-- PeterZumbruch - 2020-11-09 - 12:16

RGRE

-- PeterZumbruch - 2020-11-09 - 12:05

RGWR



    Form:

    RGWR <Register> <Value>

    <Register> : the register address has to be written in hexadecimal

    <Value> : here has to be written the new register value in hexadecimal


    Example command:
    ( toggling LEDs, by writing 1 to the PING0-PING5 registers while DDRG are set to outputs )
    send: RGRE 32
    (e.g.:)
    receive: RECV RGRE 32 1c (11100)
    send: RGWR 32 7
    receive: RECV RGWR 7: value 1b has been written and readback does not match (1b)
    (since PINs are outputs)
    send: RGRE 32
    receinve: RECV RGRE 32 1b

-- PeterZumbruch - 2020-11-09 - 12:06

I2C



    Form:
    I2C <0|1> <I2C address> <data length> <byte1 ... byte8>

    <0|1> : used to execute write or read operation. This is the Least Significant Bit (LSB) from the I2C address byte.

    <I2C address> : Here has to be written the hexadecimal value on the address byte, which is shifted to right with one bit. The reason for the right shift is because, the lsb bit ist already used in the first field, where the working operation is choosen.

    <data length> : data length

    <byte1 ... byte8> : data

    Example command:
    send: I2C 0 70 1 08
    receive: RECV I2C 0 70 01 08 -OK-

-- PeterZumbruch - 2021-03-15 - 17:49



APFEL

-- PeterZumbruch - 2020-11-09

-- PeterZumbruch - 2016-02-19


Performance

Performance Tests

    Theoretical limits

    Rate stability - RGWR toggle I/O port

      Setup
      • HadCon2
        • Firmware Version: 4.6.3.APFEL May 27 2015 15:52
        • 115200 kBit/s
        • 10 MHz Clock
      • Raspberry Pi B (1)
      • EPICS
        • base3.14.12.4
        • streamDevice-2-6
        • asyn4-23
        • application:
          • calcout Record using streamDevice and the protocol File RGWR.proto to send:
            RGWR <register address> <value>
          • modified menuScan.dbdmenuScanFast.dbd to provide faster scan rates up to 1000kHz.
          • hadcon2_RGWR_test.tar.bz2
      Procedures
        1. toggle:
          By sending RGWR 2c 80, i.e. the PINE register, the 8th pin (PE7) on PORT E which is connected partly to HadCon2's connector JAtmelMisc1, pin no. 8, is toggling its state.
          Connected to an oscilloscope the response - an rectangular pulse train - is measured. Two scenarios are measured:
          • normal operation of the IOC
          • slowed down by streamDevice debug printouts - var streamDebug 1
          Example: RGWR-pulseTrain.png
        2. By sending alternatingly RGWR 2e 80 or RGWR 2e 0, i.e. the PORTE register, the 8th pin (PE7) on PORT E which is connected partly to HadCon2's connector JAtmelMisc1, pin no. 8, is actively written 0/1 to.
          Connected to an oscilloscope the response - an rectangular pulse train - is measured.

      Measurements

        Data: toggle
          EPICS SCAN rate Freq [Hz] (1/SCAN) ideal width w/o streamDebug output w/ streamDebug printouts
          Freq [Hz] of 2 Triggers W: averaged signal width [ms] ΔW [ms] ΔW/W width ratio averaged/ideal Lost Triggers/Triggers relative Loss Freq [Hz] of 2 Triggers W: averaged signal width [ms] ΔW [ms] ΔW/W width ratio averaged/ideal Lost Triggers/Triggers relative Loss
          2.00 0.50 2000 0.250 2000.0 80 4.0% 1.00 0/50 0.0% 0.25 2000 85 4.3% 1.0 0/25 0.0%
          1.00 1.00 1000 0.500 1000.0 40 4.0% 1.00 0/50 0.0% 0.5 1000 40 4.0% 1.0 0/25 0.0%
          0.50 2.00 500 1.000 500.1 35 7.0% 1.00 0/50 0.0% 1 500 21 4.2% 1.0 0/11 0.0%
          0.20 5.00 200 2.500 200.0 10 5.0% 1.00 0/50 0.0% 2.475 202 13 6.4% 1.0 0/25 0.0%
          0.15 6.67 150 3.378 148.0 5 3.4% 0.99 0/67 0.0% 3.333 150 9 6.0% 1.0 0/17 0.0%
          0.1 10.00 100 5.000 100.0 6 6.0% 1.00 0/50 0.0% 2.5 200 4 2.0% 2.0 13/25 52.0%
          0.05 20.00 50 10.000 50.0 3 6.0% 1.00 0/50 0.0% 3.378 148 5 3.4% 3.0 13/20 65.0%
          0.04 25.00 40 12.500 40.0 4 10.0% 1.00 0/63 0.0% 4.348 115 5 4.3% 2.9 17/25 68.0%
          0.033 30.30 33 14.900 33.6 3 8.9% 1.02 0/76 0.0% 3.9 128 12 9.4% 3.9 22/30 72.6%
          0.025 40.00 25 20.160 24.8 1 4.0% 0.99 0/21 0.0% 4.032 124 10 8.1% 5.0 32/40 80.0%
          0.015 66.67 15 32.900 15.2 1 6.6% 1.01 0/67 0.0% 3.8 132 2 1.5% 8.8 58/67 87.0%
          0.014 71.43 14 35.720 14.0 3.5 25.0% 1.00 3.5/72 4.9% 4.6 109 5 4.6% 7.8 62/71 86.8%
          0.013 76.92 13 25.300 19.8 8 40.5% 1.52 23/100 23.0% 4.2 119 1 0.8% 9.2 68/77 88.4%
          0.012 83.33 12 20.830 24.0 3 12.5% 2.00 52/105 49.5% 4.1 122 2 1.6% 10.2 74/83 88.8%
          0.011 90.91 11 23.000 21.7 1 4.6% 1.98 44/90 48.9%
          0.01 100.00 10 24.500 20.4 0.5 2.5% 2.04 50/100 50.0%
          0.0075 133.33 7.5 33.800 14.8 2 13.5% 1.97 33/66 50.0%
          0.005 200.00 5 33.330 15.0 2 13.3% 3.00 67/100 67.0%
          0.004 250.00 4 31.200 16.0 2 12.5% 4.01 93/125 74.4%
          0.003 333.33 3 33.000 15.2 2 13.2% 5.05 133/166 80.1%
          0.002 500.00 2 32.900 15.2 1 6.6% 7.60 267/333 80.2%
          0.001 1000 1 breakdown of communication via UART, close to theoretical limit of ≈ 1kHz
        Data: set/reset
          EPICS SCAN rate Freq [Hz] (1/SCAN) ideal width Freq [Hz] of 2 Triggers W: averaged signal width [ms] ΔW [ms] ΔW/W width ratio averaged/ideal Lost Triggers/Triggers relative Loss
          1,00 1,00 1000 0,500 1000,0 10 1,0% 1,00 0/10 0,0%
          0,50 2,00 500 1,000 500,0 22 4,4% 1,00 0/50 0,0%
          0,20 5,00 200 2,500 200,0 10 5,0% 1,00 0/50 0,0%
          0,15 6,67 150 3,200 156,3 15 9,6% 1,04 0/60 0,0%
          0,10 10,00 100 5,000 100,0 5 5,0% 1,00 0/100 0,0%
          0,03 30,30 33 15,430 32,4 0,4 1,2% 0,98 0/30 0,0%
          0,03 40,00 25 20,000 25,0 1,5 6,0% 1,00 0/100 0,0%
          0,02 66,67 15 33,330 15,0 1,1 7,3% 1,00 3/166 1,8%
          0,01 71,43 14 35,715 14,0 1 7,1% 1,00 14/71 19,7%
          0,01 76,92 13 37,600 13,3 1 7,5% 1,02 30/76 39,5%
          0,01 83,33 12 10,000 50,0 5 10,0% 4,17 194/208 93,3%


      Results
        RGWR toggle performance:
        RGWR_toggle_performance.PNG
        • For a simple toggling register, the maximum frequency is between:
          • 66.67 Hz and 71.43 Hz.
          • Thus the recommendation is to stay above a corresponding EPICS SCAN time of:
            • 0.015s
        • If any streamDebug features are active, i.e. print outs to screen, the performance is reduced by:
          • a factor of 10
        • at higher SCAN rates up to 80% of the toggle signals are lost, but the system is still performing, since the commands are always the same.
          • in those cases the ratios show that the actual scan time is scaled up.
          • other cases have not been investigated
          • RGWR toggle performance ratios:
            RGWR_toggle_performance_ratios.PNG
        • finally at a rate of 1kHz, the system reaches is limit and the communication to the board ceases, but can be recovered.

        RGWR set/reset performance:
        RGWR_set-reset_performance.PNG
        • For a set/reset register, the maximum frequency is at around:
          • 60 Hz.
          • Thus the recommendation is to stay above a corresponding EPICS SCAN time of:
            • 0.017s




-- PeterZumbruch - 2020-11-09

-- PeterZumbruch - 2020-08-04

Topic revision: r28 - 2020-11-09, PeterZumbruch - This page was cached on 2021-10-20 - 12:18.

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback | Imprint (german) | Privacy Policy (german)