Introduction to the System

Introduction

The bus coupling unit (BCU) is the standard bus interface for KNX/EIB bus devices. Due to its universal usage the BCU may contain the application program or just serves as a bus interface. Concerning the reconfiguration of the BCU, it can be programmed as well via the bus as via the PEI. The BCU 2 is more powerful than the BCU 1. It has more EEPROM, more RAM and a lot of additional features.

This help file is a detailed description of the BCU 2. The common characteristics of KNX/EIB are described in the KNX Specification which can be obtained from the Konnex Association, Brussels.

The BCU2 is available in several mechanical shapes (e.g. for flush mounting, surface mounting, etc.) as well as a module called BIM M113.

This is a short overview of the BCU 2 technical characteristics:

Feature

Description

CPU

MC68HC705BE12

Crystal frequency

4.9152 MHz

Operation frequency

2.4576 MHz

On chip EEPROM

available | 100h ... 4FFh | (1024)
single chip protected | 4E0h ... 4FFh | (32)
used by OS | 100h ... 115h 470h ... 4DFh | (22) (112)
available for user | 116h ... 46Fh | (858)

On chip RAM

available | 050h ... 0FFh 900h ... 9CFh | (176) (208)
available for user | 0BDh ... 0DFh 0C8h ... 0DFh 972h ... 9BBh | (35, BCU 2.1) (24, BCU 2.0) (74)

On chip ROM

available | 0020h ... 002Fh 0040h ... 004Fh 5000h ... 7FFFh | (16) (16) (12287)
used by OS | 0020h ... 002Fh 0040h ... 004Fh 5000h ... 7E7Fh 7FF0h .. 7FFFh | (16) (16) (11904) (16)

8 bit A/D converter

8 channels, 8 bit with multiplexed input

Programmable I/O controller (bitengine)

integrated subprocessor, programmed for communication with transceiver modules

8 bit PLM

available are PLMA/ PLMB, several clock rates

Coretimer

timer overflow, POR, RTI, selectable interrupt rates ...

Multiplexed Port C

Pins shared between timer, PWM, SCI, SPI, ADC. Multiplex handling over software

Serial asynchronous interface

standard NRZ format, 32 software selectable baud rates, selectable word length

Serial synchronous interface

Full duplex, master slave operation, programmable clock polarity/ phase ...

Watchdog

resolution min. 46.667 ms ... max. 53.33 ms

16 bit timer

free running counter, driven by operation frequency


Compatibility

The BCU 2 is upwards compatible to the BCU 1. Exceptions to this are the entry points of the system functions (API functions) and the features listed in the following table:

LM - Frequency

Two reasons for increased LM frequency in BCU2:
a.) the higher crystal frequency of the BCU2 (4.9 instead of 4.0 MHz),
b.) in HW of the BE12 µC is left one internal divider (/16).

It is not possible to use the slow frequency of BCU 1 style. In case of loaded application style (BCU 1/ BCU 2 style) the following rates are possible :

BCU2 | BCU1 application | BCU2 application
fast | 2400 Hz (instead of 1953 Hz) | 9600 Hz
slow | 2400 Hz (instead of 122 Hz) | 2400 Hz

The selection of these rates can be chosen in ConfigDes

U_Delay faster

The crystal frequency of BCU 2 is 4.9152 MHz. The ratio to a BCU 1 is 4.9152/4 = 1.2288. So the internal loops run with granularity 0.4166 ms instead of 0.5 ms. The system provides a correction for U_Delay (in steps of 0.5 ms):
Internal parameter = parameter + parameter div 4 (= parameter * 1.25)
(Note : obviously no correction if parameter < 4)

PortD not at PEI

PortD connection is selectable by the CPU/ Bitengine, in system BCU 2 it is directly connected to the programming button/ LED

Checksum only tested at start-up

BCU 2 style
After loading some code/ date into the BCU 2 a CRC is established (if you want one, see Segment Control Records). On every start-up of BCU 2 the CRC will be calculated again and compared with the CRC located in secured EEPROM block. Take care of changing EEPROM bytes in secured blocks of EEPROM during normal operation (User), after a reset the corresponding "load state" machine has the state ERROR.

BCU 1 style
After bus/ PEI access to EEPROM (e.g. memory write/ PC_SetValue) the CRC - located on 1FFh - is automatically updated, in application the user himself must update the CRC by calling the corresponding API function.

Remark: in BCU 1 on every 256 scheduler cycle the CRC is controlled on validity.

Confirm error
(bit 6 in RunError)

BCU 2
This bit indicates that not all system default MCB's found in the active MCB EEPROM locations.

BCU 1
If there is a T_GROUP_DATA.conf in the message queue, but the communication object is not in state "TRANSMITTING" then confirm error in run error flags will be set (user stopped).

Maximum of 127 addresses

The address table is required to be sorted in ascending order. The internal search algorithm does not allow more than 127 entries.
If more than 127 entries are downloaded into the address table the corresponding load state machine switches to ERROR (on event load complete).

Maximum of 127 association The BCU2 supports up to 128 associations. In principle the association table would allow more than that, but any association above this limit is unable to receive messages.

Address table must be loaded for sending any group telegram

All GROUP_DATA_REQUEST are inhibited if the "load state" machine of address table isn’t on state LOADED. In this case a negative confirmation goes internal back to requester.

Write 00h to 10Dh
(error flags) needs delay of 1 second

An internal reconfiguration of BCU can be started with following subjects :

  • Clear EEPROM

  • Reload the system default MCB’s

  • Reload the system default passwords

It takes "some" time, therefore wait for approx. 1 sec. with next operation

Access protection

