EPICS site GSI | Projects & Activities | EPICS site

Multi-purpose control API implementation on HadCon

• Introduction
  • Objective
  • HadCon2
• Setup
  • Hardware
    • Documentation
      • HadCon - Documentation
  • Software
    • Code Repositories
      • git
        • git.gsi.de
      • Tar Balls & ELFs
        • Tar ball, including ELFs
        • HadCon2 - ELF 32-bit LSB executable, Atmel AVR 8-bit, version 1 (SYSV), statically linked, not stripped
    • ETRAX
    • ATMEL
      • Toolchain & Access
        • Prerequisites
        • AVR
        • avrdude
        • avarice
        • Docs / Tutorials / Help
      • Supported devices
        • 1-wire
      • Tweaks
        • Program Space (Harvard Architecture)
        • Memory usage
• Operation
  • Device classes
    • CAN bus
    • 1-wire
    • Internal ADC
      • Threshold Relay
    • I²C - a.k.a. Two Wire Bus
      • DACs
    • Internals of microcontroller
    • ... to be extended
  • Protocol
    • General
      • CPU → μController
      • μController → CPU
    • HELP
    • CAN
    • SPI
      • Api Basic Operation Principle
      • General Operation
        • Basic Operation
        • Advanced Operation
        • Expert Operation
      • Main Commands
        • SPI
        • SPI w/write
        • SPI a/add
        • SPI wb/write_buffer
        • SPI t/transmit
        • SPI css/cs_set
        • SPI csr/cs_release
        • SPI r/read
        • SPI sw/show_write_buffer
        • SPI sr/show_read_buffer
      • Clean-up
        • SPI p/purge
        • SPI pw/purge_write_buffer
        • SPI pr/purge_read_buffer
        • SPI reset
      • Status
        • SPI s/status
        • SPI cs
        • SPI csb/cs_bar
        • SPI cs_pins
      • Chip Select Configuration
        • SPI cs_select_mask
        • SPI csap/cs_add_pin
        • SPI csrp/cs_remove_pin
      • SPI Configuration
        • SPI c/control_bits
        • SPI spi_enable
        • SPI data_order
        • SPI master
        • SPI clock_polarity
        • SPI clock_phase
        • SPI speed
        • SPI speed_divider
        • SPI double_speed
      • API Configuration
        • SPI transmit_byte_order
        • SPI transmit_report
        • SPI auto_purge_write_buffer
        • SPI auto_purge_read_buffer
    • DAC
      • Availablity
      • Channel numbers
      • Commands
      • Output
    • RGRE
    • RGWR
    • I2C
    • APFEL
      • General Operation
      • Version 0
        • Commands
        • First Test Results (16 Jan 2015)
        • Logic Analyzer Results (14 Oct 2015)
        • Summary (10 Oct 2015)
        • Details (port A - 10 Oct 2015)
        • Details (port F - 06 Nov 2015)
      • Version 1
        • Overview
        • $CMND $alternative/$command
        • $CMND $alternative/$command
        • $CMND $alternative/$command
        • $CMND $command
        • $CMND $alternative/$command
• last updated status & plans (-- PeterZumbruch - 13 Jul 2011)
  • current version: 4.3
  • near future version: 4.4
  • future versions:
  • Meanwhile ...

Introduction

Objective

edit

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

(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
    • I²C (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

• NOTE while this project stays maintained, also the successor of HadCon is supported. So for HadCon2's implementation, feel free to have a look at the project Multi-purpose control implementation on 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

• Documentation
  • Info
  • Layout
  • Powering
  • CPU
    • Kernel
    • USART - Universal Synchronous and Asynchronous serial Receiver and Transmitter
  • Microcontroller
    • USART - Universal Synchronous and Asynchronous serial Receiver and Transmitter
  • CPLD (Complex Programmable Logic Devices)
    • connects to:
  • I²C
    • 2 × 4-channel 8-Bit DAC - Digital-to-Analog Converter
  • regulators
    • linear regulator V_IN: 5.5V - 8V → V_OUT: 5V
    • switching regulator: V_OUT: 3.3V
  • galvanically isolated CAN-bus
    • Can - High-speed Can Transceiver
    • iCoupler Digital Isolator
  • Switches
    • Rotary Code Switches, hexadecimal coding
    • Buttons
  • LEDs
  • Connectors
    • JDINOUT1 / JDINOUT2
    • JADC1
    • JTAG1
    • JCAN1
    • JDAC1
    • JPS1
    • JSUBD1
  • Bugs, Notes, Remarks, Tweaks & Twiddling
    • Notes and Remarks
      • 1-wire
    • Tweaks: increase ATMEL_CLOCK to 10MHz
    • Bug: Switches

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

ETRAX

ATMEL

Toolchain & Access

Prerequisites

Since USB devices are not assigned statically and may change, in the following it is assumed that the serial/usb devices used to program/access the Hadcon are:
• programming with olimex: /dev/olimex
• access: /dev/hadcon2 An automatic assignment of specified USB devices to those dev ports is described here
  at "usbdev - dynamic dev symbolic link and proper access rights"

AVR

• AVR - gcc based
  • avr : e.g. zypper se avr
  • Warning: reading http://www.nongnu.org/avr-libc/bugs.html pointing to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30289 tells us, that memset is wrong compiled
    • avr-gcc 3.3.5 - OK
    • fixed in 4.1.3, 4.2 branch, and >= 4.3.0.
    • typically you get 4.1.2
• avr-gcc, avr-libc
  • openSuse - Repository: (from: http://www.mikrocontroller.net/articles/AVR_Eclipse#openSuSE)
    1. zypper ar http://download.opensuse.org/repositories/CrossToolchain:/avr/openSUSE_13.1/ <Some Name>
    2. zypper install avr-libc cross-avr-gcc

avrdude

• AVRDUDE - AVR Downloader/UploaDEr
  • AVRDUDE is a utility to download/upload/manipulate the ROM and EEPROM contents of AVR microcontrollers using the in-system programming technique (ISP).
  • https://www.nongnu.org/avrdude/
• Programming:
  
  $> 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

avarice

• obsolete alternative to avrdude
  • Development of avarice has been discontiuned
  • avarice: http://avarice.sourceforge.net
Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)
• Programming:
  
  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

• Note:
  • avarice does not support the --program feature from version 2.12 on, so make sure you have maximal 2.11.
• Local build:
  1. Download sources :
     
     %FOREACH{"av_version" in="2.11,2.12"}%
     • avarice-$av_version (local copy)
     %NEXT{"av_version"}%
  2. Patches
     1. Download patches for g++ -version ≥ 6.4:
        
        %FOREACH{"av_version" in="2.11,2.12"}%
        • $av_version
          %FOREACH{"av_file" in="pragma.h,jtagrw.cc"}%
          • patch.avarice-$av_version.$av_file
          %NEXT{"av_file"}%
          %NEXT{"av_version"}%
     2. Apply Patches:
        
        %FOREACH{"av_version" in="2.11,2.12"}%
        • $av_version
          %FOREACH{"av_file" in="pragma.h,jtagrw.cc"}%
          • patch src/$av_file < patch.$av_version.$av_file
          %NEXT{"av_file"}%
          %NEXT{"av_version"}%
  3. build
     • • ./configure && make or
       • ./configure && make && make install
• Pitfalls & Obstacles:

  programming

  HadCon's and HadCon2's CPLD/FPGA size differs avarice must have the right arguments
  $>avarice -c 0,1,0,8 --jtag /dev/olimex -B 1000000 --erase --program --file api.elf

  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,8 --jtag /dev/olimex -B 1000000 -W ff19e0

Docs / Tutorials / Help

• AVR Knowledge:
  • AVR Tutorial (german): http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
  • Helper to show memory consumption add it to PATH
    • avr-mem.sh: avr-mem (original from http://www.mikrocontroller.net/topic/52953 http://www.mikrocontroller.net/attachment/18841/avr-mem.sh)
  • AVR http://www.rn-wissen.de/index.php/Avr-gcc (german)
    • Tipps and Tricks: http://www.rn-wissen.de/index.php/Avr-gcc#Optimierungen.2C_Tipps_.26_Tricks (german)
  • AVR libc manual: http://www.nongnu.org/avr-libc/user-manual/index.html

Supported devices

1-wire

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

Tweaks

Program Space (Harvard Architecture)

• Program space:
  • http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
  • http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Speicherzugriffe (german)
    • http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29 (german)

Memory usage

• Memory usage:
  • http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc#Dynamischer_RAM-Verbrauch (german)

Operation

• 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"

• 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

I²C - 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)Hide ... (Expand all... Collapse all)



edit

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

---

CAN

---

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)



edit

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:

SPI

---

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)



