AN452
W
I R E L E S S
M-B
US
S
TACK
P
ROGRAMMER
’
S
G
UIDE
1. Overview
This specification describes in detail the Application Programmer Interface (API) for the Silicon Labs Wireless
M-Bus stack. The Silicon Labs Wireless M-Bus stack uses a Silicon Labs C8051 MCU and EZRadioPRO
®
.
Wireless M-Bus is a European standard for meter reading applications using the 868 MHz frequency band.
1.1. Stack Layers
Wireless M-Bus uses the 3-layer IEC model, which is a subset of the 7-layer OSI model. See Figure 1.
Application
EN 13757-3
MCU
app
Data Link
EN 60870-5-2
M-Bus
phy
PHY
EN 13757-4
Figure 1. Stack Layers
Si443x
The Physical Layer (PHY) is defined in EN 13757-4. The Physical Layer defines how the bits are encoded and
transmitted, the RF modem characteristics (chip rate, preamble, and synchronization word), and RF parameters
(modulation, center frequency, and frequency deviation).
The PHY layer is implemented using a combination of hardware and firmware. The EZRadioPRO
®
performs all of
the RF and modem functions. The EZRadioPRO is used in FIFO mode with the packet handler disabled. The
MbusPhy.c module provides SPI interface, encoding/decoding, block read/write, and packet handling and
manages the transceiver states.
The M-Bus Data Link Layer is implemented in the MbusLink.c module. The M-Bus Application Programming
interface consists of public functions that may be called from the Application Layer in the main thread. The
MbusLink module also implements the Data Link Layer. The Data Link Layer will format and copy data from the
application TX buffer to the MbusPhy TX buffer, adding the required headers and CRCs.
The Application layer itself is not part of the M-Bus firmware. The Application Layer defines how a wide variety of
data is to be formatted for transmission. Most meters only need to transmit one or two types of data. Adding a large
amount of code to accommodate any kind of data to the meter would add unnecessary code and cost to the meter.
If might be feasible to implement a library or a header file with an exhaustive list of data types. However, most
metering customers know exactly what kind of data they need to transmit and can refer to the standard for
formatting details. A universal reader or sniffer might implement a complete set of application data types on the PC
GUI. For these reasons, the Application Layer is implemented using example applications for a meter and reader.
Rev. 0.1 2/10
Copyright © 2010 by Silicon Laboratories
AN452
AN452
1.2. Required Standards
1.2.1. EN 13757-4
EN 13757-4
Communication system for meters and remote reading of meters
Part 4: Wireless meter readout
Radio meter reading for operation in the 868 MHz to 870 MHz SRD band
1.2.2. EN 13757-3
Communication system for meters and remote reading of meters
Part 3: Dedicated Application Layer
1.2.3. IEC 60870-2-1:1992
Telecontrol equipment and systems
Part 5: Transmission protocols
Section 1:Link transmission procedure
1.2.4. IEC 60870-1-1:1990
Telecontrol equipment and systems
Part 5: Transmission protocols
Section 1: Transmission frame formats
1.3. Definitions
M-Bus—M-Bus
is a wired standard for meter reading in Europe.
Wireless M-Bus—Wireless
M-Bus for meter reading applications in Europe.
PHY—Physical
Layer defines how data bits and bytes are encoded and transmitted.
API—Application
Programmer interface.
LINK—Data
Link Layer- defines how blocks and frames are transmitted.
CRC—Cyclic
Redundancy Check.
FSK—Frequency
Shift Keying.
Chip—Smallest
unit of transmitted data. One data bit is encoded as multiple chips.
Module—A
C code source .c file.
1.4. Coding Conventions
The following conventions were adopted for this project:
The compiler_defs.h file is used for cross compiler support.
Memory specific pointers are used for buffers and module registers.
Each module has a short descriptive file name.
MbusLink.c
MbusPhy.c
Public functions include a short module prefix:
API
MbusPhy—PHY module
MbusLink—mbus
Public variables also include the same module prefix, starting with a capital letter, since they are globals.
MbusLink—mbus
API
MbusPhy—PHY module
2
Rev. 0.1
AN452
Each module includes an API header file with public function prototypes.
MbusLink.h
MbusPhy.h
Module public bits and variables are declared external in the module header file.
Public variables are bit or byte only, or qualified using a binary semaphore.
Public variables are used sparingly.
No module includes external variables from another module
Public variable declarations and internal prototypes are located in the module source file.
Hardware-specific macros and bit definitions are located in a hardware_defs.h header file.
Compile time build options, memory specifiers macros, and buffer size macros are located in the
module _defs.h files.
Function parameters passed as inputs may be indicated using __in, and parameters passed as outputs may be
indicated using __out.
Rev. 0.1
3
AN452
2. PHY API
2.1. PHY Layer Modules and File Organization
Table 1. PHY Layer Modules and File Organization
File Name
MbusPhy.h
MbusPhy.c
MbusPhy_const.h
MbusPhy_const.c
hardware_defs.h
MbusPhy_def.h
si443x_B1.h
compiler_defs.h
C8051F930_defs.h
Description
Physical Layer header file
Physical Layer c file
Physical Layer constants header file
Physical Layer constants c file
Hardware definitions file
M-Bus definitions file
Si4432 header file
Compiler definitions file
F930 header file
cross compiler macros
Code constants used for Radio con-
figuration
hardware specific macros
M-Bus build and configuration
options
Comments
2.2. Functions
2.2.1. MbusPhyInitRegisters
Prototype:
PHY_STATUS MbusPhyInitRegisters(void);
Parameters:
none
Returns:
PHY_STATUS (U8) status:
PHY_STATUS_SUCCESS
PHY_STATUS_ERROR_INVALID_STATE
Description:
The PhyInitRegisters() function should be called after resetting the MCU, from the main() function, before using
any other PHY functions. This function will initialize the internal PHY registers in the MCU memory to their default
values. This function does not use the SPI or radio hardware.
It must be called while the radio is in shutdown mode. If the PHY is not in the shutdown state, this function will
return the error code PHY_STATUS_ERROR_INVALID_STATE.
4
Rev. 0.1
AN452
2.2.2. MbusPhyPowerUp
Prototype:
PHY_STATUS MbusPhyPowerUp (void);
Parameters:
none
Returns:
PHY_STATUS (U8) status:
PHY_STATUS_SUCCESS
PHY_STATUS_ERROR_INVALID_STATE
Description:
This function will power up the radio from the shutdown state.
Note that the time to go into IDLE state depends on the current PHY state.
Shutdown
Idle (17 ms)
Standby
Idle (1 ms)
While it is possible to call the MBusPhyIdle() function directly from shutdown, the MCU will be waiting a long time
for the radio to complete the power on reset sequence. The MCU can perform tasks while the Radio is powering up
by using the MbusPhyPowerUp() function first. The MBusPhyIdle() function should be called before using any PHY
functions that require the PHY to be in the Idle or standby state.
This can be used to perform tasks while waiting for Idle mode.
MbusPhyPowerUp ();
// This code is performed while the crystal is starting.
MbusPhyRadioIdle ();
2.2.3. MbusPhyIdle
Prototype:
PHY_STATUS MbusPhyIdle (void);
Parameters:
none
Returns:
PHY_STATUS (U8) status:
PHY_STATUS_SUCCESS
PHY_STATUS_ERROR_POR_TIMEOUT
PHY_STATUS_ERROR_XTAL_TIMEOUT
PHY_STATUS_ERROR_INVALID_STATE
Description:
This function will put the PHY into IDLE state from any other state.
Note that the time to go into IDLE state depends on the current radio state.
Shutdown
Idle (17 ms)
Standby
Idle (1 ms)
RX
Idle (does not wait)
The MbusPhyPowerUp function may be used to perform tasks while waiting for the radio to power up.
MbusPhyPowerUp ();
// This code is performed while the crystal is starting.
MbusPhyRadioIdle ();
Rev. 0.1
5
京公网安备 11010802033920号
Copyright © 2005-2026 EEWORLD.com.cn, Inc. All rights reserved
电子工程世界
