AN746 SILABS | Alldatasheet
Document overview
- Manufacturer or author: Provided By ALLDATASHEET.COM(FREE DATASHEET DOWNLOAD SITE)
- PDF pages: 30
Technical content
The latest example source codes are available on the Silicon Labs web site: www.silabs.com. interchangeable RF Pico Boards. Figure 1. LCD Base Board
directly be connected via USB to the PC for downloading and debugging code on the U2 MCU. Figure 2. RF Pico Board connected to the LCD base board. Table 1. LCD Base Board Selection
Connect an RF Pico Board to the LCD base board through RFP1 and RFP2. Select the desired power source with SW1 power selector switch. Connect the LCD base board to an USB port of the PC. Wait for Windows to install the driver of the debug interface if necessary. Table 2. Pin Assignments
2 GND Ground Ground
5 VDD Supply input VDD
4 Rev. 0.1 3. Software Tools There are two software tools provid ed by Silicon Labs to help EZRadi o software developm ent, the Wireless Development Suite (WDS) and the Silic on Labs Integrated Development Environment (IDE), both available on silabs.com. 3.1. Wireless Development Suite (WDS) The recommended starting point for Si4012 development is the WDS. It can be downloaded from silabs.com and can be installed on a PC. After connecting one of the ha rdware platforms described in this document to the PC, WDS is able to identify the connected board by reading the EBID memories of the board. The EZConfig Setup GUI is part of the Wireless Development Suite (WDS) program. This setup interface provides an easy path to quickly selecting and loading the desired configuration for the Si4012 device. The configuration table provides a list of prel oaded, common config urations validated by Silicon La bs. EZConfig also allows for custom configuration to be loaded using the Radio Conf iguration Application. After the desired configuration is selected, the EZConfig setup automatically creates the configuration data that can be used to configure the EZRadio chip. The program then gives the option to configure directly the EZRadio chip of the connected hardware, to modify a selected demo code with the configuration and download it to the connected hardware, or to launch Silicon Labs IDE with the new configuration data prelo aded into the user prog ram. For more complete information on WDS and EZConfig usage, refer to the WDS User’s Guide, available on silabs.com. 3.2. Silicon Labs IDE The Silicon Laboratorie s Integrated Development Envi ronment (IDE) is a standard tool for program development for any Silicon Labs 8-bit MCUs includin g the C8051F930 that is used on the hardware platforms described in this document. The Silicon Laboratories IDE in tegrates a project ma nager, a source-code editor, source-level debugger, and an in-system flash programmer. The IDE interfaces to third party development tool chains to provide system designers a complete embedded software development environment. The Keil Demonstration Toolset includes a compiler, linker, and assembler and easily integrates into the IDE. 3.2.1. Downloading and Running the Example Codes 1. Connect the hardware platform to the PC according to the description of the used platform. 2. Start Silicon Labs IDE (IDE 4.40 or higher required) on your computer. 4. Before connecting to the target device, several connection options may need to be set. Open the Connection Options window by selecting Options→Connection Options... in the IDE menu. 5. Select USB Debug Adapter in the “Serial Adapter” section. 6. If more than one adapter is connected, choose the appropriate serial number from the drop-down list. 7. Check the “Power target after disconnect” if the target board is currently being powered by the USB Debug Adapter. The board will remain powered after a software disconnect by the IDE. 8. Next, the correct “Debug Interface” must be selected. Check the C2 Debug Interface. 9. Once all the selections are made, click the OK button to close the window. 10. Click the Connect button in the toolbar or select Debug→Connect from the menu to connect to the C8051F930 MCU of the platform. 11. Erase the flash of the C8051F930 MCU in the Debug→Download object code→ Erase all code space menu item. 12. Download the desired example HEX file either by hitting the Download code (Alt+D) toolbar button or from the Debug →Download object code menu item. 13. Hit the Disconnect toolbar button or invoke the Debug →Disconnect menu item to release the device from halt and to let it run.
state; when pulled low, the Si4012 wakes up. NIRQ is the interrupt request output that goes low when an enabled interrupt is triggered in the Si4012. for the Si4012 is only two pins, SDA and SCL. Figure 3. Minimal MCU Interface command structure and command details of the Si4012.
6 Rev. 0.1 4.2. Initialization After power on or wake up from shut down, the chip goes through an internal reset process and gets in an initial state. Initialization of the chip can be done by setting some basic parameters of the chip operation according to the user’s requirements. For calculating the parameters, a calculatio n spreadsheet, “si4012_calc_regs.xls”, is provided by Silicon Labs. For details, see “AN564: Si4012 Calculator Spreadsheet Usage”, available at www.silabs.com. The user inputs the required values into the spreadsheet: Center frequency Modulation type FSK deviation Total PA power Bit rate and gets the PROPERTY values, such as: PA_CONFIG TX_FREQ MODULATION_FSKDEV BITRATE_CONFIG in hex form that have to be used as parameters of the SET_PROPERTY command to be sent to the Si4012. The commands typically used for initialization are: SET_PROPERTY SET_INT CHANGE_STATE LED_CTRL To ease the use of these commands, a C header file called Setup_Si4012.h can be generated via the Wireless Development Suite.
Rev. 0.1 7 The generated header file contains the precompiled co mmands according to the parameter values set on the Control Panel of WDS. Here is a part of the header file used in the examples: #define Si4012_MODE_SELECTION 0x60, 0x00, 0x00 Selected mode: Standby #define Si4012_TUNE_INTERVAL 0x11, 0x21, 0x00, 0x0A Tune interval: 10 #define Si4012_MODULATION_FSKDEV 0x11, 0x20, 0x01, 0x18 Modulation type: FSK biFskDev: 24 #define Si4012_CHIP_CONFIG 0x11, 0x10, 0x00 FSK deviation polarity: LDB First: OFF Use external Cristal: OFF #define Si4012_TX_FREQ 0x11, 0x40, 0x33, 0xC1, 0xE4, 0x58 Transmission frequency [MHz]: 868,344920 #define Si4012_BITRATE_CONFIG 0x11, 0x31, 0x00, 0x60, 0x02 Data Rate [kbps]: 9,6 Ramp Rate [us]: It is also possible to manually modify this file so that it includes multiple commands for alternative values of the same parameter. To use the header file above, constant arrays have to be initialized with the defined commands first. Here is the corresponding part of the example program: //arrays initialized with precompiled commands SEGMENT_VARIABLE(C_CHIP_CONFIG[], U8, SEG_CODE) = {Si4012_CHIP_CONFIG}; SEGMENT_VARIABLE(C_LED_INTENSITY[], U8, SEG_CODE) = {Si4012_LED_INTENSITY}; SEGMENT_VARIABLE(C_MODULATION_FSKDEV[], U8, SEG_CODE) = {Si4012_MODULATION_FSKDEV}; SEGMENT_VARIABLE(C_TUNE_INTERVAL[], U8, SEG_CODE) = {Si4012_TUNE_INTERVAL}; SEGMENT_VARIABLE(C_FIFO_THRESHOLD[], U8, SEG_CODE) = {Si4012_FIFO_THRESHOLD}; SEGMENT_VARIABLE(C_BITRATE_CONFIG[], U8, SEG_CODE) = {Si4012_BITRATE_CONFIG}; SEGMENT_VARIABLE(C_TX_FREQ[], U8, SEG_CODE) = {Si4012_TX_FREQ}; SEGMENT_VARIABLE(C_LBD_CONFIG[], U8, SEG_CODE) = {Si4012_LBD_CONFIG}; SEGMENT_VARIABLE(C_XO_CONFIG[], U8, SEG_CODE) = {Si4012_XO_CONFIG}; SEGMENT_VARIABLE(C_PA_CONFIG[], U8, SEG_CODE) = {Si4012_PA_CONFIG}; Then the SetProperty function is called that outputs the constant arrays (i.e., the commands) on the SMBus: // set up the radio using the precompiled commands in Setup_Si4012.h // (Setup_Si4012.h can be generated from WDS) Si4012_Status = SetProperty(C_LED_INTENSITY, 3);
8 Rev. 0.1 Si4012_Status = SetProperty(C_CHIP_CONFIG, 3); Si4012_Status = SetProperty(C_MODULATION_FSKDEV, 4); // Si4012_Status = SetProperty(C_TUNE_INTERVAL, 4); // Si4012_Status = SetProperty(C_FIFO_THRESHOLD, 5); // Si4012_Status = SetProperty(C_BITRATE_CONFIG, 5); Si4012_Status = SetProperty(C_TX_FREQ, 6); // Si4012_Status = SetProperty(C_LBD_CONFIG, 6); // Si4012_Status = SetProperty(C_XO_CONFIG, 7); // Si4012_Status = SetProperty(C_PA_CONFIG, 8); U8 SetProperty(U8 * command, U8 clenght) SmbusStatus = SMBusWrite(SI4012_SLAVE_ADDRESS, clenght, command); SmbusStatus = SMBusRead(SI4012_SLAVE_ADDRESS, 1, &error); return error; Because properties are initialized to a default value by the reset process after a power on or wakeup from shutdown, the user has to initialize a property only if its desired value is different from its default value. For this reason, some SetProperty calls are commented out in the code above to save time and battery power. 4.3. Interrupt Handling The NIRQ pin of the Si4012 is used to issue interrupts to the host. The host should poll the NIRQ pin or use interrupts (NIRQ) to get interrupt status. The host can then read the interrupt status of the radio with GET_INT_STATUS command that also clears the interrupts at the same time. The GET_INT_STATUS command is also useful for polling th e interrupt status of the Si4012 via the SM Bus interface when the NIRQ pin is not connected. 4.4. How to Send a Packet Longer than 255 Bytes The Si4012 device has a 255-byte transmit FIFO; however, it is possible to transmit longer packets than 255 bytes. The FIFO in the Si4012 has two programmable thresholds and the chip can provide interrupts when the data in the transmit FIFO reaches these thresholds . The first threshold is the FIFO Almo st Full Threshold. If the number of bytes filled into the FIFO reaches this level, then the radio can provide an interrupt for the MCU to start the packet transmission. The second threshold is the FIFO Almost Empty Threshold. If the number of bytes in the transmit FIFO reaches this level, then the radio can provide an interrupt for the MCU. Then the microcontroller will need to fill more data into the transmit FIFO to avoid FIFO underflow.
Figure 4. Transmit FIFO Status Signals The Si4012 is able to measure its own supply voltage in two modes. One mode of operation is to measure the supply voltage whenever the GET_BAT_STATUS command is invoked. The supply voltage is measured after the main current-cons uming blocks of the device are temporarily turned on. command gives back the result in mV. and threshold can be set in the LBD_CONFIG property. across the crystal terminals. The example program does not use a crystal.
10 Rev. 0.1 5. Sample Projects Several complete sample projects are provided in the AN746SW.zip file available at www.silabs.com. 5.1. General Project Structure All the sample projects have a unified structure and co mmon driver set. This chapter gives the reader a brief introduction of the structure of the sample projects. 5.1.1. Prerequisites The settings in the sample project f iles assume that some Silic on Labs or third party so ftware tools are already installed on the PC where the sample project going to be compiled. The tools need to be installed depends on the functionality to be used. The following list contains a complete set of such programs: Silicon Laboratories IDE— Used to open the preconfigured project files and manage the build process. Keil C51 v9.0+ or SDCC v3.0+— Compilers to use in accordance with the Silicon Laboratories IDE to manage build process. Silicon Labs Flash Programming Utility (optional)— Needed only if programming outside the Silicon Labs IDE is necessary. Make (optional)— This tool is needed in case other compiler is used, or the build process takes place outside of the SiLabs IDE. 5.1.2. Supported Compilers The projects come with two SiLabs IDE project file. The o ne that name ends with “_Keil” contains the settings for and is appropriate to compile with Keil’s C51 tool chain. The other that ends with “_SDCC” is prepared to use the SDCC compiler tool chain. Please note , if you use the 2k limited evaluation license for Keil’s C51 compiler, you may need to unlock it to 4k, as some project's size exceeds the 2k code size limit. However, the sample projects can be complied not only with the two mentioned compiler, but with almost any ANSI C compiler for 8051 architecture with little or no modifications. Each project already contains a “Makefile” in order to provide an easy and convenient way to compile the code outside the Silicon Labs’ IDE with the toolchain of choice. Each sample project described in this document contains a compiled version of the source code in Intel hex format that is widely supported by a variety of programming and debugging tools. The compiled file in the projects has been generated using the SiLabs IDE and the Keil C51 tool chain. 5.1.3. Directory Structure All sample project has a common directory structure, with se parated source and project files in order to ease the understanding of the individual modules. For every sample project the following directories and files can be found in the main directory: bin—Contains the SiLabs project files for Keil and SDCC co mpilers and the Makefile if the make tool is used instead. doc—Doxygen generated documentation based on comments inside the source files in html format. out—The outputs of the compilation process come to this folder. After successful compilation, this directory contains for example the hex file, the linker output and the OMF file. src application drivers Directories containing the source files. Doxyfile—In this file, the Doxygen documentation generator settings can be found. Cleanup.bat—Batch file used to delete all files generated during build process.
Rev. 0.1 11 5.1.4. Software Modules In the sample projects the layered software approach is followed. There’s a distinct scope for each software module and such modules can communicate through each other’s API functions. The software modules are separated and focused to cover one specific task. The following figure shows the software layers and its relations. The individual software modules are separated into several source files. In the sample projects there is one header file that is included in the source files and collects the individual headers that need to be included. Under the src folder the application related sources can be found in the application folder, the common modules (e.g., handlers, drivers) are located under the driver directory. Application Handlers Lowleveldrivers HardwareAbstractionLayer Libraries Hardware
12 Rev. 0.1 5.2. Sample Application Descriptions 5.2.1. Empty Project (Base_Project) This sample project is intended to demonstrate the basic concept of setting up the Si4012 radio chip. This project is the essential core of the following th ree sample codes (CW_Transmit, PN9, TX). It is primarily responsible for initializing the MCU and RFIC as well. It also initializes the Human-Mach ine Interface (HMI) module related handlers, such as the push button handler, the LED handler, and the buzzer handler that are potentially useful for the rapid application development.
Rev. 0.1 13 In the main() function, the vInitializeHW() invokes initialize functions for the MCU IOs and peripherals. It also starts the HMI module handlers that are scheduled to run once in every 1 ms during the user application. These timing intervals are generated by the Timer2 peripheral overflow interrupt. Finally, it enab les the MCU related internal interrupts. In the main() function, the SampleCode_Demo_Pollhandler() is responsible for several tasks: 1. It checks if the Si4012 Pico board is connected to the LCD Baseboard. 2. Reads the RF EBID content in order to learn to which frequency band the Pico board is designed for. The possible options can be either 434 MHz or 915 MHz. 3. Configures the RFIC to the operating mode that is generated by the Wireless Development Studio. 4. Starts the user application program.
14 Rev. 0.1
Rev. 0.1 15 The SampleCode_Demo_Pollhandler() includes a state machine, and the different states represent the previously mentioned tasks. 1. SM_START: Turn off the Si4012 RFIC Check if the RF EBID is available on the Pico board Read the EBID content to determine the radio type and the frequency band Having detected the RF Pico board successfully, the next state will configure the Si4012 RFIC. 2. SM_STEP1: Configure the radio with the WDS generated parameters Turn on the fourth LED on the LCD baseboard Having configured the RFIC successfully, the next state will execute the user application code. 3. SM_STEP2: User application code can be started from this point. The state of SM_STEP1 simply configures the chip by calling the Si4012_Configure() function. The fourth LED will be turned on if there were no failures during the radio in itialization. If any kinds of failures occurred either in SM_START or in SM_STEP1 states, for example, communication error, configuration error, or unavailable RF Pico board, the pr ogram execution will be forced to the ERROR_HOOK immediately. The fourth LED will then blink rapidly to indicate that the error detection occurred. The state of SM_STEP2 can contain the user application code. Since it is an empty project, it does not execute any code after the radio initialization.
16 Rev. 0.1 5.2.2. Continuous Wave Transmission (CW_Transmit) Since the radio configuration happened according to the empty project, the only remaining task is to start the CW mode transmission with the Si4012_Start_CW_Mode() fu nction. Having done the ra dio configuration, the transmission will start shortly thereafter. To illustrate how to expand the code with dynamic behavior, SM_STEP2 provides the user with a clear example of how to use the LCD baseboard push-buttons for turning in/out the CW transmission. After starting the CW mode, an LED on the RF Pico board will turn on, indicating that the mode is successfully activated. By pushing the second button, the user can stop the transmission with the Si4012_Stop_CW_Mode() function. By pushing the first button, the transmission can be restarted again.
Rev. 0.1 17 5.2.3. Pseudo Random Transmission (PN9) Since the radio configuration happened according to the empty project, the only remaining task is to start the CW mode transmission with the Si4012_Start_PN9_Mode(U 8 bModeSelector) function. Having done the radio configuration, the transmission will start shortly thereafter. To illustrate how to expand the code with dynamic behavior, SM_STEP2 provides the user with a clear example of how to use the LCD baseboard push-buttons for turning in /out the PN-9 transmission. After starting the PN-9 mode, an LED on the RF Pico board will turn on, indicating that the mode is successfully activated. By pushing the third button, the user can stop the transmission with the Si4012_Stop_PN9_Mode() function. By pushing the second and the third buttons, the transmission can be restarted again in PN-9 zero or in PN-9 one mode.
18 Rev. 0.1
Rev. 0.1 19 5.2.4. Packet Transmission (TX) Since the radio configuration happened according to the em pty project, the only remaining task is to send packets with the Si4012_SendPacket(U8 bButtonNumber) function. Having done the radio configuration, SM_STEP2 waits for push button actions. Three different kinds of pack ets can be sent by pushing button1, button2, and button3. When a button is pushed, the appropr iate LED on the LCD base board w ill blink once. The same packet will be sent over the air three times shortly after one another. After one packet has been sent successfully, the RF Pico board LED will blink once. The following figure illustrates the packet structure used in this sample project. The CRC field is calculated over the CHI P ID, the button info, and the rolling counter to en sure error-free packet reception. The two-byte CRC is implemented in the CRC.h module by CRC_CalculateCRC16(U8* pbInputData, U8 bLengthOfInputData) function. The Si4012 related func tions are implemented in the Si4012.h module. These functions can manipulate the radio such as turn off/on th e radio chip, start/stop the different transmit modes (CW/ PN9), send packets using the built-in FIFO, and set the internal properties via the radio’s Application Programming Interface (API). The API offers the option to access a ll of the radio’s internal properties. The host MCU is connected to the radio via SMBus. The SMBus related functions, which can provide access to the API, can be found in SMBus.h module under the drivers folder. The packet to be sent, including the preamble and the sync word pattern, are filled in the FIFO of the radio by the host MCU. The sample code related functions are listed below. PREAMBLE SYNC WORD CHIP ID Button info Rolling Counter CRC 13 byte 2 byte 4 byte 1 byte 2 byte 2 byte
20 Rev. 0.1 The Setup_Si4012.h module configuration should be generated by the Wireless Development Studio, edited, and then added to the project in order to enable the Si4012_C onfigure() function to initialize the radio chip. During the configuration, the Si4012_SetP roperty(…) function will init ialize the API properties by sending the arrays of bytes beginning with prefix of SI4012_CONFIG_ARRAY_DATA_RADIO. The WDS generated properties are listed below.
Rev. 0.1 21 The additional header files should be included in the co mmon bsp.h located in the src/drivers directory. The bsp.h file already contains included headers:
22 Rev. 0.1 5.3. Common Software Modules In the modules hierarchy the common software module s are located between the application and the hardware layers. It is a set of interfaces that provides possibilities to be able to control various peripherals on modular HW platforms. Registers can be initialized with pre-configured settings an d peripherals can be enabled to start/stop their own processing. The major tasks of these software modules are to initialize the hardware elements and control its behaviors. The principle of their installation is to provide a façade for the upper layers. Functionally, the User Application, at the top of the hierarchy, can be independent of the hardware and its logical operation can remain unchanged even if the hardware has been modified later. It can be adapted to any device without encountering difficulties. All the modules in the followi ng subsections except the human-machine interface module are mainly responsible for handling the dedicated internal peripherals such as the IO, the timers, the SPI and the PCA. The HMI holds them together so it gives a higher abstraction level to the User Application in form of handlers. 5.3.1. IO Control Module The IO control related source files, called control_IO.h and control_IO.c, can be found in the /src/drivers/ folder. The module handles the port initializations for the physical HW platform e.g. LEDs, push-buttons, buzzer. It can set the state of the LEDs and read the status of the selected push-buttons. 5.3.2. Programmable Counter Array Driver The PCA related source files, called pca.h and pca.c, can be found in the /src/driver/ folder. The module initializes the PCA so as to create beeping sounds on the buzzer. The time-base source of the PCA counter can be selected. Interrupts can be generated when the lower byte of the counter overflows. PWM-mod cycle length can be also selected to modify the frequency of the tweeting sound. void vCio_InitIO(void); void vCio_SetLed(U8 biLedNum); void vCio_ClearLed(U8 biLedNum); BIT gCio_GetPB(U8 biPbNum); void vPca_InitPcaTmr(U8 biPulseSelect, U8 biPcaTmrItEnable, U8 biCycleLengthSelect);
Rev. 0.1 23 5.3.3. SPI Driver The SPI related sour ce files, called spi.h and spi.c , can be found in the /src/driver/ folder. To enable the SPI interface the SPI port has to be enabled and associated to the crossbar. The directions of the SCK, MISO and MOSI ports have to be configured properly on the IO port. Finally, the default states of the pins have to be set correctly. Since several devices can be connected to the same SPI bus, the NSEL pin of the selected device is activated during communication. Since the commands to be sent to the API are sequenc es of bytes, the module has to be able to send and receive continuous byte stream. There are some cases when either reading a single byte directly from the MISO or writing specified number of bits directly to the MOSI is necessary. In order to cover these kinds of cases, “bitbang” read/write methods have been also implemented. 5.3.4. Timer Peripheral Driver The timer related source files, called timer.h and timer.c, can be found in the /src/drivers/ folder. The module handles two 16-bit timers, timer2 and timer3. The most a ccurate timing interval can be calculated from the frequency of the system clock which is generally 24.5 MHz. External clock sources can be selected as timer input and moreover the required timing frequency can be adjusted thoroughly with several different prescalers. In general, the timer settings belonging to the so-called heart-beat frequency of 1 kHz (1 ms) are prepared. Using the timer with the 1 ms settings, timeouts multiple of 1 ms ca n be easily implemented. Timer related operations can give possibilities to start or stop counting. Additionally, interrupts can be generated when the low byte of the timer overflows. Timers can also be checked whether get expired or not. U8 bSpi_ReadWriteSpi1(U8 biDataIn); void vSpi_EnableSpi1(void); void vSpi_DisableSpi1(void); void vSpi_ClearNselSpi1(U8 biSelectDevice); void vSpi_SetNselSpi1(U8 biSelectDevice); void vSpi_WriteDataSpi1(U8 biDataInLength, U8 *pabiDataIn); void vSpi_ReadDataSpi1(U8 biDataOutLength, U8 *paboDataOut); U8 bSpi_ReadByteBitbangSpi1(void); void vSpi_WriteBitsBitbangSpi1(U8 biDataIn, U8 biNumOfBits); void vTmr_InitTmr2(void); void vTmr_StartTmr2(U8 biPrescaler, U16 wiPeriod, U8 biItEnable, U8 biExtClkSel); BIT gTmr_Tmr2Expired(void); void vTmr_StartTmr3(U8 biPrescaler, U16 wiPeriod, U8 biItEnable, U8 biExtClkSel); UU16 wwTmr_GetTmr3(void); BIT gTmr_Tmr3Expired(void);
24 Rev. 0.1 5.3.5. Human-Machine Interface Module The HMI related source files, called hmi.h and hmi.c, can be found in the /src/driver/ folder. In order to use this module, the required handlers need to be initialized at the very beginning of the program. Checking the status of the various hardware components requ ire to have a common cyclic mechan ism. A 1 ms interrupt based cycle is vital to be running in the background to serve the different handlers. By using the LED handler, states of LEDs can be set and cleared either separately or together. To manipulate the LEDs’ behavior dynamically, eHmi_LedStates needs to be used. By using the button handler, statuses of the push-but tons can be read. Even if more button events happened simultaneously, they can be stored to be handled later. The last pushed button event is always available first amongst the unhandled events. HANDLERS //Start the push button handler void vHmi_InitPbHandler(void); // Start the Led handler void vHmi_InitLedHandler(void); // Start the Buzzer Handler void vHmi_InitBuzzer(void); void vHmi_InitLedHandler(void); void vHmi_ChangeLedState(eHmi_Leds qiLed, eHmi_LedStates qiLedState); void vHmi_ChangeAllLedState(eHmi_LedStates qiLedState); void vHmi_LedHandler(void); void vHmi_ClearAllLeds(void); typedef enum _eHmi_LedStates eHmi_LedOff_c = 0x00, /**< Led is in off state */ eHmi_LedStdBy_c = 0x01, /**< Led waits for state change */ eHmi_LedOn_c = 0x10, /**< Led is in on state */ eHmi_LedBlink2Hz_c = 0x20, /**< Led blinks with 2Hz */ eHmi_LedBlink1Hz_c = 0x30, /**< Led blinks with 1Hz */ eHmi_LedBlinkHalfHz_c = 0x40, /**< Led blinks with 0.5Hz */ eHmi_LedBlinkOnce_c = 0x50, /**< Blinks led once */ eHmi_LedBlinkWait_c = 0x55, /**< Blinks led once */ } eHmi_LedStates; void vHmi_InitPbHandler(void); BIT gHmi_PbIsPushed(U8 *boPbPushTrack, U16 *woPbPushTime); BIT gHmi_IsPbUnHandled(void); U8 bHmi_PbGetLastButton(U16 *woPbPushTime); void vHmi_PbHandler(void);
Rev. 0.1 25 By using the buzzer related sub-interface, state of buzzer can be changed to the required one. To manipulate the buzzer’s behavior dynamically, eHmi_BuzzStates needs to be used. void vHmi_InitBuzzer(void); void vHmi_ChangeBuzzState(eHmi_BuzzStates qiBuzzState); void vHmi_BuzzHandler(void); typedef enum _eHmi_BuzzStates eHmi_BuzzOff_c = 0x00, /**< Buzz is in off state */ eHmi_BuzzStdBy_c = 0x01, /**< Buzz waits for state change */ eHmi_BuzzOn_c = 0x10, /**< Buzz is in on state */ eHmi_Buzz2Hz_c = 0x20, /**< Buzz 2Hz */ eHmi_Buzz1Hz_c = 0x30, /**< Buzz 1Hz */ eHmi_Buzz0Hz5_c = 0x40, /**< Buzz 0.5Hz */ eHmi_Buzz0Hz25_c = 0x41, /**< Buzz 0.25Hz */ eHmi_BuzzOnce_c = 0x50, /**< Buzz once */ eHmi_BuzzOnceAndCont_c = 0x51, /**< Buzz once and continue buzzing*/ eHmi_BuzzWait_c = 0x55, /**< Waits for buzz once */ } eHmi_BuzzStates;
26 Rev. 0.1 5.4. Empty Project Structure An empty project structure can be found along with sample projects on the silabs.com website for reference. The empty project has been created to help users starting to write their custom firmware with preconfigured project files, common directory structure, and Silicon Labs drivers. The project follows the convention for directory structure introduced in the sample projects. It contains driver modules for the radio and MCU peripherals as well as a default MCU initialization procedure. The main function in the empty project is as follows: User defined init functions should be placed before the while loop. The vInitializeHW() looks as follows: The radio_config.h configuration should be generated, edited then added to project in order to enable the vRadio_Init() function to initialize the radio chip. The vPlf_McuInit() shall be modified according to the hardware used. The additional header files should be included in the common bsp.h located in src/drivers directory. The bsp.h file already contains included headers: void main(void) // Initialize the Hardware and Radio vInitializeHW(); while (TRUE) // Write your code HERE. void vInitializeHW(void) // Initialize the MCU peripherals vPlf_McuInit(); // Initialize the Radio vRadio_Init();
Rev. 0.1 27 Description of the header files: compiler_defs.h—Contains compiler related definitions in order to provide a uniform way to use non-ANSI C keywords, such as BIT, XDATA, SEGMENT_VARIABLE and more. platform_defs.h—Platform definitions, in th is header the type of hardware, MCU can be defined. hardware_defs.h—Definitions can be found in this header that cl osely related to the actual hardware, for example, which pins connected to LEDs, push-buttons, etc. application_defs.h—Definitions for the given application. spi.h—Serial Peripheral Interface driver header file. Contains functions to access and utilize the MCUs SPI interface. radio_config.h—Radio configuration header. This file is gene rated by the Wireless Development Studio (WDS). The user may want to add custom configurations to this file. radio_hal.h—Common hardware abstractio n layer for both Si446x and Si4455 radio families. radio_comm.h—Common communication layer for both Si446x and Si4455 radio families. The next group of header includes depends on the actual radio chip defined in platform_defs.h. /* Application specific includes */ #include "compiler_defs.h" #include "platform_defs.h" #include "hardware_defs.h" #include "..\\application\\application_defs.h" #include "spi.h" #include "..\\application\\radio_config.h" #include "..\\application\\radio.h" #include "..\\drivers\\radio\\radio_hal.h" #include "..\\drivers\\radio\\radio_comm.h" #ifdef SILABS_RADIO_SI446X #include "..\\drivers\\radio\\Si446x\\si446x_api_lib.h" #include "..\\drivers\\radio\\Si446x\\si446x_defs.h" #include "..\\drivers\\radio\\Si446x\\si446x_nirq.h" #include "..\\drivers\\radio\\Si446x\\si446x_patch.h" #endif #ifdef SILABS_RADIO_SI4455 #include "..\\drivers\\radio\\Si4455\\si4455_api_lib.h" #include "..\\drivers\\radio\\Si4455\\si4455_defs.h" #include "..\\drivers\\radio\\Si4455\\si4455_nirq.h" #endif
28 Rev. 0.1 5.4.1. Porting the Project for another MCU The porting of an example project to an MCU of choice ca n be done easily thanks to the layered approach of the project structure. This reduces the effort required to comp ile the code for other architec ture, as only the low-level functions must be modified. The following drivers shall be modified: compiler_defs.h, hardware_defs.h, platform_defs.h, application_defs.h This header files contains definitions for the 8051 architecture and the SiLabs hardware platform. This may be modified according to the new architecture and hardware. spi.c, spi.h The SPI driver module shall be supplied to enable the communication with the radio. radio_hal.c, radio_hal.h The radio hardware abstraction layer may be adjusted, as the GPIOs, nIRQ and SDN pins are defined in this file. The above mentioned files may not cover all requirements for porting the project to other MCU, as it depends on what is to be ported and which other drivers are used by the project. The compiler toolchain setup, the appropriate startup codes, and linker scripts are out of the scope of this chapter; the user is responsible for providing them as appropriate for the given architecture.
Rev. 0.1 29 NOTES:
Silicon Laboratories intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or intending to use the Silicon Laboratories products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical" parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Laboratories reserves the right to make changes without further notice and limitation to product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Silicon Laboratories shall have no liability for the consequences of use of the information supplied herein. This document does not imply or express copyright licenses granted hereunder to design or fabricate any integrated circuits. The products must not be used within any Life Support System without the specific written consent of Silicon Laboratories. A "Life Support System" is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Laboratories products are generally not intended for military applications. Silicon Laboratories products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons. Trademark Information Silicon Laboratories Inc., Silicon Laboratories, Silicon Labs, SiLabs and the Silicon Labs logo, CMEMS®, EFM, EFM32, EFR, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZMac®, EZRadio®, EZRadioPRO®, DSPLL®, ISOmodem ®, Precision32®, ProSLIC®, SiPHY®, USBXpress® and others are trademarks or registered trademarks of Silicon Laboratories Inc. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. All other products or brand names mentioned herein are trademarks of their respective holders. http://www.silabs.com Silicon Laboratories Inc.
400 West Cesar Chavez
Austin, TX 78701 USA Simplicity Studio One-click access to MCU tools, documentation, software, source code libraries & more. Available for Windows, Mac and Linux! www.silabs.com/simplicity MCU Portfolio www.silabs.com/mcu SW/HW www.silabs.com/simplicity Quality www.silabs.com/quality Support and Community community.silabs.com