edit

Api Basic Operation Principle

• HadCon 2 Multipurpose Controls Api Basic Operation

---

General Operation

---

The SPI command set allows to operate the Serial Peripheral Interface SPI interface of the HadCon(2)'s microcontroller, (currently "only") as a master.
It sends data in atomic chunks of bytes via the MOSI pin to slave devices and receives via the MISO pin the responses. This happens in a buffered mode, so that multiple bytes can be send and received at once.
The current limitation of the write-buffer is linked to the input string buffer of 140 characters, i.e. ≈ 60 bytes.
Up to 8 Chip-Select/SlaveS Select output pin(s) can be defined and manipulated either
• automatically ( Basic Operation ),
• semi-automatically ( Advanced Operation ), or
• manually ( Expert Operation )
The received data is stored in a read buffer which is of the same size as the write buffer. The purging of the buffers depend on the mode of operation and the configuration settings.

Basic Operation

---

"Single Command Operation"

All necessary steps are taken automatically, optional behavior can be achieved by changing the configuration.

Example task:
SPI write dc 7f 8f8fb4 0123456789abcdef be

equivalent to
SPI dc 7f 8f8fb4 0123456789abcdef be
NOTE: only even number of digits per argument are allowed
This write command includes the following steps:
1. optionally purge read buffer
   

   (default

   TRUE)

2. purge write buffer
3. filling the write buffer
   by decomposing input byte by byte
   ⇒ dc 7f 8f 8f b4 01 23 45 67 89 ab cd ef be
4. set cs
   • setting the defined chip-select pin(s) to "active low"
     • optionally masked by an external mask
5. transmit/receive
   byte by byte in the given byte-order
   • transmit write buffer content
   • attaching received bytes to the end of the read buffer
6. release cs
   • release the defined chip-select pins(s) to "passive high"
     • optionally masked by an external mask
7. optionally purge write buffer
   (default: FALSE)
The read buffer content can be shown as follows:
• last read element
  
  SPI read

• last read 3 elements
  
  SPI show_read_buffer 3 1

• first read 6 elements
  
  SPI show_read_buffer 6

• the full content
  
  SPI show_read_buffer
See read, and show_read_buffer commands for details

---

Advanced Operation

---

The user can prepare step by step the write buffer before automatically sending it.
Example sequence: add/write_buffer

 
    SPI purge_read_buffer      // optionally
    SPI purge_write_buffer     // optionally     
   
    SPI add dc 7f              
    SPI add 8f8fb4             // repeat until write buffer is full
    SPI add 0123456789abcdef   //
    SPI add be                 //
   
    SPI show_write_buffer      // optionally
   
    SPI write_buffer           
   
    SPI write_buffer           // e.g. repeat it, if auto_purge is OFF
   
    SPI write_buffer 02        // only activate second chip select pin, by masking it with 0x02

The write_buffer command includes all remaining necessary steps:
1. set cs
   • setting the defined chip-select pin(s) to "active low"
     • optionally masked by an external mask
2. transmit/receive
   byte by byte in the given byte-order
   • transmit write buffer content
   • attaching received bytes to the end of the read buffer
3. release cs
   • release the defined chip-select pins(s) to "passive high"
     • optionally masked by an external mask
4. optionally purge write buffer
Example sequence: write/write_buffer

 
    SPI write dc 7f 8f8fb4 0123456789abcdef be 
    SPI write_buffer           // e.g. repeat it, if auto_purge is OFF
   ...              
    SPI write_buffer
    SPI write_buffer 02        // only activate 2nd chip select pin, by masking it with 0x02
    SPI write_buffer 01        // only activate 1st chip select pin
    SPI write_buffer fc        // only activate the other chip select pins

Reading: see Basic Operation

---

Expert Operation

---

The user has full control on setting and releasing chip select pins.
Example sequence: selected chip select

 
    SPI purge_read_buffer     // optionally
    SPI purge_write_buffer    // optionally     
    SPI add dc 7f 8f8fb4 0123456789abcdef be              

    SPI cs                    // get status of defined chip select pins
    SPI cs_bar                // same as above but with "active low" logic

    SPI cs_set                // set all available chip select pins to "active"
    SPI transmit           
    SPI cs_release            // set all available chip select pins to "passive"

    SPI cs_set 01             // only activate 1st chip select pin to "active"
    SPI transmit           
    SPI cs_release            // set all available chip select pins to "passive"

    SPI cs_set fe             // only activate the other chip select pins to "active"
    SPI transmit           
    SPI cs_release ee         // set masked chip select pins to "passive", keep 5th "active"
    SPI cs_release 10         // set masked chip select pins to "passive", keep 5th "active"

