GSI Helmholtzzentrum für Schwerionenforschung GmbH
Epics > EpicsProjectsAndActivities > HardwarePlatforms > HadCon2 > HadCon2MultipurposeControlsApi
GSI Wiki webs: Main | System | Sandbox  
Epics@GSI Webhome
EPICS site GSI | Projects & Activities | EPICS site

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

    edit

    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

edit

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

edit

The basic operation principle is that

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

edit

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

edit

General


HELP

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

CAN

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

SPI

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

DAC

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

RGRE

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

RGWR

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

I2C

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



APFEL

-- PeterZumbruch - 2015-07-09

-- PeterZumbruch - 2016-02-19


Performance

Performance Tests

edit

    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

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 | Legal notice | Privacy Policy (german)