Only allocated memory is accessible, so it is not possible to access every memory location as in a BCU 1 system. The memory access depends on the allocated memory control blocks (MCB's) and its access level.

If you get a BCU 2 in state "virgin" (after you bought one) there are system default MCB's established, the same state is reached if you use the "master reset"

Write FFh to 10Dh
(error flags) needs restart the application

application in BCU 2 style

Nothing happened ...

application in BCU 1 style

This happens normally after a download of BCU 1 style application into an BCU 2. Following operations will be done internally after the write:

  1. Set EIB_Obj_Ptr/ Count = 0 (not available in BCU 1 style).

  2. Get the loaded 8 bit CommsTabPtr, AssocTabPtr, UsrPrgPtr, UsrInitPtr, UsrSavPtr addresses and write them into the internal 16 bit BCU 2 start addresses.

Start-up time for application (after power-up)

The time is calculated by the following equation :

application start = 1.706 sec + NOT (device address(low)) div 2 * 10 ms

1.706sec is the power-up time of BCU1.

address low | start-up time after reset | remark
00h | 2.986 sec | address table must be loaded
FFh | 1.706 sec | address table must be loaded

Background :
On power-up all devices start their application at the same time. Thus all devices might want to access the bus simultaneously, which is avoided by the pseudo-random delay. In order to be minimum for the default address FFFFh the start-up time is calculated with the operator NOT for the low byte of the address.

Telegram rate limitation

BCU 1 / BCU 2.0
in the first 17 seconds no telegram is send on the bus (in these implementation the counter is set only if the first "17 second block" is over).

BCU 2.1
the limitation is enabled in the first 17 seconds.

Start-up mode
(application behavior on pressing program button)

BCU 1 behaviour
as long as the button is pressed the application does not start.

BCU 2 behaviour
by pressing the button for a short time the application does not start, also if you release the button (it means: a short pressure on start-up is sufficient).

Conditions : application must be "loaded" (see load state machine).

Using the BCU 2 as compatible device for BCU 1 means using the old load procedure (see description of BCU 1). In this case it is possible to use the extended EEPROM starting with 200h and the High RAM for the user application. It is also possible to use the new API 2 functions except the loadable PEI-Driver and the replaceable application callback. The mask version of the BCU 2 is 20h/21h, the mask type is 00h for BCU (20h/21h).

Never use any undocumented feature of the BCU, because an application software may not run on a future version of the BCU.

Never write complete bytes on PORT C of the BCU (sta/stx PORTC), because part of PORT C is used for bus communication.


Language support

The user interface of the operating system of the BCU2 is defined on Assembler level. In principle would be possible to implement any language support for any cross assembler and any cross compiler. Using the EIB-IDE and the contained templates and project generation the following IAR products are supported:

Micro Series 6805 Assembler | © Copyright IAR Systems 1985
Micro Series Universal Linker | © Copyright IAR Systems 1987 - 1999

The only supported programming language is Assembler. Note that EIB-IDE adjusts some environment settings for better support of IAR products. Please see the EIB-IDE documentation for the supported versions of the IAR assembler and linker. Usage of other versions than the supported ones is not recommended.

Segment definitions: |
EEPRM | system EEPROM
ZDATA | low ram
HDATA | high ram
ADRTAB | addresstable
ASSOCTAB | associationtable
EEDATA | parameter
CODE | usercode

Example for segment definition (used from standard project of EIB-IDE) which is located in the project assigned mak file (<Project>.mak). The following conversion/ handling of these directives is described in one example to load control.

SEGMENTS =
-Z(CODE)PTR=0\
-Z(CODE)EEPRM=100\
-Z(CODE)PTR1=5000\
-Z(DATA)ZDATA=00BD(C8)-00DF\ (BCU 2.1/ BCU 2.0, only for explanation, use one possibility)
-Z(DATA)ZEDATA=00E0\
-Z(DATA)HDATA=0972-9BB\
-Z(DATA)HEDATA=09BC\
-Z(CODE)ADRTAB,ASSOCTAB,EEDATA,CODE=0116-046f\
-Z(CODE)ECODE=0470


About

Copyright

© Siemens AG September 2005 V1.2

Remark

The data contained herein are subject to change without notice. Siemens does not warrant for correctness or completeness of the documentation or that the products described are qualified for certification.

License

This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Germany License (Creative Commons Namensnennung-NichtKommerziell-Keine Bearbeitung 2.0 Deutschland). To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/2.0/de/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

Creative Commons Namensnennung-NichtKommerziell-Keine Bearbeitung 2.0 Deutschland Lizenzvertrag


Memory Map of the BCU 2

Memory Overview

Address

Segment names

I/O space and system ROM | $0000 $004F |
Low RAM 176 bytes | $0050 $00FF | ZDATA (BDh,C8h - DFh)
EEPROM 992 bytes | $0100 $04DF | EEPROM (100h -115h) ADRTAB (116h - .....) ASSOCTAB EEDATA CODE
EEPROM (single chip protected ) 32 bytes | $04E0 $04FF |
High RAM 208 bytes | $0900 $09D0 | HEDATA (972h - 9BBh)
System ROM | $5000 $7FFF |


Low RAM

Low RAM (BCU 2.0)

address | name | length | comment
$0050-$005C | Reg B..N | 13 | registers reserved for the internal application (i.e. user program)
$005D-$005F | iReg B..D | 3 | registers reserved for the internal application (i.e. user program) in interrupt mode only
$0060 | SystemState | 1 | reserved for API 1
$0061-$00C3 | system | 99 | reserved for system software
$00C4 | PEI_Interface | 1 | reserved for serial protocol
$00C5 | PEI_Info | 1 | reserved for serial protocol
$00C6-$00C7 | system | 2 | reserved for system software
$00C8-$00CD | PEI_Buff | 6 | reserved for serial protocol on PEI type 10 (FT 1.2) , 12, 16 | Segment: ZDATA ($C8-$DF)
$00CE-$00DF | user RAM | 18 | internal user application data (group objects, marker ...)
$00E0-$00FF | stack | 32 | system software/ stack, E0h stack overflow marker, on start-up set to "0"

Low RAM (BCU 2.1)

address | name | length | comment
$0050-$005C | Reg B..N | 13 | RAM: registers reserved for the internal application (i.e. user program)
$005D-$005F | iReg B..D | 3 | RAM: registers reserved for the internal application (i.e. user program) in Interrupt-Mode only
$0060 | SystemState | 1 | reserved for API 1
$0061-$00BC | system | 90 | reserved for system software
$00BD-$00C3 | PEI_Buff | 7 | reserved for serial protocol on PEI type 10 (FT 1.2), 12, 16
$00C4 | PEI_Interface | 1 | reserved for serial protocol only if it is used
$00C5 | PEI_Info | 1 | reserved for serial protocol only if it is used
$00C6-$00DF | user RAM | 26 | internal user application data (group objects, marker ...) | Segment: ZDATA ($BD-$DF)
$00E0-$00FF | stack | 32 | system software/ stack, E0h stack overflow marker, on startup set to "0"


High RAM

High RAM (BCU 2.0/ 2.1)

Memory Address | Name | Length | Comment | Segment
$0900-$0971 | MS_Buffer | 114 | reserved for message system |
$0972-$0989 | user RAM2 | 24 | internal user application data (group objects, marker ...) | HIGHRAM
$098A-$09A2 | PEI_RecBuf | 25 | reserved for serial protocol / user
$09A3-$09BB | PEI_SndBuf | 25 | reserved for serial protocol / user


EEPROM

Address | Name | Length | Comment | Segment
$0100 | OptionReg | 1 | - | EEPROM
$0101-$0102 | ManData | 2 | manufacturer code
$0103-$0107 | Application ID | 5 | accessible via SegmentControlRecord
$0108 | CheckLim | 1 | -
$0109 | PEI_Type | 1 | accessible via SegmentControlRecord
$010A | SyncRate | 1 | SPI baud rate on PEI type12/ 14
$010B | PortCDDR | 1 | PORTC data direct. on PEI type 10/ 17
$010C | PortADDR | 1 | PORTA data direct. (checked by ETS!)
$010D | RunError | 1 | firmware run time error flags
$010E | RouteCnt | 1 | routing count constant
$010F | MxRstCnt | 1 | INAK retransmitting limit, BUSY retransmitting limit
$0110 | ConfigDes | 1 | configuration descriptor
$0111 | AssocTabPtr | 1 | used only on BCU 1 style applications
$0112 | CommsTabPtr | 1 | used only on BCU 1 style applications
$0113 | UsrInitPtr | 1 | -
$0114 | UsrPrgPtr | 1 | -
$0115 | UsrSavPtr | 1 | -
$0116-$046F | UsrEEPROM | 858 | User EEPROM start with address table | Segment ADRTAB ASSOCTAB EEDATA CODE
$0470-$04DF | System | 112 | reserved for system (MCB section, pointer ...)


System ROM

Memory Address | Name | Length | Comment
$5000-$7E7F | System ROM | 11904 | reserved for system software
$7E80-$7FDF | Bootloader ROM | 352 | reserved for system software
$7FE0-$7FEF | Bootloader vectors | 16 | reserved for system software
$7FF0-$7FFF | System ROM vectors | 16 | reserved for system software


I/O-Space and System ROM

memory address | name | length | comment
$0000-$001F | I/O-space 1 | 32 | I/O registers Be careful by us ing this memory with direct access.
$0020-$002F | page 0 ROM | 16 | $0020 OR_TAB | 0000 0001 0000 0010 0000 0100 0000 1000 0001 0000 0010 0000 0100 0000 1000 0000
 |  |  | $0028 AND_TAB | 1111 1110 1111 1101 1111 1011 1111 0111 1110 1111 1101 1111 1011 1111 0111 1111
$0030-$003F | I/O space 2 | 16 | I/O registers Be careful by us ing this memory with direct access.
$0040-$004F | page 0 ROM | 16 | reserved for system software
 |  |  | $004E masktype $004F maskversion |  | ($00 = TP-BCU) ($20/$21 = 2.0/2.1)


Single chip protected EEPROM

Memory Address | Name | Length | Comment
$04E0-$04FF | protected EEPROM | 32 | reserved for system software


SystemState

Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0
PARITY | DM | UE | SE | ALE | TLE | LLM | PROG

PROG

bit set means BCU is in programming mode
bit clr means BCU is in normal operation mode

LLM

bit set means BCU is in normal operation mode
bit clr means BCU is in busmonitor mode

TLE

bit set means BCU transport layer is active
bit clr means BCU transportlayer is not active

ALE

bit set means BCU application layer is active
bit clr means BCU application layer is not active

SE

bit set means BCU serial interface is enabled on PEI type 10,12,16
bit clr means BCU no serial interface is used (exception PEI type 14)

UE

bit set means user is running
bit clr means user is not running

DM

bit set means BCU is in download mode. Download mode is entered

  1. after forced master reset the system remains in download mode, until PEI type 20 is removed.

  2. by setting this bit via MemoryWrite as a temporary state (until reset finished, ca. 46ms)

bit clr means BCU is in normal operation mode.

Note: download mode has nothing to do with a bus download to the BCU, the naming has purely historical reasons.

PARITY

even parity for bit 0 ..6

SystemState has the following values in the following states:

Behaviour | Value | Remark
after reset (PEI type: no serial) | 8Eh | LL, TL, AL enabled, user dependent on the entry conditions
after reset (PEI type: serial) | 1Eh | LL, TL, AL enabled, user dependent on the entry conditions
after master reset | 5Fh | PROG, LL, TL, AL, SE, DM enabled

To activate a layer/ reset the system its necessary to write the following values into system state.

Mode

Value

actions after write to system state

Busmonitor
(internal message len = 29)

90h

- SE always enabled

- switch NL to PM
(corresponding to Link Layer Busmonitor, except user)

Link-Layer
(internal message len = 26)

12h

- SE always enabled

- set redirection to Normal mode (preselection)

- if TLE not enabled :
switch NL to PM
(corresponding to Link Layer, except user)

- if ALE not enabled :
switch LC to TC, AL to PM, MG to PM
(corresponding to Transport Layer Remote, except user)

Transport-Layer
(internal message len = 26)

96h

Application-Layer
(internal message len = 26)

1Eh

Reset

C0h

- set DM bit in system state (until reset finished)
- system resets immediatly

In Link Layer Busmonitor mode the reset occurs because on C0h in system state the DM bit is set (means serial PEI type) but the serial interface (SE) is not active too. The mode for LLB can be reached by

  • PEI_Switch (PEI type 10, EMI 2)

  • PC_Set_Value, (PEI type 12/16, EMI 1)

In all other modes the reset occurs only if the DM bit is set after write to SystemState.


CheckLim

This byte defines the area of EEPROM which is secured by the checksum. The feature is only active if a BCU 1.x application is downloaded into a BCU 2 target device. In this case variables located in EEPROM, whose value changes during runtime (e.g. a comm. object value), must be outside the check range.

Check range | 108 to (100h + CheckLim - 1) except 10Dh (RunError)
Allowed values | 09H to FFh


PortCDDR

This byte contains the direction bit setting for the Port C

0 | input
1 | output

This value is used only on PEI type 17/ 10. The conditions to activate these settings for PORTC are :

Runcontrol of application | running/ ready
LoadState of application | loaded

In order to reduce possible EMC influences the BCU2 system copies this setting to the HC05 DDRC Register on each scheduler cycle. After a possible direct changing of DDRC (RAM register of HC05) by the user application the direction will be reset to the value of PortCDDR in the next scheduler cycle (dependent on the PEI type).


PortADDR

This byte contains the direction bit setting for PORT A.

0 | input (setting for whole Port A on system start-up)
1 | output

The BCU2.1 system copies this setting to the HC05 DDRA Register on App Init call and on each App Main call. This is different to an BCU 2.0, there PortADDR is set only on application main call.


RunError

In this set of flags, runtime errors are stored for error analysis purposes. The flags are only set by the system. They must be cleared explicitly by some management tool.

A flag is set if the corresponding bit = 0 ( bit =1 means no error).

Bit# | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | must be 1 | SYS3_ERR | SYS2_ERR | OBJ_ERR | STK_OVL | EEPROM_ERR | SYS1_ERR | SYS0_ERR

Name | Description | Behavior of BCU | Hint
SYS0_ERR | internal system error (msg buffer offset corrupt) | forces a complete system reset, application will be restarted (user init, usr main call) | error occurs when any msg buffer offset (parameter for system routines) has no legal value
SYS1_ERR | internal system error (parity bit in SystemState is corrupt) | forces a complete system reset, application will be restarted (user init, usr main call) | in each scheduler cycle the validity of system state is checked
EEPROM_ERR | EEPROM check detected an CRC error | application runstate is set to halted (user stopped) application load state is set to error | CRC on Start-up
STK_OVL | stack overflow was detected | forces a complete system reset, application will be restarted (user init, user main call) | stack depth over the maximum (RAM)
OBJ_ERR | RAM flag table error (*PTR not in ZPAGE range) | application runstate is set to halted (user stopped, bit UE in SystemState will be reset) |
SYS2_ERR | internal system error (stuck/ overheat detection) | post internally neg. confirm (if system transmitting), user will be not stopped, cut system from bus traffic (released only over reset) | Physical Layer
SYS3_ERR | internal system error (not for each default MCB [ROM] an MCB [EEPROM] exists with the same start address) | MCB chain corrupt, user will not be stopped | The BCU2 system checks (once on startup) whether for each default MCB an MCB in EEPROM exists with the same start address.


User Entry Pointers

System BCU 2.x consists of 1 kByte EEPROM. The three pointer locations from BCU1

113h | 1 byte | UsrInitPtr (telegram rate limitation)
114h | 1 byte | UsrPrgPtr (*ptr to user timer description)
115h | 1 byte | UsrSavPtr

contain only the low byte of the pointers and cannot address the whole EEPROM. When a BCU1 application is loaded, the system copies the completed 16 bit pointers to the system pointer locations (above 46Fh). When a BCU2 application is loaded, the 16 bit pointers are loaded to the system via load control records. The system decides dependent on the contents of 115h on whether a BCU1 application or a BCU2 application is loaded (see below).

This means :

  • system BCU 2.x does not use the pointers at 113h, 114h, 115h directly for starting any routines (neither with a BCU1 nor a BCU2 application), but the 16 bit pointers stored in the system EEPROM.

  • the pointer at 113h is only used for a possible telegram rate limitation (parameter stored at AppInit-1)

If telegram rate limitation is used in a BCU2 application, the problem exists that the low byte of the UsrInitPtr is not loaded to 113h by the download procedure. Therefore in the application program you must use macro %OldUsrInit with parameter <#.low.AppInit>. This macro stores the low (8 bit) part of AppInit *PTR to 113h. Note also that in this case the UsrInit routine must start between 100h and 1FFh.

  • the pointer at 114h is only used for a possible user timer description block (parameter stored at AppMain-1)

If timer description block is used in a BCU2 application, the problem exists that the low byte of the UsrPrgPtr is not loaded to 114h by the download procedure. Therefore in the application program you must use macro %OldUsrPrg with parameter <#.low.AppMain>. This macro stores the low (8 bit) part of AppMain *PTR to 114h. Note also that the main routine must start between 100h and 1FFh.

  • the pointer at 115h is used for distinction between a BCU 1.x and a BCU 2.x application

if = 0 system assumes that a BCU 2 application is loaded
if <> 0 system assumes that a BCU 1 application is loaded


ManData

101h/ 102h | BCU hardware manufacturer ID | ETS reads the manufacturer ID via property 12 of the device object and only over this mechanism these data must be read (valid for ETS 2 version 1.1.b an later). If you are using earlier versions of ETS take care that the data at 104h match to the data at 102h because the versions of ETS read (depending on the application [BCU1/ BCU 2]) address 104h or the property. | The codes for manufactures are distributed by EIBA / Konnex Association.
103h/ 104h | internal application software manufacturer ID | readable via the property 13 of application object |
105h/ 106h | internal application software device type
107h | internal application software version


System Architecture Overview


Scheduler

The following tasks are cyclically called by the scheduler:

  • All communication tasks (LL, NL, TL,TC,LC, AL, MG, PM)

  • Check internal system parameters (stack, system state parity)
  • Check entry conditions for user application


User

The user has to take care of the condition on power on (startup) for the application start.
(see Initialization Mode and User Save Mode )

According to the dynamic behavior of whole system on runtime - e.g. asynchroneous system int occurs ...- the stack depth inside the user (API / own defined subroutine call's) should not cross 4 levels.

The has to take care that the clearing of user RAM (Hi/ Lo) / RegB-RegN occurs just if one of the three user modes is active:

  • Init

  • Main
  • Save

Entry conditions for application init

Actions

  • Loadctrl is loaded

  • Requested PEI type = physical PEI type
  • No EEPROM/ OBJECT error (error flags)
  • Runctrl is ready

- Call user application init routine

Entry conditions for application main

Actions

  • Loadctrl is loaded

  • Requested PEI type = physical PEI type
  • No EEPROM/ OBJECT error (errorflags)
  • Runctrl is running

Call user application main routine
(time to stay maximum inside ~ 10 ms)

Entry conditions application save

Actions

  • Save signal is set

  • User is running (check UE bit in system state)

Call user save routine
(at the end force reset)


Application Layer

The Application layer (layer-7) provides a large variety of application services for the application process. Application processes in different EIB end devices interoperate by using services access points (SAPs) of layer-7 over communication relationships.

The BCU 2 application layer uses only the one-to-many connectionless (multicast) communication relationship. The one-to-all connectionless (broadcast), one-to-one connectionless and the one-to-one connectionoriented communication relationships are handled by the management part.

Interactivity of the Application Layer


Transport Layer

The transport layer (layer-4) provides a reliable data transmission over communication relationships. Communication relationships are logical channels that connect users of layer-4 with eachother. Layer-4 provides four different types of communication relationships:

  • one-to-many connection-less (multicast, group communication)

  • one-to-all connection-less (broadcast)
  • one-to-one connection-less
  • one-to-one connection-oriented

Communication relationships are identified by a local communication relationship identifier (cr_id) which should be unique for all communication relationships of this EIB end device. The layer4 converts the cr_id into the destination_address and vice versa by using the addresstable. Every communication relationship type provides specific layer-4 services. The transport layer of the BCU2 is divided in two parts, one part for the group communication and one part for broadcast and peer to peer communication.

interactivity of the Data Transport Layer

communication type | service | remark
multicast communication | T_Groupdata (UDT) | - group object handling - logical connection from one to many EIB end devices
1:1 connectionless communication | T_DevData (UDT) | - handling between two devices without connection establishment - don't used during a connection to the same device is activ
1:1 connectionoriented communication | T_Connect (UCD) T_Data (NDT) T_Disconnect (UCD) | - sequenznumber handling - timeout handling - behavior according EIB handbook
broadcast communication | T_Broadcast (UDT) | - logical connection from one to all EIB end devices

Name | TPCI Codings
UDT (unnumbered data) | 00xxxxxxb
NDT (numbered data) | 01xxxxxxb
UCD (unnumbered control) | 10xxxxxxb
NCD (numbered control) (TACK/ TNACK) | 11xxxxxxb


Network Layer

The network layer (also called "layer-3") is the layer between the data link layer and the network layer user (transport layer). The EIB network layer conforms to the definitions of the ISO/OSI model (ISO 7498) network layer. The message flow inside the layer is shown below. The L_Busmon indication is not provided because this service is active (and necessary) only in busmonitor mode. In this mode LL services will post directly to the PEI.

Interactivity of the Network Layer


Link Layer

The data link layer (also called "layer-2") is the layer between the data link layer user (network layer) and the physical layer. The EIB/KNX data link layer conforms to the definitions of the ISO/OSI model (ISO 7498) data link layer. It provides the medium access control and the logical link control.

The data link layer is using the services of the physical layer and provides services to the data link layer user. The logical link control examines the frame format and destination address of a frame and decides whether the frame should be received or not. The data link layer detects transmission errors and repeated frames. Individual octets coming from the physical layer are put together to a link service data unit (LSDU). LSDUs that have to be transmitted to a destination are delivered to the physical layer with individual octets.

Interactivity of the Data Link Layer

Remarks for Link Layer

- handles reliable data transmission between end devices
- handles the repetition behavior (repetitions can be influenced by the application, see %mxRstCnt )
- receiving, repetition and most parts of sending are fully interrupt driven (different to an BCU 1 system)
and so the system (include the application) runs between receiving/ transmitting of telegrams too
- link layer is initialized after at least 10 bit times of logical one (no pulse) else stay in endless loop
(possible stuck at startup)

Coding | Code | Remark | Prio
INACK | 0Ch | collision detection is active INACK overwrites IACK | Prio 2
IACK | CCh | collision detection is active | Prio 3
BUSY | C0h | collision detection is active BUSY overwrites INACK | Prio 1
? | 00h | BUSY/ INACK without collision detection (one device is BCU 1 ) | -

BUSY generation on:

  1. No free buffer from message system available (it happens after any address mode fit to the device)

  2. EEPROM write operation is running (it happens before computing of any address mode, frame is destroyed internally)

INACK generation on:
(it happens after any address mode fit to the device)

  1. CRC error

  2. data bit invalid (sampling has failed, not enough "good" samples)
  3. parity error
  4. stop bit error

The maximum number of repetitions of one frame on the bus is 5 (if BUSY/ INACK counter is set to 3, see above ). Combinations are possible. During one "transmission sequence" the counter's will be not reseted.

Sending BCU | Responding BCU | Remark
original frame | nothing |
1. repetition | INACK | INACK or nothing is handled in same way (INACK counter decremented)
2. repetition | INACK |
3. repetition | BUSY | here no INACK possible because sending BCU would stopped after this
4. repetition | BUSY |
5. repetition | BUSY |

Wait times after frame | Description
nothing occurs (forces repetitions) | at least 50 bit times, range [50 ..53] (solved over physical layer)
INACK | at least 50 bit times, range [50 ..53] (solved over physical layer)
BUSY | ~ 150 bit times (solved over system timer)
00h (?) | ~ 150 bit times (solved over system timer), same as BUSY

Wait times depend on frame priority * | Description
10R10000 (system) | at least 50 bit times, range [50 < t < = 53]
10R11000 (alarm) | at least 50 bit times, range [50 < t <= 53]
10R10100 (high) | at least 53 bit times
10R11100 (low) | at least 53 bit times

* These are not "hard" conditions, on the border limits there is an overlapping [in range of µs] possible.


Physical Layer

The physical layer (also called "layer-1") is the layer between the physical layer user (link layer) and the medium (here TP [twisted pair]). The KNX/EIB TP1 physical layer conforms to the definitions of the ISO/OSI model (ISO 7498) physical layer. It consists of the following components:

  • The logical unit of the physical layer consisting itself of a medium-dependent and a medium independent sublayer

  • The medium attachment unit (MAU)
  • The medium interface (i.e. the connector)
  • The medium
  • Optionally: a separate power supply to the medium, for non-self-powered devices.

The physical layer of BCU 2 is handled by an internal subprocessor (bitengine) which is independent from the HC05 Motorola kernel. The bitengine consists of two independent (really parallel) tasks (receiver/ transmitter) which are synchronised by software. Receiver and transmitter are active and sensitive at the same time. The interface between these subprocessor and the HC05 is handled by data/ interrupt registers. Receiving has a higher priority than transmitting.

Transmitter | - pulse forming
 | - pause/ gap time handling
Receiver | - pulse sampling
 | - collision/ short circuit detection send 0 : receive 0 -> valid send 0 : receive 1 -> error (short circuit on bus, set SYS2_ERR) send 1 : receive 1 -> valid send 1 : receive 0 -> error (collision)
 | - detection/ generation of EIB specific signals (EOP, SBSF...)
start bit sampling | - machine state IDLE -> detect bit -> do sampling initialization (10*k) -> sample start bit -> machine state RCV DATA
data bit sampling | - machine state RCV DATA ->detect bit -> sample data bits (after any data byte gap of 2 ..2.5 bit times expected) - on gap > 2.5 bit times -> machine state IDLE (end of frame)-> give EOP to link layer

The principal method of standard frame handling is given here.
The principal method of polling frame handling is given here.

Here are some hints for explanation of the below pictures:

  1. k= 813.8020833 ns

  2. the logical "0" is the dominant bit (compared to logical "1")
  3. logical "0" will be detect over whole scan-window k= 2 .. 69 (11..26 for startbit)
  4. logical "1" will be detect only in scan-window k= 33 .. 69
  5. error on startbit forces no error "message" to link layer (possible INACK generation ...)
  6. test on valid means :

    • start bit must consist of at least 5 "good" samples and they must be equal to one

    • second sample window must consist of at least 5 "good" samples and they must be equal to zero
    • data bits must consist of at least 9 "good" samples (could be equal to one/ zero)


TRM normal FRM

Transmission of Standard Frame

Arbitration active

  • physical layer scan short (~ 5 µs) before own transmission if another device was earlier on bus and prevent in this case the own transmission

Arbitration not active

  • physical layer ignores any bus activities and forces possible overwriting of data bytes on IACK/ Polling (necessary for example on overwriting of earlier IACK on bus with BUSY, 15 bit timing jitter)

Soonbusfree

  • physical layer forces a soonbusfree (SBSF) interrupt to the link layer

after ACK occurs

OK

transmission successful (except INACK/ BUSY)

before expected ACK

ERROR

target device not responding


TRM Polling FRM

Transmission of Polling Frame

Arbitration active

  • physical layer scan short (~ 5 µs) before own transmission if another device was earlier on bus and prevent in this case the own transmission

Arbitration not active

  • physical layer ignores any bus activities and forces possible ovwerwriting of data bytes on IACK/ Polling (nessesary for example on overwriting of earlier IACK on bus with BUSY, 15 bit timing jitter)


Modes of operation

The BCU 2 has some special operation modes which are set by the system software. Before a mode is reached few hardware settings/ system settings must be made (important for application behaviour of possible external hardware, etc.):

  • Set DDRA to input

  • Wait until no interrupt occurs (for example endless "save" interrupt before system runs stable)
  • Reset stack pointer to FFh
  • Set DDRB to output, clear PORTB
  • Clear PLMA/ PLMB
  • Switch on AC/ DC converter
  • Clear complete HIGHRAM/ ZDATA (except stack)
  • Enable watchdog
  • ...

After a reset the BCU is in normal operation mode. The special modes can be reached by various operations during startup or during normal operation.

  • Initialisation mode with PEI type 20 (Master Reset)

  • Busmonitor mode

  • User save mode

  • Normal operation mode


Normal operation mode

Entry Conditions

Actions

No initialisation mode with PEI type 20
No user save mode
No busmonitor mode

  • Wait until save signal is released

  • Initialise hardware
  • Initialise system software
  • Wait until bus is free
  • Wait for startup
  • Check checksums
  • Start scheduler


User Save Mode

Entry Conditions

Actions

Push-button is pressed during bus power-up

  • User run state machine is set to halted

  • User does not start (Appinit, Appmain, Appsave)


Busmonitor mode

Entry Conditions

Actions

Via the PEI_Switch service
writing to SystemState

  • All messages from link layer are directly sent to the PEI

  • The BCU is completely inactive on the bus
  • Every ACK, NACK, BUSY generates a message to the PEI

Error flags on busmonitor service

bit 7 frame error (stop bit error)
bit 6 data bit error
bit 5 parity bit error
bit 4 not defined
bit 3 message lost
bit 2 | "
bit 1 | telegram count (mod 8)
bit 0 | "


Initialization Mode with PEI type 20

Initialisation Mode with PEI type 20 (Master Reset)

Entry conditions

Actions

PEI-Type 20 is detected, programming button is pressed and bus is powered

  • Physical address is set to FFFFh

  • Address table length is set to 1
  • Option register is set to FFh.
  • All load state machines are set to UNLOADED
  • The memory from 470h ... 4xxh is cleared
  • The pointer to serial protocol is set to 0000h
  • The EIB-Objectpointer is set to 0000h
  • The EIB-Objectcount is set to 00h
  • All keys are set to FFFFFFFFh
  • establish system MCBs (including generation of CRC)

HINT: The polling address/ slot number for slave mode is not removed.


Message System

The BCU 2 message system is more complex than in BCU 1. It consists of a redirection table which is able to distribute different services to the assigned message queues in the BCU 2. Besides the message system is able to convert EMI 1 services into EMI 2 and vice versa.

Parts of the message system

  • Message queue (anchors for the different layers)

  • each task has its own message queue

Common rule for posting messages to USR or PEI:

  • bit UE in SystemState means USR running/ not running
    (can be read also via the property PID_RUN_STATE_CONTROL in application interface object)
  • bit SE in system state means PEI active/ not active

USR

PEI

not running

running

not running (not active) all messages will be released messages for PEI will be released,
messages for USR will be posted to USR, behaviour for messages depends on
  • %RouteCnt (U_delMsg, if set all messages to the user will be released)
  • internal application (process/ frees different message types for USR by application programmer)
running (active) messages for USR will be posted to PEI and sent via the serial interface to the external controller messages for PEI will be posted to PEI,
messages for USR will be posted to USR,
behavior for USR messages depend on
  • %RouteCnt (U_delMsg, if set all messages to the user will be released)
  • internal application (process/ frees different message types for USR by application programmer)

Special rule for post messages from PEI

incoming message code (4xh)
(TASK_TC_ID)

convert service code
4xh to 5xh

outgoing message code (5xh)
 (TASK_LC_ID)

  • All messages will be posted if dedicated bit for layer in ServiceControl is enabled
    (exception : PEI_Switch, PC_Set_Value/ PC_Get_Value)
  • The PEI Switch service allows the user to switch to a specific layer.

  • Redirection table (service code conversion)

Step 1 : convert the incoming services to the dedicated message queue ID dependent on the table entries
Step 2 : switch the result of Step 1 over possible installed PEI switch settings

incoming frame »

redirection table

» outgoing queue ID »

switch table

» real target queue ID

  • MS_Buffer (High Ram Buffer for messages)


Message Flow

REMARK : These message names are not the actual names used in KNX.


Queue ID Definition of Redirection Coding

Queue ID Definition/ Redirection Coding

Queue ID | Symbol | Queue Description | Redirection Coding (Table )
0 | - | free message buffers | -
1 | TASK_LL_ID | Linklayer | 1xh
2 | TASK_NL_ID | Networklayer | 2xh
3 | TASK_TL_ID | Transportlayer multicast | 3xh
4 | TASK_TC_ID | Transportlayer broadcast Transportlayer one to one connectionless Transportlayer one to one connection orient. | 4xh
5 | TASK_LC_ID | Transportlayer local | all 4xh messages from PEI-Management
6 | TASK_AL_ID | Applicationlayer | 7xh
7 | TASK_MG_ID | Management | 8xh , 9xh
8 | TASK_PM_ID | PEI system | Axh
9 | TASK_US_ID | User | Dxh, Exh, Fxh


Structure of Redirection Table

The redirection table is located in system ROM.
They provide a "hard" converting of incoming frames to serveral queue ID's.

Table ID | Queue ID | Service Code Arrangement
0 | 0 | 0xh (put the message to free queue)
1 | TASK_LL_ID | 1xh
2 | TASK_NL_ID | 2xh
3 | TASK_TL_ID | 3xh
4 | TASK_TC_ID | 4xh
5 | 0 | 5xh (put the message to free queue)
6 | 0 | 6xh (put the message to free queue)
7 | TASK_AL_ID | 7xh
8 | TASK_MG_ID | 8xh
9 | TASK_MG_ID | 9xh
A | TASK_PM_ID | Axh
B | TASK_LC_ID | Bxh (not used on EMI1/ EMI2, service internal not used)
C | 0 | Cxh (put the message to free queue)
D | TASK_US_ID | Dxh
E | TASK_US_ID | Exh
F | TASK_US_ID | Fxh


Structure of the Message System


Buffer Structure of Standard Frame

Buffer Structure on Standard Frame

Message Buffer (25 Byte)
L | Srv | ....BB.C | S | S | D | D | aRRRIIII | TTssssAA | AAEEEEEE | dddddddd | SAP
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - 23 | 24

L | length
Srv | service code
BB | bus priority (Time behavior)
C | confirm state ( 0=ok; 1= error)
S | source address
D | destination address
a | address type
R | routing counter
I | information length
T | TPCI
s | sequence number
A | APCI
E | extended APCI / data (max 6 bit)
d | data (max 14 byte)
SAP | SAP number


Buffer Structure on Property Read/ Write/ Resp. Frame

Buffer Structure on
Property Read / Write/ Response

Extended definition of messagebuffer in case of property read or write
message header | object ID | property ID | number of elements | start index | data (max10 byte) |
 | IIIIIIII | PPPPPPPP | AAAASSSS | SSSSSSSS | dddddddd | SAP
0 - 9 | 10 | 11 | 12 | 13 | 14 - 23 | 24


Buffer Structure of Polling

The polling mechanism is a new way to get informations from several EIB-devices in one EIB telegram frame. The polling mechanism is based on the master / slave concept. A polling master may request the polling data (1 Byte) from up to 14 slaves. The polling master and the slaves must be located in the same physical line.

 | Master | Slave
Addressing Hints | - up to 15 slots are requestable - request ID numbered from 0..15 (0 not useful) - address type is independent from all other address modes | - answer ID (slot) numbered from 0..14
Define Answer Address | - dosn't matter | - set with device object property ID 18
Define Answer Slot | - dosn't matter | - set with device object property ID 18
Value for Response | - dosn't matter | - set with U_SetPollingRsp

Extended definition of messagebuffer in case of polling master frame (polling request)
 |  | control byte | Src Addr |  | Poll Addr |  | Number of Slots | Slot 0 - 14
L | Srv | 11110000 | S | S | D | D | 0000nnnn | empty
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - 22

Extended definition of messagebuffer in case of polling master frame (polling confirm)
 |  | control byte | Src Addr |  | Poll Addr |  | Number of Slots | Slot 0 - 14
L | Srv | 11110000 | S | S | D | D | 0000nnnn | filled
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - 22

REMARK:

In general the BCU 2 is capable to handle 15 answer slots. If you want to store those polling answer in a "generic" communication object be careful with the requested slot number (answer slots ) because 15 slot's doesn't fit complete in any communication object.


Introduction

Introduction Timer System

The Timer system of the BCU2 is based on the 16-Bit free running counter and the 8-Bit ripple counter called the core timer from the 68HC705BE12.

The 8-Bit core timer is used for:

  • Watchdog reset

  • User-Timer in device applications
  • Telegram rate limitation after reset is also based on this timer

The 16-Bit free running counter is used for:

  • The system timer which is available for the application program

  • Management application
  • TL, for connection supervision
  • LL, for service repetition after 150 bit times because of a preceeding 'BUSY' frame

CLOCK GENERATION

Crystal Frequency (CF):

4.9152 MHZ

Operation Frequency (OF):

2.4576 MHz

Watchdog resolution

  • Based on the coretimer RTI

  • Released the watchdog reset due to a fixed 8 prescaler latest after 53.33ms
  • One digit tolerance (watchdog reset can occur earliest after 46.667ms)

Timer resolution (OF/4)

0.6144 MHz
1.62760417 µs

CORE TIMER

The 8-Bit core timer overflows every 416.667µs. A real time interrupt (RTI) is released after a fix 16 prescaler every 6.667ms.


User Timers

User Timer

The user timers are software timers. The number of timer is only limited by the free memory of User RAM in the ZPAGE. Each user timer can have a different time base. But each timer must be updated by the user application at least one time per timer-tick in its own time base.

For each user timer, a byte must be reserved in RAM. All of these bytes must by allocated in one block. The first byte in this block corresponds with the first User-Timer, the second byte corresponds with the second user timer and so on. The bit 7 in each byte is reserved, the bits 0-6 is used for the timer-value (0-127). This value will be decrement, only if you use the update function U_GetTM. You can set the user timer if you use the function U_SetTM, or you can load the corresponding RAM directly with the value. The bit7 must be 0. A description-block in EEPROM is used to describe the user timers. Each User-Timer-function needs a pointer to this description-block.

The structure of the EEPROM-description-block is:

Offset in Block | Length (Bytes) | Meaning
0 | 1 | pointer to user timer RAM-data
1 | 1 | low nibble = time base User-Timer 0 high nibble = time base User-Timer 1
2 | 1 | low nibble = time base User-Timer 2 high nibble = time base User-Timer 3
... | ... | ...

Following time bases are possible:

Time Base | Time Resolution
0 | app. 133 ms
1 | app. 266 ms
2 | app. 533 ms
3 | app. 1.066 sec
4 | app. 2.133 sec
5 | app. 4.266 sec
6 | app. 8.533 sec
7 | app. 17.067 sec
8 | app. 34.133 sec
9 | app. 68.267 sec
10 | app. 2 min 16 sec
11 | app. 4 min 33 sec
12 | app. 9 min 6 sec
13 | app. 18 min 12 sec
14 | app. 36 min 24 sec
15 | app. 72 min 48 sec


U_GetTM internal

Note: This is a description of the internal registers of the user timer as accessed by the BCU2 system. These registers cannot be accessed from the application program. See the API functions on how to use the user timers.


User Timer internal

Note: This is a description of the internal registers of the user timer as accessed by the BCU2 system. These registers cannot be accessed from the application program. See the API functions on how to use the user timers.

The user timer based on the coretimer RTI and 3 additional register:

- CORE_Timer
- CORE_Timer+1
- CORE_Timer+2

The "CORE_Timer+2" register is cyclic decremented from 20 (decimal) down to 0 by the RTI core timer. On every overflow (00h -> FFh) the "CORE_Timer+2" is reload with value 20 and the register CORE_Timer+1 and CORE_Timer will be updated.


System Timers

System Timer

The BCU2 has a maximum of 5 system timers (number 0 - 4).

  • Timer 0 is reserved for the LL, for service repetition after 150 bit times because of a preceeding 'BUSY' frame.
  • Timer 1 is reserved for the serial protocol if the protocol is active.
  • Timer 2 is reserved for the debounce function. If debouncing is not used the timer is available for the user.
  • Timer 3 is available for the user.
  • Timer 4 is reserved for the transport layer.

The functions for the BCU2 system timer are U_TS_Set, U_TS_Seti and U_TS_Del . The following modes and scales are possible :

Mode | Code | Description
TS_TYPE_EVT | 20h | Event: can only used with TS_Seti fixed scale of 6.6ms, generates an event for own/ standard PEI driver
TS_TYPE_MSG | 30h | Message: generates a timer-indication message
TS_TYPE_MSG_CYC | 40h | Message cyclic: generates cyclic a Timer_ind message
TS_TYPE_DOWN | 50h | Down counter: reserved for compatible function to BCU1, use with TM_Load
TS_TYPE_DIFF | 60h | Difference counter: reserved for compatible function to BCU1, use with TM_Load

Scales | Code | Resolution
TS_SCALE041MS | 00 hex | approximately 0.416 ms
TS_SCALE6_6MS | 20 hex | approximately 6.667 ms
TS_SCALE106S | 40 hex | approximately 106.6 ms
TS_SCALE1_6S | 60 hex | approximatley 1.7 sec
TS_SCALE26S | 80 hex | 27.3 sec

Cyclic Scales (only for type TS_TYPE_MSG_CYC) | Code | Resolution
TS_100MS | 04h | 100 ms
TS_1SEC | 08h | 1 sec
TS_1MIN | 0Ch | 1 min

The old BCU1 timer functions TM_Load and TM_GetFlg are supported too, but be careful and note that due to the BCU2 crystal frequency there is a difference in the time unit compared to BCU1.

Time range by using old BCU1 timer function:

intern BCU2 calculation by using the difference counter: base *13/16
e.g.
Range 1: 0.41666ms *16/13 = 0.51282ms
Range 2: 6.66667ms *16/13 = 8.20512ms
...

intern BCU2 calculation by using in down counter: runtime * 1.25
e.g.
Range 1: 0.41666ms *1.25 = 0.52083ms
Range 2: 6.66667ms *1.25 = 8.33333ms
...

Range

Time Unit BCU1

Time-Unit BCU2 Down Counter

Time-Unit BCU2 Difference Counter

1

app. 0.5 ms

0.5208 ms

0.5128 ms

2

app. 8.0 ms

8.3333 ms

8.205 ms

3

app. 130 ms

133.33 ms

131.28 ms

4

app. 2.1 s

2.133 s

2.1005 s

5

app. 33 s

34.125 s

33.608 s

Attention: By adding return values of a difference counter into an own timer register you should note, that there are a different tolerances which depend on the return value:

e.g. Timer range 1 (0.4166ms):
periodically call TM_getFlag every 2.8ms tol: 14.3%
periodically call TM_getFlag every 7.5ms tol: 4.5%
periodically call TM_getFlag every 12.8ms tol: 1.3%


Difference Counter Timer internal

Note: This is a description of the internal registers of the system timer as accessed by the BCU2 system. These registers cannot be accessed from the application program. See the API functions on how to use the system timers.


Down Counter Timer internal

Note: This is a description of the internal registers of the system timer as accessed by the BCU2 system. These registers cannot be accessed from the application program. See the API functions on how to use the system timers.


Message Cyclc Timer internal

Message Cyclic Timer internal

Note: This is a description of the internal registers of the system timer as accessed by the BCU2 system. These registers cannot be accessed from the application program. See the API functions on how to use the system timers.


Message Timer internal

Note: This is a description of the internal registers of the system timer as accessed by the BCU2 system. These registers cannot be accessed from the application program. See the API functions on how to use the system timers.


System Timer internal

Note: This is a description of the internal registers of the system timer as accessed by the BCU2 system. These registers cannot be accessed from the application program. See the API functions on how to use the system timers.

The 16-Bit hardware-counter is used for the BCU2 system timers and readable by the two alternate counter register TACNTH and TACNTL.

The timer interrupt every 106.667ms updates 3 additional registers for realizing time measuring up to 20 days.

A Timer Table is placed in RAM-Area. Each of the 5 system timers possesses an entry of 3 bytes in the table

Timer Table | Timer 0 | Timer 1 | Timer 2 | Timer 3 | Timer 4
Control /Task-ID | used for Link Layer | used for serial protocol | used for debounce function | free | used for Transport Layer
Parameter
Timervalue

The bits in the timer table have the following definition:

Control |  | Parameter |  |  |  | Timervalue
Bit 4 - 7 | Bit 0 - 3 | Bit 5 - 7 | Bit 4 | Bit 2 - 3 | Bit 0 - 1 | Bit 0 - 7
Event | Task-ID | Parameter |  |  | Overflow | expiration time
Message | Task-ID | timer range | Parameter |  | Overflow | expiration time
Message/cyclic | Task-ID | timer range | Cycle time |  | Overflow | expiration time
Downcounter | Task-ID | timer range | Flag | xx | timer extension | expiration time
Differencecounter | Task-ID | timer range | x | xx | x | last actual timer-value

x = undefined (don't cares)


Access Protection

In BCU 2 are different "modes/ kinds" of access protection. In general the BCU 2 has a protection against forbidden memory access (e.g. via the EIBus), but it is also possible to enable or disable advanced access features.

  • Memory protection by MCB/ CRC

- Just the allocated memory can be accessed
- Allocation and release of memory is done through the appropriate system objects
(address table object, association table object and application program object).

MCB structure

  • Global memory access protection by 4 access levels (0...3)

Access Level

Usage

Remark

Assigned Synonym

0

loading application programs

required for load state machine of application

PRIVILEGE_CONFIGURATION

1

loading address table/
association table

required for load state machine of address table/ association table

PRIVILEGE_SERVICE

2

application parameters

-

PRIVILEGE_USER

3

reserved for free access without authorization (no key entry)

-

PRIVILEGE_NO

- After the master reset the access level is set to 3 and all the keys have the value FFFF FFFFh.

  • Service disable

- Programming of the physical address by using broadcast messages,
- Services are used through the PEI

Can be disabled/ enabled to prevent the usage of these services without appropriate authorization.


Authorization Key settings

Authorization/ Key setting

Message Request

Message Response

Remark

Authorization

T_DATA.indication
(APCI=AuthorizeRequest, Key)

T_DATA.indication
(APCI=SetKeyRequest, AccessLevel, Key)

  • only possible if connection established

Key setting

T_DATA.indication
(APCI=AuthorizeResponse, CurrentAccessLevel)

T_DATA.indication
(APCI=SetKeyResponse, AccessLevel)

  • current accesslevel must be lower/ same of level want to set

  • one key per accesslevel
  • new key overwrite the old key
  • delete a key with setting key ‘FFFF FFFFh’


Memory Allocation Memory Write/Read

Memory Allocation/ Memory Write/ Memory Read

The BCU 2 has a built-in memory management system. It guarantees that only the available memory can be allocated. The allocated memory can be accessed and used. Memory is allocated by writing an Absolute Code/Data Allocation Record to the Load Control of the appropriate EIB-object.

The data are written by direct memory access. Make sure that the tool has the required access rights which are defined during memory allocation. Otherwise you may lock out yourself!

During the writing process data flow control is necessary, because writing to EEPROM is slow. The best way to do this is to combine verification with flow control. So write data with one message and verify the same data by reading it back with the next message or enable the verify-mode in the device object.

Message Request

Message Response

Remark

Memory Write

T_DATA. indication (APCI=MemoryWrite, Length, Address,Data)

T_DATA. indication (APCI = MemoryResponse, Length, Address, Data)

if verify mode enabled (automatic memory response) a memory response occurs

Memory Read

T_DATA. indication (APCI = MemoryRead, Length, Address)

T_DATA. indication (APCI = MemoryResponse, Length, Address, Data)

if verify mode enabled (automatic memory response) not nessesary

Memory Allocation

T_DATA. indication (APCI = PropertyWrite, ObjectID=?, PropertyID=05H, StartAddress, Length, Access Rights, Memorytype, Flags)

T_DATA. indication (APCI = PropertyResponse, ObjectID=?, PropertyID=05H, return state of load/ state mashine)

only possible if appropriate load/ state machine is in state loading,

Memory allocation may take quite a while, because significant amounts of EEPROM have to be programmed,

For each allocated memory block of type EEPROM checksum control can be requested (appended at the end of the memory block),

checksum is set when the load state of an object is set to "loaded",

checksum is controlled on each reset,

If a checksum error is detected then the load state of the corresponding program object is set to Error.


Memory Control Block structure

Memory Control Block structure (MCB)

Each memory control block has the length of four bytes. If a cyclic redundancy check is required, the CRC bytes are stored after the end of the administered memory block. The BCU has
- 6 defined MCB's
- 6 unused MCB's

Enable CRC (1 bit) | Owner (3 bit) | Pointer to Memory (12 bit)
r/w Access (4 bit) |  | Type (2bit) | Length of Memory (included the optional checksum) (10 bit)

0x0120h : : |
0x0130h 0x0131h : : 0x0149h (optional checksum) | block length max. 1024 byte
: : 0x0150h |

Default MCB's in BCU 2.1

Startaddress | Length | CRC | Access Level (r/w) | Type | Owner | Remark
4Dh | 3h | no | 1100b | ROM | system | ROM release/ mask version
60 | 1h | no | 1100b | RAM | system | system state
BDh | 23h | no | 1010b | RAM | user | low user ram
100h (x) | 100h | yes | 1010b | EEPROM | olduser | enable loding of BCU 1.x app.
200h | 270h | yes | 1010b | EEPROM | user | new user
972h | 4Ah | no | 1010b | RAM | user | high user ram

(x) if this M CB type (olduser) is active and a Memory Write/ PC_SetValue occurs to these MCB
(remember there are also splitted MCB's possible, but this whole MCB is used only for BCU 1 application) the CRC on 1FFh will be automatically updated

Example :
- BCU 1.x application is loaded, Memory Write to MCB occurs
- downloading BCU 1.x application

Pointer to memory space | contains the location of the memory block
Length of memory space | contains the number of bytes of the memory block
Read/write access | required access level for reading and writing this memory block, 2 bit each. Encoding:
 | 00 | system administrator level (used by ETS) for loading internal application programs
 | 01 | parametrization level (used by ETS) for loading address/ association tables, application parameters
 | 10 | free for application specific use
 | 11 | no access level
Enable CRC | 1 / 0 | CRC enabled/ CRC disabled
MCB type | 0 | ROM
 | 1 | zero page RAM
 | 2 | RAM
 | 3 | EEPROM
Owner type | 0 | unused (only free "space" for establishing any new MCB)
 | 1 | address table
 | 2 | association table
 | 3 | newuser, BCU 2.x applications
 | 5 | olduser, BCU 1.x applications (CRC automaticlly updated)
 | 4 | system
 | 7 | free, MCB is "not using", but has information inside (type, length ...)


Load Procedure

Before a tool can write any new data into the BCU it must handle the correct way for valid allocation of memory. Within the BCU it will be distinguished between three general parts of allocation sections :

- Address table
- Association table
- Application

Each part can consist of several "memory allocation records", but this is only useful for the application itself. Only in application itself it is useful to "create" different mcb's with different behavior. The most reason for this is to use EEPROM data in application save routine (here the mcb crc behavior must be disabled, remember on mcb calculation on startup ...)

%AbsDataSeg .SFB.(CODE),.SFB.("300h"),RW3,MEMTYP_EEPROM,CRC_EN | EEPROM code segment (CODE ... 300h) crc on
%AbsDataSeg .SFB.("301h"),.SFB.(ECODE-1),RW3,MEMTYP_EEPROM,CRC_DIS | EEPROM code segment (301h ... ECODE-1) crc off

The mechanism for loading data is independent of any other allocated memory blocks. There are only some acceptances for the successful loading of any data.

  • First command before loading any data is to unload the specific section (Adr, Asso, App), unload performs a setting the assigned section to free and starting the merge algorithm (see below)

  • U ntil loading any data into the BCU (ma c hine state = loding) it is strongly recommended to handle no other communication with BCU (in a way o f a second µC on EMI ...)

Conditions on the "allocation record" for successful loading :

  1. Start/ end address of requested memory must fit in one available MCB

  2. Owner of MCB found under point 1 must be free
  3. Type of MCB found under point 1 must be the same as the type of requested memory
  4. If there is one (two) split(s) necessary there must be at least one (two) unused MCB's to install the new free MCB's else loading data failed
  5. After this the system trys to split the MCB's into several parts and try merge the new established free MCB's.

example on allocation memory with result of 2 free mcb's

mem low |  | mem high
free MCB
splitting section | requested memory | splitting section
free MCB |  | free MCB

example on merge for a released memory

mem low |  | mem high
 | released memory |
free MCB |  | free MCB
free MCB

Steps for successful loading of complete application:

1. Connecting

Connect via bus or serial PEI

2. Getting the access rights

Authorize if required.

3. Verifying BCU version

Check the correct mask type and mask version. In addition it may be checked in some cases if the device is of the correct type (order number)

4. Verifying hardware type

Check if the port A direction bit settings in the application program matches those in the BCU.

5. Unloading the BCU

  • Set AddressTable.LoadControl = 'Unload

  • Set AssociationTable.LoadControl = 'Unload'
  • Set Application.LoadControl = 'Unload'

LoadStates must then be changed to or be 'Unloaded'.

6. Loading the address table

  • Set AddressTable.LoadControl = 'Load'.

AddressTable.LoadState must then be changed to 'Loading'.

  • Allocate the required memory (absolute addresses)

  • Load the data by direct memory access (absolute code + data)
  • Load the Segment Control Record
  • Set AddressTable.LoadControl = 'LoadCompleted'.

AddressTable.LoadState must then be changed to 'Loaded'.

7. Loading the association table

  • Set AssociationTable.LoadControl = 'Load'.

AssociationTable.LoadState must then be changed to 'Loading'.

  • Allocate the required memory (absolute addresses)

  • Load the data by direct memory access (absolute code + data)
  • Load the Segment Control Record
  • Set AssociationTable.LoadControl = 'LoadCompleted'

AssociationTable.LoadState must then be changed to 'Loaded'.

8. Loading the application program

  • Set ApplicationProgram.LoadControl = 'Load'.

ApplicationProgram.LoadState must then be changed to 'Loading'.

  • Allocate the required memory (absolute addresses)

  • Load the data by direct memory access (absolute code + data)
  • Load the Segment Control Record
  • Load the Task-Pointer Record
  • Load the Task-Control Record
  • Set ApplicationProgram.LoadControl = 'LoadCompleted'

ApplicationProgram.LoadState must then be changed to 'Loaded'.

9. Modifying access keys

Set the access keys as required.

10. Restart the device

Restart

11. Disconnecting

Disconnect.

Steps for successful loading of one section:

1. Connecting | Connect
2. Getting the access rights | Authorize if required.
3. Verifying BCU version | Check for the correct mask type, mask version.
4. Unloading the object | LoadControl = 'Unload'. LoadState must then change to or be 'Unloaded'.
5. Loading the object | LoadControl = 'Load'. LoadState must then change to 'Loading'. Allocate the required memory (absolute addresses). Load the data by direct memory access (absolute code + data). Load the Segment Control / Information Records. LoadControl = 'LoadCompleted'. LoadState must then change to 'Loaded'.
6. Restart the device | Restart (if nessesary, e.g. on application)
7. Disconnecting | Disconnect


Load Events

An event for the state machine is a writing to the corresponding LoadControl. The encoding of the different record types (data) for writing to the Load Control property is as follows.

Load Events 1 Byte | Value | Remark
no operation | 00h | nothing to do
start load | 01h | the state machine is change to loading
load complete | 02h | the state machine is change to loaded
unload | 04h | the state machine is change to unloaded
segment | 03h | allocation / information records further coded as follows: 00h Absolute Code/Data Allocation Record 02h Segment Control Record 03h Task Pointer Record 04h Task Control Record1 05h Task Control Record2

Not all record types are supported by all program objects. The table below shows which records are supported by which program object.

 | No Operation | Start Load | Load Complete | Code/ Data Allocation | Segment Control | Task Pointer | Task Control | Unload
Address Table | X | X | X | X | X |  |  | X
Association Table | X | X | X | X | X |  |  | X
Application Program | X | X | X | X | X | X | X | X


Load State Machines

The load procedure for device configuration data define the general mechanism for changing the different programmable parts in the BCU. For each of the three general parts of allocation section one load state machine (LSM) is defined which controls the load process. Nevertheless it is recommended to program only one part at a time. The following state transition diagram is valid for all LSM.

Load State Machine

  • Each general part has a property which allows to read the load status/ write the load state event (after any write of event to the LSM the status is given in the response)

  • The load status is stored in non-volatile memory (EEPROM), because it must be preserved also on power fail

  • Status "unloaded" does not just mean that no valid data are in the BCU (that means every allocated memory is released, but without the event "segment" [start load + load complete] it can't reach a valid memory structure, e.g. the status "loaded")

  • Critical transition is load completed, because during this transition the checksums are calculated and the data are declared as valid

The load states are encoded as follows.

Load Status | Value (1 Byte) | Remark
Unloaded | 0 | no data loaded
Loaded | 1 | data loaded
Loading | 2 | load process is active
Error | 3 | error in data detected


Run State Machine

Run State Machine of the Application Program

The states of the run state machine can be read from the run control property by the property read service and are encoded as follows.

Format

State

(reading run control)

1 Byte

State | Value | Remark
Halted | 0 | the program is halted
Running | 1 | the program is running
Ready | 2 | the program is ready, but not yet running
Terminated | 3 | the program is terminated

The application program can be started and stopped for diagnostic purposes (if the run conditions are fulfilled). The run state machine is controlled by writing to the run control property via the property write service.
The data for the run control are encoded as follows.

Format

Control

(writing run control)

1 Byte

Control | Value | Remark
No operation | 00h | no operation
Restart | 01h | request to restart the program
Stop | 02h | request to stop the program

EVENTS |  |  | STATES | Halted | Running | Ready | Terminated
No operation 00h |  |  |  | Halted | Running | Ready* | Terminated
Restart 01h | Appl. loaded |  |  | Ready* | Ready* | Ready* | Ready*
 | Appl. not loaded |  |  | Halted | Halted | Halted | Halted
Stop 02h |  |  |  | Terminated | Terminated | Terminated | Terminated
Unload Application |  |  |  | Halted | Halted | Halted | Halted
Device Restart |  | Appl. loaded |  | Ready* | Ready* | Ready* | Ready*
 |  | Appl. not loaded |  | Halted | n.a. | n.a. | Halted

* The transition from Ready to Running is done automatically if the run conditions are fulfilled (i.e. PEI type is correct).


Load Control on BCU1/ BCU2


Absolute Code Data Record

Absolute Code/ Data Allocation Record

0H | 3H | 00H | StartAddr | Length | Access | MemType | Flags
4 Bit | 4 Bit | 1 Byte | 2 Bytes | 2 Bytes | 1 Byte | 1 Byte | 1 Byte

StartAddr | absolute start address of memory block
Length | length of memory block in bytes
Access | contains the access level of the segment
 | Bit 0-3: Bit 4-7: | write access level read access level
MemType | contains the type of the memory 01h Zero Page RAM 02h High RAM 03h EEPROM
Flags | Bit 0-6: Bit 7: | must be zero if this bit is set to '1' then checksum control is enabled


Segment Control Record

0H | 3H | 02H | SegmentPtr | PEI-Type | Manufact | AppID | AppVer
4 Bit | 4 Bit | 1 Byte | 2 Bytes | 1 Byte 109h | 2 Bytes 103h/ 104h | 2 Bytes 105h/ 106h | 1 Byte 107h

SegmentPtr

Absolute start address of:

these segment pointer are not the pointer in EEPROM description at 114h, 111h

  • application main function*,

  • association table,
  • address table (always on 116h)

* the following fields below are only used for application segment

PeiType | specifies the required PEI type for running the application program
Manufact | manufacturer ID of application program
AppId AppVer | ID and version of application program (both ID's will be declared in macro with name <%AppID, %AppIDOld>)

AppVer structure :

Bit# | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
meaning | main version number (0-F) |  |  |  | sub version number (0-F)


Task Control Record1

0H | 3H | 04H | EIB-Object Pointer | EIB-Object Counter
4 Bit | 4 Bit | 1 Byte | 2 Bytes | 1 Byte

EIB-ObjectPointer | absolute address of user EIB objects table, 0000h when not used
EIB-ObjectCount | number of user EIB objects


Task Control Record2

0H | 3H | 05H | AppCallBack | C-ObjectDescPtr | C-ObjectSegPtr0 | C-ObjectSegPtrl
4 Bit | 4 Bit | 1 Byte | 2 Bytes | 2 Bytes | 2 Bytes | 2 Bytes

AppCallBack | absolute address of application call back function
C-ObjectDescPtr | pointer to communication object table
C-ObjectSegptr0 | segment pointer 0 to communication objects
C-ObjectSegPtr1 | segment pointer 1 to communication objects


Task Pointer Record

0H | 3H | 03H | AppInit | AppSave | SP_Handler
4 Bit | 4 Bit | 1 Byte | 2 Bytes this is not the pointer in low EEPROM | 2 Bytes this is not the pointer in low EEPROM | 2 Bytes

AppInit | absolute start address of application initialization function
AppSave | absolute start address of application save function
SP_Handler | absolute start address of own serial PEI handler, 0000h when standard handler is used


S19 Load Control Paragraphs

Header Paragraph

Format Version | Offset | Reserved
1 Byte | 2 Byte | 13 Byte
00H | <16-bit address> | 0000H

End Paragraph

Control Code | Reserved
1Byte | 15 Byte
FFH | 0000H

Restart Paragraph

Control Code | Reserved
1Byte | 15 Byte
0CH | 0000H

Delay Paragraph

Control Code | delay time | Reserved
1Byte | 2 Byte | 13 Byte
0DH | <time in ms> | 0000 H

Write Memory Paragraph

Control Code | Start Address | End Address | Reserved
1Byte | 2Byte | 2 Byte | 11Byte
08H | <16-bit address> | <16-bit address> | 0000H

Write Memory with Verify Paragraph

Control Code | Start Address | End Address | Reserved
1Byte | 2Byte | 2 Byte | 11Byte
09H | <16-bit address> | <16-bit address> | 0000H

Write Memory Direct Paragraph

Control Code | Start Address | End Address | Data
1Byte | 2Byte | 2 Byte | max. 11 Bytes
0AH | <16-bit address> | <16-bit address> |

Compare Memory Direct Paragraph

Control Code | Start Address | End Address | Data
1Byte | 2Byte | 2 Byte | max. 11 Bytes
0BH | <16-bit address> | <16-bit address> |

Write Property Paragraph

Control Code | Object ID | Property ID | Start Index | Number of Elements | Data
1Byte | 1 Byte | 1 Byte | 2 Byte | 1 Byte | max. 10 Bytes
05H |  |  | <first Element> |  |

Write Property with Verify Paragraph

Control Code | Object ID | Property ID | Start Index (first Element) | Number of Elements | Data
1Byte | 1 Byte | 1 Byte | 2 Byte | 1 Byte | max. 10 Bytes
06H |  |  | <first Element> |  |

Compare Property Paragraph

Control Code | Object ID | Property ID | Start Index (first Element) | Number of Elements | Data
1Byte | 1 Byte | 1 Byte | 2 Byte | 1 Byte | max. 10 Bytes
07H |  |  | <first Element> |  |

Address Table Load Paragraph

Control Code | Reserved
1Byte | 15Byte
11H | 0000H

Address Table Load Completed Paragraph

Control Code | Reserved
1Byte | 15Byte
12H | 0000H

Address Table Unload Paragraph

Control Code | Reserved
1Byte | 15Byte
14H | 0000H

Address Table Data Segment Paragraph

Control Code | Segment Type | Segment ID | Segment Address | Segment EndAddr | Access Attributes | Memory Type | Memory Attributes | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 2 Bytes | 1 Byte | 1 Byte | 1 Byte | 1Byte
13H | 0 | 0 |  |  |  |  |  | 0000H

Address Table Task Segment Paragraph

Control Code | Segment Type | Segment ID | Start Address | reserved | Application ID | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 1Byte | 5 Bytes | 5Byte
13H | 2 | 0 |  | 0 |  | 0000H

Association Table Load Paragraph

Control Code | Reserved
1Byte | 15Byte
21H | 0000H

Association Table Load Completed Paragraph

Control Code | Reserved
1Byte | 15Byte
22H | 0000H

Association Table Unload Paragraph

Control Code | Reserved
1Byte | 15Byte
24H | 0000H

Association Table Data Segment Paragraph

Control Code | Segment Type | Segment ID | Segment Address | Segment EndAddr | Access Attributes | Memory Type | Memory Attributes | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 2 Bytes | 1 Byte | 1 Byte | 1 Byte |
23H | 0 | 0 |  |  |  |  |  | 0000H

Association Table Task Segment Paragraph

Control Code | Segment Type | Segment ID | Start Address | reserved | Application ID | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 1Byte | 5 Bytes | 5Byte
23H | 2 | 0 |  | 0 |  | 0000H

Application Load Paragraph

Control Code | Reserved
1Byte | 15Byte
31H | 0000H

Application Load Completed Paragraph

Control Code | Reserved
1Byte | 15Byte
32H | 0000H

Application Unload Paragraph

Control Code | Reserved
1Byte | 15Byte
34H | 0000H

Application Data Segment Paragraph

Control Code | Segment Type | Segment ID | Segment Address | Segment EndAddr | Access Attributes | Memory Type | Memory Attributes | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 2 Bytes | 1 Byte | 1 Byte | 1 Byte |
33H | 0 | 0 |  |  |  |  |  | 0000H

Application Task Segment Paragraph

Control Code | Segment Type | Segment ID | Start Address | Required PEI Type | Application ID | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 1Byte | 5 Bytes | 5 Byte
33H | 2 | 0 |  |  |  | 0000H

Application Task Pointer Paragraph

Control Code | Segment Type | Segment ID | Address of Init | Address of Save | Start Address of PEI Handler | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 2 Byte | 2 Bytes | 7 Byte
33H | 3 | 0 |  |  |  | 0000H

Application Task Control 1 Paragraph

Control Code | Segment Type | Segment ID | Address to EIB Objects | Number of EIB Objects | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 1 Byte | 7 Byte
33H | 4 | 0 |  |  | 0000H

Application Task Control 2 Paragraph

Control Code | Segment Type | Segment ID | Address of AL Callback | Address of Comm-Objects | Segment Pointer 1 to Comm- Objects | Segment Pointer 2 to Comm- Objects | Reserved
1Byte | 1Byte | 1Byte | 2 Bytes | 2 Byte | 2 Bytes | 2 Bytes | 5 Byte
33H | 5 | 0 |  |  |  |  | 0000H


S19 Format for the Load Controls

S19 Format for the LoadControl

Some tools support the loading of programs to the BCU. For this operation the programs have to be put in a defined format. This format is basically the default S19-format or IAR debug format with some additional conventions. The programs have to be linked to the final absolute addresses. The control information for the load procedure must be given in a reserved memory area (5000h++), this area is not required for the program code or its data (because BCU 2.x loadable EEPROM starts on 100h and ends at 4FFh).

S00B00004C6F61644374726CDF (comment record)

S19 record with control informations
S1130000005000000000000000000000000000009C (on address 0000h the addresssegment is fixed)
S10450100E8D
S10450201477 (unload address table)
S10450302457 (unload association table)
S10450403437 (unload application)
S1045050114A
S10F50601300000116011D3F0380000036
S10E5070130200011600000000000005
S10450801219
S104509021FA
....
S19 record with data
S10401160BD9
S11301191000100110021003100410051006100736
S1070129100810099D
...
S9030000FC (end record)

REMARK :

Loactions coding with rmb x are not included in the S19 reocord.
(see pararagraph address 116h, 117h/ 118h is rmb 2 [tables.asm], next is pararagraph starts at address 119h)

Paragraph structure

Sx (paragraph type)

length of following data (include CRC)

absolute address
(16 bit)

Data

CRC, ones complement of summarized data (exclude Sx)

Paragraph types

S0

comment record

-

S1

data record

  • first data record (header paragraph with address 0000h) consists control information (address segment for computation)

  • next control data record following the address structure S1, length, address segment + 10h * x

  • raw data records consists the actual target address and memory contents for the BCU 2.x

  • the control records will be computed (for instance %AbsDataSeg ...) and handled the download for the raw data

  • reserved absolut paragraph addresses are F000H to FFFFH

S9

end record

-


CRC Calculation on Load Control

The mechanism for calculation CRC is the same for loading BCU 1.x/ BCU 2.x applications into system BCU 2.x. The CRC follows the equation :

 | i=startaddress (SFB) |
CRC = | SUM (eor address[i] ) | mod 256
 | i<=endaddress (SFE) |

The CRC itsself is not included.


Example Load Controls

Example of Load Controls

%Commands
%Connect

*----------------------------------------------------------------------------------------------------------------------------------------------

%Unload Adr | unload the address table
%Unload Assoc | unload the association table
%Unload App | unload the application

*----------------------------------------------------------------------------------------------------------------------------------------------

%Load Adr | load the address table
%AbsDataSeg .SFB.(ADRTAB),.SFE.(ADRTAB-1),RW3,MEMTYP_EEPROM,CRC_EN | EEPROM data segment
%AbsTaskSeg addrTab | table entrypoint
%LoadCompleted |

*-----------------------------------------------------------------------------------------------------------------------------------------------

%Load Assoc | load the association table
%AbsDataSeg .SFB.(ASSOCTAB),.SFE.(ASSOCTAB-1),RW3,MEMTYP_EEPROM,CRC_EN | EEPROM data segment
%AbsTaskSeg assocTab | table entrypoint
%LoadCompleted |

*-------------------------------------------------------------------------------------------------------------------------------------------------

%Load App | load the application
%AbsDataSeg .SFB.(ZDATA),.SFB.(ZEDATA-1),RW3,MEMTYP_ZRAM,CRC_DIS | ZRAM data segment
%AbsDataSeg .SFB.(HDATA),.SFB.(HEDATA-1),RW3,MEMTYP_RAM,CRC_DIS | HRAM data segment
%AbsDataSeg .SFB.(EEDATA),.SFE.(EEDATA-1),RW3,MEMTYP_EEPROM,CRC_DIS | EEDATA data segment
%AbsDataSeg .SFB.(EEPRM),.SFB.(ADRTAB-1),RW3,MEMTYP_EEPROM,CRC_DIS | EEPROM system segment
%AbsDataSeg .SFB.(CODE),.SFB.(ECODE-1),RW3,MEMTYP_EEPROM,CRC_EN | EEPROM code segment
%AbsTaskSeg AppMain,PeiType,AppID,AppVer | main pointer, required PEI type,Task ID
%TaskPtrRecord AppInit,AppSave | init, save pointer
%TaskCtrlRec1 0,0 | pointer to user EIB Objects, count
%TaskCtrlRec2 AppCallBack,EE_CommsTab,CObjSeg0,CObjSeg1 | pointer to callback handler (system/ own) pointer to communication objects table, segment selector pointer
%LoadCompleted |

*---------------------------------------------------------------------------------------------------------------------------------------------------

%Restart

forces device restart

%AbsCObjSeg EE_CommsTab

table entrypoint (ETS)

%Disconnect
%CommandsEnd


Device Identification

Device Identification/ changing methods for memory

Within the system 2 is an easy way to get information about the selected device. In the information is readable and some of it is also changeable. In system 2 is distinguish between two main properties: the system- and the user specific property.

SYSTEM

  • Device object

  • Address table object

  • Association table object
  • Application object

- Permanent available
- Four objects
- Each object consists of several characteristics

USER

  • User object(s) (the design of these objects in an application is showing here)

- Circumferences of user property depends of the user application (defined by the programmer)
- Can only accessed if the application is "loaded"

Change the address/ association table

The address and the association table can be easily modified (without changing of maximum size) by writing new values in it. In this case it must be assured that no malfunctions occur during the modification process. This can be done by setting the length of the address table to one and the length of the association table to zero during the modification. After the modification is finished the lengths can be set to the desired value and a "load complete" event must be generated to update the checksum. Changing the maximum size of the tables is more complicated. In any case the memory layout defined by the developer must not be corrupted.

1. Connecting | Connect
2. Getting the access rights | Authorize if required.
3. Verifying BCU version | Check for the correct mask type, mask version.
4. Modifying the address table | Verify that AddressTable.LoadState == 'Loaded'. Set AddressTable.Loadcontrol = StartLoad LoadState must then change to 'Loading'. Change the data by direct memory access (absolute code + data) LoadState must then change to 'Loaded'.
5. Modifying the association table | Verify that AssociationTable.LoadState == 'Loaded'. Set AssociationTable.Loadcontrol = StartLoad LoadState must then change to 'Loading'. Change the data by direct memory access (absolute code + data) Set AssociationTable.Loadcontrol = LoadComplete LoadState must then change to 'Loaded'.
6. Disconnecting | Disconnect

Change the physical address

  • Setting the physical address by pressing program button

Do not change the physical address directly (possible CRC of address table MCB!)

1. Check for existence

Try to connect (T_CONNECT) to a device with the specified physical address.

2. Check for selection

Check using the PhysAddrRead-service via broadcast, whether the programming button of a device was pressed, inform the user, and wait. In the case of multiple selection the procedure breaks off with an error message. In the case that a device with the specified physical address was found but not selected the procedure breaks off with an error message.

3. Programming the physical address

Program the physical address using the PhysAddrWrite-service via broadcast.

4. Verify programming

Set up a communication connection to the specified physical address.

5. Reset the device

Use the Reset-service to reset the device.
Note that by this operation the programming LED is switched off first, and second the communication connection breaks down.

  • Setting the physical address by serial number

Do not change the physical address directly (possible CRC of address table MCB!)

1. Check for existence

Try to connect (T_CONNECT) to a device with the specified physical address.

2. Check for selection

Check using the PhysAddrReadSerialno-service via broadcast, if the device with the specified serial number exists or not. In the case that a device with the specified physical address was found but not specified serialnumber the procedure breaks off with an error message.

3. Programming the physical address

Program the physical address using the PhysAddrWriteSerialno-service via broadcast.

4. Verify programming

Set up a communication connection to the specified physical address.

5. Reset the device

Use the Reset-service to reset the device
Note by this operation the communication connection breaks down.


Device Object

Property Name/ Memory Type | Property ID | Value | Type | Number of Elements | Access read / write
Object ID / EEPROM | PID_OBJECT_TYPE | 1d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ read only
Device Control/ RAM | PID_DEVICE_CONTROL | 14d | PT_GENERIC01 | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Service Control / EEPROM | PID_SERVICE_CONTROL | 8d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Firmware Revision / ROM | PID_FIRMWARE_REVISION | 9d | PT_UNSIGNED_CHAR | 1 | PRIVILEGE_NO/ read only
Serial Number* / EEPROM | PID_SERIAL_NUMBER | 11d | PT_GENERIC06 | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Manufacturer ID* / EEPROM | PID_MANUFACTURER_ID | 12d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Order Info* / EEPROM | PID_ORDER_INFO | 15d | PT_GENERIC10 | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
PEI-Type / RAM | PID_PEI_TYPE | 16d | PT_UNSIGNED_CHAR | 1 | PRIVILEGE_NO/ read only
Pollgroup Settings / EEPROM | PID_POLL_GROUP_ SETTINGS | 18d | PT_POLL_GROUP_ SETTINGS | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
PortA DDR / EEPROM | PID_PORTADDR | 17d | PT_UNSIGNED_CHAR | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Manufacturer Data* / EEPROM | PID_MANUFACTURE_ID | 19d | PT_GENERIC04 | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION

* Writeable only on BCU 2.1

PID_OBJECT_TYPE

object type of the device object (00h)

PID_DEVICE_CONTROL

temporary controlfield for the device

Bit

00

user stopped

set if bit 0 in PID_SERVICE_CONTROL is 1 and the run state changed from running to stopped.

Bit

01

frame with the own physical address was received

set if bit 1 in PID_SERVICE_CONTROL is 1 and a telegram with the own physical address as the source address was received.

Bit

02

verify mode on

If set to 1, verify mode is enabled. If the verify mode is enabled during a TL connection, the system answers each reveived A_Memory_Write with an A_Memory_Response automatically.

Verfiy mode is automatically disabled when the TL connection is finished. (e.g. T_Disconnect).

Bit

03-07

reserved

PID_SERVICE_CONTROL |  |  |  | permanent controlfield for the device
 | Bit | 00 | user stoped srvinfo enable If enabled, each changing of the run state from running to stopped triggers a message (A_ServiceInformation_Indication_Write) with the contents of PID_DEVICE_CONTROL as data. Note: changing the PEI type manually may trigger a lot of messages. |  | (1=enable ; 0=disable)
 | Bit | 01 | receive own physaddr srvinfo enable If enabled, each received telegram with the own physical address as the source address triggers a message (A_ServiceInformation_Indication_Write). |  | (1=enable ; 0=disable)
 | Bit | 02 | physical address write enable If disabled, the system does not allow changing of the physical address (via services A_IndividualAddress_Write or A_IndividualAddressSerialNumber_Write). |  | (0=enable ; 1=disable)
 | Bit | 03 | reserved |  |
 | Bit | 04-07 | reserved |  |
 | Bit | 08 | userlayer- services on EMI disable |  | (1=disable ; 0=enable)
 | Bit | 09 | linklayer- services on EMI disable |  | (1=disable ; 0=enable)
 | Bit | 10 | networklayer- services on EMI disable |  | (1=disable ; 0=enable)
 | Bit | 11 | transportlayer group- services on EMI disable |  | (1=disable ; 0=enable)
 | Bit | 12 | switch service- services on EMI disable |  | (1=disable ; 0=enable)
 | Bit | 13 | transportlayer connection oriented- services on EMI disable |  | (1=disable ; 0=enable)
 | Bit | 14 | application layer- services on EMI disable |  | (1=disable ; 0=enable)
 | Bit | 15 | management- services on EMI disable |  | (1=disable ; 0=enable)

PID_FIRMWARE_REVISION | revision number of the firmware starting with 00h
PID_SERIAL_NUMBER | serial number (unsigned char[6])
PID_MANUFCTURE_ID | manufactur specific ID
PID_ORDER_INFO | manufacture specific order ID
PID_PEI_TYPE | actual connected (HW resistor) PEI type

PID_POLL_GROUP_SETTINGS

2 byte polling group, 1byte slotnumber

Polling group address (16 bit) | PollingSlotNo (S)
AAAA AAAA AAAA AAAA | E000SSSS E(1=disable, 0=enable)

PID_PORTADDR

direction register for PORTA (0=input; 1=output)


Address Table Object

Property Name/ Memory Typ | Property ID | Value | Type | Number of Elements | Access read / write
Object ID / EEPROM | PID_OBJECT_TYPE | 1d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ read only
Load Control / EEPROM | PID_LOAD_STATE_CONTROL | 5d | PT_CONTROL | 1 | PRIVILEGE_NO/ PRIVILEGE_SERVICE
Addresstable Pointer / EEPROM | PID_TABLE_REFERENCE | 7d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ read only

PID_OBJECT_TYPE | object type of the address table (01h)
PID_LOAD_STATE_CONTROL | for further Information see Load/ Statemachines
PID_TABLE_REFERENCE | pointer to address table

 | Address Table | Length (bytes) |  | Remark (receiving/ sending)
Connection nr. | length | 1 | Lo mem | number of entries (max. 127)
0 | physical address | 2 | ß | physical/ broadcast addresssed telegrams are independent from loadstate of address table on address table length of "0" the loadstate of address table is unimportant 0 entries : all group addresses accepted, 1 entry : no group address accepted, max. 127 entries (sorted in ascending order) loadstate <> loaded inhibits sending any group telegram
1 | group address 1 | 2
2 | group address 2 | 2
3 | group address 3 | 2
... | ... | 2
n | group address n | 2 | Hi mem

Physical Address

Bit # | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | area address |  |  |  | line address |  |  |  | device address

Group Address

Bit # | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | group address

group address 0000H is reserved as the broadcast address.


Association Table Object

Property name/ Memory Typ | Property ID/ number (decimal) | Value | Type | Number of Elements | Access read / write
Object ID / EEPROM | PID_OBJECT_TYPE | 1d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ read only
Load Control / EEPROM | PID_LOAD_STATE_CONTROL | 5d | PT_CONTROL | 1 | PRIVILEGE_NO/ PRIVILEGE_SERVICE
Associationtable Pointer / EEPROM | PID_TABLE_REFERENCE | 7d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ read only

PID_OBJECT_TYPE | object type of the address table (02h)
PID_LOAD_STATE_CONTROL | for further information see Load/ Statemachines
PID_TABLE_REFERENCE | pointer to association table

 | Assoc. Table |  | Length (bytes) |  | Remark
Association nr. | length |  | 1 | Lo mem | number of associations (max. 255)
0 | cr_id 1 | SAP nr. 0 | 2 | ß | on standard callback SAP=com object number
1 | cr_id 2 | SAP nr. 1 | 2 |  | first entries are the sending entries (SAP’s)
2 | cr_id 3 | SAP nr. 2 | 2 |  |
3 | cr_id 4 | SAP nr. 3 | 2 |  |
... | ... | ... | 2 |  |
n | cr_id n | SAP nr. n | 2 | Hi mem |


Application Program Object

Property Name/ Memory Typ | Property ID | Value | Type | Max. Number of Elements | Access read / write
Object ID / EEPROM | PID_OBJECT_TYPE | 1d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ read only
Load Control / EEPROM | PID_LOAD_STATE_CONTROL | 5d | PT_CONTROL | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Run Control / RAM | PID_RUN_STATE_CONTROL | 6d | PT_CONTROL | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
PEI-Type Required / EEPROM | PID_PEI_TYPE | 16d | PT_UNSIGNED_CHAR | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Application Version / EEPROM | PID_APPLICATION_VER | 13d | PT_GENERIC05 | 1 | PRIVILEGE_NO/ PRIVILEGE_CONFIGURATION
Groupobject Tablereference / EEPROM | PID_TABLE_REFERENCE | 7d | PT_UNSIGNED_INT | 1 | PRIVILEGE_NO/ read only

PID_OBJECT_TYPE | object type of the programm object (03h)
PID_LOAD_STATE_CONTROL | for further information see Load/State Machines
PID_RUN_STATE_CONTROL | for further information see Run/State Machines
PID_PEI_TYPE | required PEI type of user
PID_APPLICATION_VER |
PID_TABLE_REFERENCE | when using standard callback this pointer must point to the communication object table (must be loaded)

 | Communication Object Table |  |  | Length (bytes) |  | Remark
Object nr. | object count |  |  | 1 | Lo mem | number of communication objects (max .85)
 | RAM flag table pointer |  |  | 1 | ß |
0 | Data pointer | Config byte | Type byte | 3 (1/1/1) |  |
1 | Data pointer | Config byte | Type byte | 3 (1/1/1) |  |
2 | Data pointer | Config byte | Type byte | 3 (1/1/1) |  |
... | ... | ... | ... | 3 (1/1/1) |  |
n | Data pointer | Config byte | Type byte | 3 (1/1/1) | Hi mem |

DataPointer

pointer to memory

ConfigByte |  |
Bit | 0,1 | transmission priority | 00 01 10 11 | reserved (system priority) alarm priority high operational priority low operational priority | Times
Bit | 2 | communication enable | 1 0 | = enabled = disabled | see Message cycle see Polling cycle
Bit | 3 | read enable | 1 0 | = enabled = disabled |
Bit | 4 | write enable | 1 0 | = enabled = disabled | "disable" inhibits any updates (it doesn`t matter if response update is set)
Bit | 5 | memory segment select | 0 1 | = CobjSeg0 = CobjSeg1 (use Seg.selector 0/1) | in BCU 1 style: 0 : Seg.selector offset = 000h) 1 : Seg.selector offset = 100h)
Bit | 6 | transmit enable | 1 0 | = enable = disable | see Message cycle see Polling cycle
Bit | 7 | response update | 1 0 | = update on response = no update on response |

TypeByte
Code | Symbol | value-size |
0 | UINT1 | 1 bit | Bit 6 and Bit 7 of the type byte must be 0
1 | UINT2 | 2 bit | Bit 6 and Bit 7 of the type byte must be 0
2 | UINT3 | 3 bit | Bit 6 and Bit 7 of the type byte must be 0
3 | UINT4 | 4 bit | Bit 6 and Bit 7 of the type byte must be 0
4 | UINT5 | 5 bit | Bit 6 and Bit 7 of the type byte must be 0
5 | UINT6 | 6 bit | Bit 6 and Bit 7 of the type byte must be 0
6 | UINT7 | 7 bit | Bit 6 and Bit 7 of the type byte must be 0
7 | UINT8 | 1 byte | Bit 6 and Bit 7 of the type byte must be 0
8 | UINT16 | 2 byte | Bit 6 and Bit 7 of the type byte must be 0
9 | TIME_DATE | 3 byte | Bit 6 and Bit 7 of the type byte must be 0
10 | FLOAT | 4 byte | Bit 6 and Bit 7 of the type byte must be 0
11 | DATA6 | 6 byte | Bit 6 and Bit 7 of the type byte must be 0
12 | DOUBLE | 8 byte | Bit 6 and Bit 7 of the type byte must be 0
13 | DATA10 | 10 byte | Bit 6 and Bit 7 of the type byte must be 0
14 | MAXDATA | 14 byte | Bit 6 and Bit 7 of the type byte must be 0
15 | VARDATA | 1-14 bytes | not supported by standard callback

RAMFlagTable

Byte 0 | Comms-Flag 1 | Comms-Flag 0 | (low memory)
Byte 1 | Comms-Flag 3 | Comms-Flag 2 |
... | ... | ... | (high memory)

CommFlags

bit 00-01 | transmission status | 00 idle/OK 01 idle/error 10 transmitting 11 transmit-request
bit 02 | data-request-flag | 0 = idle/response(arrived) 1 = data-request
bit 03 | update-flag (external) | 0 = not updated 1 = updated


Diagnostics

Diagnostic Possibilities

Problem | Examination by | Located in | Remark
Memory problems | Load states | - Addresstable object - Associationtable object - Application program object | CRC error : state = error
Download problems | Several propertys | - Device object | Manufacturer doesn't' match connected HW PEI type ...
Application problems | Run State | - Application program object - Runstate machine | State of application (start/stop ...) and start/ stop the application manual


BCU 2 User EIB Objects

User EIB Objects

To use User EIB Objects, the EIB-ObjectPointer and EIB-ObjectCount must be set during the load procedure with the Task Control Record1

EIB-ObjectPointer | Absolute address of User-EIB-Objects-Table
EIB-ObjectCount | Number of User EIB-Objects

The User EIB-Object-Table contain a 16-Bit pointer for each User-EIB-Object

High Byte

Low Byte

Pointer to User EIB-Object 1

Pointer to User EIB-Object 2

...

Pointer to User EIB-Object n

Each User EIB Object consists at least of the Object-ID Property

Access Level | Read (*) (4 Bit) | Write (*) (4 Bit) |
Property Count | n (1 Byte)
Property 1 | PID_OBJECT_ID (1 Byte) |  | PUINT (1 Byte) | OBJECT-ID High (1 Byte) | OBJECT-ID Low (1 Byte)
Property 2 | PID_USER 1 |  | PropCtrl 1 | Variable | Variable
... | ... |  | ... | ... | ...
Property n | PID_USER n |  | PropCtrl n | Variable n | Variable n

The internal access to the objects depends of the different levels ...

  • Current system access level

  • R/W rigths of property, [(*) one definition of level per object, valid for each property]


Attributes of Properties

All properties are accessible by general management service.

Byte 0 | Byte 1 |  |  |  | Byte 2 |  | Byte 3
Property-ID | Property Control (8bit) |  |  |  | Variable (16bit)
1 byte | Write (1bit) | Array (1bit) | Ptr (1bit) | Type (5bit) | Function bit (1bit) | Pointer High (7bit) | Pointer Low (8bit)

Property-ID

1 Byte

Property ID of User Property (201-255)

Write

1 Bit

0 Property is read-only
1 Property is read and write enable

Array

1 Bit

0 No Array
1 Pointer to Array (absolute 255 Byte possible)

Ptr

1 Bit

0 No Pointer. Value direct in property
1 Pointer to Value, Array or Function

Type

5 Bit

Property Data Type | Type Code | Type Length
PT_CONTROL | 00h | 1 read / 10 write
PT_CHAR | 01h | 1
PT_UNSIGNED_CHAR | 02h | 1
PT_INT | 03h | 2
PT_UNSIGNED_INT | 04h | 2
PT_EIB_FLOAT | 05h | 2
PT_DATE | 06h | 3
PT_TIME | 07h | 3
PT_LONG | 08h | 4
PT_UNSIGNED_LONG | 09h | 4
PT_FLOAT | 0Ah | 4
PT_DOUBLE | 0Bh | 8
PT_CHAR_BLOCK | 0Ch | 10
PT_POLL_GROUP_SETTING | 0Dh | 3
PT_SHORT_CHAR_BLOCK | 0Eh | 5
PT_GENERIC01 | 11h | 1
PT_GENERIC02 | 12h | 2
PT_GENERIC03 | 13h | 3
PT_GENERIC04 | 14h | 4
PT_GENERIC05 | 15h | 5
PT_GENERIC06 | 16h | 6
PT_GENERIC07 | 17h | 7
PT_GENERIC08 | 18h | 8
PT_GENERIC09 | 19h | 9
PT_GENERIC10 | 1Ah | 10

Variable/Pointer

16/15 Bit

Pointer 0 / Array 0 | Property Value
Pointer 1 / Array 0 | Pointer to Value / Function
Pointer 0 / Array 1 | Not defined
Pointer 1 / Array 1 | Pointer to Array structure

Function bit

1 Bit

0

variable / array pointer

1

pointer to Userfunction with following parameters:

Input | carry = | 0 Property Read 1 Property Write
 | X = Pointer to message buffer
Output | carry = | 0 Read OK 1 Read not OK
 | X = Pointer to message buffer
 | acca = Message length

In case of defining a userfunction the user has to fill up the complete message buffer with the requested data. For property writing the user function is called once as property writing and second as property read.

Array structure (must be in EEPROM)

byte 0 | byte 1 | byte 2
max element count | pointer to array

Array (EEPROM/ RAM)

byte 0 | byte 1 ... (n*typelength)
actual element count | element 1 | element 2 | ... | element n


EIB Objects Access

EIB Object Access


Standard Callback / UserCallBack-Interface

A callback function interface is defined within the BCU 2. This allows the application engineer to program access routines to either group-objects or EIB application objects as efficient as necessary for the application. Especially for group-objects the data interface access procedures may be an overhead for the internal user application, which can be reduced by an own callback function interface. Some examples show the

Mechanism and logical flow from object til groupaddress,
Mechanism for the polling cycle,
Mechanism for the message cycle,
Service handling on message/ polling cycle.

on standard callback handling.

Note:
If an own callback is used, this part of the user will run as an part of system management. This means that the conditions for running an own callback are the same as for the user application. The equation of

AppCallBack equ AL_SAPcallback (AL_SAPcallback = 5081h)

in the <Project.asm> file performs an write of standard callback address (5081h) into the TaskControlRecord2. By handling BCU 1 group communication objects (BCU 1.x application loaded) always the standard callback is active. If an user callback is used the equation is defined in that form

AppCallBack equ AppCallBack (AppCallBack = 1xxh ... 4xxh)

where the equation must not defined again by user, because the label is yet defined as entry label of user callback. The AppCallBack is then responsible for handling the own communication objects / user EIB objects.
For an own callback function the same interface is used as for the standard callback.

Attention:
If standard communication objects are used and a own callback is only supplementary to the standard callback (like the example below), beware of recursion by internal update of communication objects. Take care of setting unconditional "Transmit requests" for a lot of objects. If the first arriving confirm reset the "transmitting" flags (in RAM flags), the application will force new "transmit requests" to these objetcts and so the other objects won't be transmitted on the bus (search direction for objects from low (0) .. high )

ON returncode 0 (SAP_CB_OK) don't change contents of messagebuffer (will be post away).
ON returncode 3 (SAP_CB_SEND) don't change RegK (internal loop variable).

Symbol: | AL_SAPcallback
Call-Address: | 5081H
Description: | Complete handling of GroupCommunicationObjects and User-EIB-Objects
Inputs: | X | Index to message
 | Carry | 0: polling mode: 1: message mode: | call one times in a cycle call if an message for an object is received either a group communication object or a EIB object (ASAP = FFh)
Outputs: | X | index to message
 | A | state
 |  | 0 : SAP_CB_OK (return messagebuffer to system)
 |  | 1 : SAP_CB_BREAK (break and free buffer)
 |  | 2 : SAP_CB_GETBUF (hold buffer and break)
 |  | 3 : SAP_CB_SEND (send message and break)
Effects: | changes A, X, RegB-RegN

Example: | ... |  |
 | AppCallBack |  | ;user entry for callback
 |  | bcc Nomsg |
 | * Message received
 |  | lda UMSG_COM_NR,x | ;load ASAP number
 |  | cmp #06 | ;check if object #6 accessed
 |  | bne STDcallback |
 | * handle own object #6
 | ... |  |
 | STDcallback |  |
 |  | sec | ;mark message mode
 | Nomsg | jmp AL_SAPcallback | ;use standard callback


Mech message

Mechanism on Message Cycle (Std. Callback Handler)

The system calls the Standard Callback Handler/ own Callback Handler (with message mode) under the following condition :

  • Association table must be "loaded"

AL_CallbackHandler (Standard Callback Handler)

Incoming T_Group_Data_conf :

  1. Set object (ramflags) of former T_Group_Data_requ

  2. Return (SAP_CB_OK)

Incoming T_Group_Data_ind :

  1. Get properties of object, on error (object not found) return (SAP_CB_OK)

  2. Check if object "communication enable", on error return (SAP_CB_OK)
  3. Check APCI
    • on value read : check readable

      • error : return (SAP_CB_OK)

      • ok: read object data, set APCI response, return (SAP_CB_SEND)

    • on value write : check writeable

      • error : return (SAP_CB_OK)

      • ok: copy object data, return (SAP_CB_OK)

    • on value response : check writeable/ response update

      • error : return (SAP_CB_OK)

      • ok: copy object data, return (SAP_CB_OK)

    • on unknown APCI : return (SAP_CB_BREAK)

  • Message with T_Group_Data_ind occurs (at this point the SAP is unknown ...)

- Call handler with T_Group_Data_ind
- depends on the "return values" of handler the following things will be done :

    • SAP_CB_SEND (value read forces value response )

      • save on to SAP

      • get cn

      • force T_Group_Datat_requ

    • SAP_CB_GETBUF

      • return without clearing message

    • SAP_CB_BREAK

      • event occurs in standard handler only on no value read/ write/ response APCI

      • return with clearing message

    • SAP_CB_OK (value write/ response)

      • call handler again with same T_Group_Data_ind

      • do internal update of possible other linked objects

      • do it as long as valid associations are available

      • after no other association available handle possible "A_Event" generation for value write/ response

        • A_Event behavior enabled : post "A_Event"

        • A_Event behavior disabled : return with clearing message

        • content in A_Event is TSAP

  • Message with T_Group_Datat_conf occurs (the SAP inside the message is an valid SAP depend on the former T_Group_Data_requ)

- Call handler with T_Group_Datat_conf
- Depends on the "return values" of handler the following things will be done :

    • SAP_CB_SEND (system needs no conf -> requ behavior, but beware of damned programmers ...)

      • save on to SAP

      • get cn

      • force T_Group_Datat_requ

    • SAP_CB_GETBUF

      • return without clearing message

    • SAP_CB_BREAK

      • return with clearing message

    • SAP_CB_OK

      • convert confirm -> indication (simulate the own request as an external indication)

      • on APCI value read : return with clearing message

      • on APCI write/response : do internal update of possible other linked objects

Information Flow


Mech polling

Mechanism on Polling Cycle (Std. Callback Handler)

The scheduler calls cyclic the Standard Callback Handler/ own Callback Handler (with polling mode) with success under the following conditions :

  • Association table must be "loaded"

  • Message buffer must be available

AL_CallbackHandler (Standard Callback Handler)

  1. search object with status "transmit request" with index from 0 .. max, if no object found -> return(SAP_CB_BREAK)

  2. check telegram rate limitation (based on timer)
  3. check object properties (transmit enable, communication enable), on error set object (RAM flags) to transmiterror
  4. set object (RAM flags) to transmitting
  5. set buspriority in CTRL byte of frame
  6. value read : -> data request : set object number to read,set APCI
  7. value write : -> no data request : set object number to write, copy object data, set APCI
  8. return (SAP_CB_SEND)

Depend on the "return values" of handler the following things will be done :

  • SAP_CB_SEND

    1. save on to SAP

    2. get cn (on error - cn not exists - negative T_Group_Data_conf)
    3. get sn
    4. check sn <> on (on error - this is not a sending object - negative T_Group_Data_conf [AL : set errorflags in object] )
    5. force T_Group_Datat_requ (per scheduler cycle only one request)

  • Other -> clears message

Information flow


Objects handling

Mechanism and logical flow from objects til groupaddress


Mech service

Service handling on polling/ message cycle (standard handler)

REMARKS

The left side of the picture shows inputs of a possible T_Group_Data_requ. Only the APCI's ValueRead/ Write leads to this service. The same way is valid for user request A_GROUP_DATA_requ. The right side shows the different handling for the incoming confirm or indication.


BCU 2 Loadable PEI-Handler

Loadable PEI-Handler

The PEI Handler can be implemented as an event handler which receive hardware and software events. In general the system distinguish between

  • Standard PEI handler (several PEI types)

  • Own PEI handler (only available on PEI type 10)

Just one handler is active at the same time. The own PEI handler is only called if no EEPROM write access is active. This means, that on EEPROM write access (needs ~20 ms) data overflow could be occurs when more than one PEI event "happens" in this time range (~20ms). The own PEI handler is called only if user run conditions are fulfilled.

Take care that the time stay in interrupt is not longer than possible interrupt load "frequen cy"!

Events : hardware

  • Handler called based on HW interrupt

  • Event in acca

Hardware event description | constant name | event code | PEI-Info
SCI flag RDRF set, receiver is configurated with even parity (9 data bits) | rc_even | 03h | received data from UART
SCI flag RDRF set, receiver is configurated with odd (9 data bits)/ none parity (8 data bits) | rc_odd/ rc_none | 13h | received data from UART
SCI flag TC set | tc | 14h | - UART2
SCI flag TDRE set | tdre | 05h | -
SCI flag IDLE | sci_idle | 06h | -
SPI flag SPIF set | spif | 08h | received data from UART
Output Compare A | OCA | 10h | timer value hi (res. 0.4166 ms)
Output Compare B | OCB | 20h | timer value hi (res. 0.4166 ms)
Input Capture A | ICA | 30h | timer value hi (res. 0.4166 ms)
Input Capture B | ICB | 40h | timer value hi (res. 0.4166 ms)

Events : software

  • Handler called based on SW interrupt

  • Event in acca

Software event description | constant name | event specification
system wants to transmit any message via PEI to an external device | PM_MESSAGE | F1h (message is located in PEI_SndBuf)
Cyclic call (called once in each scheduler cycle, except if there is one of the other events) | PM_CYCLE | F2h
Initialisation | PM_INIT | F3h
Timer events | user defined with TS_Seti |

Handler : call

  • Handler is calling if runstate of application is running or ready

  • Handler is calling if no EEPROM write access is active

Handler : definition

  • With EIB IDE/ New project/ Options PEI driver [x]

With these option one additional file is created (PEI.asm) which consists the template for the own PEI driver.

  • Download the activation of handler via Task Pointer Record

- Standard handler is active when the pointer to serial handler (SP_Handler) is "zero"
- Own handler is active when pointer to serial handler (SP_Handler) is not "zero"
(in this case the pointer points to the beginning of own handler code e.g. label SP_Handler)

Handler : initialization

  • Asynchronous communication U_SCI_Init

  • Synchronous communication U_SPI_Init.
  • Happen in PEI handler block (<PEI.asm>)

Take care of the requested int's and there activation

PORTC : initialisation

  • DDRC bit settings (depend of the own selected protocol) with %PortCDDR

  • Happen in Appmain/ Macro block (<Project>.asm)


Information Flow on Own PEI Driver


BCU 2 Reserved memory for PEI-Handler

Reserved Memory for PEI Handler

PEI_REC_BUFFER

serial receive buffer (25 byte), implicitly used with the serial buffer post flag

PEI_SND_BUFFER

serial send buffer (25 Byte), implicitly useed with the serial buffer semaphore

PEI_Interface

Bit 0

reserved

Bit 1

flag (use in standard handler with the following behaviour)

  • This flag marks an occupation of the PEI_SND_BUFFER (overwrite locking).

  • As long as the flag is set the PEI handler accepts no other message from the message system to be transmitted over the PEI.

  • The PEI handler resets the flag after successful transmission or after the last repetition was sent.

Bit 2

reserved

Bit 3

reserved

Bit 4

reserved

Bit 5

reserved

Bit 6

reserved

Bit 7

flag (use in standard handler with the following behaviour)

  • This flag marks the reception of a complete frame over the PEI and posts the PEI_REC_BUFFER to the required layer.

  • The PEI handler resets the flag after the message was posted successfully.

PEI_Info

additional data, event dependent


UART1

Description for enable/ disable several interrupts over registers SCCR2


UART2

Description for interrupt registers SCSR


UART3

Description for enable/ disable 8/ 9 databits over registers SCCR1


UART4

Description for enable/ disable OCA/ OCB ... and the interrupt register
(take care that the register TCR1/ TSR are not public in the EIB-IDE macros)


UART5

  • General data flow on PEI typ 16/12

REMARK

The sending device is responsible for the pause of 3 ms after each data block, if the time is not correct the receiving BCU forces no error (in case of BCU is slave device)

  • Data on synchronous transmission

REMARK:

If the master signals to the slave "request for data tranfer" (RTS) he must be able to handle a starting data transmission of slave immediatly after the slave responds with CTS independent if transmission starts with possible startbit or not. This means that the master can't suppose that any start bit is transmitting first at all and this time of bit can be used for any internal initialization af master.

  • Data on asynchronous transmission


Physical External Interface (PEI)

The electrical and logical properties of the PEI connector lines depend on the PEI type given by the periphery module. Different functional types of physical external interfaces are available for the various applications.

The PEI lines for 20V (pin 8), 5V (pin 5), ground (pin 1 and pin 10) and PEI type selection (pin 6) are the same for all PEI types. The following table shows the logical specification of the other PEI lines, depend on the PEI type supported by System BCU 2.

PEI-Type / Resistor- Type [kOhm] | Functional Description | PEI pin 2 I/O 2 RxD/ AD7 | PEI pin 3 I/O 1 SCLK (syn) / AD6 | PEI pin 4 I/O 3 TxD/ AD5 | PEI pin 5a PWM2 - | PEI pin 6a I/O 6 AD4 - | PEI pin 7 I/O 4 CTS/ AD3 | PEI pin 9 I/O 5 RTS/ AD2
00 / - | No adapter
01 / 910 | illegal adapter
02 / 430 | 4 inputs, 1 output (LED) | INPUT | INPUT | INPUT | OUTPUT | OUTPUT | INPUT | OUTPUT
03 / 355 | reserved
04 / 187 | 2 inputs, 2 outputs + 1 output (LED) | OUTPUT | OUTPUT | INPUT | OUTPUT | OUTPUT | INPUT | OUTPUT
05 / 140 | reserved
06 / 107 | 3 inputs, 1 output + 1 output (LED) | INPUT | OUTPUT | INPUT | OUTPUT | OUTPUT | INPUT | OUTPUT
07 / 84.5 | reserved
08 / 66.5 | 5 inputs | INPUT | INPUT | INPUT | OUTPUT | OUTPUT | INPUT | INPUT
09 / 54.9 | reserved
10 / 45.3 | default: FT1.2 protocol | ser. input: RxD | def. by user | ser. output: TxD | def. by user | def. by user | def. by user | def. by user
 | loadable serial protocol | ser. input: RxD | def. by user | ser. output: TxD | def. by user | def. by user | def. by user | def. by user
11 / 37.4 | reserved
12 / 30.1 | serial synchronous interface message protocol | ser. input RDI | output: SCLK | ser. output: TDO | OUTPUT | OUTPUT | CTS | RTS
13 / 24.3 | reserved
14 / 19.1 | serial synchronous interface data block protocol | ser. input: RDI | output: SCLK | ser. output: TDO | OUTPUT | OUTPUT | CTS | RTS
15 / 14.7 | reserved
16 / 11.0 | serial asynchronous interface, message protocol | ser. input: RXD | OUTPUT | ser. output: TxD | OUTPUT | OUTPUT | CTS | RTS
17 / 7.5 | programmable I/O | def. by user | def. by user | def. by user | OUTPUT | OUTPUT | def. by user | def. by user
18 / 4.53 | reserved
19 / 2.0 | 4 outputs, 1 output (LED) | OUTPUT | OUTPUT | OUTPUT | OUTPUT | OUTPUT | OUTPUT | OUTPUT
20 / 0 | Initialization | ser. input: RxD | OUTPUT | ser. output: TxD | OUTPUT | OUTPUT | CTS | RTS


PEI Pin Description

PEI-Pinning

5a

5

4 (In1)

3 (Out 1)

2 (Out 2)

1

PLMB | +5V | PortC.3 TxD/ AD5 I/O 3 | PortC.4 CLK/ AD6 I/O 1 | PortC.2 RxD/ AD7 I/O 2 | Ground
PortC.7 AD4 I/O 6 | PEI-Type | PortC.6 CTS/ AD3 I/O 4 | +20V | PortC.5 RTS/ AD2 I/O 5 | Ground

6a

6

7 (In 2)

8

9

10


External Message Interface

For internal and external purposes each service primitive corresponds to a unique message code. The following table summarises the names and values of the internal constants at the BCU 1/ BCU 2.

  • On PEI type 12/ 16 service codes of EMI 1 active

  • On PEI type 10 (FT 1.2) service codes of EMI 2 active
  • System uses internally only EMI 2 services codes, dependent on PEI type they will be converted
Link Layer Service Primitives | Message Code PEI-Type 10 | Message Code PEI-Type 12/16 | Destination (Layer)
L_Data.requ | 11 | 11 | LL
L_Data.ind | 29 | 49 | NL
L_Data.conf | 2E | 4E | NL
L_Busmon.ind | 2B | 49 | NL/PEI
L_Polldata.requ | 13 | - | LL
L_Polldata.conf | 25 | - | NL

Network Layer Service Primitives | Message Code PEI-Type 10 | Message Code PEI-Type 12/16 | Destination (Layer)
N_DataGroup.requ | 22 | - | NL
N_DataGroup.ind | 3A | - | TL grp
N_DataGroup.conf | 3E | - | TL grp
N_DataConnected.requ | 21 | - | NL
N_DataConnected.ind | 49 | - | TL co
N_DataConnected.conf | 4E | - | TL co
N_Broadcast.requ | 2C | - | NL
N_Broadcast.ind | 4D | - | TL cl
N_Broadcast.conf | 4F | - | TL cl
N_Polldata.requ | 23 | - | NL
N_Polldata.conf | 35 | - | TL grp

Transport Layer Service Primitives | Message Code PEI-Type 10 | Message Code PEI-Type 12/16 | Destination (Layer)
T_DataGroup.requ | 32 | 22 | TL grp
T_DataGroup.ind | 7A | 4A | AL grp
T_DataGroup.conf | 7E | 4E | AL grp
T_DataConnected.requ | 41 | 21 | TL co
T_DataConnected.ind | 89 | 49 | AL co
T_DataConnected.conf | 8E | - | AL co
T_DataIndividual.requ | 4A | - | TL cl
T_DataIndividual.ind | 94 | - | AL cl
T_DataIndividual.conf | 9C | - | AL cl
T_Connect_requ | 43 | 23 | TL co
T_Connect_ind | 85 | 43 | PEI
T_Connect.conf | 86 | - | PEI
T_Disconnect.requ | 44 | 24 | TL co
T_Disconnect.ind | 87 | 44 | PEI
T_Disconnect.conf | 88 | - | PEI
T_Broadcast.requ | 4C | - | TL cl
T_Broadcast.ind | 8D | - | AL cl
T_Broadcast.conf | 8F | - | AL cl
T_Polldata.requ | 33 | - | TL grp
T_Polldata.conf | 75 | - | AL
T_Local_requ | 46 | - | TL grp
T_Local.ind | 92 | - | TL grp
T_Local.conf | 97 (not used) | - | TL grp

Application Layer Service Primitives | Message Code PEI-Type 10 | Message Code PEI-Type 12/16 | Destination (Layer)
A_DataGroup.requ | 72 | - | AL
A_DataGroup.ind | EA | - | User
A_DataGroup.conf | EE | - | User
A_Polldata.requ | 73 | - | AL
A_Polldata.conf | E5 | - | User
M_UserDataConnected.requ | 82 | 31 | AL co
M_UserDataConnected.ind | D2 | 49 | User
M_UserDataConnected.conf | D1 | - | User
M_IntObjData.requ | 9A | - | AL co+cl
M_IntObjData.ind | D4 | - | User
M_IntObjData.conf | DC | - | User
M_Connect_ind | D5 | - | User
M_Disconnect_ind | D7 | - | User

PEI Service Primitives | Message Code PEI-Type 10 | Message Code PEI-Type 12/16 | Destination (Layer)
U_ValueRead.requ | 74 | 35 | AL grp
U_ValueRead.conf | E4 | 45 | User
U_ValueWrite.requ | 71 | 36 | AL grp
U_Event.ind | E7 | 4D | User
U_FlagsRead.requ | 7C | 37 | AL grp
U_FlagsRead.conf | EC | 47 | User

PEI Basic Service Primitives | Message Code PEI-Type 10 | Message Code PEI-Type 12/16 | Destination (Layer)
PC_SetValue.requ (A) | A6 | 46 | -
PC_GetValue.requ (A) | AC | 4C | -
PC_GetValue.conf | AB | 4B | PEI
PEI_Identify.requ | A7 | - | -
PEI_Identify.conf | A8 | - | PEI
PEI_Switch.requ (A) | A9 | - | -

Other Service Primitives | Message Code PEI-Type 10 | Message Code PEI-Type 12/16 | Destination (Layer)
TM_Timer.ind | C1 | - | -

(A) : service is always available, independent of possible message redirection

(on any error there is an redirection to standard possible)


Services Overview

The following table shows all the intern BCU2 message codes in a two-dimensional table. The message codes consist of 2 parts. The first part (high nibble) is the number of the destination module, the second part (low nibble) is a independent number.

service | 0 (Hist) | 1 LL | 2 NL | 3 TLG | 4 TLC | 5 PLG | 6 PLC | 7 AL | 8 Mgmt | 9 Mgmt | A PEI | B debug | C Timer | D User(1) | E User(2) | F User(3)
0 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
1 |  | L_Data.req | N_Data.req |  | T_DataConnected.req |  |  | U_ValueWrite.req |  |  |  |  | TM_Timer.ind | A_UserData.con |  |
2 |  |  | N_DataGroup.req | T_DataGroup.req |  |  |  | A_R/WGroup.req | A_UserData.req | T_Local.ind |  |  |  | A_UserData.ind |  |
3 |  |  | N_Polldata.req | T_Polldata.req | T_Connect.req |  |  | A_Polldata.req |  |  |  |  |  |  |  |
4 |  |  |  |  | T_Disconnect.req |  |  | U_ValueRead.req |  | T_DataIndividual.ind |  |  |  | M_InterfaceObjData.ind | U_ValueRead.con |
5 |  |  | L_Polldata.con | N_Polldata.con |  |  |  | T_Polldata.con | TConnect.ind |  |  |  |  | A_Connect.ind | A_Polldata.con |
6 |  |  |  |  | T_Local.req |  |  |  | T_Connect.con |  | PC_SetValue.req |  |  |  |  |
7 |  |  |  |  |  |  |  |  | TDisconnect.ind | T_Local.con | PEI_Identify.req |  |  | A_Disconnect.ind | U_Event.ind |
8 |  |  |  |  |  |  |  |  | T_Disconnect.con |  | PEI_Identify.con |  |  |  |  |
9 |  |  | L_Data.ind |  | N_Data.ind |  |  |  | T_DataConnected.ind |  | PEI_Switch.req |  |  |  |  |
A |  |  |  | N_DataGroup.ind | T_DataIndividual.req |  |  | T_DataGroup.ind |  | M_IntObj Data..req | PEI_Switch.con |  |  |  | A_GroupData.ind |
B |  |  | L_Busmon.ind |  |  |  |  |  |  |  | PC_GeValue.con |  |  |  |  |
C |  |  | N_Broadcast.req |  | T_Broadcast.req |  |  | U_FlagsRead.req |  | T_Data Indivi- dual.con | PC_GetValue.req |  |  | M_IntObjData.con | U_FlagsRead.con |
D |  |  |  |  | N_Broadcast.ind |  |  |  | T_Broadcast.ind |  |  |  |  |  |  |
E |  |  | L_Data.con | N_DataGroup.con | N_Data.con |  |  | T_DataGroup.con | T_DataConnected.con |  |  |  |  |  | A_GroupData.con |
F |  |  |  |  | N_Broadcast.con |  |  |  | T_Broadcast.con |  |  |  |  |  |  |


PEI-Switch-Service

The PEI-Switch-Service has the function to switch message queues from one layer to an other. In the system BCU 2 each layer has an own message queue and it is possible to redirect this queue to an other layer. The message coding is shown underneath.

REMARK:

  • Value "0" in layer key means release a possible message for the assigned layer

  • Value <> "0" in system status forces a write of this value to System State

  • PEI switch service is always available (independent of possible message redirection)

Service | System Status | Layer Key
A9 | SS | LL | NL | TLG | TLC | TLL | AL | MG | PEI | USR | res.
1 byte | 1 byte | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits | 4 bits

Examples:

Normal Mode EXAMPLE

A9

00

1

2

3

4

5

6

7

8

9

A

Application Layer (possible messages to user redirect to PEI)

A9

00

1

2

3

4

5

6

7

8

8

A

Transport Layer Remote EXAMPLE

A9

00

1

2

3

4

4

8

8

8

0

A

Transport Layer Local EXAMPLE

A9

00

1

2

3

4

5

6

7

8

0

A

Link Layer ( all messages from LL redirect to PEI, IACK generation)

A9

00

1

8

3

4

5

6

7

8

0

A

Link Layer Busmonitor (all messages from LL redirect to PEI, no IACK generation)

A9

90h

1

8

3

4

5

6

7

8

0

A


Example for PEI Switch

The Local Transport Layer

Important for BCU 2 local access is the understanding of the local transport layer. Therefore here both the local and the (normal) remote transport layer are described.

COMMON RULE : when switched to local transport layer all messages from the PEI will be redirected ! (see Message System)

The local transport layer uses a different state machine than the remote TL. The differences are:

Property | TL remote | TL local
T_Connect | required for connection oriented services | always required
TACK | used | not used
Evaluation of TPCI | yes | no
connection timeout | used | used
necessary for | interface handling over RS232 | local download, local read/ write

Abbreviations in the following diagrams:

TC: connection-oriented transport layer

LC: local transport layer

A) Internal message redirection after PEI Switch service (1,2,3)

B) Example for different activities on local/ remote transport layer.


PEI-Identify-Service

The identify service is to get information about the local BCU.

PEI-Identify-Request

service

A7

1 byte

PEI-Identify-Response

service | physical address |  | serial number
A8 | ppppppp | pppppppp | ssssssss | ssssssss | ssssssss | ssssssss | ssssssss | ssssssss
1 byte | 2 byte |  | 6 byte


PEI Behavior on Reset


How to get connection between BIM 113 and external µC

How to connect an external µC to the BCU2

A difficult problem in developing applications is connecting an external µC to the BCU2. What type of application must be downloaded into the BIM an what are the restrictions for these applications? The next picture will give you an overview over the general communication between two bus devices and afterwards the details for the "internal" communication between the BCU2 an the µC in one of these devices.

Information Flow (for the example configuration below)

  1. Button on sensor is pushed

  2. Sensor forces an group value write on EIB

  3. Actuator BCU receives the message and informs external µC

  4. µC handles the action (switch on light) and responds the state to the BCU

  5. BCU responds on EIB the real state via A_GroupValue_Write to the sensor

  6. Sensor handles its own status LED dependent on the contents in status telegram

consists of
- BCU2 (BIM 113)
- external µC (as actuator) 		consists of
- BCU2 (BIM 113)
- push button (with status LED)
Application program (flow diagram)

 pMsg = Message(User);
if (pMsg)
{
if (pMsg = = CommObjAccess)
{
if (RequestedObject (CommObjAccess) = = NewUpdate)
Discard (CommObjAccess)
else
Allow (CommObjAccess)
}
CheckForUpdates();
:
:
}; 		Comments

// get message from external µC
// message for user available

// message is of type object access

// access to object with new update ?
// yes, discard this access

// no, allow this access

// check and inform ext. µC on possible // updates 		Application program (flow diagram)

 if (ButtonInput)
{
SetTransmitRequest(ButtonObject)
}
if (NewUpdate(StateObject))
{
Actualize(StateLED)
:
:
};

Comments

// check on button

// generate telegram

// check on new update

// update state LED


Internal Application Structure

The internal application consists of two parts, which handle the communication object access between an external µC and the internal application program, the application layer and the user layer. As in the example below, there are some critical parts on communication handling in combination with dual ram access via different layers. Problems with not synchronised RAM access can be avoided by a state machine in the user program.

External µC application requirements | Example for µC
1. use service code M_USER_DATA_ind for requests to BIM 2.check service code M_USER_DATA_requ from BIM | pMsg.ServiceCode = M_USER_DATA_ind PostMessage(pMsg) pMsg=GetMessage(User); if (pMsg) ...

User/ external µC application requirements Example for BCU 2.x

0. check service code M_USER_DATA_ind from ext. µC

1. use service M_USER_DATA_requ for requests to ext. µC

2. use a serial PEI type (10, FT12)

3. disable the "user delete message function" from OS

4. check for messages/ and service coding

5. release messages which the ext. µC does not need (this reduces PEI traffic)

--

--

%PeiType 10
%RouteCnt 060H

AppMain

jsr PopBuf
bcs getUserMessage ; message found ?
jmp CheckForUpdates ; no message found ...

getUserMessage:

lda UMSG_SERVICE,x ; check service
cmp #M_USER_DATA_ind ; request from external µC ?
beq User_data ; yes

lda #TASK_PM_ID
jmp U_MS_Post ; any other service (see hints on U_delMsgs API)

user_data:

lda UMSG_APCIE,x
and #07h ; mask only services from 0 .. 7
cmp #01

beq read_eeprom_var
cmp #02
beq write_eeprom_var
cmp #03

...

write_eeprom_var:

...

read_eeprom_var:

...

lda 116h ;read number of address table entries

sta UMSG_DAT0,x

lda #M_USER_DATA_requ; use service for requesting µC
sta UMSG_SERVICE,x ;len(indication) > len (request) else adjust len

lda #TASK_PM_ID ; set destination for service to PEI
jmp U_MS_Post ; post answer back to external µC

CheckForUpdates:

...


Problem on Faulty Status

Two-sided communication object access

A common problem results from two sided access on dual used communication objects, where such an object is used as input and also reflects the status of an action in the external µC (i.e. it is also an output object). The next picture will give you an example where the handling of communication objects is distributed to different layers AL and USR and leads in that way to such a problem. As the AL ignores the state of the RAM flags of the object it is possible that a newer object value is available but the old state from the external µC will overwrite the new value. The old state should be discarded. This problem can be solved by a semaphore controlling in the user application.

Time | Remark
t1 > t2 | the correct state will be returned (the first state occurred before the second GroupValueWrite)
t1 < t2 | from the view of requester the old status will be returned (the first state occurred after the second GroupValueWrite)


Overview API Reference

The addresses of API function on a BCU 2.0 system are the same as in a BCU 2.1 system.

Communication object manipulation

U_flagsGet | reading RAM flags
U_flagsSet | writing RAM flags
U_testObj | testing the RAM flags
U_transRequest | setting transmit request
*AL_SAPcallback | standard callback

EEPROM manipulation support functions

EEwrite | writing to EEPROM
EEsetChecksum | updating checksum
*U_EEWriteBlock | write EEPROM block

Timer support functions

TM_Load | starting system timer
TM_GetFlg | reading system timer status
U_SetTM | setting user timer
U_GetTM | reading user timer status
U_Delay | delay
*U_TS_Set | set BCU2 timer
*U_TS_Del | delete BCU2 timer
*U_TS_Seti | set BCU2 timer event mode

PEI support functions

U_ioAST | binary port access
U_SerialShift/ U_Char_Out | byte exchange via serial PEI
S_AstShift / S_LAstShift | data block exchange via serial PEI

Message handling functions

AllocBuf | buffer allocation
FreeBuf | buffer release
PopBuf | message request
*U_MS_Post | post a message to a specified messagequeue
*U_MS_Switch | redirects a message from one messagequeue to a other

Application support functions

U_debounce | debouncing
U_delMsgs | ignoring messages to the user
U_readAD | doing AD conversion
U_map | characterisation function
*U_GetAccess | get actual access level
*U_SetPollingRsp | set value for polling response

Arithmetic functions

multDE_FG | unsigned integer multiply
divDE_BC | unsigned integer divide
*FP_Flt2Int | IEEE floatingpoint to integer conversion
*FP_Int2Flt | integer to IEEE floatingpoint conversion

Miscellaneous functions

shlAn | acca shift left
shrAn | acca shift right
rolAn | acca rotate left
U_SetBit | bit write
U_GetBit | bit read

Tables

AND_TAB | and table
OR_TAB | or table

Loadable PEI support

*U_FT12_Reset | reset FT1.2 protocol
*U_FT12_GetStatus | get FT1.2 protocolstatus
*U_SCI_Init | initialize serial comunication interface (SCI)
*U_SPI_Init | initialize serial periphal interface (SPI)

(*) new BCU2 API functions (API 2)


Overview BCU2 API

The addresses of API function on a BCU 2.0 system are the same as in a system 2.1.

Communication object manipulation

*AL_SAPcallback

standard callback

EEPROM manipulation support functions

*U_EEWriteBlock

write EEPROM block

Timer support functions

*U_TS_Set | set BCU2 timer
*U_TS_Del | delete BCU2 timer
*U_TS_Seti | set BCU2 timer event mode

Message handling functions

*U_MS_Post | post a message to a specified messagequeue
*U_MS_Switch | redirects a message from one messagequeue to a other

Application support functions

*U_GetAccess | get actual access level
*U_SetPollingRsp | set value for polling response

Arithmetic functions

*FP_Flt2Int | IEEE floatingpoint to integer conversion
*FP_Int2Flt | integer to IEEE floatingpoint conversion

Loadable PEI support

*U_FT12_Reset | reset FT1.2 protocol
*U_FT12_GetStatus | get FT1.2 protocolstatus
*U_SCI_Init | initialize serial comunication interface (SCI)
*U_SPI_Init | initialize serial periphal interface (SPI)

EEPROM manipulation support functions (only for BCU 2.1 and higher )

*U_EE_WriteHI

write byte to EEPROM


Overview BCU1 API

The addresses of API function on a BCU 2.0 system are the same as in a system 2.1.

Communication object manipulation

U_flagsGet | reading RAM flags
U_flagsSet | writing RAM flags
U_testObj | testing the RAM flags
U_transRepuest | setting transmit repuest

EEPROM manipulation support functions

EEwrite | writing to EEPROM
EEsetChecksum | updating checksum

Timer support functions

TM_Load | starting system timer
TM_GetFlg | reading system timer status
U_SetTM | setting user timers
U_GetTM | reading user timer status
U_Delay | delay

PEI support functions

U_ioAST | binary port access
U_SerialShift/ U_Char_Out | byte exchange via serial PEI
S_AstShift / S_LAstShift | data block exchange via serial PEI

Message handling functions

AllocBuf | buffer allocation
FreeBuf | buffer release
PopBuf | message request

Application support functions

U_debounce | debouncing
U_delMsgs | ignoring messages to the user
U_readAD | doing AD conversion
U_map | characterisation function

Arithmetic functions

multDE_FG | unsigned integer multiply
divDE_BC | unsigned integer divide

Miscellaneous functions

shlAn | acca shift left
shrAn | acca shift right
rolAn | acca rotate left
U_SetBit | bit write
U_GetBit | bit read

Tables

AND_TAB | and table
OR_TAB | or table


Program Example

************************************ MODULE ***********************************
* This file is generated by the EIB-IDE programming tool
* $Workfile:: SAMPLE.asm $
* $Date: $
* $Revision: 0 $
* Description :
* Author :
* Modified :
*******************************************************************************
name SAMPLE
title 'SAMPLE'
*Includes
$wrk\mode.inc
********************************************************************************

* EEPROM Data, a detailed description of macros can be found in the BCU2-Helpfile

  %OptionReg 0FFH      ;EEPROM Option Register
  %SyncRate 0C0H       ;Baud Rate for serial sync. PEI (Preselection = 9600 Baud)
  %PortCDDR 0FFH       ;Port C Direction Bits Setting
  %PortADDR 000H       ;Port A Direction Bits Setting
  %RouteCnt 0E0H       ;Routing Count
  %MxRstCnt 063H       ;Restart Limits for NAK and BUSY
  %ConfigDes 0E8H      ;Defines special functions for the BCU
  %PeiType 4           ;required Pei-Typ
  %AppID (00FFFF0000h) ;2 Byte Manufacture + 2 Byte ApplikationID
  %AppVersion 0ffh     ;Application version first try

  public CObjSeg0      ;segmentpointer 0 for CommObject values
  public CObjSeg1      ;segmentpointer 1 for CommObject values

rseg ZDATA
* segment definition
ZPAGE

PEI_BUFFER rmb 9
* Reserve Serial-Protocol-Buffer at zeropage with a length of 9 Byte if the PEI is * used, do not touch this buffer when using serial-PEI !!
* ATTENTION: PEI_Interface, PEI_Info are inside of usable user-memory. Take care
* when using own serial protocol handler

ZUSER_RAM0 rmb 8
* Extended Zero-Page RAM of BCU 2.1
* If this area is used, you should take care of reserving 8 bytes to ensure correct * startaddress of debounce-area (see below)

ZUSER_RAM1

Debounce rmb 2
* 2 Byte reserved for debounce function, if used must located at address $CEh, $CFh

CommObjCount equ 2
* number of comm.objects

RAMflags rmb (CommObjCount+1)/2
* definition RAMflags

CObjSeg0
* segmentpointer 0 for CommObject values
* >>>>> add your communication object values in LowRAM here <<<<<
* >>>>> add your RAM (zeropage) variables here <<<<<

***************************RAM-Daten High-RAM ***************************

  rseg HDATA
* segment definition
HRAM_USER_DATEN

CObjSeg1

* segmentpointer 1 for CommObject values
* >>>>> add your communication object values in HighRAM here <<<<<

RcvObjValue rmb 1  ;Value of comm.obj 1
SendObjValue rmb 1 ;Value of comm.obj 2

* >>>>> add your RAM (highram) variables here <<<<<

  org HRAM_USER_DATEN+24

* Reserve Serial-Protocol-Buffer at highram
* with a length of 25 Byte if the PEI is used

PEI_REC_BUFFER rmb 25 ;do not touch this buffers
PEI_SND_BUFFER rmb 25 ;by using serial-PEI

*****************************EEPROM-Data ************************************

  rseg EEDATA ; segment definition
  public EE_CommsTab

EE_CommsTab

* a detailed description of macros can be found in the BCU2-Helpfile
* Communication Objecttable

  fcb CommObjCount ; number of communication objects
  fcb RAMflags     ; RAM-Flag-Table-Pointer

* >>>>> add your comunication objects here <<<<<

  %COM_OBJECT RcvObjValue,UINT1,ComRW.or.PrioLow,CObjSeg1
  %COM_OBJECT SendObjValue,UINT1,ComRW.or.PrioLow,CObjSeg1

*-----------------------------------------------------------------------------

PROP_USER equ 201
* Property ID User Property
EibObjTypeUser equ 50001

  %EIB_OBJECT_TAB 1

* Definition of EibObjects:
* a detailed description of the macros can be found in the BCU2-Helpfile
* >>>>> add your EIB objects here <<<<<

EibObject0
 %EIB_OBJECT 0,EibObjTypeUser+0,AccRFree,AccWFree
 %PROP_VAL PROP_USER+0,PUINT ,PCTRL_WRITE,0000h,Label0
 %PROP_PTR PROP_USER+1,PULONG,PCTRL_WRITE,PropValue0
 %EIB_OBJECT_END 0
PropValue0 fqb 00000000h

* >>>>> add your EEPROM variables here <<<<<

*********************************** FUNCTION ****************************

* begin user code

  rseg CODE
  public AppInit
  public AppMain
  public AppSave
  public AppCallBack

*********************************** FUNCTION *****************************
* Name AppInit
**************************************************************************

AppInit
* >>>>> add your initialization code here <<<<<
  rts

*********************************** FUNCTION *****************************
* Name AppSave
**************************************************************************

AppSave
* >>>>> add your code for the saveroutine here <<<<<
  rts

*********************************** FUNCTION *****************************
* Name AppMain
**************************************************************************

AppMain
  lda #0              ;Test if object 0 was updated
  jsr U_testObj
  beq AppEnd          ;if not -> end
  lda RcvObjValue     ;load inverted value of object0 to object1
  eor #01
  sta SendObjValue
  lda RAMflags        ;set flags of object1 (send), recommended use API function
  ora #$30
  sta RAMflags
AppEnd

  lda SendObjValue    ;show value of object1 on LED
  eor #$11
  jsr U_ioAST
  rts

AppCallBack equ AL_SAPcallback
* no own callback is used, use standard callback

  rmb 1               ; checksumbyte
  end


Float to Integer

Float to Integer Conversion

Symbol: | FP_Flt2Int |
Call-Address: | 5087h |
Description: | Converts a 4 byte IEEE floatingpoint to 2 byte integer
Inputs: | X RegF | pointer to 32 bit float offset to exponent (8bit)
Outputs: | RegB:RegC | 2 byte integer
Effects: | Changes A, RegD, RegE

Format encoding


Integer to Float

Integer to Float Conversion

Symbol: | FP_Int2Flt |
Call-Address: | 5084h |
Description: | Converts an 2 byte integer to 4 byte IEEE floatingpoint
Inputs: | RegB:RegC | 2 byte integer
 | X | pointer to 32 bit float
 | RegF | offset to exponent (8bit)
Outputs: | 4-Byte IEEE float at address X
Effects: | Changes A, RegD

Format encoding


The IEEE standard for Floating Point Arithmetic

The IEEE (Institute of Electrical and Electronics Engineers) has produced a standard for floating point arithmetic. This standard specifies how single precision (32 bit) and double precision (64 bit) floating point numbers are to be represented, as well as how arithmetic should be carried out on them.

Single Precision

The IEEE single precision floating point standard representation requires a 32 bit word, which may be represented as numbered from 0 to 31, right to left.

31

30

-

23

22

-

0

sign (1bit)

exponent (7bit)

mantissa (23bit)

S

EEEEEEEE

FFFFFFFFFFFFFFFFFFFFFFF

The value V represented by the word may be determined as follows:

  • If E=255 and F is nonzero, then V=NaN ("Not a number")

  • If E=255 and F is zero and S is 1, then V=-Infinity
  • If E=255 and F is zero and S is 0, then V=Infinity
  • If 0<E<255 then V=(-1)**S * 2 ** (E-127) * (1.F) where "1.F" is intended to represent the binary number created by prefixing F with an implicit leading 1 and a binary point.
  • If E=0 and F is nonzero, then V=(-1)**S * 2 ** (-126) * (0.F) These are "unnormalized" values.
  • If E=0 and F is zero and S is 1, then V=-0
  • If E=0 and F is zero and S is 0, then V=0

In particular,

  0 00000000 00000000000000000000000 = 0
  1 00000000 00000000000000000000000 = -0

  0 11111111 00000000000000000000000 = Infinity
  1 11111111 00000000000000000000000 = -Infinity

  0 11111111 00000100000000000000000 = NaN
  1 11111111 00100010001001010101010 = NaN

  0 10000000 00000000000000000000000 = +1 * 2**(128-127) * 1.0 = 2
  0 10000001 10100000000000000000000 = +1 * 2**(129-127) * 1.101 = 6.5
  1 10000001 10100000000000000000000 = -1 * 2**(129-127) * 1.101 = -6.5

  0 00000001 00000000000000000000000 = +1 * 2**(1-127) * 1.0 = 2**(-126)
  0 00000000 10000000000000000000000 = +1 * 2**(-126) * 0.1 = 2**(-127)
  0 00000000 00000000000000000000001 = +1 * 2**(-126) * 0.00000000000000000000001 =
                                       2**(-149)  (Smallest positive value)


Write Byte to EEPROM

Symbol: | U_EE_WriteHI
Call-Address: | 50B2h
Description: | Write one byte to the EEPROM
Inputs: | RegH:RegI | Memory Address
 | acca | Byte to write
Outputs: | - |
Effects: | changes A, X, RegB, RegG, RegJ

REMARK :

This function is only available in system 2.1 and higher. If you using this API without Project for BCU 2.1 (EIB IDE 2.3) you must insert this API function with the following equatation in file Stdba_20.inc, after U_setPollingRsp. This is only nessesary if you want to develop BCU 2.1 applications with older EIB IDE's (take care of the other template structure, an example is given in application example)

U_EE_WriteHI EQU 50B2h


Write Block to EEPROM

Symbol: | U_EE_WriteBlock
Call-Address: | 5099h
Description: | Write a block of 4 bytes to the EEPROM attention: the address must have align to 4
Inputs: | RegH:RegI | Memory Address
 | RegK,RegL,RegM,RegN | Memory Block to write
Outputs: | - |
Effects: | changes A, X, RegB


Get FT 1.2 Protocollstatus

Serial protocol specification : see EIBA handbook volume 3/ part 6/ chapter 2.

Symbol:

U_FT12_GetStatus

Call-Address:

509Fh

Description:

Gets the FT 1.2 Protocollstatus

Inputs:

Carry

0
1

get status
force status request

Outputs:

A

==0 | State not ok
!=0 | State ok

Effects


Reset FT1.2 Protocol

Serial protocol specification : see EIBA handbook volume 3/ part 6/ chapter 2.

Symbol: | U_FT12_Reset
Call-Address: | 509Ch
Description: | Reset FT 1.2 protocol with specified baudrate
Inputs: | A | Baudrate
Outputs: | - |
Effects: | changes A, X


Get actual Access Level

Symbol: | U_GetAccess
Call-Address: | 5096h
Description: | gets the actual accesslevel of the system (The accesslevel can be changed over authorization) Nessesary for : - memory write/ read - key setting - property read/ write
Inputs: | - |
Outputs: | A | accesslevel
Effects: | - |


Post Messages

Symbol: | U_MS_Post
Call-Address: | 508Dh
Description: | Post the message pointed by X to the message queue A
Inputs: | X A | pointer to message message queue ID |
Outputs: | - |  |
Effects: | change A, X
Example: | ... |  |
 | jsr bcc lda jsr | PopBuf no_message #TASK_PM_ID U_MS_Post | ;get message from user queue ;if no message branch ;load queue/task id for PEI ;post
 | ... |  |


Message Redirection

Symbol: | U_MS_Switch
Call-Address: | 508Ah
Description: | redirects messages from one task to an other ,all messages posted to queue ID X now posted to queue ID A.
Inputs: | X A | message queue ID to redirect new destination for queue X
Outputs: | -
Effects: | changes A, X, RegC

Example: | ldx | #TASK_AL_ID | ;load queue/task id from application layer
 | lda | #TASK_US_ID | ;load queue/task id from user
 | jsr | U_MS_Switch | ;now all messages for the applicationlayer are send to the user
 | .... receive messages .... handle messages for applicationlayer
 | clrx clra |  |
 | jsr | U_MS_Switch | ;reset all redirections


Set Polling Response

Symbol: | U_SetPollingRsp
Call-Address: | 50AEh |
Description: | Set the value to response at polling request.
Inputs: | A | Value to response
Outputs: | - |
Effects: | - |

Notes: Reserved values for response:

FFh | no user running / not set from user
F0h-Fdh | reserved
FEh | fill character no slave responding
00h | set at user startup

Bit 7 | 0 | userstate
 | 1 | systemstate
Bit 6 | error
Bit 5 | alarm
Bit 4 | reseverd
Bit 0-3 | usercode


Initialization of Serial Communication Interface

Symbol:

U_SCI_Init

Call-Address:

50A2h

Description:

Initialize the SCI from 68HC05BE12 for serial asynchroneous communication

  • enable SCI-System (baudrate, 8 databits, receiver/ transmitter enable, TC int off, RDRF int on)

  • disable SPI-System
  • configure PORTC multiplexer

Inputs:

A = Baudrate

B1200 = 1200 baud
B2400 = 2400 baud
B4800 = 4800 baud
B9600 = 9600 baud
B19200 = 19200 baud
B38400 = 38400 baud

Outputs:

-

Effects:

changed Registers: A, X


Initialization of Serial Peripheral Interface

Symbol:

U_SPI_Init

Call-Address:

50A5h

Description:

Initialize the SPI from 68HC05BE12 for Serial Synchron Communication

  • enable SPI-System (set baudrate from EE_SyncRate, CPOL and CPHA from EE_ConfigDes)

  • disable SCI-System
  • configure PORTC multiplexer

Inputs:

-

Outputs:

-

Effects:

changed Registers: A, X


Delete BCU 2 Timer

Delete BCU 2 System Timer

Symbol: | U_TS_Del
Call-Address: | 5093h
Description: | Delete BCU2 Timer (should only used for delete cyclic timermode TS_TYPE_MSG_CYC, because all other timer modes have an defined end "state" )
Inputs: | X | Timernumber
Outputs: | Carry | 1
Effects: | clear column of selected timer in timer table

Timernumber | Description
0 | reserved for the LL
1 | reserved for the serial protocol if used
2 | reserved for the debounce function. If deboucing is not used the timer is available for the user
3 | available for the user
4 | reserved for the transport layer

Example:

intern Timer Table | Timer 0 | Timer 1 | Timer 2 | Timer 3 | Timer 4
Control /Task-ID | used for Link Layer | used for seriell protocol | used for debounce function | clear clear clear | used for Transport Layer
Parameter
Timervalue


Set BCU 2 Timer

Set BCU 2 System Timer

Symbol: | U_TS_Set
Call-Address: | 5090h
Description: | Set a BCU2 Timer
Inputs: | X A RegB RegC RegD | Timernumber Timermode (see REMARK) Timer Scale / Cyclic Scale (see REMARK) TimerValue (not for Mode TS_TYPE_MSG_CYC) TimerParameter (only Mode TS_TYPE_MSG)
Outputs: | Carry: | 0 ok, timer set 1 error (timer not set!)
Effects: | Changes A, X, RegB-RegE

REMARK

Timernumber: | 0 | reserved for Link Layer
 | 1 | reserved for the serial protocol ( if used )
 | 2 | reserved for the debounce function. If deboucing is not used, the timer is available for the user
 | 3 | available for the user
 | 4 | reserved for the transport layer

Timermode: | TS_Type_DIFF (Difference counter)
 | Scales | Time-Unit
 | TS_SCALE041MS | 0.5128 ms
 | TS_SCALE6_6MS | 8.2051 ms
 | TS_SCALE106MS | 131.282 ms
 | TS_SCALE1_6S | 2.1005 s
 | TS_SCALE26S | 33.608 s
 | TS_TYPE_DOWN (Downcounter)
 | Scales | Time-Unit
 | TS_SCALE041MS | 0.41667 ms
 | TS_SCALE6_6MS | 6.667 ms
 | TS_SCALE106MS | 106.67 ms
 | TS_SCALE1_6S | 1.7067 s
 | TS_SCALE26S | 27.3 s
 | TS_TYPE_MSG (Messagetimer)
 | Scales | Time-Unit
 | TS_SCALE041MS | 0.41667 ms
 | TS_SCALE6_6MS | 6.667 ms
 | TS_SCALE106MS | 106.67 ms
 | TS_SCALE1_6S | 1.7067 s
 | TS_SCALE26S | 27.3 s

The timer system generates a TM_TIMER.indication Message, which can be read by using the "PopBuf" function. The Message is structured as follow:

Length | Servicecode: timer indication | Parameter | Timer Number
08 | C1 |  |

  • although th length is always set to 08, the real length is only 4 byte

  • for detecting the message by using function PopBuf, it's absolutely necessary to disable U_delMsgs-call (bit 7 in makro: %RouteCnt )

TS_TYPE_MSG_CYC ( cyclic Message Timer )

Scales

Time-Unit

TS_100MS

100 ms

TS_1SEC

1 s

TS_1MIN

1 min

The timer system generates cyclic a TM_TIMER.indication Message, which can be read by using the "PopBuf" function. (see TS_TYPE_MSG above)

TS_TYPE_EVT ( Timer Event Mode )

not possible with U_TS_Set, use U_TS_Seti


Set BCU 2 Interrupt Timer Event

Symbol: | U_TS_Seti
Call-Address: | 50ABh
Description: | Set BCU 2 Timer for event generation - only use in interrupt - usable for own/ standard PEI driver - generates an event (coded with A) for own/ standard PEI driver Attention: - can only used with fixed scale of 6.6ms - TASK ID is not used for destination queue (always PEI)
Inputs: | X iSMB_D iSMB_C A | Timernumber destination TASK_PM_ID OR TS_TYPE_EVT (logical 'or' operator!) Timervalue Timer Parameter max. 6 bit
Outputs: | -
Effects: | A, iSMB_D

Timernumber | Description
0 | reserved for the LL
1 | reserved for the serial protocol if used
2 | reserved for the debounce function. If deboucing is not used the timer is available for the user
3 | available for the user
4 | reserved for the transport layer
TASK_ID | Code | Description
TASK_LL_ID | equ 01h | ;Link Layer
TASK_NL_ID | equ 02h | ;Networ Layer
TASK_TL_ID | equ 03h | ;Transportlayer groups
TASK_TC_ID | equ 04h | ;Transportlayer Peer to Peer
TASK_LC_ID | equ 05h | ;Local Connect
TASK_AL_ID | equ 06h | ;Application Layer
TASK_MG_ID | equ 07h | ;Management
TASK_PM_ID | equ 08h | ;PEI-Management
TASK_US_ID | equ 09h | ;User


Buffer Allocation

Symbol:

AllocBuf

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

116Ah
117Eh
5000h

Description:

Allocates a message buffer.

Inputs:

-

Outputs:

x | pointer to buffer
Carry | 0 no buffer allocated (X invalid) 1 buffer allocated

Effects:

changed Registers: A


AND TAB

Symbol : | AND_TAB |
Address : | Mask 1.0: Mask 1.1: Mask 1.2: Mask 2.x: | 0028h 0028h 0028h 0028h

AND_TAB

Address (hex.) | Value (binary)
28 | 1111 1110
29 | 1111 1101
2A | 1111 1011
2B | 1111 0111
2C | 1110 1111
2D | 1101 1111
2E | 1011 1111
2F | 0111 1111

This table is helpful for MASK-operation. If you need a value of these tables, you only need a one-byte-offset. This is helpful for loops.

 | ldx | #AND_TAB | ;ptr to AND_TAB
loop | lda | ... |
 | and | ,X | ;MASK-operation
 | sta | ... |
 | : |  |
 | incx |  |
 | bra | loop |


Divide unsigned Int

Unsigned Integer Divide

Symbol: | divDE_BC
Call Address: | Mask 1.0: Mask 1.1 /1.2: Mask 2.x: |  | 0AFCh 0B0Bh 5030h
Description: | Divides the unsigned integer value in the registers RegD:RegE by the unsigned integer value in the registers RegB:RegC.
Inputs: | RegD:RegE = dividend RegB:RegC = divisor
Outputs: | RegF:RegG = quotient RegD:RegE = remainder
 | Carry | 0 1 | ok divide by zero
Effects: | changed Registers: A, X, RegB, RegC


Update Checksum

Updating Checksum

Symbol: | EEsetChecksum
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | 0C5Dh 0C68h 503Ch
Description: | only used for old BCU1 application, updates the checksum byte of the EEPROM. This function must be called if any byte inside the check range is modified by the USER.
Inputs: | none |
Outputs: | none |
Effects: | changed Registers: A, X, RegB, RegC, RegH


Write EEPROM

Writing to EEPROM

Symbol:

EEwrite

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0C2Dh
0C38h
503Fh

Description:

Writes a byte to the specified location in memory.The write operation takes ~ 20ms.
Attention: Update checksum if necessary! (on BCU 1.x application)

By using input parameters after return from subroutine, you have to consider that
in general input parameters could be effected by system and so not valid after return

Inputs:

A = value to write
X = offset in EEPROM

Outputs:

none

Effects:

changed Registers: A, X, RegB, RegC, RegH


Buffer Release

Symbol: | FreeBuf |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | 118Ch 11A0h 5006h
Description: | releases a previously allocated buffer.
Inputs: | X | pointer to buffer
Outputs: | none |
Effects: | changed Registers: A, X


Multiply unsigned Int

Unsigned Integer Multiply

Symbol: | multDE_FG
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: |  | 0B3Ch 0B4Bh 5033h
Description: | Multiplies the unsigned integer values in the registers RegD:RegE and RegF:RegG.
Inputs: | RegD:RegE = factor RegF:RegG = factor
Outputs: | RegB:RegC = product
 | Carry | 0 1 | ok overflow
Effects: | changed Registers: A, X


OR TAB

Symbol: | OR_TAB |
Address: | Mask 1.0: Mask 1.1: Mask 1.2: Mask 2.x: | 0020h 0020h 0020h 0020h

OR_TAB

Address (hex) | Value (binary)
20 | 0000 0001
21 | 0000 0010
22 | 0000 0100
23 | 0000 1000
24 | 0001 0000
25 | 0010 0000
26 | 0100 0000
27 | 1000 0000

This table is helpful for MASK-operation. If you need a value of these tables, you only need a one-byte-offset. This is helpful for loops.


Message Request

Symbol:

PopBuf

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

11ACh
11C0h
5003h

Description:

searches for a message addressed to the user

Inputs:

BCU 2 : none
BCU 1 : acca

Bit# | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
meaning | buffer type (1=long) | layer address |  |  | must be 0

BCU 1 distinguish between long (23 byte)/ short buffers (9? byte)

Outputs:

X = pointer to buffer

Carry =

0 no such message (X invalid)
1 message found

Effects:

changed Registers: A


Accu rotate left

Symbol: | rolAn |
Call Address: | Mask 1.0: | not implemented
 | Mask 1.1: | not implemented
 | Mask 1.2: | 0AF4h (rolA1) 0AF2h (rolA2) 0AF0h (rolA3) 0AEEh (rolA4) 0AECh (rolA7)
 | Mask 2.x: | 5009h(rolA1) 500Ch (rolA2) 500Fh (rolA3) 5012h (rolA4) 5015h (rolA7)
Description: | Rotate the accu left via carry by n bits. The possible values for n are 1, 2, 3, 4, 7
Inputs: | A = value |
Output: | A = rotated value
Effects: | changed Registers: none


Data Block Exchange via Serial PEI

Symbol:

S_AstShift / S_LAstShift (SPI Interface)

Call Address:

Mask 1.0:
Mask 1.1 /1.2:
Mask 2.x:

1103h
1117h
5042h

(S_AstShift) 130 ms timeout

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

1101h
1115h
5045h

(S_LAstShift) 1 second timeout

Description:

The specified data block is exchanged via the serial SPI PEI-interface.

  • uses ~ 130 ms/ 1 second timeout

  • byte exchange must be completed within the timeout-time
  • flow control activ (RTS/ CTS handling)
  • timeout forces reinitialisation of synchron serial interface
  • use %SyncRate for the specific baudrate
  • use only on PEI type 14
  • long wait times causes problems on the bus (busy acknowledges)
  • behavior on system startup must be correct

Message length | Data
1 byte | max 24 byte

Inputs:

X = pointer to data block

Outputs:

X = pointer to data block (the pointer is identical to input, but it contains response)

Carry =

0 communication O.K.
1 communication failed

Effects:

changed Registers: A, RegB, RegC, RegD, RegE, RegG, RegI


Accu shift left

Symbol: | shlAn |  |
Call Address: | Mask 1.0: | 0B9Ah 0B99h 0B98h 0B97h | (shlA4) (shlA5) (shlA6) (shlA7)
 | Mask 1.1 /1.2: | 0BA9h 0BA8h 0BA7h 0BA6h | (shlA4) (shlA5) (shlA6) (shlA7)
 | Mask 2.x: | 5018h 501Bh 501Eh 5021h | (shlA4) (shlA5) (shlA6) (shlA7)
Description: | Shifts the accu left by n bits. The values possible for n are 4, 5, 6, 7. The new bits are set to zero.
Inputs: | A = value |
Outputs: | A = shifted value
Effects: | changed Registers: none


Accu shift right

Symbol: | shrAn |  |
Call Address: | Mask 1.0: | 0BDAh 0BD9h 0BD8h 0BD7h | (shrA4) (shrA5) (shrA6) (shrA7)
 | Mask 1.1/1.2: | 0BE9h 0BE8h 0BE7h 0BE6h | (shrA4) (shrA5) (shrA6) (shrA7)
 | Mask 2.x: | 5024h 5027h 502Ah 502Dh | (shrA4) (shrA5) (shrA6) (shrA7)
Description: | Shifts the accu right by n bits. The values possible for n are 4, 5, 6, 7. The new bits are set to zero.
Inputs: | A = value |  |
Outputs: | A = shifted value
Effects: | changed Registers: none


Read System Timer Status

Reading System Timer Status

Symbol:

TM_GetFlg

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0E2Ah
0E49h
5036h

Description:

Reading Systemtimer
The timer-status is returned.
In operation mode 0, it returns if the runtime is expired.
In operation mode 1, the time since the last call to this function is returned

Inputs:

A = timer number

Outputs:

Operation Mode 0

Operation Mode 1

Carry: | 0 time not yet expired
 | 1 time expired

A = time since the last call

Effects:

changed Register: A, RegB, RegC, RegE


Set System Timer

Start System Timer

Symbol:

TM_Load

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0E0Ch
0E2Bh
5039h

Description:

Starting System timer
The specified timer is initialized with operation mode and time-range.
In addition, the run-time is set in operation mode 0 and the timer is started.

Inputs:

A = (see below)

Bit # | 7 / 6 | 5 / 4 | 3 | 2 / 1 / 0
Meaning | must be 0 | timer # | operation mode | timer range

X = run-time (operation mode 0 only)

Outputs:

none

Effects:

changed Registers: A, X, RegB, RegC, RegD, RegE

REMARK

timer

0 is reserved for the Link-Layer
1 is reserved for the serial protocol if used
2 is reserved for the debounce function.If deboucing is not used the timer is available for the user
3 is available for the user

operation mode

  • 0 = down counter (In operation mode 0, a timer is initialized with a run-time. If this time is expired, then this is flagged. The timer may be restarted during operation.)

  • 1 = difference counter (In operation mode 1, the timer calculates the time since the last call to the timer function. The user must take care to avoid range overflows!)

timer range

A timer has a resolution of 8 bits. It can be operated in five different time-ranges. E.g. a timer-value of 5 in time-range 2 means about 40ms.

Range | Time-Unit
1 | app. 0.5 ms
2 | app. 8.0 ms
3 | app. 130 ms
4 | app. 2.1 s
5 | app. 33 s


Debounce

Debouncing

Symbol: | U_debounce |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | 0C64h 0C75h 5051h
Description: | debounces a complete byte. As long as the debounce time is not yet expired or the value is changing the latest debounced value is returned. address USERRAM+0 = last input value address USERRAM+1 = debounced value Note: It is not necessary to initialize the software timer 2!
Inputs: | A = value (byte) for debouncing X = debounce-time in 0.5ms-units
Outputs: | A = debounced value (byte)
Effects: | uses software timer 2 changed Registers: A, X, RegB, RegC, RegD, RegE, USERRAM+0/+1
Symbol: | U_deb10 |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | not available 0C73H 504BH
Description: | U_debounce with fixed debounce time of 10ms
Symbol: | U_deb30 |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | not available 0C6FH 504EH
Description: | U_debounce with fixed debounce time of 30ms


Delay

Symbol:

U_Delay

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0DDBh
0DFAh
5054h

Description:

waits the specified amount of time.

  • delay is based on the internal hardware-timer.

  • no delay times above 15ms should be used
  • there's a tolerance of 0,4166ms.
  • WDog is triggered internally

Inputs:

A = delay time in app. 0.5ms

Outputs:

none

Effects:

changed Registers: A, X, RegB

REMARK:
Due to a intern conversion the resolution is approximatly 0,52083ms.
(Internaly calculation: delay time = akku * 1,25 * 0,4166ms). But be careful for rounding error!

delay time in akku | real delay time
5 | 2,50ms
6 | 2,92ms
7 | 3,33ms
8 | 4,16ms
9 | 4,58ms
10 | 5,00ms
11 | 5,42ms
... | ...


Ignore Messages to the User

Ignoring Messages to the User

Symbol:

U_delMsgs

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0C82h
0C93h
5057h

Description:

removes any messages addressed to the user

  1. call this function in the USER main routine, if you do not expect any messages. Otherwise the buffer resources in the BCU may become exhausted due to external faults.

  2. There is another way to delete messages for the user. Set bit 7 in the macro %RouteCnt

  3. TConnect/ TDisconnect messages will be post by the management to the user, take care of using this feature on any connection oriented access to the device, the messages "hang" in the user queue

Inputs:

none

Outputs:

none

Effects:

changed Registers: A, X


Read RAM Flags

Symbol:

U_flagsGet

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0C8Ch
0C9Dh
505Ah

Description:

gets the RAM-Flags of the specified communication-object.
Use this function only if standard callback is active (on defenition of own callback the flag/object structure may not be the same as in standard callback)

Inputs:

A = communication-object-number

Outputs:

Carry = 1 : object not exists/ not in range of ZPAGE (RegB invalid)

Carry = 0 : RegB = RAM-flags

Bit # | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | undefined |  |  |  | update flag | data request flag | transmission status

Effects:

changed Registers: A, X only in case of error, RegC, RegJ


Write RAM flags

Writing RAM-Flags

Symbol:

U_flagsSet

Call Address:

Mask 1.0:
Mask 1.1:
Mask 2.x:

0C94h
0CB3h
505Hh

Description:

Sets the RAM-flags of the specified communication-object.
Use this function only if standard callback is active (on defenition of own callback the flag/object structure may not be the same as in standard callback)

Inputs:

A = communication-object-number
RegB = RAM-flags

Bit # | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | undefined |  |  |  | update flag | data request flag | transmission status

Outputs:

Carry = 1 : object not exists/ not in range of ZPAGE (flags not set)

Effects:

changed Registers: A, X only in case of error, RegC, RegJ


Bit Read

Symbol: | U_GetBit |
Call Address: | Mask 1.0: Mask 1.1: Mask 1.2: Mask 2.x: | 0DEDh 0E0Ch 0E0Ch 5075h
Description: | Reads the specified bit in register RegH.
Inputs: | A RegH | bit number byte to be read from
Outputs: | Zero-flag | 0 if bit set 1 if bit clear
 | RegB | value of OR_TAB
Effects: | changed Registers: A


Read User Timer Status

Reading User Timer Status

Symbol:

U_GetTM

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0D4Dh
0D71h
5060h

Description:

reads a User-Timer

gets the status of a User-Timer. This function is the only function which updates this (specified) timer.

Inputs:

A | User-Timer number
X | pointer to EEPROM-description-block (always between 100h ... 1FFh)

Outputs:

Zero-Flag =

0 timer not yet expired
1 timer expired

Effects:

changed Registers: A, X, RegD

Symbol: | U_GetTMx |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | not available 0D6CH 5063H
Description: | reads a User-Timer with the exception that pointer to the EEPROM-description-block is fetched from the byte directly before the user main program. For using this function see this UserEntryPrt.
Effects: | changed Registers: A, X, RegD

REMARK:
Ensure that this function periodically is called at least one time per timer resolution. Otherwise some "timer-ticks" may be lost.The example below shows how a delay can be implemented using the user-timers.

ZUSER_RAM1 |  |
UserTimer0 | rmb 1 |
EEPROM-Data |  |
UsrTmr | fcb UserTimer0 fcb 0 | ;pointer to timervalue ;time base = 133ms
RSEG CODE |  |
* start of timer |  |
 | lda #10 |
 | sta RegE | ;time = 1.3 sec ( 10* Timebase 133ms)
 | lda #0 | ;user-timer 0
 | ldx #.Low.(UsrTmr) | ;ptr to description
 | jsr U_SetTM |
or other way to start a timer
 | lda #10 |
 | sta UserTimer0 |
* check of timer status
 | lda #0 | ;User-Timer 0
 | ldx #.Low.(UsrTmr) | ;ptr to description
 | jsr U_GetTM |
 | beq ... | ;branch if timer expired


IO AST

Binary Port Access

Symbol:

U_ioAST

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0DA7h
0DCFh
5066h

Description:

Binary I/O is handled via the PEI port.
The bits are mapped to the PEI-port as follows:

I/O-Bit# | INPUT # or OUTPUT # | PEI-Pin
0 | 1 | 3
1 | 2 | 2
2 | 3 | 4
3 | 4 | 7

Via I/O-flags reading or writing can be selected for each bit/pin.

Inputs:

A = I/O-flags and values

Bit # | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | I/O flags 0 = read, 1 = write |  |  |  | bit values (for writing only)
I/O Bit # | 3 | 2 | 1 | 0 | 3 | 2 | 1 | 0

Outputs:

RegB = read bit-values

Bit # | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
 | bit values of A before read / write |  |  |  | read bit values (valid only if read selected for that bit, all write selected bits are set to 0
I/O Bit # | 3 | 2 | 1 | 0 | 3 | 2 | 1 | 0

Effects:

Changed Registers: A, X, RegB, RegC


Characterisation Function

Symbol:

U_map

Call Address:

Mask 1.0:
Mask 1.1 /1.2:
Mask 2.x:

0C9Bh
0CBAh
5069h

Description:

Maps the input value by using a conversion table. Input value and result are 16-bit signed integer numbers. For the conversion a table of x-y-valuepairs is used. The input value must be inside the x-value-range. For values in between two x-y-value-pairs linear interpolation is used. Starting with mask-version 1.2 of the system-software, this function can operate in all 4 quadrants.
The interpolation-formula used is: Y = [(X-X1)*(Y2-Y1)]/(X2-X1) + Y1
Note: All intermediate results must not exceed the signed integer value range.

Inputs:

RegB:RegC | value to be mapped (signed integer)
x | pointer to conversion table (EEPROM offset to Address 100h)

Outputs:

RegB:RegC | result (signed integer)
Carry | 0 ok 1 conversion error, result not valid

Effects:

changed Registers: A, X, RegD, RegE, RegF, RegG, RegH, RegI

REMARK

The conversion table is assumed to be in EEPROM and has the following format :
(x-values in ascending order, LSByte is high byte).

Length (x-y-pair count) (1 byte)
X0 | Y0
X1 | Y1
... | ...
low word | high word


Read AD

Doing AD Conversion

Symbol: | U_readAD |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | 0D35h 0D54h 506Ch
Description: | starts AD-conversion for the specified port and reads the result. This operation is repeated by the specified number of times. The sum of the values of all read operations is returned.
Inputs: | A = AD port number X = number of read operations
Outputs: | RegD:RegE = sum of read values
Effects: | changed Registers: A, X


Byte Exchange via Serial PEI

Symbol:

U_SerialShift

(SPI Interface)

Call Address:

Mask 1.0:
Mask 1.1:
Mask 1.2:
Mask 2.x:

not available
not available
0C90h
5048h

Description:

The specified byte is exchanged via the serial SPI PEI-interface.

  • uses ~ 130 ms-timeout

  • byte exchange must be completed within the timeout-time
  • flow control activ (RTS/ CTS handling)
  • use %SyncRate for the specific baudrate
  • use only on PEI type 14
  • long wait times causes problems on the bus (busy acknowledges)
  • behavior on system startup must be correct

Inputs:

A = byte to be transferred

Outputs:

A = received byte

Carry =

0 communication O.K.
1 communication failed

Effects:

changed registers: A, RegB, RegC, RegD, RegE, RegG,RegI

Symbol:

U_Char_Out

(SPI/ SCI Interface)

Call Address:

Mask 2.x:

508AH

Description:

The specified byte is exchanged via the serial SPI/ SCI PEI interface (depend on PEI type).

  • no timeout

  • no flow control activ (RTS/ CTS handling)
  • use %SyncRate for SPI/ U_SCI_Init for SCI bauadrate (else 9600 baud are preselected on SCI with the systeminitialisation)
  • 8/ 9 databits possible (see UART 3)

Inputs:

A = byte to be transferred

Outputs:

-

Effects:

none


Bit Write

Symbol: | U_SetBit |
Call Address: | Mask 1.0: Mask 1.1: Mask 1.2: Mask 2.x: | 0DF9h 0E18h 0E18h 5078h
Description: | Sets the specified bit in register RegH.
Inputs: | A RegH Carry | bit number byte to modify bit value to set
Outputs: | A = RegH = modified byte
Effects: | changed Registers: RegB


Set User Timer

Setting User Timer

Symbol:

U_SetTM

Call Address:

Mask 1.0:
Mask 1.1 / 1.2:
Mask 2.x:

0D8Ah
0DB3h
506Fh

Description:

loads a User-Timer

Inputs:

A | User-timer number
X | pointer to EEPROM-description-block (always between 100h ... 1FFh)
RegE | time to be set

Outputs:

none

Effects:

changed Registers: A, X, RegD

Symbol: | U_SetTMx |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | not available 0DAFH 5072H
Description: | loads a User-Timer with the exception that pointer to the EEPROM-description-block is fetched from the byte directly before the user main program. For using this function see this UserEntryPrt.
Effects: | changed Registers: A, X, RegD

REMARK:
If you load the timer with the timer-value 0, the timer is always expired. If you load the timer with 1, the timer can be immediate expired, because the timer-tolerance is one timer-tick. If you load the timer with a value >127, the bit7 will be ignored.


Test RAM Flags

Symbol: | U_testObj |
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | not available 0CA5h 507Bh
Description: | Fetches the RAM-flags from the specified object and resets the update flag. Use this function only if standard callback is active (on defenition of own callback the flag/object structure may not be the same as in standard callback)
Inputs: | A = communication-object-number
Outputs: | Carry = 0 : RegC = RAM-flags (right adjusted), Zero-flag = NOT update flag Carry = 1 : object not exists/ not in range of ZPAGE (RegC invalid)
Effects: | changed Registers: A, X only in case of error, RegC, RegJ


Set Transmit Request

Setting Transmit Request

Symbol: | U_transRequest
Call Address: | Mask 1.0: Mask 1.1 / 1.2: Mask 2.x: | 0D91h 0DB9h 507Eh
Description: | Sets a transmit-request in the specified communication-object. If a telegram is being currently transmitted for this object, then the transmit-request is not set. Use this function only if standard callback is active (on defenition of own callback the flag/object structure may not be the same as in standard callback)
Inputs: | A = communication-object-number
Outputs: | Carry = 0 : ok Carry = 1 : object not exists/ not in range of ZPAGE/ object still transmitting
Effects: | changed Registers: A, X in case of error , RegC, RegJ


Overview to BCU2 Makros

Overview BCU2 Macros

Reference

%OptionReg | %IMPLEMENT_ADDRESSTABLE
%SyncRate | %END_ADDRESSTABLE
%PortCDDR | %IMPLEMENT_ASSOCTABLE
%PortADDR | %END_ASSOCTABLE
%RouteCnt | %COM_OBJECT
%MxRstCnt | %EIB_OBJECT_TAB
%ConfigDes | %EIB_OBJECT
%AppID | %EIB_OBJECT_END
%AppVersion | %PROP_VAL
%PeiType | %PROP_PTR
Compatibility |
%AppIDOld | %AppVersionOld
%PeiTypeOld | %OldUsrInit
%OldUsrPrg |


%AppID

%AppID <Value>

<Value> | 32 bit Application ID
Description | Defines Application ID-Number

In BCU 2.x this macro defines only equates with the definition XXX=<value>.
The "real" download of this ID's happens in the SegmentControlRecord .


%AppIDOld

%AppID Old <Value, 32 bit>

Handling of application ID without using the load controls of BCU 2 (SegmentControlRecord). The macro performs the following code :

103h/ 104h | high word of <value>
105h/ 106h | low word of <value>

In some macro definition of EIB IDE macros.inc the definition for memory start location is set to 104h. Take care that this is changed to 103h when using this macro.


%AppVersion

%AppVersion | <Value>
<Value> | 1 Byte Applicationversion
Description | Defines The Application Version

In BCU 2.x this macro defines only equates with the definition XXX=<value>.
The "real" download of this ID's happens in the SegmentControlRecord


%AppVersionOld

%AppVersion Old <Value, 8 bit>

Handling of application version without using the load controls of BCU 2 (SegmentControlRecord).
The macro performs the following code :

107h

<value>


%COM_OBJECT

%COM_OBJECT | <Pointer>, <Type>, <Flags> [,CSegPtr1]
<Pointer> | 1 Byte Pointer to Object Value
<Type> | 1 Byte Communication Object-Type UINT1 UINT2 UINT3 UINT4 UINT5 UINT6 UINT7 UINT8 UINT16 TIME_DATE FLOAT DATA6 DOUBLE DATA10 MAXDATA
<Flags> | Bit0/1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 | Transmission Priority Communication Enable (1=Enable) Read Enable (1=Enable) Write Enable (1=Enable) Segment Selector (0=CObjSeg0, 1=CObjSeg1) Transmission Enable (1=Enable) Response Update (1=Enable)
Description | Defines a communication Object-Description

These combinations are defined in the macros.inc file.

ComRW | 11011100b
ComR | 11001100b
ComW | 11010100b
ComOnly | 11000100b
PrioLow | 00000011b
PrioHigh | 00000001b
PrioAlarm | 00000010b
PrioSystem | 00000000b
CSegPtr1 | 00100000b


%ConfigDes

%ConfigDes <Value>

<Value> | bit 0 = not used (not available for own definition)
 | bit 1 = CPHA (clockphase for serial synchronous interface )
 | bit 2 = CPOL (clockphase for serial synchronous interface )
 | bit 3 = telegram rate limitation
 |  | 0 = enabled (limit @UsrInitPtr-1) 1 = disabled
 | bit 4 = not used (not available for own definition)
 | bit 5 = application processor (not used in system software)
 |  | 0 = exists 1 = does not exist
 | bit 6 = A_EVENT-message-generation
 |  | 0 = enabled 1 = disabled
 | bit 7 = PLM-frequency (the contents of these HW PLM registers is cleared at system startup/ user not running)
 |  | 0 = slow mode 1 = fast mode
Description | Defines special functions for the BCU

HINTS


%EIB_OBJECT

%EIB_OBJECT | <EIB-Objectnumber>, <EIB-Object-Type>, <AccessRead>, <AccessWrite>
<EIB-Objectnumber> | Number of the EIB-Object
<EIB-Object-Type> | Type of the EIB-Object
<AccessRead> | Access level for reading
 | AccRFree AccRApp AccRLoad AccRSys | Free Access Access to Application Parameters Access To Address and Association Table Access to Application Program
<AccessWrite> | Accesslevel for writing
 | AccWFree AccWApp AccWLoad AccWSys | Free Access Access to Application Parameters Access To Address and Association Table Access to Application Program
Description | Defines an EIB-Object


%EIB_OBJECT_END

%EIB_OBJECT_END | <EIB-Objectnumber>
<EIB-Objectnumber> | Number of the EIB-Object
Description | Marks the end of an EIB-Object


%EIB_OBJECT_TAB

%EIB_OBJECT_TAB | <Eib Objectcount>
<Eib-ObjectCount> | number of EIB objects
Description | Defines the EIB-Object Table


%END_ADDRESSTABLE

%END_ADDRESSTABLE |
Description | Reserves CRC byte and marks the end of the addresstable


%END_ASSOCTABLE

%END_ASSOCTABLE |
Description | Reserves CRC byte and marks the end of the associationtabletable


%IMPLEMENT_ADDRESSTABLE

%IMPLEMENT_ADDRESSTABLE |
Description | Marks the start of the addresstable


%IMPLEMENT_ASSOCTABLE

%IMPLEMENT_ASSOCTABLE |
Description | Marks the start of the association table


%MxRstCnt

%MxRstCnt Value

<Value> | bits 2-0 | INAK-Restart-Limit (value 0..7 possible)
 | bits 4-3 | always 0
 | bits 7-5 | BUSY-Restart-Limit (value 0..7 possible)
Description | Defines the values for INAK / BUSY retrys

Bit# | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | BUSY retransmit limit |  |  | 0 | 0 | INAK retransmit limit


%OldUsrInit

%OldUsr Init <Value, 8 bit>

Handling of application init entry pointer for compatibility.
The macro performs the following code :

113h

<value>


%OldUsrPrg

%OldUsr Prg <Value, 8 bit>

Handling of application main entry pointer for compatibility.
The macro performs the following code :

114h

<value>


%OptionReg

%OptionReg <Value>

<Value> Value for OptionRegister

Description

option register always FFh
(read and write from/ to 100h is inverted by the systemsoftware of the BCU 2.x)

OptionRegister:

Bits 0 and 1 of this byte are used by the processor hardware.

Bit# | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | must be 1 |  |  |  |  |  | EEPROT (MC68HC705BE12-specific) 0 = EEPROM 300h-4DFh protected 1 = EEPROM 300h-4DFh writable | COPDIS (MC68HC705BE12-specific) 0 = disable watchdog 1 = enable watchdog

In the hardware of MC68HC705BE12 this bits are opposite to the explanation of OptionRegister. To guarantee compatibility to BCU 1.x the value will be inverted on write/ read to this location by the operating system.

Block | Range | Description
1 | 100h .. 2FFh (512 byte) | not protected at all
2 | 300h .. 4DFh (480 byte) | selectable over optionsregister
3 | 4E0h .. 4FFh (32 byte) | only programable/ eraseable in bootloader/ test mode


%PeiType

%PeiType | <Value>
<Value> | 1 Byte PeiType
Description | Defines the requested PEI type of the user application.

In BCU 2.x this macro defines only equates with the definition XXX= <value>.
The "real" download of this ID's happens in the SegmentControlRecord


%PeiTypeOld

%PeiType Old <Value, 8 bit>

Handling of application version without using the load controls of BCU 2 (SegmentControlRecord).
The macro performs the following code :

109h

<value>


%PortADDR

%PortADDR <Value>

<Value> Directionbits for PORTA

Description

Defines Port A direction bit settings (Hint)


%PortCDDR

%PortCDDR <Value>

<Value> directionbits for PORTC

Description

Defines Port C direction bit settings (Hint)


%PROP_PTR

%PROP_PTR | <Property ID>, <PropertyType>, <Control>, <PropertyPtr>
<Poperty ID> | ID of the property
<PropertyType> | Type of the Property
<Control> | Controlbits of the Property
 | PCTRL_RDONLY PCTRL_WRITE PCTRL_ARRAY | Property is Read Only Property is Read and Write Property is pointer to Arraydescription
<PropertyPtr> | Pointer to PropertyValue
Description | Defines a Property Value in an EIB-Object

Example

*located in EEPROM
%PROP_PTR PID_USER01,PUCHAR,PCTRL_WRITE.or.PCTRL_ARRAY,user_array_ptr
...
*located in EEPROM
user_array_ptr | fcb 20 | ;maximum length of array
 | fdb user_array | ;pointer to user array
... |  |
*located in EEPROM or RAM
user_array | rmb 1 | ;actual length of array
 | rmb 20 | ;array data
... |  |


%PROP_VAL

%PROP_VAL | <PropertyID>, <PropertyType>, <Control>, <PropertyValue> [,Label]
<Poperty ID> | ID of the property
<PropertyType> | Type of the Property
<Control> | Controlbits of the Property
 | PCTRL_RDONLY PCTRL_WRITE | Property is Read Only Property is Read and Write
<PropertyValue> | Initial value of the Property
<Label> | optional label for the PropertyValue
Description | Defines a Property Value in an EIB-Object

Example

*located in EEPROM

%PROP_VAL PID_USER01,PUINT,PCTRL_WRITE,01h,Name_of_Variable

...

*assembler output (source)

fcb PID_USER01
fcb PUINT.or.PCTRL_WRITE
Name_of_Variable fdb 0001h
(this variable is accessable by the complete program, it is only a other way of variable definition )


%RouteCnt

%RouteCnt <Value>

<Value> | bits 3-0 | always 0 |
 | bits 4-6 | routing count |
 | bit 7 | U_delMsg-call | 0 = disabled
 |  |  | 1 = enabled
Description | Defines routing count start value and U_delMsgs switch feature

Bit# | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
Meaning | U_delMsg | route count |  |  | must 0 | must 0 | must 0 | must 0

This function U_delMsg is called just before the user main routine (user).


%SyncRate

%SyncRate <Value>

<Value> Syncrate

Description

Defines the SyncRate (baudrate) for synchronous PEI on type 12/ 14
In some EIB IDE standard program templates the default value is set to FFh (be careful when using SPI because the value is not valid)

SyncRate | BCU 1.x | BCU2
00h | 125 000 | 153 000
40h | 41 666 | 51 200
02h | - | 38 400
03h | - | 19 200
C0h | 9 600 | 9600
C9h | 4 800 | 4 800
D2h | 2 400 | 2 400
DBh | 1 200 | 1 200
E4h | 600 | 600
EDh | 300 | 300


Overview to BCU2 Load Ctrl Makros

Overview Load Control Macro Reference

AbsCObjSeg | Delay | Restart
AbsDataSeg | DisConnect | TaskCtrlRec1
AbsStackSeg | EIBObjDef | TaskCtrlRec2
AbsTaskSeg | Load | TaskPtrRecord
Commands | LoadCompleted | Unload
CommandsEnd | PropCompare | Write
CompareDirect | PropWrite | WriteDirect
Connect | PropWriteVerify | WriteWithVerify


%AbsCObjSeg

%AbsCObjSeg

<ComObjectTablePtr>

<ComObjectTablePtr>

Pointer to Communication Object Table

Description

This macro adds a record to the S19 file to announce the communication object table to the tool. This record contains the startaddress of the communication object table (2 bytes). If you don´t use the standard callback with standard communication object handling, you have to delete this macro from the file "load_ctl.asm". Keep in mind that neither the "EIB ide"- nor the "ETS"-software will support another communication object handling system (e.g. defining ramflag-settings in the "ETS")!

CommObject Table Type ID for the BCU 2 is 00 01 00 01 00H.
This segment gives information for tools only. It is not transmitted on the bus!

Example: %AbsCObjSeg EE_CommsTab


%AbsDataSeg

%AbsDataSeg | <startaddress>, <endaddress>, <access level>, <memorytype>, <CRC-usage>
<startaddress> | address of the first byte in the memoryblock which shall be allocated. To get the correct address tools uses the assembler-command ".SFB.(<Segment> [ offset])"
<endaddress> | address of the last byte in the memoryblock which shall be allocated. To get the correct address tools uses the assembler-command ".SFE.(<Segment> [ offset])"
<accesslevel> | defines the accesslevel which is necessary to get permission to read or write from/to the allocated memory segment after download. Possible settings are R00 (highest access level) to R03 (lowest access level) to get read-permission or W00 to W03 for write-permission, respectively. The two different values are concatenated by the assembler-command ".OR."
<memorytype> | type of memory of the segment which shall be allocated. Possible settings are : - MEMTYP_EEPROM - MEMTYP_RAM. This is needed for checking purpose
<CRC-usage> | this parameter determines whether or not CRC is calculated for the specified memory segment. Possible settings are CRC_EN or CRC_DIS
Description: | This macro allocates a block of memory as specified by its parameters and sets access rights and checksum usage for it. All data found in the S19 file belonging to this memoryblock are copied to it. Considering the correct usage of the different memory segments. For further details see the loading-rules and the rules for defining memory-segments.

Example: %AbsDataSeg .SFB.(ASSOCTAB),.SFE.(ASSOCTAB-1), RW3, MEMTYP_EEPROM, CRC_EN


%AbsStackSeg

%AbsStackSeg | <startaddress>, <endaddress>, <access level>, <memorytype>, <CRC-usage>
<startaddress> | Address of the first byte in the memoryblock which shall be allocated. The EIB-ide-tool uses the assembler-command ".SFB.(<Segment> [ offset])" to get the correct address
<endaddress> | Address of the last byte in the memoryblock which shall be allocated. The EIB-ide-tool uses the assembler-command ".SFE.(<Segment> [ offset])" to get the correct address
<accesslevel> | Defines the accesslevel which is necessary to get permission to read or write from/to the allocated memory segment after download. Possible settings are R00 (highest access level) to R0F (lowest access level) to get read-permission or W00 to W0F for write-permission, respectively. The two different values are concatenated by the assembler-command ".OR.".
<memorytype> | Type of memory of the segment which shall be allocated. Possible settings are MEMTYP_EEPROM for EEPROM or MEMTYP_RAM for RAM. This is needed for checking purpose
<CRC-usage> | This parameter determines whether or not CRC-checking shall be executed for the specified memory segment. Possible settings are APPLIE_CRC or NO_CRC
Description: | This macro allocates a block of -memory as specified by its parameters and sets access-rights and CRC-usage for it. The allocated memory block is used as stack for the user-program

Example: %AbsStackSeg .SFB.(CSTACK2),.SFE.(CSTACK-1),AprDp.OR.AprDp,MEMTYP_RAM,NO_CRC


%AbsTaskSeg

%AbsTaskSeg | <entrypoint>, [<PEItype>, <AppID>, <version>]
<entrypoint> | startaddress of a application main function or beginning of a table, respectifely
<PEItype> | type of the PEI adapter which is necessary to execute the user program. Valid settings are 00 - 20 (decimal values!)
<AppID> | application ID 2 byte manufacturer ID 2 byte devicetype ID
<version> | version number of the software
Description: | -

Example: %AbsTaskSeg AppMain,PeiTyp,AppID,AppVer


%Commands

Description:

This macro has to be called as the first command in the load-control file to initialize the code generation for the load sequence

Example: %Commands


%CommandsEnd

Description:

This macro has to be called as the last command in the load control file to mark
the end of the load-sequence

Example: %CommandsEnd


%CompareDirect

%CompareDirect | <startaddress>, <data1> [, ... , <data9>]
<startaddress> | startaddress of the memory block
<data1>...<data9> | Up to 9 databytes - separated by commas - which shall be compared with the contents of the memory block beginning at <startaddress>
Description: | Reads up to 9 bytes stored in a concatenated block of memory and compares them with the bytes specified as parameters. If an error is detected, the download will be interrupted and an error message will be raised

Example: %CompareDirect 0B7F5h,000h,000h,000h,000h,0B7h


%Connect

Description:

This macro establishes the connection to the target device necesarry for download

Example: %Connect


%Delay

%Delay | <time>
<time> | Time in milliseconds (0 – 65535 = 16 Bit)
Description: | This macro causes the download tool to wait for the specified time before starting its next action

Example: %Delay 60


%DisConnect

Description:

This macro ends the connection to the target device

Example: %Disconnect


%EIBObjDef

%EIBObjDef | <ObjCount>
< ObjCount > | number of EIB objects
Description | This macro announce the EIB object types to the tool. This segment gives information for tools only. It is not transmitted on the bus!

Example: %EIBObjDef 4


%Load

%Load | <StateMachine>
<StateMachine> | Name of the task which shall be setting in state "loading". Valid names are Addr, Assoc and App
Description | This macro causes the transition of the specified load state machine to the state "loading". While in this state, new data can be transfered to a device

Example: %Load App


%LoadCompleted

Description

This macro causes the transition of the actual load state machine to the state "loaded". In this state tables are evaluated and programs are set to running

Example: %LoadCompleted


%PropCompare

%PropCompare | <Object ID>, <PropID>, <StartIndex>, <ElementCount>,<Data1-5>
<Object ID> | object index
<PropID> | property identifier
<StartIndex> | startindex
<ElementCount> | number of elements to compare
<Data1-5> | words
Description: | This macro is used to compare data from a property

Example: %PropCompare OBJ_ID_DEV,PROP_POLLING_ADDR,1,1,0000h,0000h


%PropWrite

%PropWrite | <Object ID>, <PropID>, <StartIndex>, <ElementCount>,<Data1-5>
<Object ID> | object index
<PropID> | property identifier
<StartIndex> | startindex
<ElementCount> | number of elements to write
<Data1-5> | words
Description: | This macro is used to write data to a property without verification

Example:

%PropWrite OBJ_ID_DEV,PROP_POLLING_ADDR,1,1,0000h,0000h


%PropWriteVerify

%PropWriteVerify | <Object ID>, <PropID>, <StartIndex>, <ElementCount>,<Data1-5>
<Object ID> | object index
<PropID> | property identifier
<StartIndex> | startindex
<ElementCount> | number of elements to write
<Data1-5> | words
Description: | This macro is used to write data to a property with verification.

Example: %PropWriteVerify OBJ_ID_DEV,PROP_POLLING_ADDR,1,1,0000h,0000h


%Restart

Description:

This macro causes a reset of the connected device. Afterwards a new connection has to be established by calling the macro "Connect".

Example: %Restart


%TaskCtrlRec1

%TaskCtrlRec1 | <ptr to EIB-Objtable>, <EIB-ObjectsCount>
<ptr to EIB-Objtable> | pointer of the EIB object table
<EIB-ObjectsCount> | number of user EIB objects
Description: | This macro announce user EIB objects to the system

Example: %TaskCtrlRec1 EIB_ObjPtr,EIB_ObjCount


%TaskCtrlRec2

%TaskCtrlRec2 | <callbackptr>[,<ComObjectTablePtr>, <Segmentptr0>, <Segmentptr1>]
<callbackptr> | pointer to callbackfunction

The following parameters are required if standard callback is used.

<ComObjectTabPtr> | pointer to communication object table
<Segmentptr0> | segmentpointer 0 for communication objects
<Segmentptr1> | segmentpointer 1 for communication objects
Description: | This macro announce the communication objecthandling for communication objects to the system

Example: %TaskCtrlRec2 AppCallBack,EE_CommsTab,CObjSeg0,CObjSeg1


%TaskPtrRecord

%TaskPtrRecord | <Initptr>,<Saveptr>[,<SpHandlerptr>]
<Initptr> | pointer to user init function
<Saveptr> | pointer to user save function
<SpHandlerptr> | pointer to serial protocol handler (00h if standardhandler is used)
Description: | this macro announce pointer to userfunctions to the system

Example: %TaskPtrRecord AppInit,AppSave,SP_Handler


%Unload

%Unload | <StateMachine>
<StateMachine> | Name of the task which shall be unloaded. Valid names are Addr, Assoc and App
Description: | This macro causes the transition of the specified load state machine of a device to the state "unloaded". This state is necessary to enable the loading of new tables or programs

Example: %Unload Assoc


%Write

%Write | <startaddress>, <endaddress>
<startaddress> | startaddress of the memory block
<endaddress> | endaddress of the memory block
Description: | Writes a concatenated block of data from the S19-file to the specified memory addresses. The written data are not verified!

Example: %Write 0b620h,0b7ffh

Remark :

Take care of using these not verified control types, when using BCU 2.x as serial interface (in combination with ETS, ...). It is possible (depend on the number of successive services %Write) that the interface (BCU 2.x) does not react successfully on any returned bus traffic.

On PEI type 16 any T_DataConnected.req doesn't lead to an T_DataConnected.con on the host (will be released in the BCU on PEI type 16), in that way the host dosn't know when he is able to send the next T_DataConnected.req. to the interface. So after a short random time the next request is starting by the host and as long as buffers are available in the BCU the request's will be accepted. If all buffers in the interface are occupied an possible answer of an parametrized device can't be handled, the RS232 interface will answer with BUSY.

The normal parametrization uses verfied control types, after the first T_DataConnected.req (Memory write) the next T_DataConnected.req (Memory Read) wait's for the answer T_DataConnected.ind (Memory response). Only after this finished transaction the next request is started. So an maximum of 2 following T_DataConnected.req occurs in one transaction.

The BCU 1.x system handle this mechanism in a other way, BCU 1.x doesn't accept any message, they message will be blocked on RS232 interface (serial data line) as long as no buffers available.


%WriteDirect

%WriteDirect | <startaddress>, <data1> [, ... , <data9>]
<startaddress> | startaddress of the memory block
<data1>..<data9> | Up to 9 databytes - separated by commas - which shall be written directly to the specified block of memory beginning at <startaddress>
Description: | Writes up to 9 bytes (there are no more macro parameters) given directly as parameters to the specified block of memory. After writing no verification is executed

Example: %WriteDirect 0B7F5h,000h,000h,000h,000h,0B7h

Remark :

Take care of using these not verified control types, when using BCU 2.x as serial interface (in combination with ETS, ...). It is possible (depend on the number of successive services %Write) that the interface (BCU 2.x) does not react successfully on any returned bus traffic.

On PEI type 16 any T_DataConnected.req doesn't lead to an T_DataConnected.con on the host (will be released in the BCU on PEI type 16), in that way the host dosn't know when he is able to send the next T_DataConnected.req. to the interface. So after a short random time the next request is starting by the host and as long as buffers are available in the BCU the request's will be accepted. If all buffers in the interface are occupied an possible answer of an parametrized device can't be handled, the RS232 interface will answer with BUSY.

The normal parametrization uses verfied control types, after the first T_DataConnected.req (Memory write) the next T_DataConnected.req (Memory Read) wait's for the answer T_DataConnected.ind (Memory response). Only after this finished transaction the next request is started. So an maximum of 2 following T_DataConnected.req occurs in one transaction.

The BCU 1.x system handle this mechanism in a other way, BCU 1.x doesn't accept any message, they message will be blocked on RS232 interface (serial data line) as long as no buffers available.


%WriteWithVerify

%WriteWithVerify | <startaddress>, <endaddress>
<startaddress> | startaddress of the memory block
<endaddress> | endaddress of the memory block
Description | Writes a concatenated block of data from the S19 file to the specified memory addresses. The transferred data are verified immediately after writing by reading the same addresses. If an error is detected, the download will be interrupted and an error-message will be raised.

Example: %WriteWithVerify 0b620h,0b7ffh


EIB Frame Format

EIB Frame Decoding

1.Byte | 2.Byte | 3.Byte | 4.Byte | 5.Byte | 6.Byte | 7.Byte | 8.Byte | 9.Byte | 10.Byte | 11.Byte | 12.Byte | 13.Byte | 14.Byte | 15.Byte |
 |  |  |  |  |  | 00xx xx00 | 0000 0000 |  |  |  |  |  |  |  | (Obj)ValueRead
 |  |  |  |  |  | 00xx xx00 | 01DD DDDD | 1 - 6 Bit Data |  |  |  |  |  |  | (Obj)ValueResponse
 |  |  |  |  |  | 00xx xx00 | 01XX XXXX | DDDD DDDD . . . | 7 Bit - 14 Byte Data |  |  |  |  |  | (Obj)ValueResponse
 |  |  |  |  |  | 00xx xx00 | 10DD DDDD | 1 - 6 Bit Data |  |  |  |  |  |  | (Obj)ValueWrite
 |  |  |  |  |  | 00xx xx00 | 10XX XXXX | DDDD DDDD . . . | 7 Bit - 14 Byte Data |  |  |  |  |  | (Obj)ValueWrite
 |  |  |  |  |  |  |  | physical High Addr | physical Low Addr |  |  |  |  |  |
 |  |  |  |  |  | 00xx xx00 | 1100 0000 | AAAA AAAA | AAAA AAAA |  |  |  |  |  | Set-PhysAddr_Request (Write_PhysAddr)
 |  |  |  |  |  | 00xx xx01 | 0000 0000 |  |  |  |  |  |  |  | Read_PhysAddr_Request
 |  |  |  |  |  | 00xx xx01 | 0100 0000 |  |  |  |  |  |  |  | Read_PhysAddr_Response
 |  |  |  |  |  |  |  | 6 Byte Serial Number |  |  |  |  |  |  |
 |  |  |  |  |  | 00xx xx11 | 1101 1100 | .... .... .... |  |  |  |  |  |  | Read_PhysAddr_Serno_Request
 |  |  |  |  |  |  |  | 6 Byte Serial Number | reserved 4 Byte |  |  |  |  |  |
 |  |  |  |  |  | 00xx xx11 | 1101 1101 | .... .... .... | . . . 0000 0000 . . . |  |  |  |  |  | Read_PhysAddr_Serno_Response
 |  |  |  |  |  |  |  | 6 Byte Serial number | new high address | new low address | 4 Byte reserved |  |  |  |
 |  |  |  |  |  | 00xx xx11 | 1101 1110 | .... .... .... | .... .... | .... .... | .... .... |  |  |  | Set_PhysAddr_Serno_Request
 |  |  |  |  |  |  |  |  | 2 Byte reserved |  |  |  |  |  |
 |  |  |  |  |  | 00xx xx11 | 1101 1111 | RRRR RABC | 0000 0000 | 0000 0000 |  |  |  |  | Service_Information_Request
 |  |  |  |  |  |  | channel_no | read counter |  |  |  |  |  |  |
 |  |  |  |  |  | 01ss ss01 | 10PP PPPP | CCCCCCCC | sum of AD_converter_access |  |  |  |  |  | ReadADC_Request
 |  |  |  |  |  |  | channel_no | read counter | value high | value low |  |  |  |  |
 |  |  |  |  |  | 01ss ss01 | 11PP PPPP | CCCCCCCC | DDDDDDDD | DDDDDDDD |  |  |  |  | ReadADC_Response
 |  |  |  |  |  |  | number | address high | address low |  |  |  |  |  |
 |  |  |  |  |  | 01ss ss10 | 0000 LLLL | AAAAAAAA | AAAAAAAA |  |  |  |  |  | ReadMemory_Request
 |  |  |  |  |  |  | number | address high | address low |  |  |  |  |  |
 |  |  |  |  |  | 01ss ss10 | 0100 LLLL | AAAAAAAA | AAAAAAAA | DDDDDDDD | . . . |  |  |  | ReadMemory_Response
 |  |  |  |  |  |  | number | address high | address low |  |  |  |  |  |
 |  |  |  |  |  | 01ss ss10 | 1000 LLLL | AAAAAAAA | AAAAAAAA | DDDDDDDD | . . . |  |  |  | WriteMemory_Request
Control Field | Source | Address | Destination | Address | NPCI | 01ss ss10 | 1100 0000 | number | address high | address low |  |  |  |  | User_Read_Memory_Request
10R1 PP00 | SSSS SSSS | SSSS SSSS | DDDD DDDD | DDDD DDDD | ARRR LLLL | 01ss ss10 | 1100 0001 | number | address high | address low | data | . . . |  |  | User_Read_Memory_Response
 |  |  |  |  |  | 01ss ss10 | 1100 0010 | number | address high | address low | data | . . . |  |  | User_WriteMemory_Request
 |  |  |  |  |  |  |  |  | address hi | address low | AND-data | XOR-data |  |  |
 |  |  |  |  |  | 01ss ss10 | 1100 0100 | number | aaaa aaaa | aaaa aaaa | AAAAAAAA... | ... XXXXXXXX ... |  |  | User_Write_Memory_Bit_Request
 |  |  |  |  |  | 01ss ss10 | 1100 0101 |  |  |  |  |  |  |  | User_Read_MFactinfo_Request
 |  |  |  |  |  | 01ss ss10 | 1100 0110 | manufacturer_id | manufacturer_specific | manufacturer_specific |  |  |  |  | User_Read_MFactinfo_Response
 | RRR : routing counter 000 crossable 0 areas 001 crossable 1 areas 010 crossable 2 areas 011 crossable 3 areas 100 crossable 4 areas 101 crossable 5 areas 110 crossable 6 areas 111 routing counter will not be decremented |  |  |  |  | 01ss ss11 | 00xx xxxx |  |  |  |  |  |  |  | ReadMaskVersion_Request
 |  |  |  |  |  |  |  | mask_version |  |  |  |  |  |  |
 |  |  |  |  |  | 01ss ss11 | 01xx xxxx | TTTTTTTT | VVVVVVVV |  |  |  |  |  | ReadMaskVersion_Response
 |  |  |  |  |  | 01ss ss11 | 10xx xxxx |  |  |  |  |  |  |  | Restart_Request
 |  |  |  |  |  |  |  |  | address hi | address low | AND-data | XOR-data |  |  |
 |  |  |  |  |  | 01ss ss11 | 1101 0000 | number | aaaa aaaa | aaaa aaaa | AAAAAAAA... | ... XXXXXXXX ... |  |  | WriteMemoryBit_Request
 |  |  |  |  |  | 01ss ss11 | 1101 0001 | 0000 0000 | kkkk kkkk | kkkk kkkk | kkkk kkkk | kkkk kkkk |  |  | Authorize_Request
 |  |  |  |  |  | 01ss ss11 | 1101 0010 | level |  |  |  |  |  |  | Authorize_Response
 |  |  |  |  |  | 01ss ss11 | 1101 0011 | level | kkkk kkkk | kkkk kkkk | kkkk kkkk | kkkk kkkk |  |  | SetKey_Request
 | PP : bus access priority 00 system 01 high 10 alarm 11 normal |  |  |  |  | 01ss ss11 | 1101 0100 | level |  |  |  |  |  |  | SetKey_Response
 |  |  |  |  |  | 0xss ss11 | 1101 0101 | object_id | property_id | no_of_elem | start_ | _index |  |  |  | PropertyValue_Read
 |  |  |  |  |  | 0xss ss11 | 1101 0110 | object_id | property_id | no_of_elem | start_ | _index | data ... |  |  | PropertyValue_Response
 |  |  |  |  |  | 0xss ss11 | 1101 0111 | object_id | property_id | no_of_elem | start_ | _index | data ... |  |  | PropertyValue_Write
 |  |  |  |  |  | 0xss ss11 | 1101 1000 | object_id | property_id | property_index |  |  |  |  | PropertyDescription_Read
 | R : repeat flag: 0 repeat 1 first attempt |  |  |  |  |  |  |  |  |  |  | max_no_of_elements |  | access |
 |  |  |  |  |  | 0xss ss11 | 1101 1001 | object_id | property_id | property_index | type | iiii iiii | iiii iiii | rrrr wwww | PropertyDescription_Response
 |  |  |  |  |  | 10ss ss00 |  |  |  |  |  |  |  |  | Open
 |  |  |  |  |  | 10ss ss01 |  |  |  |  |  |  |  |  | Close
 |  |  |  |  |  | 10ss ss10 |  |  |  |  |  |  |  |  | OpenConf
 | A: Address type: 0 physical addressed 1 group addressed |  |  |  |  | 10ss ss11 |  |  |  |  |  |  |  |  | reserved(destroyed)
 |  |  |  |  |  | 11ss ss00 |  |  |  |  |  |  |  |  | reserved
 |  |  |  |  |  | 11ss ss01 |  |  |  |  |  |  |  |  | CloseConf
 |  |  |  |  |  | 11ss ss10 |  |  |  |  |  |  |  |  | Transport Layer ACK
 |  |  |  |  |  | 11ss ss11 |  |  |  |  |  |  |  |  | Transport Layer NAK


EIB Frame Format (Controlfield)

EIB Frame Control Field Format

Control Field |  |  |  |
1011 0000 | B0Hex | L_DATA request | system | not repeated
1001 0000 | 90Hex | L_DATA request | system | repeated
1011 1000 | B8Hex | L_DATA request | alarm | not repeated
1001 1000 | 98Hex | L_DATA request | alarm | repeated
1011 0100 | B4Hex | L_DATA request | high | not repeated
1001 0100 | 94Hex | L_DATA request | high | repeated
1011 1100 | BCHex | L_DATA request | normal | not repeated
1001 1100 | 9CHex | L_DATA request | normal | repeated
1111 0000 | F0Hex | L_POLLDATA request | system |


Short Cuts

Abbreviations

Some of the names in the help file are not used in same manner. Caused trough historic name changing there are some differences listed below.

name | synonym | remark
TC | TLC | transport layer connection oriented
TLG | TL | transport layer group oriented
LC | TLL | transport layer local
grp | - | group oriented
cl | - | connection less
co | - | connection oriented
LSM | load state machine |


Creative Commons Namensnennung-Keine Bearbeitung 2.0

Creative Commons Namensnennung — Nicht-kommerziell — Keine Bearbeitung 2.0 Deutschland

Lizenzvertrag

DAS URHEBERRECHTLICH GESCHÜTZTE WERK ODER DER SONSTIGE SCHUTZGEGENSTAND (WIE UNTEN BESCHRIEBEN) WIRD UNTER DEN BEDINGUNGEN DIESER CREATIVE COMMONS PUBLIC LICENSE („CCPL“ ODER „LIZENZVERTRAG“) ZUR VERFÜGUNG GESTELLT. DER SCHUTZGEGENSTAND IST DURCH DAS URHEBERRECHT UND/ODER EINSCHLÄGIGE GESETZE GESCHÜTZT.

DURCH DIE AUSÜBUNG EINES DURCH DIESEN LIZENZVERTRAG GEWÄHRTEN RECHTS AN DEM SCHUTZGEGENSTAND ERKLÄREN SIE SICH MIT DEN LIZENZBEDINGUNGEN RECHTSVERBINDLICH EINVERSTANDEN. DER LIZENZGEBER RÄUMT IHNEN DIE HIER BESCHRIEBENEN RECHTE UNTER DER VORAUSSETZUNGEIN, DASS SIE SICH MIT DIESEN VERTRAGSBEDINGUNGEN EINVERSTANDEN ERKLÄREN.

1. Definitionen

  1. Unter einer „Bearbeitung“ wird eine Übersetzung oder andere Bearbeitung des Werkes verstanden, die Ihre persönliche geistige Schöpfung ist. Eine freie Benutzung des Werkes wird nicht als Bearbeitung angesehen.
  2. Unter den „Lizenzelementen“ werden die folgenden Lizenzcharakteristika verstanden, die vom Lizenzgeber ausgewählt und in der Bezeichnung der Lizenz genannt werden: „Namensnennung“, „Nicht-kommerziell“, „Weitergabe unter gleichen Bedingungen“.
  3. Unter dem „Lizenzgeber“ wird die natürliche oder juristische Person verstanden, die den Schutzgegenstand unter den Bedingungen dieser Lizenz anbietet.
  4. Unter einem „Sammelwerk“ wird eine Sammlung von Werken, Daten oder anderen unabhängigen Elementen verstanden, die aufgrund der Auswahl oder Anordnung der Elemente eine persönliche geistige Schöpfung ist. Darunter fallen auch solche Sammelwerke, deren Elemente systematisch oder methodisch angeordnet und einzeln mit Hilfe elektronischer Mittel oder auf andere Weise zugänglich sind (Datenbankwerke). Ein Sammelwerk wird im Zusammenhang mit dieser Lizenz nicht als Bearbeitung (wie oben beschrieben) angesehen.
  5. Mit „SIE“ und „Ihnen“ ist die natürliche oder juristische Person gemeint, die die durch diese Lizenz gewährten Nutzungsrechte ausübt und die zuvor die Bedingungen dieser Lizenz im Hinblick auf das Werk nicht verletzt hat, oder die die ausdrückliche Erlaubnis des Lizenzgebers erhalten hat, die durch diese Lizenz gewährten Nutzungsrechte trotz einer vorherigen Verletzung auszuüben.
  6. Unter dem „Schutzgegenstand“ wird das Werk oder Sammelwerk oder das Schutzobjekt eines verwandten Schutzrechts, das Ihnen unter den Bedingungen dieser Lizenz angeboten wird, verstanden
  7. Unter dem „Urheber“ wird die natürliche Person verstanden, die das Werk geschaffen hat.
  8. Unter einem „verwandten Schutzrecht“ wird das Recht an einem anderen urheberrechtlichen Schutzgegenstand als einem Werk verstanden, zum Beispiel einer wissenschaftlichen Ausgabe, einem nachgelassenen Werk, einem Lichtbild, einer Datenbank, einem Tonträger, einer Funksendung, einem Laufbild oder einer Darbietung eines ausübenden Künstlers.
  9. Unter dem „Werk“ wird eine persönliche geistige Schöpfung verstanden, die Ihnen unter den Bedingungen dieser Lizenz angeboten wird.

2. Schranken des Urheberrechts. Diese Lizenz lässt sämtliche Befugnisse unberührt, die sich aus den Schranken des Urheberrechts, aus dem Erschöpfungsgrundsatz oder anderen Beschränkungen der Ausschließlichkeitsrechte des Rechtsinhabers ergeben.

3. Lizenzierung. Unter den Bedingungen dieses Lizenzvertrages räumt Ihnen der Lizenzgeber ein lizenzgebührenfreies, räumlich und zeitlich (für die Dauer des Urheberrechts oder verwandten Schutzrechts) unbeschränktes einfaches Nutzungsrecht ein, den Schutzgegenstand in der folgenden Art und Weise zu nutzen:

  1. den Schutzgegenstand in körperlicher Form zu verwerten, insbesondere zu vervielfältigen, zu verbreiten und auszustellen;
  2. den Schutzgegenstand in unkörperlicher Form öffentlich wiederzugeben, insbesondere vorzutragen, aufzuführen und vorzuführen, öffentlich zugänglich zu machen, zu senden, durch Bild- und Tonträger wiederzugeben sowie Funksendungen und öffentliche Zugänglichmachungen wiederzugeben;
  3. den Schutzgegenstand auf Bild- oder Tonträger aufzunehmen, Lichtbilder davon herzustellen, weiterzusenden und in dem in a. und b. genannten Umfang zu verwerten;

Die genannten Nutzungsrechte können für alle bekannten Nutzungsarten ausgeübt werden. Die genannten Nutzungsrechte beinhalten das Recht, solche Veränderungen an dem Werk vorzunehmen, die technisch erforderlich sind, um die Nutzungsrechte für alle Nutzungsarten wahrzunehmen. Insbesondere sind davon die Anpassung an andere Medien und auf andere Dateiformate umfasst.

4. Beschränkungen. Die Einräumung der Nutzungsrechte gemäß Ziffer 3 erfolgt ausdrücklich nur unter den folgenden Bedingungen:

  1. Sie dürfen den Schutzgegenstand ausschließlich unter den Bedingungen dieser Lizenz vervielfältigen, verbreiten oder öffentlich wiedergeben, und Sie müssen stets eine Kopie oder die vollständige Internetadresse in Form des Uniform-Resource-Identifier (URI) dieser Lizenz beifügen, wenn Sie den Schutzgegenstandvervielfältigen, verbreiten oder öffentlich wiedergeben. Sie dürfen keine Vertragsbedingungen anbieten oder fordern, die die Bedingungen dieser Lizenz oder die durch sie gewährten Rechte ändern oder beschränken. Sie dürfen den Schutzgegenstand nicht unterlizenzieren. Sie müssen alle Hinweise unverändert lassen, die auf diese Lizenz und den Haftungsausschluss hinweisen. Sie dürfen den Schutzgegenstand mit keinen technischen Schutzmaßnahmen versehen, die den Zugang oder den Gebrauch des Schutzgegenstandes in einer Weise kontrollieren, die mit den Bedingungen dieser Lizenz im Widerspruch stehen. Die genannten Beschränkungen gelten auch für den Fall, dass der Schutzgegenstand einen Bestandteil eines Sammelwerkes bildet; sie verlangen aber nicht, dass das Sammelwerk insgesamt zum Gegenstand dieser Lizenz gemacht wird. Wenn Sie ein Sammelwerk erstellen, müssen Sie - soweit dies praktikabel ist - auf die Mitteilung eines Lizenzgebers oder Urhebers hin aus dem Sammelwerk jeglichen Hinweis auf diesen Lizenzgeber oder diesen Urheber entfernen. Wenn Sie den Schutzgegenstand bearbeiten, müssen Sie - soweit dies praktikabel ist- auf die Aufforderung eines Rechtsinhabers hin von der Bearbeitung jeglichen Hinweis auf diesen Rechtsinhaber entfernen.
  2. Sie dürfen die in Ziffer 3 gewährten Nutzungsrechte in keiner Weise verwenden, die hauptsächlich auf einen geschäftlichen Vorteil oder eine vertraglich geschuldete geldwerte Vergütung abzielt oder darauf gerichtet ist. Erhalten Sie im Zusammenhang mit der Einräumung der Nutzungsrechte ebenfalls einen Schutzgegenstand, ohne dass eine vertragliche Verpflichtung hierzu besteht, so wird dies nicht als geschäftlicher Vorteil oder vertraglich geschuldete geldwerte Vergütung angesehen, wenn keine Zahlung oder geldwerte Vergütung in Verbindung mit dem Austausch der Schutzgegenstände geleistet wird (z.B. File-Sharing).
  3. Wenn Sie den Schutzgegenstand oder ein Sammelwerk vervielfältigen, verbreiten oder öffentlich wiedergeben, müssen Sie alle Urhebervermerke für den Schutzgegenstand unverändert lassen und die Urheberschaft oder Rechtsinhaberschaft in einer der von Ihnen vorgenommenen Nutzung angemessenen Form anerkennen, indem Sie den Namen (oder das Pseudonym, falls ein solches verwendet wird) des Urhebers oder Rechteinhabers nennen, wenn dieser angegeben ist. Dies gilt auch für den Titel des Schutzgegenstandes, wenn dieser angeben ist, sowie - in einem vernünftigerweise durchführbaren Umfang - für die mit dem Schutzgegenstand zu verbindende Internetadresse in Form des Uniform-Resource-Identifier (URI), wie sie der Lizenzgeber angegeben hat, sofern dies geschehen ist, es sei denn, diese Internetadresse verweist nicht auf den Urhebervermerk oder die Lizenzinformationen zu dem Schutzgegenstand. Ein solcher Hinweis kann in jeder angemessenen Weise erfolgen, wobei jedoch bei einer Datenbank oder einem Sammelwerk der Hinweis zumindest an gleicher Stelle und in ebenso auffälliger Weise zu erfolgen hat wie vergleichbare Hinweise auf andere Rechtsinhaber.
  4. Obwohl die gemäss Ziffer 3 gewährten Nutzungsrechte in umfassender Weise
    ausgeübt werden dürfen, findet diese Erlaubnis ihre gesetzliche Grenze in
    den Persönlichkeitsrechten der Urheber und ausübenden Künstler, deren berechtigte geistige und persönliche Interessen bzw. deren Ansehen oder Ruf nicht dadurch gefährdet werden dürfen, dass ein Schutzgegenstand über das gesetzlich zulässige Maß hinaus beeinträchtigt wird.

5. Gewährleistung. Sofern dies von den Vertragsparteien nicht anderweitig schriftlich vereinbart,, bietet der Lizenzgeber keine Gewährleistung für die erteilten Rechte, außer für den Fall, dass Mängel arglistig verschwiegen wurden. Für Mängel anderer Art, insbesondere bei der mangelhaften Lieferung von Verkörperungen des Schutzgegenstandes, richtet sich die Gewährleistung nach der Regelung, die die Person, die Ihnen den Schutzgegenstand zur Verfügung stellt, mit Ihnen außerhalb dieser Lizenz vereinbart, oder - wenn eine solche Regelung nicht getroffen wurde - nach den gesetzlichen Vorschriften.

6. Haftung. Über die in Ziffer 5 genannte Gewährleistung hinaus haftet Ihnen der Lizenzgeber nur für Vorsatz und grobe Fahrlässigkeit.

7. Vertragsende

  1. Dieser Lizenzvertrag und die durch ihn eingeräumten Nutzungsrechte enden automatisch bei jeder Verletzung der Vertragsbedingungen durch Sie. Für natürliche und juristische Personen, die von Ihnen eine Datenbank oder ein Sammelwerk unter diesen Lizenzbedingungen erhalten haben, gilt die Lizenz jedoch weiter, vorausgesetzt, diese natürlichen oder juristischen Personen erfüllen sämtliche Vertragsbedingungen. Die Ziffern 1, 2, 5, 6, 7 und 8 gelten bei einer Vertragsbeendigung fort.
  2. Unter den oben genannten Bedingungen erfolgt die Lizenz auf unbegrenzte Zeit (für die Dauer des Schutzrechts). Dennoch behält sich der Lizenzgeber das Recht vor, den Schutzgegenstand unter anderen Lizenzbedingungen zu nutzen oder die eigene Weitergabe des Schutzgegenstandes jederzeit zu beenden, vorausgesetzt, dass solche Handlungen nicht dem Widerruf dieser Lizenz dienen (oder jeder anderen Lizenzierung, die auf Grundlage dieser Lizenz erfolgt ist oder erfolgen muss) und diese Lizenz wirksam bleibt, bis Sie unter den oben genannten Voraussetzungen endet.

8. Schlussbestimmungen

  1. Jedes Mal, wenn Sie den Schutzgegenstand vervielfältigen, verbreiten oder öffentlich wiedergeben, bietet der Lizenzgeber dem Erwerber eine Lizenz für den Schutzgegenstand unter denselben Vertragsbedingungen an, unter denen er Ihnen die Lizenz eingeräumt hat.
  2. Sollte eine Bestimmung dieses Lizenzvertrages unwirksam sein, so wird die Wirksamkeit der übrigen Lizenzbestimmungen dadurch nicht berührt, und an die Stelle der unwirksamen Bestimmung tritt eine Ersatzregelung, die dem mit der unwirksamen Bestimmung angestrebten Zweck am nächsten kommt.
  3. Nichts soll dahingehend ausgelegt werden, dass auf eine Bestimmung dieses Lizenzvertrages verzichtet oder einer Vertragsverletzung zugestimmt wird, so lange ein solcher Verzicht oder eine solche Zustimmung nicht schriftlich vorliegen und von der verzichtenden oder zustimmenden Vertragspartei unterschrieben sind
  4. Dieser Lizenzvertrag stellt die vollständige Vereinbarung zwischen den Vertragsparteien hinsichtlich des Schutzgegenstandes dar. Es gibt keine weiteren ergänzenden Vereinbarungen oder mündlichen Abreden im Hinblick auf den Schutzgegenstand. Der Lizenzgeber ist an keine zusätzlichen Abreden gebunden, die aus irgendeiner Absprache mit Ihnen entstehen könnten. Der Lizenzvertrag kann nicht ohne eine übereinstimmende schriftliche Vereinbarung zwischen dem Lizenzgeber und Ihnen abgeändert werden.
  5. Auf diesen Lizenzvertrag findet das Recht der Bundesrepublik Deutschland Anwendung.