Reading: see Basic Operation

---

---

Main Commands

---

SPI

Format

• SPI
  • short-cut of SPI status

Format

• SPI <list of data bytes|words|dwords|qwords>
  • short-cut of SPI write

---

SPI w/write

Task

send list of bytes to clients, including predefined purge, chip-select behavior

Format

• SPI write <list of data bytes|words|dwords|qwords>
• SPI w     <list of data bytes|words|dwords|qwords>

Response

• nothing
• if DEBG > 0
  RECV SPI write OK

Description


As described in section Basic Operation

Arguments

• list of data bytes|words|dwords|qwords|...

Comments

• Maximum single number length 24 digits
• only byte-wise sending allowed
• see SPI cs_select_mask
• see SPI auto_purge_write_buffer
• see SPI auto_purge_read_buffer
• see SPI transmit_report
• see SPI transmit_byte_order

---

SPI a/add

Task

add list of data byte by byte to the write buffer

Format

• SPI add <list of data bytes|words|dwords|qwords>
• SPI a   <list of data bytes|words|dwords|qwords>

Response

• nothing
• if DEBG > 0
  RECV SPI add OK

Arguments

• list of data bytes|words|dwords|qwords|...

Comments

• Maximum single number length 24 digits

---

SPI wb/write_buffer

Task

send write buffer content to clients, including predefined purge, chip-select behavior,
optionally selecting chip select pins

Format

• SPI write_buffer [ <Chip Select Mask> ]
• SPI wb [ <Chip Select Mask> ]

Response

RECV SPI write_buffer


Description

Arguments

• optional: external chip select mask:
  • [ 0 ... FF]
  • each bit represents a cs pin
    • 1:active, 0:inactive

Comments

• see SPI auto_purge_write_buffer
• see SPI auto_purge_read_buffer
• see SPI transmit_report
• see SPI transmit_byte_order
• see SPI cs_pins

---

SPI t/transmit

Task

send write buffer content to clients, w/o any chip select manipulation

Format

• SPI transmit
• SPI t

Response

• nothing
• if DEBG > 0
  RECV SPI transmit OK

Description

Arguments

• -

Comments

• see SPI transmit_report
• see SPI transmit_byte_order

---

SPI css/cs_set

Task

sets (selected) chip select pins to "active low"

Format

• SPI cs_set [ <Chip Select Mask> ]
• SPI css [ <Chip Select Mask> ]

Response

RECV SPI cs 1:1 2:- 3:- 4:- 5:- 6:- 7:- 8:-


Description

On success cs is called to show the current status

Arguments

• optional: external chip select mask:
  • [ 0 ... FF]
  • each bit represents a cs pin
    • 1:active, 0:inactive

Comments

• see SPI cs_select_mask
• see SPI cs

---

SPI csr/cs_release

Task

releases (selected) chip select pins to "passive high"

Format

• SPI cs_release [ <Chip Select Mask> ]
• SPI csr [ <Chip Select Mask> ]

Response

RECV SPI cs 1:1 2:- 3:- 4:- 5:- 6:- 7:- 8:-


Description

Arguments

• optional: external chip select mask:
  • [ 0 ... FF]
  • each bit represents a cs pin
    • 1:active, 0:inactive

Comments

• see SPI cs_select_mask
• see SPI cs

---

SPI r/read

Task

read the last element filled into the read buffer

Format

• SPI read
• SPI r

Response

RECV SPI read <value>


Description

read the last element filled into the read buffer
depending on the transmit_byte_order : * 0, MSB: last element (FIFO) * 1, LSB: first element (LIFO)

Arguments

• -

Return values

• <value>
  • "--" , if read buffer is empty
  • last byte filled [0 .. FF]

Comments

• see SPI transmit_byte_order

---

SPI sw/show_write_buffer

Task

show (partial) content of write buffer

Format

• SPI show_write_buffer [<Number of Bytes> [<Reverse Flag>]]
• SPI sw [<Number of Bytes> [<Reverse Flag>]]

Response

• w/o any arguments,
  buffer filled, ≤ 8 bytes:
  
  SPI sw
RECV SPI show_write_buffer elements: 0x5 (5)
RECV SPI show_write_buffer 10 00 10 21 42
• w/o any arguments,
  buffer filled, > 8 bytes:
  
  SPI sw
