You are here: GSI Wiki>Epics Web>EpicsProjectsAndActivities>DriversAndInterfaces>HadConMultipurposeControlsApi (2020-12-11, PeterZumbruch)Edit Attach
Epics@GSI Webhome

Multi-purpose control API implementation on HadCon

Introduction

Objective

HadCon is a general purpose IO module for detector and experiment control as well as for small data acquisition systems.

hadcon

(HADControl general purpose board) Since its first application has been a power monitor for the Hades Shower Detector it has been formerly introduced and well known as HadShoPoMo (Hades Shower Power Monitor (HADControl/HadShoPoMo general purpose board).

HadCon has an SoC on-board, ETRAX 100LX MCM 4+16 from AXIS (Wikipedia: en/de) - which will be discontinued, see the new HadCon2.

Running a standard Linux the Etrax provides "Connectivity to the world" via TCP/IP.
On the other side it connects via its internal serial interface to an ATMEL AT90CAN128 microcontroller and optionally to an Xilinx CPLD.
Via this junction the ATMEL provides a multitude of possible connections to field buses and general I/O ports.

EPICS base and its applications, modules, and extensions can be cross-compiled to run on Etrax Axis' CRIS architecture (see section Architecture: ETRAX's CRIS by AXIS

  • Summarizing:
    • CPU: AXIS ETRAX 100LX MCM 4+16
    • Microcontroller: ATMEL AT90CAN128
      • I2C (internal)
        • 2 × 4-channel 8-Bit DAC - Digital-to-Analog Converter
      • CANbus
        • galvanically isolated CAN - High-speed CAN Transceiver
          • optional external power supply
      • SPI
      • ADCs
      • RS232
      • 32 digital I/Os
    • CPLD: Xilinx XCR3064XL-6CS48C
    • 2 × Rotary Code Switches, hexadecimal coding
    • Ericsson PME 5218TS switching regulator for up to 6A 3.3V power usable for other boards
    • full EPICS support

This projects' objective is to combine all existing HadCon (HADControl general purpose board) implementations into one μController code for its ATMEL AT90CAN128:
  • CANbus (based on the thesis and work of L.Fouedjou, see Project Page)
  • One-Wire bus implementation
    • ADC
    • DAC
    • Temperature
    • Switches
  • HadCon's internals
    • DACs
    • ADCs
  • ...

HadCon2

Setup

Hardware

  • HadCon
    • Power supply, 6V
    • Kernel programming: Sergey Yurevic, HADES
    • Schematic
    • Micro-controller: AT90CAN128
    • CPU: AXIS ETRAX 100LX MCM 4+16
    • CPLD: 64 Macrocell CPLD Xilinx (XC)R3064XL
    • Tweaks:
        Set fuses
        First time you are programming a new hadcon board with “Olimex” (s.below) you have to “set fuses” (up-to-now I don't now what this means) by issuing from your cross compiling computer the following sequence:
        $> avarice -c 0,1,0,4 --jtag /dev/ttyUSB0 -B 1000000 -W ff19e0
        Bridge Flip-flop to increase ATMEL_CLOCK to 10MHz
        to be able to transmit up to baud rates of 115200 you have to manipulate the hardware of the hadcon.
        The clock signal of the oscillator X1 is 20 MHz. It is scaled down by two flip-flops (UFF1, UFF2) first to 10 MHz and then to 5 MHz.
        Now 10 MHz are needed
        Therefore UFF2 has to be bridged or short-cut, i.e.
        1. pin 5 of UFF2 has to be disconnected from its pad and removed
        2. A cable has to be soldered connecting pin 1 of UFF2 to the solder pad of pin 5
        DHCP / NFS mount
        Etrax tries to NFS mount directories extracted from the DHCP information:
        1. At start-up the ETRAX board with its kernel sends an DHCP broadcast request with its MAC adress
        2. An special (private) DHCP server returns the needed network settings
        3. But the secondary DNS server address is taken as mount point to mount files from
        4. more about contact Sergey Yurevich at GSI
  • AVR-USB-JTAG Connector (olimex)
    • ADAN2: Connector
      • ADAN2 schematic,pdf: ADAN2 Measuring adapter
        • missing connection on pin 1 and 2 in the schematic, they connect one-to-one
        • final connection :
          AVR-JTAG-USB pin ADAN2 in pin JTAG hadcon in
          AVR name HadCon name
          TCK 1 9 9 TCK
          GND 2 8 8 GND
          TDO 3 7 7 TDIN
          VREF 4 - -  
          TMS 5 1 1 TMS
          NSRST 6 - -  
          VCC 7 5 5 +5V
          NTRST 8 - -  
          TDI 9 3 3 TDOUT
          GND 10 10 10 GND
    • make sure the user accessing the AVR-USB-JTAG has sufficient permissions
      • suse-linux:
        • user should be member of group dialout
        • before accessing change group by issuing the command: newgrp dialout
          • TODO: Check: are there smarter alteratives ???
  • Devices to connect to
    • CAN
    • 1-Wire
    • Registers
    • ...

Documentation

    HadCon - 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

ETRAX

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

Operation

The basic operation principle is that
  • HadCon's ETRAX processor communicates via the serial interface (/dev/ttyS1) with the μController sending and receiving keyword based ASCII streams/strings (see Protocol below for details)
  • μController provides the communication with the (external) devices

  • In general a command and its possible response e.g. HELP is sent/retrieved from the ETRAX to the ATMEL with
    $> /mnt/flash/API-Master "HELP"
    or by listening to /dev/ttyS1 while sending the command to the same device
    $> cat </dev/ttyS1 &
    $> echo >/dev/ttyS1 "HELP"

The following two sections, describe
  • first the connections from the ATMEL to the possible device classes, and
  • in the second part the corresponding protocols commands and responses of the API seen from the controlling ETRAX via the serial bus.

Device classes

    CAN bus

    • Acting as a CAN bus master, using connector JCAN1
    • up-to-now:
      • only 11-Bit-Identifier, "Base frame format" (CAN 2.0A)
      • 29-Bit-Identifier, "Extended frame format" (CAN 2.0B) extension on request
    • Sending, receiving, subscription to channels defined by ID and optionally by a mask (default 0)

    1-wire

    • access to up to 8 individual 1-wire chains/buses connected to connector JDINOUT2, pins 1-8
    • global commands
      • list all devices
      • determine parasitic devices
      • TODO:
        • missing, not yet implemented, but prepared
          • 1-wire atomic commands
    • family specific commands
      • temperature sensor
      • adc
      • switches (1/2/8(TODO))

    Internal ADC

    • read values
      Threshold Relay
      • switching of output pin depending on input of ADC
      • configurable input
        • TODO: add documentation

    I2C - a.k.a. Two Wire Bus

    • not yet implemented in version 3.1 but in progress, comes with 4.0
    • direct access only to internal devices foreseen (DAC)
      • but a bit of soldering may widen its horizon.
      DACs

      • 2 times 4 channels DAC,
      • output connector JDAC1 and partly JPS

    Internals of microcontroller

    • help, all and command specific
    • debugging
      • increasing verbosity,
      • mask available
    • status (show)
      • memory status (initially unused, unused, free)
      • available predefined error statements
    • direct register access read/write
    • JTAG enable/disable (handle with care)

    ... to be extended

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

    Show ... (Expand all... Collapse all)
-- PeterZumbruch - 2020-11-09 - 12:09

CAN

    Show ... (Expand all... Collapse all)
-- PeterZumbruch - 2020-11-09 - 12:08

SPI

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

DAC

    Show ... (Expand all... Collapse all)
-- PeterZumbruch - 2020-11-09 - 12:16

RGRE

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

RGWR

    Show ... (Expand all... Collapse all)
-- PeterZumbruch - 2020-11-09 - 12:06

I2C

    Show ... (Expand all... Collapse all)
-- PeterZumbruch - 2021-03-15 - 17:49

APFEL

-- PeterZumbruch - 2015-07-09

last updated status & plans (-- PeterZumbruch - 13 Jul 2011)

current version: 4.3

  • 1-wire:
    • OWTP (temperature), OWAD (adc), OWLS (list devices) seems to work
      • according to the manual OWTP delivers reasonable values 25 to 30
    • OWAD in use and no complains
    • single ID access to the commands
    • 1-wire OWDS (read and write)
    • PARA parasitic mode check
    • optimize temperature conversion n_bus * 750 ms -> 1*750ms, make it optional
      • also done for adc
  • RLTH, threshold triggered relay
  • RADC, internal ADC readout
  • API:
    • HELP, SHOW, RSET, DEBG, PING, VERS
  • CAN bus:
    • SEND, SUBS, USUB
    • co-work with Florian Feldbauer, Univerity of Bochum
  • Atmel
    • RGWR, RGRE, register access
    • JTAG
  • I2C / Two Wire
    • TWIS
  • co build with HadCon2 (F.Brabetz)

near future version: 4.4

  • Request to implement DS2408 8-Channel Addressable Switch, by RPC/HADES/Coimbra
    • OW8S

future versions:

  • TWIS incl. subcommands for setting parameters
  • 1-wire elementary commands implementation, as subcommands
  • 1-wire OWxS switch:
    • OWxS: combine OWDS, OWSS, OW8S into a single command
  • ?? 1-wire: optionally: split temperature conversion into an automatic task initiated every (5-10) seconds, (maybe) blocking 1-wire bus for 750 ms, but not the
  • API settings command: APIC command value(s) or combine with SHOW command
  • check warnings
  • other possible devices
    • organizing local ADC support
      • including (already but rudimentary) existing relay / state machine control ( min < value < max )
  • clean-up
    • merge available commands into sub-commands
      • OWxx=, RGxx, RLxx
    • improve HELP content
  • modularize code to jump table of structure of functions (execute, help, ...) per command represented by its index
    • get rid of huge switch/case structures
  • USART
    • input/output buffer for USART
  • ...

Meanwhile ...

Due to several request I had to develop different features in different branches. The main task is now to merge all these projects into one, where this is its poor-mans backup tarball.

-- PeterZumbruch - 21 Mar 2013

Attachments 4
Edit  | Attach | Print version | History: r39 < r38 < r37 < r36 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r39 - 2020-12-11, PeterZumbruch
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)