Jennic
TECHNOLOGY FOR A CHANGING WORLD
Integrated Peripherals API
Reference Manual
JN-RM-2001
Revision 2.3
18-Jun-2007
Jennic
Important Notice
Jennic reserves the right to make corrections, modifications, enhancements, improvements and other changes to its products and services at any time, and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders, and should verify that such information is current and complete. All products are sold subject to Jennic’s terms and conditions of sale, supplied at the time of order acknowledgment. Information relating to device applications, and the like, is intended as suggestion only and may be superseded by updates. It is the customer’s responsibility to ensure that their application meets their own specifications. Jennic makes no representation and gives no warranty relating to advice, support or customer product design.
Jennic assumes no responsibility or liability for the use of any of its products, conveys no license or title under any patent, copyright or mask work rights to these products, and makes no representations or warranties that these products are free from patent, copyright or mask work infringement, unless otherwise specified.
Jennic products are not intended for use in life support systems/appliances or any systems where product malfunction can reasonably be expected to result in personal injury, death, severe property damage or environmental damage. Jennic customers using or selling Jennic products for use in such applications do so at their own risk and agree to fully indemnify Jennic for any damages resulting from such use.
All trademarks are the property of their respective owners.
2 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic
Contents
Important Notice 2 Contents 3 About this Manual 7 Organisation 7 Conventions 7 Definitions, Acronyms and Abbreviations 8
1 Introduction 9 1.1 Scope 9
readership 9
1.2 Intended
2 API Description 10 2.1 General 10 2.1.1 u32AHI_Init 10
Handling 10 2.2 Interrupt
Control 13 2.3 System
2.3.1 u8AHI_PowerStatus 13 2.3.2 vAHI_MemoryHold 14 2.3.3 vAHI_CpuDoze 14 2.3.4 vAHI_PowerDown 14 2.3.5 vAHI_Sleep (JN513x Only) 15 2.3.6 vAHI_ProtocolPower 15 2.3.7 vAppApiSetBoostMode (JN513x Only) 16 2.3.8 vAHI_HighPowerModuleEnable (JN513x Only) 16 2.3.9 vAHI_ExternalClockEnable (JN513x Only) 16 2.3.10 vAHI_AntennaDiversityOutputEnable (JN513x Only) 17 2.3.11 vAHI_SysCtrlRegisterCallback 17 2.3.12 vAHI_SwReset 17
Timers 18 2.4 Wake
2.4.1 vAHI_WakeTimerEnable 18 2.4.2 vAHI_WakeTimerStart 18 2.4.3 vAHI_WakeTimerStop 18 2.4.4 u8AHI_WakeTimerStatus 19 2.4.5 u32AHI_WakeTimerCalibrate 19 2.4.6 u8AHI_WakeTimerFiredStatus 19
Peripherals 20 2.5 Analogue
2.5.1 vAHI_ApConfigure 20 2.5.2 bAHI_APRegulatorEnabled 21 2.5.3 vAHI_APRegisterCallback 21 2.6 ADC 22 2.6.1 vAHI_AdcEnable 22 2.6.2 vAHI_AdcStartSample 22 2.6.3 bAHI_AdcPoll 23 2.6.4 u16AHI_AdcRead 23 2.6.5 vAHI_AdcDisable 23 2.7 DACs 24 2.7.1 vAHI_DacEnable 24 2.7.2 bAHI_DacPoll 24
JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 3
Jennic
2.7.3 vAHI_DacOutput 25 2.7.4 vAHI_DacDisable 25 2.8 Comparators 26 2.8.1 vAHI_CompEnable 26 2.8.2 vAHI_ComparatorEnable (JN513x Only) 27 2.8.3 vAHI_CompDisable 27 2.8.4 vAHI_CompIntEnable 28 2.8.5 vAHI_CompWakeEnable 28 2.8.6 u8AHI_CompStatus 28 2.8.7 u8AHI_CompWakeStatus 28 2.9 DIO 29 2.9.1 vAHI_DioSetDirection 29 2.9.2 vAHI_DioSetOutput 30 2.9.3 u32AHI_DioReadInput 30 2.9.4 u8AHI_DioSetByte 30 2.9.5 u8AHI_DioReadByte 31 2.9.6 vAHI_DioSetPullup 31 2.9.7 vAHI_DioInterruptEdge 31 2.9.8 vAHI_DioInterruptEnable 32 2.9.9 u32AHI_DioInterruptStatus 32 2.10 UARTs 33 2.10.1 vAHI_UartEnable 33 2.10.2 vAHI_UartDisable 34 2.10.3 vAHI_UartSetClockDivisor 34 2.10.4 vAHI_UartSetBaudDivisor 34 2.10.5 vAHI_UartSetControl 35 2.10.6 vAHI_UartSetInterrupt 36 2.10.7 vAHI_UartSetRTSCTS (JN513x Only) 36 2.10.8 vAHI_UartReset 37 2.10.9 u8AHI_UartReadLineStatus 37 2.10.10 u8AHI_UartReadModemStatus 38 2.10.11 u8AHI_UartReadInterruptStatus 38 2.10.12 vAHI_UartWriteData 38 2.10.13 u8AHI_UartReadData 39 2.10.14 vAHI_Uart0RegisterCallback 39 2.10.15 vAHI_Uart1RegisterCallback 39 2.11 Timers 40 2.11.1 vAHI_TimerEnable 40 2.11.2 vAHI_TimerClockSelect 41 2.11.3 vAHI_TimerStartSingleShot 41 2.11.4 vAHI_TimerStartRepeat 42 2.11.5 vAHI_TimerStartDeltaSigma 42 2.11.6 vAHI_TimerStartCapture 43 2.11.7 vAHI_TimerReadCapture 43 2.11.8 vAHI_TimerStop 43 2.11.9 vAHI_TimerDisable 44
Only) 44
(JN513x
2.11.10 vAHI_TimerDIOControl
2.11.11 u8AHI_TimerFired 44 2.11.12 vAHI_Timer0RegisterCallback 45 2.11.13 vAHI_Timer1RegisterCallback 45 2.12 Tick Timer 46
4 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic 2.12.1 vAHI_TickTimerInit 46 2.12.2 vAHI_TickTimerWrite 46 2.12.3 vAHI_TickTimerIntPendClr 46 2.12.4 bAHI_TickTimerIntStatus 46 2.12.5 vAHI_TickTimerConfigure 47 2.12.6 vAHI_TickTimerIntEnable 47 2.12.7 u32AHI_TickTimerRead 47 2.12.8 vAHI_TickTimerInterval 47 2.13 Serial Peripheral Interface 48 2.13.1 vAHI_SpiConfigure 48 2.13.2 vAHI_SpiReadConfiguration 49 2.13.3 vAHI_SpiRestoreConfiguration 49 2.13.4 vAHI_SpiSelect 49 2.13.5 vAHI_SpiStop 50 2.13.6 vAHI_SpiStartTransfer32 50 2.13.7 u32AHI_SpiReadTransfer32 50 2.13.8 vAHI_SpiStartTransfer16 50 2.13.9 u16AHI_SpiReadTransfer16 51 2.13.10 vAHI_SpiStartTransfer8 51 2.13.11 u8AHI_SpiReadTransfer8 51 2.13.12 bAHI_SpiPollBusy 51 2.13.13 vAHI_SpiWaitBusy 52 2.13.14 vAHI_SpiRegisterCallback 52 2.14 Serial Interface (2 Wire) 53 2.14.1 vAHI_SiConfigure 53 2.14.2 vAHI_SiSetCmdReg 54 2.14.3 vAHI_SiWriteData8 54 2.14.4 vAHI_SiWriteSlaveAddr 55 2.14.5 u8AHI_SiReadData8 55 2.14.6 bAHI_SiPollBusy 55 2.14.7 bAHI_SiPollTransferInProgress 55 2.14.8 bAHI_SiPollRxNack 56 2.14.9 bAHI_SiPollArbitrationLost 56 2.14.10 vAHI_SiRegisterCallback 56 2.15 Intelligent Peripheral Mode 57 2.15.1 vAHI_IpEnable 57 2.15.2 bAHI_IpSendData 57 2.15.3 bAHI_IpReadData 58 2.15.4 bAHI_IpTxDone 58 2.15.5 bAHI_IpRxDataAvailable 58 2.15.6 vAHI_IpRegisterCallback 58 2.16 Flash 59 2.16.1 bAHI_FlashInit (JN513x Only) 59 2.16.2 bAHI_FlashErase 59 2.16.3 bAHI_FlashEraseSector (JN513x Only) 60 2.16.4 bAHI_FlashProgram 60 2.16.5 bAHI_FullFlashProgram (JN513x Only) 61 2.16.6 bAHI_FlashRead 61 2.16.7 bAHI_FullFlashRead (JN513x Only) 62 References 63 JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 5
Jennic
6 ? Jennic 200
7 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic
About this Manual
This manual describes the software Application Programming Interface (API) to the peripheral devices on the JN5121 and JN513x single-chip IEEE 802.15.4 compliant wireless microcontrollers. This is known as the Integrated Peripherals API. It details the calls that may be made through the API in order to set up, control and respond to events generated by the peripheral blocks, such as UARTs, general-purpose IO lines and timers among others. Setting up and using power saving modes are also covered.
The software invoked by this API is present in the on-chip ROM. This API does not include support for the IEEE 802.15.4 MAC hardware built into the device; this hardware is controlled using the MAC software stack that is built into the on-chip ROM. Readers are recommended to refer to [1] for further information on the use of this feature.
Note 1: This manual was previously known as the Hardware Peripheral Library Reference Manual.
Note 2: This manual covers both the JN5121 and JN513x versions of the Integrated Peripherals API. Some of the API functions described in this manual are for the JN513x only - these are clearly marked.
Organisation
This document consists of two chapters.
? Chapter 1 gives a brief overview of the scope of the manual
? Chapter 2 describes in detail the calls available to control each feature of the device
Conventions
Code fragments or function prototypes are represented by Courier typeface. When referring
to constants or functions defined in the code they are emboldened, like so.
JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 7
Jennic
Definitions, Acronyms and Abbreviations
ACL Access Control List
ADC Analogue to Digital Converter AES Advanced Encryption Standard AHI Application Hardware Interface API Application Programming Interface CPU Central Processor Unit CTS Clear-To-Send DAC Digital to Analogue Converter DIO Digital Input Output
FIFO First-In, First-Out queue MAC Medium Access Control PAN Personal Area Network PIB PAN Information Base PWM Pulse Width Modulation RAM Random Access Memory RTS Ready-To-Send
SPI Serial Peripheral Interface
UART
Universal Asynchronous Receiver Transmitter
8 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic 1 Introduction
1.1 Scope
This document describes the Application Programming Interface (API) for the JN5121/JN513x hardware peripherals – the Integrated Peripherals API. Its functionality is as follows: ? System Controller
? Wake timers
? Analogue to digital converter (ADC)
? Digital to analogue converters (DACs)
? Comparators
? Digital Input/Output (DIO)
? Universal asynchronous receiver-transmitters (serial ports) (UARTs)
? Timers
? Serial Peripheral Interface (SPI)
? Serial Interface (2 Wire)
? Tick Timer
? External FLASH memory
Note 1: This API was previously known as the Hardware Peripheral Library or the Hardware API.
Note 2: This manual covers both the JN5121 and JN513x versions of the Integrated Peripherals API. Some of the API functions described in this manual are for the JN513x only - these are clearly marked.
This API (sometimes referred to in this document as the AHI) provides a thin layer above the registers used to control the JN5121/JN513x peripherals, by encapsulating several register accesses into one function call and hence making it easier to use the peripherals without having to acquire detailed knowledge of their operation.
This document does not describe the Baseband Controller, Modem or Radio, as these are driven by the 802.15.4 Stack API, which is always provided with the JN5121 and JN513x devices. The 802.15.4 Stack API is described in [1].
This document does not describe the API for features found on evaluation kit boards such as sensors or display panels, although the buttons and LEDs on the evaluation kit boards are connected to the GPIO pins on the JN5121/JN513x chip. The API for evaluation kit board features is described in [2].
1.2 Intended readership
It is assumed that the reader has a reasonable knowledge of ‘C’ programming.
JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 9
Jennic
2 API Description
The API is described in terms of the functions it provides, and these are grouped by peripheral.
The functions are defined in AppHardwareApi.h.
Note: There are small differences in the Integrated Peripherals API for the JN5121 and JN513x chips. Some API functions are for the JN513x only - these are clearly marked in the section headings.
2.1 General
2.1.1 u32AHI_Init
Declaration PUBLIC uint32 u32AHI_Init(void);
Inputs None
Outputs 0 if initialisation failed, otherwise a 32-bit version number (most significant 16 bits are main revision, least significant 16 bits are minor revision)
Description Used to initialise the AHI. This should be called after every reset or wake-up and before any other AHI calls are made. Note that the application API should have
been initialised before this function is called, and the call to initialise the
application API includes a parameter to register a function to call whenever an
interrupt from the peripherals occurs, see following section for details.
2.2 Interrupt Handling
Interrupts from peripheral devices are handled by a set of device-specific callbacks. These can
be set within the Integrated Peripherals API by using the appropriate callback registration
routines. For example the user can write their own UART interrupt handler and then register this routine using the vAHI_Uart0RegisterCallback function. All device-specific callback functions registered must have the following prototype:
PRIVATE void vHwDeviceIntCallback(uint32 u32DeviceId, uint32 u32ItemBitmap)
The device ID, u32DeviceId, is an enumerated value indicating the peripheral that generated
the interrupt, as follows:
Enumeration Interrupt Source Callback registration function
E_AHI_DEVICE_TICK_TIMER Tick Timer vAHI_TickTimerInit
controller vAHI_SysCtrlRegisterCallback E_AHI_DEVICE_SYSCTRL System
E_AHI_DEVICE_AES Encryption engine See JN-RM-2013-AES-
Coprocessor-API
E_AHI_DEVICE_UART0 UART 0 vAHI_Uart0RegisterCallback
E_AHI_DEVICE_UART1 UART 1 vAHI_Uart1RegisterCallback
E_AHI_DEVICE_TIMER0 Timer 0 vAHI_Timer0RegisterCallback
E_AHI_DEVICE_TIMER1 Timer 1 vAHI_Timer1RegisterCallback
master vAHI_SpiRegisterCallback E_AHI_DEVICE_SPIM SPI
10 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic
E_AHI_DEVICE_SI Serial Interface (2 wire) vAHI_SiRegisterCallback
peripheral
vAHI_IpRegisterCallback E_AHI_DEVICE_INTPER Intelligent
peripherals vAHI_APRegisterCallback
E_AHI_DEVICE_ANALOGUE Analogue
The item u32ItemBitmap is an enumerated value indicating the individual interrupt source
within the peripheral, as described in the tables below.
Before calling the callback function, the library clears the source of the interrupt, so there is no danger of the same interrupt causing the processor to enter a state of permanently trying to handle the same interrupt due to a malformed callback function. This also means that it is possible to have a NULL callback function.
The UARTs are the exception to this rule; when generating a ‘receive data available’ or ‘timeout indication’ interrupt, the UARTs will only clear the interrupt when the data is read from the UART receive buffer. It is therefore vital that if UART interrupts are to be enabled, the callback function handles the ‘receive data available’ and ‘timeout indication’ interrupts by reading the data from the UART before returning.
Note that if the Application Queue API is being used, the issue with UART interrupts is handled by the API, so the application does not have to cope with it. See [3] for more information about the Application Queue API.
The enumerated values are defined as follows:
TickTimer
Mask (Bit) Description
0 Single source for Tick Timer interrupt, therefore returns 1 every time System Controller
Mask (Bit) Description
E_AHI_SYSCTRL_COMP_MASK (29) Comparator events
Wake Timer events
E_AHI_SYSCTRL_WK1_MASK (27)
E_AHI_SYSCTRL_WK0_MASK (26)
Digital IO events
E_AHI_DIO20_INT (20)
E_AHI_DIO19_INT (19)
E_AHI_DIO18_INT (18)
.
.
E_AHI_DIO0_INT (0)
UART (Identical for both UARTs)
Enumerated Value Description
E_AHI_UART_TIMEOUT_MASK (6) Timeout indication
E_AHI_UART_RXLINE_MASK (3) Receive line status
E_AHI_UART_RXDATA_MASK (2) Receive data available
E_AHI_UART_TX_MASK (1) Transmit FIFO empty
E_AHI_UART_MODEM_MASK (0) Modem status
JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 11
Jennic
Timers (Identical for both timers)
Mask (Bit) Description
E_AHI_TIMER_RISE_MASK (1) Interrupt status, generated on timer rising edge, end of low period - will be
non-zero if interrupt for timer output going high has been set
E_AHI_TIMER_PERIOD_MASK (0) Interrupt status, generated on timer falling edge, end of period - will be
non-zero if interrupt for timer period complete has been set
Serial Interface (2-wire)
Mask (Bit) Description
E_AHI_SI_RXACK_MASK (7) Asserted if no acknowledge is received from the addressed slave
E_AHI_SI_BUSY_MASK (6) Asserted if a START signal is detected
Cleared if a STOP signal is detected
E_AHI_SI_AL_MASK (5) Asserted to indicate loss of arbitration
E_AHI_SI_ACK_CTRL_MASK (2) Acknowledge control:
0 indicates sent ACK
1 indicates sent NACK
E_AHI_SI_TIP_MASK (1) Asserted to indicate transfer in progress
E_AHI_SI_INT_STATUS_MASK (0) Interrupt status; interrupt indicates loss of arbitration or that byte transfer
has completed
SPI Master
Mask (Bit) Description
E_AHI_SPIM_TX_MASK (1) Asserted to indicate transfer has completed
Intelligent Peripheral
Mask (Bit) Description
E_AHI_IP_INT_STATUS_MASK (6) Asserted to indicate transaction has completed, i.e slave select goes high
and TXGO or RXGO has gone low
E_AHI_IP_TXGO_MASK (1) Asserted when TX data is copied to the internal buffer and cleared when it
has been sent out.
E_AHI_IP_RXGO_MASK (0) Asserted when device is ready to receive state and cleared when data RX
is complete.
Analogue Peripherals
Mask (Bit) Description
E_AHI_AP_INT_STATUS_MASK (0) Asserted to indicate capture complete or new sample ready
12 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic
2.3 System Control
The system controller provides control for the CPU and memory power and sleep operation. There are two significant blocks in the system controller. The 32kHz domain runs from a simple oscillator and is designed for very low power sleep states. Whilst sleeping, the CPU does not run and relies on an interrupt to wake it up. The interrupt can be generated externally or from within the 32kHz domain. Later sections describe the ways in which interrupts can be generated within the chip, using the wake timers to generate events within the 32kHz domain or the DIO pins for external stimuli.
The 16MHz domain is used to run the CPU and several peripherals (security engine, ADC,
timing accuracy.
device powers up. The RAM is powered by its own regulator, separate from the regulator for the CPU. This allows the RAM to remain powered when the CPU is asleep and powered down. This is useful for short sleep periods, when the time taken to re-load the RAM from flash is significant when compared to the sleep time. Alternatively, for longer sleep periods, the memory power may be removed as well, reducing the sleep current consumption.
In addition, there are two other power domains, one for analogue peripherals and the other (the protocol domain) for the modem, encryption coprocessor, radio and baseband controller. The analogue power domain is switched on if the analogue peripherals are in use.
As well as the normal sleep mode, it is possible to enter a deep sleep. In this state both the
16MHz and 32kHz clock domains are turned off and the device can only be woken by the device reset line being pulled low.
A final low power mode is doze mode, in which the CPU remains powered but the 16MHz clock to it is stopped. This uses more power than sleep mode but requires less time to restart. The CPU is brought out of doze mode by an interrupt (note that a tick timer interrupt cannot be used to bring the CPU out of doze mode).
2.3.1 u8AHI_PowerStatus
Declaration PUBLIC uint8 u8AHI_PowerStatus(void);
Inputs None
Outputs uint8 containing power domain control settings
bit 0: 1 if chip has completed a sleep-wake up cycle
bit 1: If 1 after wake up, memory contents were retained during sleep
bit 2: 1 if analogue power domain is switched on
bit 3: 1 if protocol power domain is switched on
Description Returns the power domain settings for the JN5121/JN513x, as described above. JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 13
Jennic
2.3.2 vAHI_MemoryHold
Declaration PUBLIC void vAHI_MemoryHold(bool_t bHoldDuringSleep);
Inputs bool_t
bHoldDuringSleep TRUE to power memory during sleep
FALSE to remove power from memory during sleep
Outputs None
Description Determines whether the memory will remain powered during the next sleep period.
2.3.3 vAHI_CpuDoze
Declaration PUBLIC void vAHI_CpuDoze(void);
Inputs None
Outputs None
Description Causes the CPU to stop operating until an interrupt occurs. The CPU clock will be disabled during sleep to minimise power consumption, although other modules will
still be operational. The function returns when the CPU re-starts.
2.3.4 vAHI_PowerDown
Declaration PUBLIC void vAHI_PowerDown(bool_t bDeepNotNormalSleep);
Inputs bool_t
bDeepNotNormalSleep TRUE for the sleep to be deep sleep (device only awakes through a reset)
FALSE for normal sleep (device wakes after interrupt or reset)
Outputs None
Description Sends the device to sleep. In normal sleep mode, all parts of the device are inactive or powered down apart from the 32 kHz oscillator and those parts of the
system controller used for wake up. In deep sleep, even these are powered
down. This function does not return. When the device restarts, it will begin
processing at the reset vector.
14 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic
2.3.5 vAHI_Sleep (JN513x Only)
Declaration PUBLIC void vAHI_Sleep(teAHI_SleepMode sSleepMode);
Inputs teAHI_SleepMode
sSleepMode One of:
E_AHI_SLEEP_OSCON_RAMON 32 kHz oscillator on and RAM on
E_AHI_SLEEP_OSCON_RAMOFF 32 kHz oscillator on and RAM off
E_AHI_SLEEP_OSCOFF_RAMON 32 kHz oscillator off and RAM on
E_AHI_SLEEP_OSCOFF_RAMOFF 32 kHz oscillator off and RAM off
E_AHI_SLEEP_DEEP
Deep sleep (all components off)
Outputs None
Description Sends the JN513x chip to sleep, allowing the 32 kHz oscillator and the RAM to be individually left on or switched off, as required. When in normal sleep mode, the
device wakes after an interrupt or a reset. When in deep sleep mode, the device
wakes only after a reset. When the JN513x restarts, it will begin processing at the
cold start or warm start entry point. This function does not return.
2.3.6 vAHI_ProtocolPower
Declaration PUBLIC void vAHI_ProtocolPower(bool_t bOnNotOff);
Inputs bool_t bOnNotOff TRUE to turn the protocol power domain on.
FALSE to turn the protocol power domain off. Outputs None
Description Controls the regulator that supplies the protocol domain (the radio, modem baseband and encryption coprocessor). If you intend to turn the protocol power off
and then back on again without performing a reset, you must store the current
MAC settings before turning the protocol power off. You can save the MAC
settings using the function vAppApiSaveMacSettings(). Turning the protocol power
back on can then be achieved simply by restoring the MAC settings using the
function vAppApiRestoreMacSettings(). These functions are described in [1].
While the protocol is powered down, you must not make any calls into the stack as
this may result in the stack trying to access the hardware (which is turned off) and
therefore a crash.
JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 15
Jennic
2.3.7 vAppApiSetBoostMode (JN513x Only)
Declaration PUBLIC void vAppApiSetBoostMode(bool_t bOnNotOff);
Inputs bool_t bOnNotOff TRUE to enable boost mode.
FALSE to disable boost mode (default setting). Outputs None
Description Enables or disables boost mode on a JN513x device – this increases the transmission power by approximately 3 dB (beware that this results in increased
current consumption). A new setting only takes effect when the device is
initialised, so this function call must be followed by a call to either u32AppApiInit()
or u32AppQApiInit(). The setting is maintained throughout sleep mode if memory
is held up, but is lost if memory is turned off.
2.3.8 vAHI_HighPowerModuleEnable (JN513x Only)
Declaration PUBLIC void vAHI_HighPowerModuleEnable(bool_t bRFTXEn,
bool_t bRFRXEn);
bool_t bRFTXEn TRUE to enable high power module transmitter Inputs
FALSE to disable high power module transmitter bool_t bRFRXEn TRUE to enable high power module receiver
FALSE to disable high power module receiver Outputs None
Description Allows the transmitter and receiver sections of a High-Power Module (HPM) to be individually enabled or disabled. Must be called before using radio on an HPM.
2.3.9 vAHI_ExternalClockEnable (JN513x Only)
Declaration PUBLIC void vAHI_HighPowerModuleEnable(bool_t bExClockEn);
Inputs bool_t bExClockEn TRUE to enable external clock input
FALSE to disable external clock input
Outputs None
Description Enables the use of an external source for the 32 kHz clock.
16 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic
2.3.10 vAHI_AntennaDiversityOutputEnable (JN513x Only)
Declaration PUBLIC void vAHI_AntennaDiversityOutputEnable
(bool_t bOddRetryOutEn,
bool_t bEvenRetryOutEn);
bool_t bOddRetryOutEn TRUE to enable output on DIO12
FALSE to disable output on DIO12
Inputs
bool_t bEvenRetryOutEn TRUE to enable output on DIO13
FALSE to disable output on DIO13
Outputs None
Description Supports the provision of an alternative antenna in case of a transmission failure.
DIO12 and DIO13 are each associated with an antenna, and are used to indicate
whether a transmission retry on the corresponding antenna is required. When both
DIOs are enabled for this feature, DIO13 goes high for the first transmission. If no
acknowledgement is received, the need for a first retry of the transmission is
indicated by DIO12 going high (DIO13 goes low). If required, a second retry is
indicated by DIO13 going high (DIO12 goes low). Subsequently, all odd numbered
retries are requested using DIO12 and all even numbered retries are requested
using DIO13. The application must choose the antenna for each retry accordingly.
2.3.11 vAHI_SysCtrlRegisterCallback
Declaration PUBLIC void vAHI_SysCtrlRegisterCallback(PR_HWINT_APPCALLBACK prSysCtrlCallback);
Inputs PR_HWINT_APPCALLBACK
prSysCtrlCallback Pointer to function that is to be called when a system control interrupt occurs.
Outputs None
Description Registers an application callback that will be called when the system control interrupt (caused by wake timer, comparator and DIO events) is triggered.
2.3.12 vAHI_SwReset
Declaration PUBLIC void vAHI_SwReset (void);
Inputs None
Outputs None
Description Generates an internal reset when called, which completely re-starts the system.
JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 17
Jennic
2.4 Wake Timers
The wake timers are normally used to time sleep periods and can be programmed to generate interrupts when the timeout period has completed. However, they can also be used whilst the CPU is running. There is another set of timers with more functionality that can operate only whilst the CPU is running; see Section 2.11.
The wake timers run at a nominal 32kHz but to minimise complexity and hence power consumption, they may run at up to 30% fast or slow depending on temperature, supply voltage and manufacturing tolerance. A self-calibration facility is provided to time the 32kHz clock against the 16MHz clock if accurate timing is required.
2.4.1 vAHI_WakeTimerEnable
Declaration PUBLIC void vAHI_WakeTimerEnable(uint8 u8Timer,
bool_t bIntEnable);
uint8 u8Timer Timer identity:
E_AHI_WAKE_TIMER_0 or
E_AHI_WAKE_TIMER_1
Inputs
bool_t bIntEnable TRUE to enable interrupt when timer fires FALSE to disable interrupt
Outputs None
Description Prepares a wake timer for use, enabling the associated interrupt if desired.
2.4.2 vAHI_WakeTimerStart
Declaration PUBLIC void vAHI_WakeTimerStart(uint8 u8Timer, uint32 u32Count);
uint8 u8Timer Timer identity:
E_AHI_WAKE_TIMER_0 or
E_AHI_WAKE_TIMER_1
Inputs
uint32 u32Count Count time in 32kHz periods, i.e. 32 is 1 millisecond
Outputs None
Description Starts a wake timer to time for the specified interval.
2.4.3 vAHI_WakeTimerStop
Declaration PUBLIC void vAHI_WakeTimerStop(uint8 u8Timer);
Inputs uint8 u8Timer Timer identity:
E_AHI_WAKE_TIMER_0 or
E_AHI_WAKE_TIMER_1
Outputs None
Description Stops a wake timer. No interrupt will be generated.
18 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
Jennic
2.4.4 u8AHI_WakeTimerStatus
Declaration PUBLIC uint8 u8AHI_WakeTimerStatus(void);
Inputs None
Outputs uint8 Bitmap:
Returned value logical ANDed with E_AHI_WAKE_TIMER_MASK_0 will be
non-zero if wake timer 0 is running
Returned value logical ANDed with E_AHI_WAKE_TIMER_MASK_1 will be
non-zero if wake timer 1 is running
Description Returns a bitmap where the relevant bits are set to show which timers are active.
It is possible to have more than one timer active at once. Note that a timer remains
active after the timed interval has completed.
2.4.5 u32AHI_WakeTimerCalibrate
Declaration PUBLIC uint32 u32AHI_WakeTimerCalibrate(void);
Inputs None
Outputs uint32 Returned value shows the calibration offset from the ideal, measured
against the 16MHz clock. The ideal result would be 10000 decimal. A
lower value means that the 32kHz clock is running fast and a higher
value means it is running slow.
Description Performs a calibration of the 32kHz clock against the more accurate 16MHz clock.
The returned value can be used to adjust the time interval values used to program
the wake timers.
Note that the 32kHz clock has a tolerance of +/-30%.
2.4.6 u8AHI_WakeTimerFiredStatus
Declaration PUBLIC uint8 u8AHI_WakeTimerFiredStatus(void);
Inputs None
Outputs uint8 Bitmap:
Returned value logical ANDed with E_AHI_WAKE_TIMER_MASK_0 will be
non-zero if wake timer 0 has fired
Returned value logical ANDed with E_AHI_WAKE_TIMER_MASK_1 will be
non-zero if wake timer 1 has fired
Description Returns a bitmap where the relevant bits are set to show which timers have fired.
Any fired timer status is cleared as a result of this call.
JN-RM-2001 (v2.3) 18-Jun-2007 ? Jennic 2007 19
Jennic
2.5 Analogue Peripherals
This section refers to shared functionality used by both the ADC, DAC and comparator.
2.5.1 vAHI_ApConfigure
Declaration PUBLIC void vAHI_ApConfigure(bool_t bAPRegulator,
bool_t bIntEnable,
uint8 u8SampleSelect,
uint8 u8ClockDivRatio,
bool_t bRefSelect);
bool_t bAPRegulator Enable/disable analogue peripheral regulator
Inputs
E_AHI_AP_REGULATOR_ENABLE
E_AHI_AP_REGULATOR_DISABLE
bool_t bIntEnable Enable/disable interrupt when conversion/capture
completes
E_AHI_AP_INT_ENABLE
E_AHI_AP_INT_DISABLE
uint8 u8SampleSelect Select sample period in divided clock
E_AHI_AP_SAMPLE_2
E_AHI_AP_SAMPLE_4
E_AHI_AP_SAMPLE_6
E_AHI_AP_SAMPLE_8
uint8 u8ClockDivRatio Clock divide ratio
E_AHI_AP_CLOCKDIV_2MHZ
E_AHI_AP_CLOCKDIV_1MHZ
E_AHI_AP_CLOCKDIV_500KHZ
E_AHI_AP_CLOCKDIV_250KHZ
Currently only E_AHI_AP_CLOCKDIV_500KHZ is
recommended
bool_t bRefSelect Select reference voltage
E_AHI_AP_EXTREF
E_AHI_AP_INTREF
Outputs None
Description Allows access to sample period and sampling rate for both ADC and DAC operations as well as enabling interrupts and selecting reference voltage.
The analogue peripheral regulator also supplies power for comparator
configuration functions.
20 ? Jennic 2007 JN-RM-2001 (v2.3) 18-Jun-2007
系统常用事件处理函数： －按键事件 －接收消息事件 －网络状态改变事件 －绑定确认事件 －匹配响应事件 1、按键事件 Case KEY_CHANGE: 当有按键事件发生的时，调用按键事件处理函数Sample_HandleKeys()来处理按键事件。 在SampleApp例程中按键处理函数处理了以下2件事情 －如果按键1按下，将向网络中的其他设备发送LED闪烁命令 －如果按键2按下，检测组ID号为SAMPLEAPP_FLASH_GROUP的组是否已经注册。如果已经注册，调用aps_RemoveGroup()将其删除；如果没注册就在APS层注册
2、接收消息事件 Case:AF_INCOMING_MSG_CMD: 如果有接收消息事件发生，则调用函数SampleApp_MessageMSGCB（MSG）对接收的消息进行处理。一般的接收消息事件是通过用户自定义的端点输入簇和输出簇来处理的。 在LED闪烁命令的发送函数中的输出簇为SAMPLEAPP_FLASH_CLUSTERID，所以在接收消息事件的输入簇中为SAMPLEAPP_FLASH_CLUSTERID即收到LED闪烁命令
3、网络状态改变事件 Case：ZDO_STATE_CHANGE 当有网络状态改变事件发生后，会调用函数SampleApp_NwkState()来处理网络状态改变事件。在SampleApp例程中，网络状态改变事件主要处理了以下事件： －判断设备类型（区分协调器、路由节点、终端节点） －当协调器网络建立成功后或其他类型节点加入网络后点亮led1 －通过调用osal_start_timerEx()设置一个定时事件，当时间到达后启用用户自定义事件SampleApp_Send_PERIODIC_MSG_EVT 备注：在使用过程中这里的3种设备类型不是全选，写一个就可以了，其他的删除
合同编码： 框架合作协议 甲方： 地址： 乙方： 地址： 说明：本合同由《合作协议书》及协议附件两部分组成，合同中没有涉及的内容，由甲、乙双方协商一致后另行签订书面文件。 签约地点：市区 签约时间：年月日
合作协议书 鉴于互联网技术的发展及国家大力提倡阳光采购，为了更好地服务于采购单位，实现采购的阳光化、便捷化、电子化，甲乙双方同意发挥各自的优势，在公共采购领域中开展紧密合作。 本着“公平自愿、互利共赢”的原则，甲乙双方经友好协商就合作事宜达成合作意向，签署本协议书。具体内容如下： 第一条合作内容： 1、双方有意愿积极探索电子商务在公共采购领域的合作。 2、乙方负责自身内部平台的开发、维护和管理等工作，并协助甲方进行平台接口开发及对接工作。 3、甲方负责平台接口开发和商品、交易服务的提供。 4、甲方提供给乙方自营商品，乙方根据甲方提供商品在乙方平台销售，甲方根据乙方系统的订单推送给乙方指定收货人发货。 第二条技术合作部分 1、甲方提供平台接口的技术支持。 2、甲方在现有技术上努力维护网上交易平台的正常运行，并努力提升和改进技术，使网上交易活动得以顺利进行。 3、乙方可以抓取或者链接甲方推送至乙方平台上的：□ 商品介绍、□ 价格、□ 库存、□ 商品评价、□ 其他。 4、乙方有责任保证平台接口的安全使用，不得泄露甲方提供的接口信息和数据信息，如因泄露所造成的一切损失均由乙方承担，并承担万元的违约金。 5、甲方保留在任何时候自行决定对平台服务及其相关功能、升级的权利；甲方进一步保留在服务中开发新的模块、功能的权利，上述所有新的模块、功能、软件服务的提供，除非甲方另有说明，否则仍适用本协议，如因甲方软件升级、改造影响到与乙方的合作，甲方应提前2日书面通知乙方。 6、双方保证所提供的数据、文档、资料、数据包及数据包中用户信息、商品信息、交易信息等准确无误，并不得采取任何非法方式篡改系统中的交易数据、用户信息、积分信息等系统数据或代码，否则，应承担万元的违约金 第三条商务合作部分 1、商品 1.1乙方仅可购买甲方提供的自营类商品及服务，第三方商家提供的商品及服务暂不支持交易。
开放平台技术合作合同模板 V1.0编号：xxxxxxxxxxxxxxxxxxxxxxxxx 本合同由以下双方签署： 甲方：XXXXXXXXXXXX有限公司（以下简称“甲方”） 地址： 联系人： 联系方式： 乙方：XXXXXXXXXXXX有限公司（以下简称“乙方”） 地址： 联系人： 联系方式： 本合同根据《中华人民共和国合同法》及相关法律、法规的规定，甲乙双方经友好协商，签订此合同，以兹共同遵守。 一、定义及解释 1. XXXXX开放平台（以下简称“平台”或者“开放平台”）：基于甲方各类业务的开放，由甲方提供技术文档、应用程序及相关技术支持，服务商可以通过这些技术文档、应用程序及技术支持开发应用及软件以便服务于自身或服务于平台其他用户。服务商可以通过平台应用编程接口调用指定的功能服务，访问由甲方提供的或用户授权的与用户相关的数据和/或来自甲方其他应用程序的数据信息，或者由乙方/开发者应用向甲方提供、回流数据。平台可能包括但不限于一个或多个技术文档和应用程序。 2. 服务商：指通过有效申请并通过审核验证的可基于平台进行应用开发的单位（即本合同中“乙方”）。 3. 甲方商家（或称“商家”）：指通过甲方运营／管理的网络服务平台（包括但不限于xx网、甲方关联方、甲方合作方运营／管理的网络服务平台及未来可能新设或合作的网络平台等）发布商品/服务信息、向用户提供商品/服务并向服务商采购应用的自然人、法人和其他组织。 4. 用户：指通过访问和使用甲方运营／管理的网络服务平台，与甲方商家达成订单或
有意向达成订单的消费者。 5. 应用：指服务商基于平台所开发的应用程序或软件服务，包括自用型应用和他用型应用两种类型。 6. Open API：指对所有申请并审批通过后的应用开放的遵照甲方接口协议即可调用的数据接口。 7. SDK：指对所有申请并审批通过后的应用开发的遵照甲方接口协议即可调用的编程接口。 8. UI SDK：指对所有申请并审批通过后的应用开发的遵照甲方接口协议即可调用并嵌套的界面应用。 9. 开发者：服务商接入平台需要进行系统开发，开发者是服务商中的系统开发人员（即本合同中“乙方开发人员”）。 二、甲方的服务内容 本合同生效后，乙方将开发者资质、公司资质、需要的接口服务等内容提交甲方审核，甲方审核通过后，将提供以下服务： 1. 甲方向乙方提供服务商平台，并为乙方提供应用开发的技术文档、应用程序及技术支持，包括应用数据接口的开发、封装以及与此有关的互联网技术服务。 2. 乙方基于和甲方的合作，就相关合作问题要求甲方提供的其他技术服务/支持。 3. 乙方通过平台和接口开发以便服务于乙方自身或平台其他商家。乙方可通过平台指定的方式，访问由甲方提供的或用户授权的与用户相关的数据和/或来自甲方其他应用程序的数据信息，或者由乙方向甲方提供、回流数据。 4. 具体合作方式：open API，SDK，UI SDK 三、甲方权利义务 1. 甲方负责应用开发的网络环境、接口的维护，以及平台的建设与维护。 2. 甲方有权对乙方提交的信息及线上应用/软件服务进行审核，甲方的审核流程如下： (1) 入驻审核：乙方自助申请并按照甲方“开放平台申请加入页面”中的要求提交相关资质、乙方产品信息等其他甲方需要乙方提交的信息。甲方审核人员会对乙方自助申请入驻时提交的资质及产品信息等进行审核；审核通过后，乙方有权参与平台的测试环境开发；在乙方资质缺失、拒不提供、信息造假、不符合甲方《开放平台运营管理规则》等情况下，
根据应用和市场需要定义了ZigBee 协议的分层架构，其协议的体系结构如图1 所示，其中物理层（physical layer，PHY）和媒介访问控制层（medium access control sub-layer,MAC）是由IEEE802.15.4-2003 标准定义的，在这个底层协议的基础上ZigBee 联盟定义了网络层（network layer,PHY）和应用层（application layer,APL）架构. 图1 zigbee协议栈体系结构 物理层规范 物理层定义了它与MAC 层之间的两个接口：数据服务接口PD-SAP 和管理服务接口PLME-SAP，其中PD-SAP 接口还为物理层提供了相应的数据服务，负责从无线物理信道上收发数据，而PLME-SAP 接口同时为物理层提供相应的管理服务，用于维护一个由物理层相关数据组成的数据库。物理层负责数据的调制、发送和接收、空闲信道评估（clear channel assessment,CCA）信道能量的监测（energy detect,ED）和链接质量指示（link quality indication，LQI）等。物理层帧结构由同步头、物理层帧头和物理层有效载荷三部分组成，如表1 所示。
同步头又包括32bit 的前同步码和8bit 的帧定界符，前同步码用来为数据收发提供码元或数据符号的同步；帧界定符用来标识同步域的结束及数据的开始。物理层帧头包括7bit 的帧长度和1bit 的预留位，帧长度定义了物理层净荷的字节数。物理层有效载荷就是MAC层的帧内容。 表一物理层帧格式 媒体接入控制层规范 MAC 层定义了它与网络层之间的接口，包括提供给网络层的数据服务接口MLDE-SAP 和管理服务接口MLME-SAP，同时提供了MAC 层数据服务和MAC 层管理服务。MAC层数据服务主要实现数据帧的传输；MAC 层管理服务主要负责媒介访问控制、差错控制等。 MAC 层主要功能包括以下几个方面： （1）ZigBee 协调器产生网络信标 （2）设备与信标同步 （3）支持节点加入或着退出操作 （4）信道接入方式采用免冲突载波检测多路访问（CSMA-CA）机制 （5）建立并维护保护时隙机制 （6）为设备提供安全支持 MAC 帧格式由三个基本部分组成：MAC 帧头、MAC 帧载荷和MAC 帧尾。不同类型的MAC 帧，其帧头和帧尾都是一样的，只是MAC 帧载荷有差别，通用MAC 帧格式如表2所示。 表二通用MAC帧格式 网络层规范 网络层定义了它与应用层之间的接口，包括提供给应用层的数据服务接口NLDE-SAP和管理服务接口NLME-SAP , 同时提供了网络层数据服务和网络层管理服务。网络层主要负责拓扑结构的建立和网络的维护，具体的功能如下：（1）初始化网络，即建立一个新的包含协调器、路由器和终端设备的网络（2）设备连接和断开时所采用的机制 （3）对一跳邻居节点的发现和相关节点信息的存储 （4）ZigBee 协调器和路由器为新加入节点分配短地址
1Zigbee协议栈相关概念 1.1近距离通信技术比较： 近距离无线通信技术有wifi、蓝牙、红外、zigbee，在无线传感网络中需求的网络通信恰是近距离需求的，故，四者均可用做无线传感网络的通信技术。而，其中（1）红外（infrared）：能够包含的信息过少；频率低波衍射性不好只能视距通信；要求位置固定；点对点传输无法组网。（2）蓝牙（bluetooth）：可移动，手机支持；通信距离10m；芯片价格贵；高功耗（3）wifi：高带宽；覆盖半径100m；高功耗；不能自组网；（4）zigbee:价格便宜；低功耗；自组网规模大。?????WSN中zigbee通信技术是最佳方案，但它连接公网需要有专门的网关转换→进一步学习stm32。 1.2协议栈 协议栈是网络中各层协议的总和，其形象的反映了一个网络中文件传输的过程：由上层协议到底层协议，再由底层协议到上层协议。 1.2.1Zigbee协议规范与zigbee协议栈 Zigbee各层协议中物理层（phy）、介质控制层（mac）规范由IEEE802.15.4规定，网络层（NWK）、应用层（apl）规范由zigbee联盟推出。Zigbee联盟推出的整套zigbee规范：2005年第一版ZigBeeSpecificationV1.0，zigbee2006，zigbee2007、zigbeepro zigbee协议栈：很多公司都有自主研发的协议栈，如TI公司的：RemoTI，Z-Stack，SimpliciTI、freakz、msstatePAN 等。 1.2.2z-stack协议栈与zigbee协议栈 z-stack协议栈与zigbee协议栈的关系：z-stack是zigbee协议栈的一种具体实现，或者说是TI公司读懂了zigbee 协议栈，自己用C语言编写了一个软件—---z-stack，是由全球几千名工程师共同开发的。ZStack-CC2530-2.3.1-1.4.0软件可与TI的SmartRF05平台协同工作，该平台包括MSP430超低功耗微控制器(MCU)、CC2520RF收发器以及CC2591距离扩展器，通信连接距离可达数公里。 Z-Stack中的很多关键的代码是以库文件的形式给出来，也就是我们只能用它们，而看不到它们的具体的实现。其中核心部分的代码都是编译好的，以库文件的形式给出的，比如安全模块，路由模块，和Mesh自组网模块。与z-stack 相比msstatePAN、freakz协议栈都是全部真正的开源的，它们的所有源代码我们都可以看到。但是由于它们没有大的商业公司的支持，开发升级方面，性能方面和z-stack相比差距很大，并没有实现商业应用，只是作为学术研究而已。 还可以配备TI的一个标准兼容或专有的网络协议栈（RemoTI，Z-Stack，或SimpliciTI）来简化开发,当网络节点要求不多在30个以内，通信距离500m-1000m时用simpliciti。 1.2.3IEEE802.15.4标准概述 IEEE802.15.4是一个低速率无线个人局域网(LowRateWirelessPersonalAreaNetworks，LR-WPAN)标准。定义了物理层(PHY)和介质访问控制层(MAC)。 LR-WPAN网络具有如下特点： ◆实现250kb/s，40kb/s，20kb/s三种传输速率。 ◆支持星型或者点对点两种网络拓扑结构。 ◆具有16位短地址或者64位扩展地址。 ◆支持冲突避免载波多路侦听技术(carriersensemultipleaccesswithcollisionavoidance，CSMA/CA)。（mac层） ◆用于可靠传输的全应答协议。(RTS-CTS) ◆低功耗。 ◆能量检测(EnergyDetection，ED)。 ◆链路质量指示(LinkQualityIndication，LQI)。 ◆在2.45GHz频带内定义了16个通道；在915MHz频带内定义了10个通道；在868MHz频带内定义了1个通道。 为了使供应商能够提供最低可能功耗的设备，IEEE(InstituteofElectricalandElectronicsEngineers，电气及电子工程师学会)定义了两种不同类型的设备：一种是完整功能设备(full．functionaldevice，FFD)，另一种是简化功能设备
黑格科技API接口供货协议 甲方： 乙方：黑格科技 协议号：xxxxxxxxxx
甲方： 法定代表人： 地址： 联系人： ： 传真： 邮编： 乙方：黑格科技 法定代表人：超 地址：市西城区裕民路18号北环中心2008室 联系人：宇鹏 ： 传真：3 邮编：100080 乙方作为数字类商品的运营商，同时作为容提供方（下称CP），API平台是乙方的供货平台，是与甲方合作后的后台管理平台。 经友好协商，甲方通过乙方的平台为甲方的用户提供业务服务（下称SP），乙方向甲方提供手机话费直充接口；双方按照商定的供货价格进行结算，并达成协议如下：
第一条：甲方的权利义务： 1、甲方首先按照乙方API平台（https://www.doczj.com/doc/539968125.html,）上的注册流程进行用户注册，注册后方可称为乙方的合作用户。成功注册后将会生成一个有效，甲方可利用该登陆、查询和管理业务。 2、甲方必须在乙方API平台购买一定金额的储值（储值与人民币等值），储值使用结束后，提供自动中止，甲方有权要求将储值等值兑换成人民币。甲方首次购买储值后，如未发生任何交易行为且需把全部储值兑换成等值人民币，兑换时间须自协议生效的三个月后方可申请操作。 3、甲方可以自行对乙方供货的商品进行定价，但是销售价格不能低于乙方的供货价格。 4、甲方可以对乙方的接口进行2次开发，但是不能再作为容提供商给第三方提供接口供货。 5、甲方需要对自己的平台的安全性负责，如果因为甲方自身安全问题或未及时按照乙方官网上的提示进行安全设置修改，造成商品失窃，全部由甲方自行负责，但必要时乙方应提供相关帮助。 6、甲方与乙方的接口对接，必须按照乙方提供的接口文档进行开发，如未按照接口文档的约定进行操作造成的损失全部由甲方自行承担。 第二条：乙方的权利义务： 1、乙方需要给甲方提供完善的供货系统，包括系统和接口供货系统，并且提供完善的对账系统和对账接口。对于人工充值的订单请求，乙
API服务合作协议 甲方：上海XX电子商务有限公司 乙方：深圳市XX网络科技有限公司 甲、乙双方就甲方在乙方网站（XX网站：https://www.doczj.com/doc/539968125.html, ，以下简称为乙方网站）获取数据查询API服务，在自愿、平等互利的基础上经过友好协商，达成以下协议： 一、甲方的权利与义务： 1、甲方可通过乙方授权IP（ *，下简称IP）调用由乙方提供的物流查询API服务； 2、甲方接入IP必须向乙方提出申请，经授权后接入；如因代码搬迁需要更换IP，需要重新向乙方提出接入许可； 3、甲方承诺不通过开放API向乙方计算机进行任何与物流查询API服务无关的恶意操作； 4、超过服务规定流量的API调用，经乙方书面告知后，甲方需要支付乙方超额流量费； 5、甲方的业务必须符合国家法律和社会道德，产品形式形态需提前和乙方沟通，调用接口符合乙方具体的规定； 6、甲方承诺其不会将通过乙方网站提供的API服务、公开渠道以及基于本协议项下合作获取的查询相关数据用于本协议之外的商业目的（包括单独销售，与其他任何第三方进行合作）；否则，甲方应承担由此引发的一切责任及损失。乙方有权提前终止本协议，并要求甲方赔偿乙方遭受的全部损失； 二、乙方的权利和义务： 1、乙方根据科研需要，完善API功能，提供稳定API服务； 2、乙方有义务在工作日内对甲方查询流量超标进行告知，并允许甲方在三个工作日对超标流量进行核实或对进行调整，在甲方确认核实的情形下，向甲方收取必要流量费用； 3、甲方单日流量超过60万单次以上对乙方服务器会造成较大的影响，须双方确认提高相应的服务套餐，如协商未果，乙方有权随时停止提供服务，避免影响乙方网站平台； 4、乙方需对甲方的查询资料进行严格保密，未经允许，不可泄露甲方资料，不可使用甲方资料进行任何商业活动； 5、乙方保证提供7*24小时技术服务支持，双方本着相互信任、以诚相见的原则，对于存在的技术问题、网络问题导致服务异常或者终止的情况共同协商、配合解决； 三、服务内容及费用： 以上金额以预付款的形式，进行多退少补-实际使用后按对应的套餐进行扣款；如果以季度预付，第三个月如要取消合作，须在第二个月结束的前一周时间提出，退款以整个月计算，当月如使用过则无法退款；季度结束后,如有多余的预付款,则可退款或顺延至次季
讨论ZigBee协议栈的构成以及内部OSAL的工作机理。 ZigBee协议栈OSAL介绍 操作系统抽象层 OSAL常用术语： 1.资源（Resource）：任何任务所占用的实体都叫资源，如变量、数组、结构体 2.共享资源（Shared Resource）：两个或两个以上任务使用的资源，为防止破坏资源，任务在操作共享资源时是独占状态。 3.任务（Task）：即线程，简单的程序的执行过程。任务设计时将问题尽可能分成多个任务，每个任务独立完成某项功能，同时赋予优先级、CPU寄存器和堆栈空间。一般一个任务设计为一个无限循环。 4.多任务运行（Muti-task Running）：其实同一时刻只有一个任务运行。 5.内核（Kernel）：内核负责管理各个任务。包括：分配CPU时间；任务调度；任务间的通信。 6.互斥（Mutual Exclusion）：多任务通信最常用方法是共享数据结构。 保护共享资源常用的方法： 关中断； 使用测试并置位指令（T&S指令）； 禁止任务切换； 使用信号量； 7.消息队列（Message Queue）：用于任务间传递消息。 OSAL提供如下功能： 任务注册、初始化和启动； 任务间的同步、互斥； 中断处理； 储存器分配和管理； OSAL运行机理： OSAL就是一种支持多任务运行的系统资源分配机制。 OSAL是一种基于事件驱动的轮询式操作系统。、 void osal_start_system(void)是ZigBee协议栈的灵魂，不断的查看事件列表，如果有事件发生就调用相应的事件处理函数。 SYS_EVENT_MSG是一个事件集合，是由协议栈定义的事件，即系统强制事件（Mandatory Events），它的定义为： #define SYS_EVENT_MSG 0x8000； 它包含如下事件： AF_INCOMING_MSG_CMD 收到一个新的无线数据
1.概述 1.1解析ZigBee堆栈架构 ZigBee堆栈是在IEEE 802.15.4标准基础上建立的，定义了协议的MAC和PHY层。ZigBee设备应该包括IEEE802.15.4(该标准定义了RF射频以及与相邻设备之间的通信)的PHY和MAC层，以及ZigBee堆栈层：网络层(NWK)、应用层和安全服务提供层。图1-1给出了这些组件的概况。 1.1.1ZigBee堆栈层 每个ZigBee设备都与一个特定模板有关，可能是公共模板或私有模板。这些模板定义了设备的应用环境、设备类型以及用于设备间通信的簇。公共模板可以确保不同供应商的设备在相同应用领域中的互操作性。 设备是由模板定义的，并以应用对象(Application Objects)的形式实现(见图1-1)。每个应用对象通过一个端点连接到ZigBee堆栈的余下部分，它们都是器件中可寻址的组件。 图1-1 zigbe堆栈框架 从应用角度看，通信的本质就是端点到端点的连接(例如，一个带开关组件的设备与带一个或多个灯组件的远端设备进行通信，目的是将这些灯点亮)。 端点之间的通信是通过称之为簇的数据结构实现的。这些簇是应用对象之间共享信息所需的全部属性的容器，在特殊应用中使用的簇在模板中有定义。图1-1-2就是设备及其接口的一个例子：
图1-1-2 每个接口都能接收(用于输入)或发送(用于输出)簇格式的数据。一共有二个特殊的端点，即端点0和端点255。端点0用于整个ZigBee设备的配置和管理。应用程序可以通过端点0与ZigBee 堆栈的其它层通信，从而实现对这些层的初始化和配置。附属在端点0的对象被称为ZigBee设备对象 (ZD0)。端点255用于向所有端点的广播。端点241到254是保留端点。 所有端点都使用应用支持子层(APS)提供的服务。APS通过网络层和安全服务提供层与端点相接，并为数据传送、安全和绑定提供服务，因此能够适配不同但兼容的设备，比如带灯的开关。APS使用网络层(NWK)提供的服务。NWK负责设备到设备的通信，并负责网络中设备初始化所包含的活动、消息路由和网络发现。应用层可以通过ZigBee设备对象(ZD0)对网络层参数进行配置和访问。 1.1.2 80 2.15.4 MAC层 IEEE 802.15.4标准为低速率无线个人域网(LR-WPAN)定义了OSI模型开始的两层。PHY层定义了无线射频应该具备的特征，它支持二种不同的射频信号，分别位于2450MHz波段和868/915MHz 波段。2450MHz波段射频可以提供250kbps的数据速率和16个不同的信道。868 /915MHz波段中，868MHz支持1个数据速率为20kbps的信道，915MHz支持10个数据速率为40kbps的信道。MAC层负责相邻设备间的单跳数据通信。它负责建立与网络的同步，支持关联和去关联以及MAC 层安全：它能提供二个设备之间的可靠链接。 1.1.3 关于服务接入点 ZigBee堆栈的不同层与802.15.4 MAC通过服务接入点(SAP)进行通信。SAP是某一特定层提供的服务与上层之间的接口。 ZigBee堆栈的大多数层有两个接口：数据实体接口和管理实体接口。数据实体接口的目标是向上层提供所需的常规数据服务。管理实体接口的目标是向上层提供访问内部层参数、配置和管理数据的机制。 1.1.4 ZigBee的安全性 安全机制由安全服务提供层提供。然而值得注意的是，系统的整体安全性是在模板级定义的，这意味着模板应该定义某一特定网络中应该实现何种类型的安全。 每一层(MAC、网络或应用层)都能被保护，为了降低存储要求，它们可以分享安全钥匙。SSP是通过ZD0进行初始化和配置的，要求实现高级加密标准(AES)。ZigBee规范定义了信任中心的用
STANDARD AGREEMENT SAMPLE (协议范本) 甲方：____________________ 乙方：____________________ 签订日期：____________________ 编号：YB-BH-029003 合作协议书通用版
合作协议书通用版 合作协议书（保健品系列合作） 立协议双方： ×××有限公司（以下简称甲方） ×××（以下简称乙方） 甲、乙双方本着互利互惠、共同发展的原则，经过弃分的可行性研究和相互协商，一致决定联合出资开发、生产、经营"×××"×××项目。为明确双方权利、义务，特订立本协议。 一、×××系采用高新技术开发的新一代纯天然保健食品，其可行性研究报告及市场前景预测，已得到双方确认。 二、×××系列产品的生产配方由乙方提供，作价万元，并以此作为出资的一部分。 产品配方在作为出资提供后，其所有权归双方共同享有。 三、双方出资比例各占投资总额的%，其中甲方以现金方式出资，乙方以现金和技术出资。 为产品的研发及向卫生部门申报保健品生产批准文号，甲方现金出资万元，乙方现金出资万元，另加上述技术（配方）出资万元，作为第一共同出资。
在获得卫生部门批准文号后，组织生产、经营所需的资金由双方按上述比例全额投入。 四、甲、乙双方按投资比例分配利润，承担对外债务，任何一方不得擅自在未经对方同意及清算前提出退出合作。 五、×××系列产品的生产、经营活动以甲方名义进行，其运作模式按甲方公司内部规章制度执行。 如需另行吸收股东组建公司，按《公司法》有关规定执行。 六、本协议未尽事宜，双方协商解决，并订立补充协议，以作为本协议的补充，具有相同的法律效力。 七、本律师一经签署，即具有法律效力，任何一方均应信守。如有违约，需承担相应的法律责任。 八、甲、乙双方发生纠纷，应本着有利于事业发展的原则。协商解决，如协商不成，则可诉诸法院。 九、本协议一式二份，双方各执一份，在各方签字或盖章后生效。 甲方：×××有限公司（公章） 代表： 乙方： 年月日 XX网络科技有限公司 YunBo Network Technology Co., Ltd.
本实验是基于ZStack-CC2530-2.5.1a版本的协议栈来进行实验的，整个实验需要改动 hal_board_cfg.h、hal_board_cfg.h、hal_key.c、hal_key.h和自己定义的Coordinator.c这5个文件。 注意：添加自己的按键时尽量不要修改协议栈里面的按键程序，自己另行添加即可。 1、hal_key.h 在/* Switches (keys) */下面添加自己的按键定义 #define HAL_KEY_SW_8 0x80 图1： ---------------------------------------------------------------------------------------- 2、hal_board_cfg.h 在/* S6 */ #define PUSH1_BV BV(1) #define PUSH1_SBIT P0_1 #if defined (HAL_BOARD_CC2530EB_REV17) #define PUSH1_POLARITY ACTIVE_LOW #elif defined (HAL_BOARD_CC2530EB_REV13) #define PUSH1_POLARITY ACTIVE_LOW #else #error Unknown Board Indentifier #endif 下面模仿/* S6 */下的程序定义自己的按键值： /* S8 */ #define PUSH8_BV BV(4)//修改 #define PUSH8_SBIT P0_4//修改 #if defined (HAL_BOARD_CC2530EB_REV17)
合同编号: 协议 （API接口） 甲方： 乙方： 甲方为一家公司，对有需求，同时乙方为一家提供数据共享、 并为乙方提供的技术服务支付对价。 现经甲乙双方友好协商，根据《中华人民共和国合同法》等有关法律法规，就乙方为甲方提供接口服务达成以下一致。 本合同中所用术语的定义如下： 第一条服务内容 在甲方已经依法获得被查询用户授权的前提下，乙方为甲方提供信息查询/验证服务，包括但不限于表1: 表1：
甲方承诺以如下方式三使用协议中约定的数据 方式一：科研或教育机构，用于科研教学等非盈利性用途； 方式二：企业机构，用于产品研发阶段商业用途； 方式三：企业机构，用于产品对外服务商业用途； 第二条服务期限、开通时间、方式及交付标准 1. 服务期限：自本合同生效之日起壹(1)年。 2. 服务开通时间：乙方收到甲方预付款后贰拾肆(24)小时内为甲方开通接口服务，乙方指定联系人以电子邮件的形式通知甲方指定联系人； 3. 提供服务的方式：API接口提供服务 4. 交付标准：乙方为甲方提供可用、正式帐号及密码 第三条结算期限及方式 1. 合同金额： 2. 结算方式：甲方应预付服务费。甲方应于本合同生效后伍(5) 个工作日内向乙方支付本合同项下的第一笔预付费共计人民币（大写）圆整。 3. 当甲方帐户余额低于壹千元（1000元）时，乙方应当提前三日通知到甲方充值，乙方向甲方提供正规增值税专用发票（发票内容为服务费）。 4. 对账与结算：乙方根据甲方实际查询次数从预付费中扣减服务费。每自然月结束后三(3)个工作日内，乙方向甲方提供上月账单明细及与账单金额相等的发票。如乙方提供的账单与甲方统计的数据一致，则甲方应于收到账单之日起10个工作日内与乙方确认账单金额；如乙方账单金额与甲方统计的数据误差在30条以内的，以乙方结果为准；如误差超过30条，则双方应在五个工作日内完成互查，甲方当月的结算金额以双方达成一致的最终核查结果为准；如互查后双方仍无法达成一致，双方平均承担核查不清部分数据的服务费。 6. 乙方的收款账户信息： 账户名称： 开户银行： 银行帐号： 7. 甲方的开票信息： 账户名称： 开户行： 银行账户：
合作协议合同范本 甲方：xxx ，身份证号：xxxxxxxxxxxx. 乙方：xxx ，身份证号：xxxxxxxxxxxx. 丙方：xxx ，身份证号：xxxxxxxxxxxxx. 丁方：xxx ，身份证号：xxxxxxxxxxx. 甲方、乙方、丙方、丁方本着互谅互让、平等协商的精神， 就xxxx 的经营管理事宜等达成协议如下： 一、合作事宜及职责划分 甲方、乙方、丙方、丁方在符合四方共同利益的前提下，现就正式接手xxxxx 经营管理有关事宜，自愿结成战略合作伙伴关系。具体职责范围划分如下： （1）甲方主管市场的账务管理，负责与有关管理机构、商户的协调处理关系，是合作组织唯一的合法代表人。 （2）乙方负责财务以外的市场具体管理、有关工作的开展与 实施、以及冲突问题的解决等。
（3）丙方、丁方在乙方的领导下工作，配合乙方工作抓好秩序与卫生的管理工作。 二、盈余分配与债务承担 1. 盈余分配： 甲方、乙方、丙方、丁方不领取工资报酬，在扣除正常办公开支、上交费用、人员工资（收费人员两人、会计一人、卫生清洁人员一人）及向xxxxx 交纳的费用后由甲方主持分配。其中甲方所得份额为50%，乙方、丙方、丁方三方共得50%的份额。 2. 债务承担： 若因xxxxxx 原因或其他市场方面的原因导致甲方承担债务 的，债务由本协议各方按盈余分配比例承担，并互负连带责任。 三、合作范围内的事务处理，如人员的选聘等需由甲乙丙丁四方共同协商，所需费用甲乙丙丁四方共同承担，费用的用途应予明示，各方均享有知情权。 四、甲乙丙丁任何一方不得从账务中支取、借支款项，任何一方以个人名义做出的民事行为或以合作组织名义，实为谋取个人利益的民事行为的后果均由其个人承担，与合作组织的其他方无关。一方更不得因己方原因使合作方的商业信誉受损。
个人微信开发API协议 一、基础消息类型 1、客户端发送的心跳包HeartBeatReq = 1001; 2、消息接收确认回复（接收或拒绝接收）MsgReceivedAck = 1002; 3、错误单独提升为一种消息类型Error = 1003; 4、通用任务执行结果通知TaskResultNotice = 1025; 二、设备客户端授权类消息 1、设备(手机客户端、客服客户端)获取通信token请求与响应DeviceAuthReq = 1010; 设备(手机客户端、客服客户端)获取通信token响应DeviceAuthRsp = 1011; 2、设备授权后退出(仅用于服务端内部)DeviceExitNotice = 1012; 3、账号强制下线通知AccountForceOfflineNotice = 1013; 三、手机客户端上传的通知类消息 1、手机客户端微信上线通知WeChatOnlineNotice = 1020; 2、手机客户端微信下线通知WeChatOfflineNotice = 1021; 3、微信个人号新增好友通知FriendAddNotice = 1022; 4、微信个人号移除好友通知FriendDelNotice = 1023; 5、微信好友发来聊天消息通知FriendTalkNotice = 1024; 6、手机上回复好友的聊天消息通知WeChatTalkToFriendNotice = 1026; 7、有好友请求添加好友的通知FriendAddReqeustNotice = 1027; 8、手机上发送了朋友圈通知CircleNewPublishNotice = 1031; 9、手机上删除朋友圈返回通知CircleDelNotice = 1032;
服务合作协议书范本 甲方： 住址： 法人代表： 身份证号： 乙方： 住址： 法人代表： 身份证号： 甲乙双方本着相互信任，真诚合作的原则，经双方友好协商，就乙方为甲方提供特定服务达成一致意见，特签订本合同。 一、服务内容 1、乙方同意向甲方提供附于本合同并作为本合同一部分的附件（附件自拟）所列的特定服务。服务的内容、时限、衡量成果的标准见附件。 2、如果乙方在工作中因自身过错而发生任何错误或遗漏，乙方应无条件更正，而不另外收费，并对因此而对甲方造成的损失承担赔偿责任，赔偿以附件所载明的该项服务内容对应之服务费为限。若
因甲方原因造成工作的延误，将由甲方承担相应的损失。 3、乙方的服务承诺： （1）乙方接到甲方通过电话、信函传真、电子邮件、网上提交等方式提出关于附件所列服务的请求后，在两个有效工作日内给予响应并提供服务。 （2）乙方提供给甲方的服务，必须按照合同附件规定的标准进行。 二、服务费的支付 1、服务费总金额为___________人民币（大写：____________人民币元整）。 2、本费用结构仅限于附件中列明的工作。如果甲方要求扩大项目范围，或因甲方改变已经议定的项目内容导致乙方需重复进行项目步骤，乙方将需要重新评估上述费用结构。 3、甲乙双方一致同意项目服务费以人民币形式支付。甲方将在验收确认该阶段服务完成合格，并且乙方发出该阶段工作的费用账单及正式有效的税务发票后______个工作日内，向乙方支付约定的费用。 4、有关发票方面的任何问题，甲方应在收到发票后及时书面通知乙方，以便乙方及时作出解释或解决问题，以使甲方能按时付款。 5、乙方将自行承担项目实施范围内合理的差旅费用。 6、乙方同意免除项目杂费。 三、服务的变更
ZigBee测试与协议分析 1 前言 ZigBee协议栈包括物理层协议(IEEE802.15.4)和上层软件协议(ZigBee 2007以及其他的ZigBee网络协议）。本文将从这两方面来了解这些协议，通过介绍如何捕获及如何理解关键参数，深层次剖析ZigBee技术。有了这些本质性的认识，对于分析解决无线产品应用问题，会有很大的帮助。 2 物理层分析 ZigBee的物理层为IEEE802.15.4标准所规定，定义了ZigBee底层的调制编码方式。这些规约大多是芯片设计者需要关心的，对于应用开发来说，更关心的是衡量一个芯片、一个射频系统性能的参数。在过去的文章中，已介绍了输出功率、接收灵敏度和链路预算等参数，这一讲将更深入地介绍一个调制质量的参数：EVM。EVM指的是误差向量（包括幅度和相位的矢量），表征在一个给定时刻理想无误差基准信号与实际发射信号的向量差，。从EVM参数中，可以了解到一个输出信号的幅度误差及相位误差。 EVM是衡量一个RF系统总体调制质量的指标，定义为信号星座图上测量信号与理想信号之间的误差，它用来表示发射器的调制精度，调制解调器、PA、混频器、收发器等对它都会有影响。EVM数据和眼图。 了解完这个参数之后，再看看实际测试中是如何获取EVM参数的。 ZigBee物理层的测试，在产品研发、生产和维护阶段，可以分别采用不同的仪器。 (1)产品研发阶段要测量EVM参数，需要使用带协议解析的频谱仪，最好是自带相应协议插件的仪器，可以使用安捷伦PXA N9030A频谱分析仪+8960B插件(选配了ZigBee分析插件)。这些仪器可以测试出ZigBee调制信号的星座图、实时数据和眼图等信息，在芯片级开发过程中，需要考量高频电容电感以及滤波器等的单个及组合性能，特别需要注意的是ZigBee信号的临道抑制参数，利用PXA N9030A的高分辨率，可以查看点频的带外信号，这些细节在更换射频器件供应商时，需要仔细测量，一般数字电路抄板比较容易，因为器件性能的影响不是很大，只要值和封装对了就可以，但是射频前端的设计上，即使原样的封装、容值和感值，供应商不一样，射频参数也是不一样的，板材的选用也极大地影响着阻抗匹配，因此复制和再开发都有较大难度。合格的测试工具，加上有质量保证的射频器件供应商资源，方能真正具备RF设计能力。安捷伦PXA N9030A频谱分析仪。 (2)批量生产阶段在批量生产中，不可能将实验室的研发测试仪器搬到工厂，因此，需要便携小巧的测试设备，这时可用罗德与斯瓦茨公司的热功率探头，如NRP-Z22，做一个2.4 GHz的输出功率测试，保证能够输出公差允许的功率信号即可，因为在生产中，射频器件的焊接不良、馈线连接头的接触不良，都会造成输出功率的下降甚至消失。需要注意的是，探头非常容易被静电损坏，必须要带上防静电手套进行操作，返修过程如需要经过德国，则时间长，经费也不便宜，不是很严重的损坏倒是可以在深圳维修中心处理。NRP-Z22。 (3)应用阶段在现场出现问题时，ZigBee节点已经安装到现场，不能逐一拆下来测试，并且周围的电磁环境也是没办法在单个节点上检测到，这时就需要手持式的频谱仪进行现场勘查了，例如安捷伦公司的N9912A手持式频谱仪。使用该频谱仪，可以完成无线系统设计初期的现场勘查工作，检测现场各个地点是否有异常电磁干扰，对于ZigBee来说，当然是检测是否有持续的WIFI信号干扰了。同时，更为详细的现场勘查，还包括在定点进行数据发送，预期覆盖点进行信号强度分析，以实地评估墙体等障碍物的信号衰减，在已经架设好的ZigBee网络中，也可以检测信号覆盖，数据通信是否正常等。N9912A。
zigbee协议重要名词解释及英文缩写（转载）网络层功能: 1. 加入和退出网络 2. 申请安全结构 3. 路由管理 4. 在设备之间发现和维护路由 5. 发现邻设备 6. 储存邻设备信息 当适当的重新分配地址联合其他设备,ZIGBEE2006可以依赖于网络协调者建立一个新网络. ZIGBEE应用层由APS（应用支持）、AF（应用结构）、ZDO（ZIGBEE设备对象）和厂商自定义应用对象组成。 APS功能 1. 绑定维持工作台，定义一个两个合拢的设备进行比较建立他们的需要和服务。 2. 促进信息在设备之间的限制 3. 组地址定义，移除和过滤组地址消息 4. 地址映射来自于64位IEEE地址和16位网络地址 5. 分裂、重新组装和可靠数据传输 ZDO功能 1. 定义设备内部网络（ZigBee协调者和终端接点） 2. 开始和/或回答绑定请求 3. 在网络设备中建立一个网络安全关系 4. 在网络中发现设备和决定供给哪个应用服务 ZDO同样有责任在网络中发现设备和为他们提供应用服务。 1.1.4 网络拓扑 ZIGBEE网络层支持星状、树状和网状拓扑。在星状拓扑中网络受约束与单个设备，呼叫COORD。COORD有责任建立和维持在网络中发现的设备和其他所有设备，都知道的终端接点直接和COORD 通信。在网状和树状拓扑中，COORD有责任建立一个网络和选择几个关键网络参数，但是网络有有可能直接应用于ZigBee路由器。在树状网络中，利用分等级路由策略完成路由传输数据和控制消息直通网络。树状网络在802.15.4-2003中可以采用信标引导通信。网状网络将允许所有对等网络通信。ZIGBEE 路又将不能在网状网络中发射规则的IEEE802.15.4-2003信标。
When enthusiasm becomes a habit, there is no place for fear and worry.通用参考模板（页眉可删） 公司合作合同集锦八篇 公司合作合同篇1 合同编号： 甲方： xx科技有限公司 通信 联系电话： 联系人： 乙方： 通信 联系电话： 联系人： 日期： 20xx 年 3 月 24日 为了充分发挥甲、乙双方在各自服务领域的资源优势，共同拓展企业信息化应用领域，甲、乙双方遵循诚实信用、互利互惠、共谋发展的原则，甲方与乙方就合作事宜达成以下协议：
第一条：定义 1。移动信息：指建立在手机用户许可的前提下，通过移动通信网络传输到受众手机上的短信/彩信等。 2。信息服务费：由乙方有偿为甲方开通移动信息发送系统平台并为该系统提供移动信息发送服务。 3。API：Application Programming Interface，应用程序编程接口。 4。行业应用：指以沟通、服务为目的，面向企业员工、企业客户、已定制服务的用户等，提供的信息服务。 第二条：合作模式 1。乙方是在中华人民共和国合法注册，符合中国相关法律的独立法人。 2。乙方提供基于WEB方式的客户端，提供信息的编辑录入、发送、日志查看与下载、充值记录查询、OEM等功能，但乙方保留根据自身业务情况，增加或删减功能的权利。 3。乙方提供基于标准互联网协议的API接口，供甲方业务系统调用。 4。乙方向甲方提供短信API编程接口软件的技术文档和技术指导。
5。甲方自行配备互联网接入设备，并负责正常运行。终端用户号码由甲方提供与乙方无关。 第三条：甲方权利和义务 1。甲方应妥善保管登陆帐户及密码，并定期更换，非因乙方原因导致甲方帐户密码泄漏、被盗，造成业务被盗用等后果，乙方不承担任何责任。 2。甲方负责其自身的网络系统以确保能连接到乙方的业务平台进行正常业务使用。由于甲方网络问题不能访问乙方业务平台，导致业务不可用，乙方不承担任何责任。 3。甲方有责任向其客户说明使用短信服务应严格遵守国家相关法律、法规、保证信息发送的安全，并切实做到：（1）建立健全本公司信息发送的内部保障制度、信息安全保密制度、信息安全管理制度，建立健全本公司信息安全责任制度和信息发布的审批制度，严格审查本公司所发送的信息。 （2）严格遵守《互联网信息服务管理办法》，对短信内容进行把关，保证信息内容的健康、合法。 （3）明确手机用户群和手机用户范围，手机用户必须是自愿接受短信服务，未经接收者同意或者请求，甲方不得擅自群发广告信息。