RECV SPI show_write_buffer elements: 0x14 (20)
RECV SPI show_write_buffer (#1) 10 00 10 21 42 51 25 01 ...
RECV SPI show_write_buffer (#2) 10 10 10 00 10 21 42 51 ...
RECV SPI show_write_buffer (#3) 25 01 10 10
• w/ <Number of Bytes> set, <Number of Bytes> ≠0,
  buffer empty:
  
  SPI sw 3
RECV SPI show_write_buffer --
• w/ <Number of Bytes> set, e.g. 4,
  buffer filled, ≤ 8 bytes:
  
  SPI sw 4
RECV SPI show_write_buffer 10 00 10 21
• w/ <Number of Bytes> set, e.g. 0xA,
  buffer filled, > 8 bytes:
  
  SPI sw a
RECV SPI show_write_buffer (#1) 10 00 10 21 42 51 25 01 ...
RECV SPI show_write_buffer (#2) 10 10
• w/ <Number of Bytes> set, e.g. 2,
  w/ <Reverse Flag> flag set ( TRUE,HIGH,ON,1 )
  buffer filled, ≤ 8 bytes,
  
  SPI sw 2 TRUE
RECV SPI show_write_buffer 10 10
• w/ <Number of Bytes> set, e.g. 9,
  w/ <Reverse Flag> flag set ( TRUE,HIGH,ON,1 )
  buffer filled, > 8 bytes:
  
  SPI sw 9 1
RECV SPI show_write_buffer (#1) 00 10 21 42 51 25 01 10 ...
RECV SPI show_write_buffer (#2) 10

Description

Shows (partial) content of write buffer. Depending on the optional arguments the set can be reduced to a sub set of the buffer, beginning from the first element filled or reverse beginning with the last elements added. Depending on the number of elements requested, additional information is added:

• if all elements are show a summary line is added, with the given number of elements in the buffer in hex and decimal
• if the number of elements to show exceed 8
  • a line counter (#i), starting from 1, is added in front
  • "..." are added at the end of the line, if more lines follow

Arguments

• <Number of Bytes>
  • max number of bytes to show, ≥ 0
    • 0: all available
    • else: show <Number of Bytes> elements from beginning (1) to maximum <Number of Bytes>
• <Reverse Flag>
  • flag to revert direction of interest
    • 0,FALSE,OFF,LOW: show <Number of Bytes> elements from beginning (1) to maximum <Number of Bytes>
    • else: show <Number of Bytes> elements from <number of elements> - <Number of Bytes> until last added element

Comments

• -

---

SPI sr/show_read_buffer

Task

show (partial) content of read buffer

Format

• SPI show_read_buffer [<Number of Bytes> [<Reverse Flag>]]
• SPI sr [<Number of Bytes> [<Reverse Flag>]]

Response

• w/o any arguments,
  buffer filled, ≤ 8 bytes:
  
  SPI sr
RECV SPI show_read_buffer elements: 0x5 (5)
RECV SPI show_read_buffer 10 00 10 21 42
• w/o any arguments,
  buffer filled, > 8 bytes:
  
  SPI sr
RECV SPI show_read_buffer elements: 0x14 (20)
RECV SPI show_read_buffer (#1) 10 00 10 21 42 51 25 01 ...
RECV SPI show_read_buffer (#2) 10 10 10 00 10 21 42 51 ...
RECV SPI show_read_buffer (#3) 25 01 10 10
• w/ <Number of Bytes> set, <Number of Bytes> ≠0,
  buffer empty:
  
  SPI sr 3
RECV SPI show_read_buffer --
• w/ <Number of Bytes> set, e.g. 4,
  buffer filled, ≤ 8 bytes:
  
  SPI sr 4
RECV SPI show_read_buffer 10 00 10 21
• w/ <Number of Bytes> set, e.g. 0xA,
  buffer filled, > 8 bytes:
  
  SPI sr a
RECV SPI show_read_buffer (#1) 10 00 10 21 42 51 25 01 ...
RECV SPI show_read_buffer (#2) 10 10
• w/ <Number of Bytes> set, e.g. 2,
  w/ <Reverse Flag> flag set ( TRUE,HIGH,ON,1 )
  buffer filled, ≤ 8 bytes,
  
  SPI sr 2 TRUE
RECV SPI show_read_buffer 10 10
• w/ <Number of Bytes> set, e.g. 9,
  w/ <Reverse Flag> flag set ( TRUE,HIGH,ON,1 )
  buffer filled, > 8 bytes:
  
  SPI sr 9 1
RECV SPI show_read_buffer (#1) 00 10 21 42 51 25 01 10 ...
RECV SPI show_read_buffer (#2) 10

Description

Shows (partial) content of read buffer. Depending on the optional arguments the set can be reduced to a sub set of the buffer, beginning from the first element filled or reverse beginning with the last elements added. Depending on the number of elements requested, additional information is added:

• if all elements are show a summary line is added, with the given number of elements in the buffer in hex and decimal
• if the number of elements to show exceed 8
  • a line counter (#i), starting from 1, is added in front
  • "..." are added at the end of the line, if more lines follow

Arguments

• <Number of Bytes>
  • max number of bytes to show, ≥ 0
    • 0: all available
    • else: show <Number of Bytes> elements from beginning (1) to maximum <Number of Bytes>
• <Reverse Flag>
  • flag to revert direction of interest
    • 0,FALSE,OFF,LOW: show <Number of Bytes> elements from beginning (1) to maximum <Number of Bytes>
    • else: show <Number of Bytes> elements from <number of elements> - <Number of Bytes> until last added element

Comments

• -

---

---

Clean-up

---

SPI p/purge

Task

purge write and read buffer

Format

• SPI purge
• SPI p

Response

• nothing
• if DEBG > 0
  RECV SPI purge OK

Description

purges write and read buffer, by internally calling purge_write_buffer and purge_read_buffer

Arguments

• -

Comments

• see SPI purge_write_buffer
• see SPI purge_read_buffer

---

SPI pw/purge_write_buffer

Task

purge write buffer

Format

• SPI purge_write_buffer
• SPI pw

Response

• nothing
• if DEBG > 0
  RECV SPI purge_write_buffer OK

Description

Arguments

• -

Comments

• only resets the number of elements to 0, not the data

---

SPI pr/purge_read_buffer

Task

purge read buffer

Format

• SPI purge_read_buffer
• SPI pr

Response

• nothing
• if DEBG > 0
  RECV SPI purge_read_buffer OK

Description

Arguments

• -

Comments

• only resets the number of elements to 0, not the data

---

SPI reset

Task

resets SPI interface and SPI parameter settings to their default status

Format

• SPI reset

Response

• nothing
• if DEBG > 0
  RECV SPI reset OK

Description

Arguments

• -

Comments

• see SPI status

---

---

Status

---

SPI s/status

Task

Show status

Format

• SPI status
• SPI s
• SPI

Response

RECV SPI status
RECV SPI cs 1:0 2:- 3:- 4:- 5:- 6:- 7:- 8:-
RECV SPI cs_bar 1:1 2:- 3:- 4:- 5:- 6:- 7:- 8:-
RECV SPI cs_pins 1:PORTB,0
RECV SPI cs_select_mask FF
RECV SPI control_bits 50
RECV SPI spi_enable TRUE
RECV SPI data_order 0
RECV SPI master TRUE
RECV SPI clock_polarity 0
RECV SPI clock_phase 0
RECV SPI speed 0
RECV SPI double_speed TRUE
RECV SPI speed_divider 4 (2500000Hz @ 10000000Hz)
RECV SPI transmit_byte_order 0 (MSB/big endian)
RECV SPI transmit_report FALSE
RECV SPI auto_purge_read_buffer TRUE
RECV SPI auto_purge_write_buffer FALSE
RECV SPI show_write_buffer elements: 0xd (13)
RECV SPI show_write_buffer (#1) AB BB AA BB CC EE FF 66 ...
RECV SPI show_write_buffer (#2) 54 12 45 54 58
RECV SPI show_read_buffer elements: 0 (0)

Description

• recursive call of all available status information

Arguments

• -

Comments

• -

---

SPI cs

Task

reports current status of (selected) chip select lines

Format

• SPI cs [<Chip Select Mask>]

Response

• w/o mask
  
  SPI cs
RECV SPI cs 1:0 2:- 3:- 4:- 5:- 6:- 7:- 8:-

• w/ mask, eg. 0b01100001 = 0x71
  
  SPI cs 71
RECV SPI cs 1:0 6:- 7:-


Description

Arguments

• optional [<Chip Select Mask>]
  • [ 0 ... FF]
  • each bit represents a cs pin
    • 1:chosen, 0:ignore

Response

• list of <Pin States>
  • syntax <Pin States>:
    • <Index>:<State>
      • <Index>: 1 ... 8
      • <State>:
        • 1: HIGH
        • 0: LOW
        • -: undefined, channel not connected

Comments

• -

---

SPI csb/cs_bar

Task

reports current inverted status of (selected) chip select lines

Format

• SPI cs_bar [<Chip Select Mask>]
• SPI csb [<Chip Select Mask>]

Response

• w/o mask
  
  SPI csb
RECV SPI cs_bar 1:1 2:- 3:- 4:- 5:- 6:- 7:- 8:-

• w/ mask, eg. 0b01100001 = 0x71
  
  SPI csb 71
RECV SPI cs_bar 1:1 6:- 7:-


Description

Arguments

• optional <Chip Select Mask>
  • [ 0 ... FF]
  • each bit represents a cs channel/pin
    • 1:chosen, 0:ignore

Response

• list of <Pin States>
  • syntax <Pin States>:
    • <Index>:<State>
      • <Index>: 1 ... 8
      • <State>:
        • 1: LOW
        • 0: HIGH
        • -: undefined, channel not connected

---

SPI cs_pins

Task

report current chip select channel configurations

Format

• SPI cs_pins [<CS Channel Index>]

Response

• w/o argument
  
  SPI cs_pins
RECV SPI cs_pins <List of active <Index>:<PORTx>,<Pin> CS Configurations>
  • e.g.:
    
    RECV SPI cs_pins 1:PORTB,0 2:PORTA,4 3:PORTG,4 7:PORTF,5
• w/ <CS Channel Index>
  
  SPI cs_pins <CS Channel Index>
RECV SPI cs_pins <Index><PORTx>,<Pin>,<Status>
  • e.g.:
    
    SPI cs_pins 1
RECV SPI cs_pins 1:PORTB,0,ON

Description

Arguments

• optional <CS Channel Index>
  • chip select index
  • 1 ... 8

Return values

• <List of active <Index>:<PORTx>,<Pin> CS Configurations>
  or
  <<Index>:<PORTx>,<Pin>,<Status> CS Configuration>
  • <Index>
    • chip select index
    • 1 ... 8
  • <PORTx>
    • PORTx
      • x: A ... G
  • <Pin>
    • pin number of PORTx
      • 0 ... 7
  • <Status>
    • status of chosen chip select index
      • ON: active
      • OFF: deactivated

Comments

• see SPI cs_add_pin
• see SPI cs_remove_pin

---

---

Chip Select Configuration

---

SPI cs_select_mask

Task

get / set external chip select mask

Format

• SPI cs_select_mask [<Chip Select Mask>]

Response

RECV SPI cs_select_mask <Value>


Description

The chip select mask allows to select a subset of the available, defined chip select channels.
Each bit of this mask represents a channel which can be selected or ignored.
This mask is used in all cases where chip select actions are required and not explicitly given.

• w/o argument: the current mask is shown
• w/ argument: <Value> is assigned to the configuration

Arguments

• optional, <Value>
  • chip select mask
  • range [0 ... FF]
  • each bit represents a chip select channel
    • 1:chosen, 0:ignore

Comments

• -

---

SPI csap/cs_add_pin

Task

add chip select channel configuration

Format

• SPI cs_add_pin <Symbolic Output Port Address> <Output Port Pin> [<Channel Select Index/Slot>]
• SPI csap <Symbolic Output Port Address> <Output Port Pin> [<Channel Select Index/Slot>]

Response

RECV SPI cs_pins <List of active <Index>:<PORTx>,<Pin> CS Configurations>

see SPI cs_pins

Description

Allows to add up to 8 output port PORTX:Pin combinations to act as channel select channels. Provided the chosen slots aren't used yet or the address set is already defined (see SPI cs_pins, SPI cs_remove_pin).
A successful operation is reported via SPI cs_pins

• w/o <Channel Select Index/Slot>:
  • adds channel to next free slot
• w/ <Channel Select Index/Slot>:
  • adds channel to assigned index

Arguments

• <Symbolic Output Port Address>
• symbolic name for the available output port addresses
  • PORTx
    • x: A ... G
• <Output Port Pin>
  • pin number of PORTx
    • 0 ... 7
• optionally <Channel Select Index/Slot>
  • chip select index
    • 1 ... 8

Comments

• see SPI cs_pins
• see SPI cs_remove_pin

---

SPI csrp/cs_remove_pin

Task

remove chip select channel configuration

Format

• SPI cs_remove_pin <Channel Select Index/Slot>
• SPI csrp <Channel Select Index/Slot>

Response

RECV SPI cs_pins <List of active <Index>:<PORTx>,<Pin> CS Configurations>

see SPI cs_pins

Description

Removes a chip select configuration from set of pin configuration (see SPI cs_pins).
A successful operation is reported via SPI cs_pins.

Arguments

• <Channel Select Index/Slot>
  • chip select index
    • 1 ... 8

Comments

• see SPI cs_pins
• see SPI cs_add_pin

---

---

SPI Configuration

---

SPI c/control_bits

Task

set/get SPI hardware configuraton/status

Format

• SPI control_bits [<Extended SPI Control Register>]
• SPI c [<Extended SPI Control Register>]

Response

e.g. :

RECV SPI control_bits 50
RECV SPI spi_enable TRUE
RECV SPI data_order 0
RECV SPI master TRUE
RECV SPI clock_polarity 0
RECV SPI clock_phase 0
RECV SPI speed 0
RECV SPI double_speed TRUE
RECV SPI speed_divider 4 (2500000Hz @ 10000000Hz)

Description

Allows to set/get the combined information/settings of the SPI Control Register SPCR and the SPI Status Register SPSR en bloc. Therefore those two registers are combinded into one 16bit data word with SPCR as LSB and SPSR as MSB. Since SPSR, despite its name, does have one control bit.


• w/o <Extended SPI Control Register>:
  • reports status
• w/ <Extended SPI Control Register>:
  • changes configuration

Note

all settings can be done alone using the functions described below. Success is reported via its get mode and the get functions of the seperate properties.

Arguments

• <Extended SPI Control Register>
  • 0 ... 1FF

Comments

• See SPI spi_enable
• See SPI data order
• See SPI master
• See SPI clock polarity
• See SPI clock phase
• See SPI speed
• See SPI speed divider
• See SPI double speed

---

SPI spi_enable

Task

get/set spi configuration's bit SPI enable state: SPE

Format

• SPI spi_enable [<value>]

Response

RECV SPI spi_enable ==SPI enable state: SPE==


Description

"When the SPE bit is written to one, the SPI is enabled. This bit must be set to enable any SPI operation."
(from Manual: AT90CANxx)

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• -

---

SPI data_order

Task

get/set spi configuration's bit SPI Data Order: DORD

Format

• SPI data_order [<value>]

Response

RECV SPI data_order


Description

"When the DORD bit is written to one, the LSB of the data word is transmitted first. When the DORD bit is written to zero, the MSB of the data word is transmitted first. "
(from Manual: AT90CANxx)

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• Don't mix up with API's transmit_byte_order

---

SPI master

Task

get/set spi configuration's bit SPI Master/Slave Select: MSTR

Format

• SPI master [<value>]

Response

RECV SPI master


Description

"This bit selects Master SPI mode when written to one, and Slave SPI mode when written logic zero. If SS [the 'Chip Select Pin'] is configured as an input and is driven low while MSTR is set, MSTR will be cleared"
(from Manual: AT90CANxx)

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • (0,) 1, ≠0, ON, (OFF), TRUE, (FALSE)

Comments

• Slave mode not implemented

---

SPI clock_polarity

Task

get/set spi configuration's bit SPI Clock Polarity: CPOL

Format

• SPI clock_polarity [<value>]

Response

RECV SPI clock_polarity


Description

"When this bit is written to one, SCK is high when idle. When CPOL is written to zero, SCK is low when idle."
(from Manual: AT90CANxx)

• 
  

  CPOL	Leading Edge	Trailing Edge
  0	Rising	Falling
  1	Falling	Rising

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• -

---

SPI clock_phase

Task

get/set spi configuration's bit SPI Clock Phase: CPHA

Format

• SPI clock_phase [<value>]

Response

RECV SPI clock_phase


Description

"The settings of the Clock Phase bit (CPHA) determine if data is sampled on the leading (first) or trailing (last) edge of SCK."

CPHA	Leading Edge	Trailing Edge
0	Sample	Setup
1	Setup	Sample

(from Manual: AT90CANxx)

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• -

---

SPI speed

Task

get/set spi configuration's bits SPI Clock Rate Select 1/0: SPR1/0

Format

• SPI speed [<value>]

Response

RECV SPI speed


Description

"These two bits control the SCK rate of the device configured as a Master. SPR1 and SPR0 have no effect on the Slave. "
(from Manual: AT90CANxx)

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0 ... 3
  • 
    

    speed	double speed	clock rate: SCK frequency
    0	OFF	fclkIO/4
    1	OFF	fclkIO/16
    2	OFF	fclkIO/64
    3	OFF	fclkIO/128
    0	ON	fclkIO/2
    1	ON	fclkIO/8
    2	ON	fclkIO/32
    3	ON	fclkIO/64

Comments

• See SPI double speed

---

SPI speed_divider

Task

get/set spi configuration's Clock Rate Divider

Format

• SPI speed_divider [<value>]

Response

RECV SPI speed_divider


Description

Set the ratio between f_clkIO and SCK frequency

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 2, 4, 8, 0x10, 0x20, 0x40, 0x80

Comments

• See SPI speed
• See SPI double speed

---

SPI double_speed

Task

get/set spi configuration's bit SPI Double Speed Bit: SPI2X

Format

• SPI double_speed [<value>]

Response

RECV SPI double_speed


Description

"When this bit is written logic one the SPI speed (SCK Frequency) will be doubled when the SPI is in Master mode. This means that the minimum SCK period will be two CPU clock periods. When the SPI is configured as Slave, the SPI is only guaranteed to work at f_clkio/4 or lower."
(from Manual: AT90CANxx)

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• -

---

---

API Configuration

---

SPI transmit_byte_order

Task

get/set the transmit order the data bytes of the buffer are written to the devices

Format

• SPI transmit_byte_order [<value>]

Response

RECV SPI transmit_byte_order


Description

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1
    

    <value>	transmit byte order
    0	MSB, big endian, FIFO
    1	LSB, little endian, LIFO

Comments

• -

---

SPI transmit_report

Task

get status of / enable/disable additional transmission reports after sending the write buffer

Format

• SPI transmit_report [<value>]

Response

RECV SPI transmit_report


$ Description:

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• -

---

SPI auto_purge_write_buffer

Task

get status of / enable/disable automatic write buffer purge after sending its content

Format

• SPI auto_purge_write_buffer [<value>]

Response

RECV SPI auto_purge_write_buffer


$ Description:

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• -

---

SPI auto_purge_read_buffer

Task

get status of / enable/disable automatic read buffer purge before sending data

Format

• SPI auto_purge_read_buffer [<value>]

Response

RECV SPI auto_purge_read_buffer


$ Description:

• w/o argument: get value
• w/ argument: set value

Arguments

• <value>
  • 0, 1, ≠0, ON, OFF, TRUE, FALSE

Comments

• -

---

DAC

---

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)



edit

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
     • : 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.

---

---

RGRE

---

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)



edit

RGRE <Register>
<Register> : the register has to be written with hexadecimal value

---

Example command:
send: RGRE d8
receive: RECV RGRE d8 2

RGWR

---

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)



edit

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

I2C

---

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)



edit

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-

APFEL

---

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)



edit

General Operation

The APFEL command set allows to talk to (several instances of) the APFEL ASIC. It uses a subset of the the I/O-Ports of the ATMEL μController to facilitate the communication to the proprietary protocol (q.v.Decoder.pdf) of the asic, sending a 22bit sequence for command, value, and chipId. ( → Apfel protocol code sequences)
• Logically
  • Output:
    • CLK
      • quasi clock, only the level changes are important
    • DOUT
      • data out
    • Side Select
      • position
  • Input:
    • DIN
      • data in
  • GND
• Electrical:
  • 3.3 Volt
• Physically:
  • per default:
    • JDINOUT1/2, JADC
      • I/O ports:
        

        I/O port	A		C		F
        Connector	JDINOUT1		JDINOUT2		JADC
        pins	DIN1	1	DIN1	1	DIN1	1
        	DOUT1	2	DOUT1	2	DOUT1	2
        	CLK1	3	CLK1	3	CLK1	3
        	SS1	4	SS1	4	SS1	4
        	DIN2	5	DIN2	5	DIN2	5
        	DOUT2	6	DOUT2	6	DOUT2	6
        	CLK2	7	CLK2	7	CLK2	7
        	SS2	8	SS2	8	SS2	8

---

Version 0

In the run of development an intermediate short command set has been implemented which is not so well descriptive as its future successor

edit

Commands

task	command	individual arguments	common address arguments	comment
setDac	APFEL 9 <DAC value> <dac> <chipId> <pinSetId> <sideSelectId> <port> [<quiet>] answer (if not quiet): → readDac	<DAC value> [ 0 ... 0x3FF ] <DAC> [ 1 ... 4 ]	<chipId> [ 0 ... 7, 8 ... FE, FF] 0xFF: generic call to all available chip Ids <pinSetId> [ 1, 2 ] <sideSelectId> [ 0,1 ] <port> A,C,F <quiet> [0,1]	writes DAC channel
readDac	APFEL A <dac> <chipId> <pinSetId> <sideSelectId> <port> answers: RECV APFEL dac <port> <pinSetId> <sideSelectId> <chipId> <dac> <DAC value> ERRA APFEL dac <port> <pinSetId> <sideSelectId> <chipId> <dac> <DAC value> - read validity check failed, raw value:	<DAC> [ 1 ... 4 ]		reads single DAC channel
readAllDacs	APFEL A 0  <chipId> <pinSetId> <sideSelectId> <port> answers: RECV APFEL dac <port> <pinSetId> <sideSelectId> <chipId> 0 <DAC value1> <DAC value2> <DAC value3> <DAC value4> ERRA APFEL dac <port> <pinSetId> <sideSelectId> <chipId> <dac> <DAC value> - read validity check failed, raw value:			*Not Yet Available* reads all DAC channels of an ch
autocalib	APFEL B <chipId> <pinSetId> <sideSelectId> <port>		auto calibration
TP single	APFEL C <pulse height Pattern> <chipId> <pinSetId> <sideSelectId> <port>	<pulse height Pattern> [ 2...3FF ]	test pulse
TP reset	APFEL D <pulse height> <channel> <chipId> <pinSetId> <sideSelectId> <port>	<pulse height Pattern> [ 1 ... F ] <channel> [ 1, 2 ]	test pulse inkl. reset
TP trigger	APFEL 11 <on/off> <port> <pin> <trigger position>	<on/off> [ 0,1 ] <port> [ A,B,C,D,E,F,G ] <pin> [1...8] <trigger after set (1) or after reset (2)> [1,2]		<on/off> enables/disables <pin> on <port> to trigger right in the moment after a test pulse set or reset command sequence is sent
setAmpl	APFEL E <channel> <chipId> <pinSetId> <sideSelectId> <port>	<channel> [ 1, 2 ]	setAmplification to high
resetAmpl	APFEL F <channel> <chipId> <pinSetId> <sideSelectId> <port>	<channel> [ 1, 2 ]	resetAmplification to low
listId	APFEL 10 <all> <NChipIds> <pinSetId> <sideSelectId> <port>	<all flag> [ 1...FF ] <number of chip Ids> [ 1...FF ]	check <number of chip Ids> channels and list depending on the <all flag> all or only positive results
listId++	APFEL 20 <all> <NChipIds> <minChipId> <pinSetId> <sideSelectId> <port>	<all flag> [ 1...FF ] <number of chip Ids> [ 1...FF ] <min Chip Id> [ 1...FF ]	check <number of chip Ids> channels and list depending on the <all flag> all or only positive results

---

---

First Test Results (16 Jan 2015)

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)

edit

First Test Results from 16 Jan 2015

• programm uses inline functions.

  		typical	best measured	"preHadCon2 Timings" ~× 8000
  Clock Timing	T [µs]	44.8	24.8	400,000
  	f [kHz]	22.3	40.3	0.0027
  Function call overhead offset	[µs]	~330	~300
  Task Timings
  Task		typical	best measured
  set DAC	[ms]	2.4	1.4
  read DAC	[ms]	2.7	1.6
  AutoCalibration	[ms]	48.4	27
  AutoCalibration × 256 × 2	[s]	24.8	13.8
  TestPulseSequence	[ms]	2.3	1.4
  TestPulse	[ms]	4.7	2.7
  SetAmplitude	[ms]	2.3	1.3
  ResetAmplitude	[ms]	2.3	1.3

Original Notes

---

Logic Analyzer Results (14 Oct 2015)

Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)

edit

Logic Analyzer Results

Summary (10 Oct 2015)

		typical	"preHadCon2 Timings" ~× 104
Clock Timing	T [µs]	40	400,000
	f [kHz]	25 kHz	0.0027
Function call overhead offset	[µs]	~330
Task Timings
Task		typical
set DAC w/o readback	[ms]	2
read DAC	[ms]	2.3
set DAC w/ readback (estimate)	[ms]	4.3
AutoCalibration	[ms]	~155
AutoCalibration × 256 × 2 (estimate)	[s]	~80
TestPulseSequence	[ms]	2
complete TestPulse	[ms]	4
SetAmplitude	[ms]	2
ResetAmplitude	[ms]	2

---

Details (port A - 10 Oct 2015)

set DAC	APFEL 9 3FF 3 1 1 1 A 1	%FOREACH{"item" in="setDac_APFEL_9_3FF_3_1_1_1_A_1_2015-10-14.png"}% %NEXT{"item"}%
readDAC	APFEL A 3 1 1 1 A	%FOREACH{"item" in="readDac_APFEL_A_3_1_1_1_A_2015-10-14.png"}% %NEXT{"item"}%
autocalibration	APFEL B 1 1 1 A	%FOREACH{"item" in="autocalib_APFEL_B_1_1_1_A__2015-10-14.png"}% %NEXT{"item"}%
autocalibration (full)	APFEL B 1 1 1 A	%FOREACH{"item" in="autocalib_APFEL_B_1_1_1_A_(full)_2015-10-14.png"}% %NEXT{"item"}%
TP single	APFEL C 3 1 1 1 A	%FOREACH{"item" in="TP_single_APFEL_C_3_1_1_1_A_2015-10-14.png"}% %NEXT{"item"}%
TP reset ch1	APFEL D 9 1 1 1 1 A	%FOREACH{"item" in="TP_reset_APFEL_D_9_1_1_1_1_A_2015-10-14.png"}% %NEXT{"item"}%
TP reset ch2	APFEL D 9 2 1 1 1 A	%FOREACH{"item" in="TP_reset_APFEL_D_9_2_1_1_1_A_2015-10-14.png"}% %NEXT{"item"}%
TP reset ch1 incl. Trig, Pos 1	APFEL D 9 1 1 1 1 A	%FOREACH{"item" in="TP_reset_inkl_Trig_Pos_1_APFEL_D_9_1_1_1_1_A_2015-10-14.png"}% %NEXT{"item"}%
TP reset ch1 incl. Trig, Pos 2	APFEL D 9 1 1 1 1 A	%FOREACH{"item" in="TP_reset_inkl_Trig_Pos_2_APFEL_D_9_1_1_1_1_A_2015-10-14.png"}% %NEXT{"item"}%
set amplification	APFEL E 2 1 1 1 A	%FOREACH{"item" in="setAmplification_APFEL_E_2_1_1_1_A__2015-10-14.png"}% %NEXT{"item"}%
reset amplification	APFEL F 2 1 1 1 A	%FOREACH{"item" in="resetAmplification_APFEL_F_2_1_1_1_A_2015-10-14.png"}% %NEXT{"item"}%

Details (port F - 06 Nov 2015)

Trigger Level at 2.0V

set DAC	APFEL 9 3FF 3 1 1 1 F 1	%FOREACH{"item" in="setDac_APFEL_9_3FF_3_1_1_1_F_1_2015-11-06.png"}% %NEXT{"item"}%
readDAC	APFEL A 3 1 1 0 F	%FOREACH{"item" in="readDac_APFEL_A_3_1_1_0_F_2015-11-06.png"}% %NEXT{"item"}%
autocalibration	APFEL B 1 1 1 F	%FOREACH{"item" in="autocalib_APFEL_B_1_1_1_F_2015-11-06.png"}% %NEXT{"item"}%
TP single	APFEL C 3 1 1 0 F	%FOREACH{"item" in="TP_single_APFEL_C_3_1_1_0_F_2015-11-06.png"}% %NEXT{"item"}%
TP reset ch2	APFEL D 9 2 1 1 1 F	%FOREACH{"item" in="TP_reset_APFEL_D_9_2_1_1_1_F_2015-11-06.png"}% %NEXT{"item"}%
set amplification	APFEL E 2 1 1 0 F	%FOREACH{"item" in="setAmplification_APFEL_E_2_1_1_0_F_2015-11-06.png"}% %NEXT{"item"}%
reset amplification	APFEL F 2 1 1 1 F	%FOREACH{"item" in="resetAmplification_APFEL_F_2_1_1_1_F_2015-11-06.png"}% %NEXT{"item"}%

---

Version 1

not yet implemented, but you may have a look ...
Show ... (Expand all... Collapse all)Hide ... (Expand all... Collapse all)

edit

%FOREACH{"ADDRESS" in="<portLetter> <portIndex> <sideSelectionId> <chipId>"}% %FOREACH{"CMND" in="APFEL"}%

Overview

overall main command structure:
$CMND <command> $ADDRESS  [<Argument(s)>]

command	address			arguments		comment
				"channel"	value(s)
dac	<portLetter> A,C,F,	<pinSetId> [ 1, 2 ]	<sideSelectId> [ 1, 2 ]	<chipId> [ 0 ... 7, 8 ... FE, FF] 0xFF: generic call to all available chip Ids see command chipIdIgnoreMask for limiting the chipId range	<dacId> [ 1 ... 4 ] < 4, e.g. 0xA: all DACs get value vDAC1	[vDAC1[vDAC2[vDAC3[vDAC4]]]] [ 0 ... 0x3FF ]	read/writes up to 4 DAC channels (if set with sign, incr/decr relatively)
autoCalib						auto calibration of the DAC channels
testPulse				<channelId> [ 1 ... 2 ] < 4, e.g. 0xA: both channels	height1 [height2] [ 0 ... 0xF ]	initiate test pulse
ampl				<channelId> [ 1 ... 2 ] < 4, e.g. 0xA: both channels	[ amplification1 [amplification2] ] [ 0,1, H,L ] 0,L: low amplification (× 16) 1,H: high amplification (× 32)	get/set amplification mode
l/list						lists all addresses of available ids

---

%FOREACH{"command" in="dac"}% %FOREACH{"alternative" in="d"}%

$CMND $alternative/$command

Task

Format

• NOTE: setting <chipId> to 0xFF loops over all avaiable chip IDs
• read
  • single DAC at port/pos/chipId:
    $CMND $command $ADDRESS <dacId>
    
  • all 4 DACs at port/pos/chipId:
    $CMND $command $ADDRESS
    
  • all 4 DACs of all available chipIds at port/pos:
    $CMND $command <portId> <sideSelectId>
    
• write
  • single DAC at port/pos/chipIds:
    $CMND $command $ADDRESS <dacId ≤ 4 > <value>
    
  • all 4 DACs at port/pos/chipId with same value:
    $CMND $command $ADDRESS <dacId > 4> <value>
    
  • all 4 DACs at port/pos/chipId with individual values:
    $CMND $command $ADDRESS <(dummy)> <valueDAC1> <valueDAC2> <valueDAC3> <valueDAC4>
    

Response

• single dac channel access
  
  RECV $CMND $command $ADDRESS <dacId> <value>
• any other plots per found chip
  
  RECV $CMND $command $ADDRESS <dacId> <valueDAC1> <valueDAC2> <valueDAC3> <valueDAC4>

Description


read or write values from/to DAC channel(s) (if set with sign, incr/decr relatively)

Arguments

• <portId>
• <posId>
• <chipId>
• <dacId>
• <value>

Comments

• see cim/chipIdIgnoreMask

--- %NEXT{"alternative"}%%NEXT{"command"}%

%FOREACH{"command" in="autocalib"}% %FOREACH{"alternative" in="a"}%

$CMND $alternative/$command

Task

Format

Response

Description

Comments

--- %NEXT{"alternative"}%%NEXT{"command"}%

%FOREACH{"command" in="testPulse"}% %FOREACH{"alternative" in="t"}%

$CMND $alternative/$command

Task

Format

Response

Description

Comments

--- %NEXT{"alternative"}%%NEXT{"command"}%

%FOREACH{"command" in="ampl"}%

$CMND $command

Task

Format

Response

Description

Comments

--- %NEXT{"command"}%

%FOREACH{"command" in="list"}% %FOREACH{"alternative" in="l"}%

$CMND $alternative/$command

Task

Format

Response

Description

Comments

--- %NEXT{"alternative"}%%NEXT{"command"}%

---

%NEXT{"CMND"}% %NEXT{"ADDRESS"}%

---

---

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
• I²C / 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 ...

• hadcon-projects.7z

• hadcon-projects_4.3.7z: tar ball of all hadcon related projects, 4.3 actual release

Attachments 4Attachments 4

I	Attachment	Action	Size	Date	Who	Comment
pdf	SCHEMATIC1_PAGE1.pdf	manage	14 K	2010-03-12 - 11:33	PeterZumbruch	ADAN2 Measuring adapter
sh	avr-mem.sh	manage	5 K	2010-04-01 - 11:12	PeterZumbruch	avr-mem (original from http://www.mikrocontroller.net/topic/52953 http://www.mikrocontroller.net/attachment/18841/avr-mem.sh)
7z	hadcon-projects.7z	manage	19 MB	2011-07-13 - 17:46	PeterZumbruch	tar ball of all hadcon related projects, to be merged
7z	hadcon-projects_4.3.7z	manage	17 MB	2011-11-14 - 18:02	PeterZumbruch	tar ball of all hadcon related projects, 4.3 actual release

Edit  | Attach | Print version | History: r39 < r38 < r37 < r36 | Backlinks | View wiki text | Edit wiki text | More topic actions