下载文档原格式
目录1. 适用范围................................................................................. 错误！未定义书签。
2. 原理概述................................................................................. 错误！未定义书签。
3. 开发环境................................................................................. 错误！未定义书签。
4. 技术实现................................................................................. 错误！未定义书签。
5. 参考资料................................................................................. 错误！未定义书签。
6. 免责声明................................................................................. 错误！未定义书签。
1. 概述运算放大器（Operational Amplifier，简称OPAMP）是EFM32系列微控制器片上模拟外设，经过恰当地选取外部元件，它能够实现各种模拟运算，如放大、加、减、微分和积分等。
EFM32芯片内拥有三个运算放大器（Gecko系列芯片内部没有运算放大器），分别为OPA0、OPA1和OPA2。
其中OPA0和OPA1是DAC模块的一部分，OPA2为独立的运算放大器。
OPAMP模块框图如图1.1所示。
图1.1 OPAMP模块框图这三个运算放大器可以相互配合并通过搭配合适的外部电路和内部反馈满足复杂的应用需求。
目录1. 概述 (1)2. FAQ (2)2.1 GPIO功能描述 (2)2.2 GPIO功能结构 (2)2.3 GPIO寄存器配置 (2)2.4 GPIO中断配置 (3)2.5 GPIO的低功耗特点 (4)3. 实验指导 (5)3.1 实验目的 (5)3.2 实验设备 (5)3.3 实验内容 (5)3.4 试验步骤 (5)3.5 实验参考程序 (5)3.6 实验结果 (7)4. 免责声明 (8)1. 概述通用输入输出(General Purpose Input/Output，简称GPIO)是EFM32片上的通用引脚输入和输出接口外设，其能够提供灵活的引脚功能配置，同时也是片上外设对外的接口。
其主要特点如下：z最多93个GPIO引脚；z引脚配置；上拉/下拉电阻；输入/输出使能；输出驱动能力(0.5 / 2 / 6 / 20 mA)；输入滤波器。
z16个异步外部中断；z片上外设引脚重映射；z最多6个引脚支持从EM4唤醒。
2. FAQ2.1 GPIO功能描述1. GPIO的主要作用有哪些？A：通用输入输出(General Purpose Input/Output，GPIO)是通用引脚输入和输出接口，其能够提供灵活的引脚功能配置，同时也是片上外设对外的接口。
GPIO还具有从EM4模式中唤醒功能。
2. 怎样利用与GPIO相关的emlib库函数？A：首先将em_gpio.c文件加入工程中，然后在需要调用与GPIO相关的emlib库函数的源文件中添加如程序清单2.1所示的预编译代码。
程序清单2.1 GPIO头文件#include "em_gpio.h"2.2 GPIO功能结构1. EFM32系列的GPIO管脚是如何命名的？A：EFM32系列MCU的引脚组织为每个端口16个引脚，每个独立的GPIO引脚命名为Pxn，x表示端口号(A，B，C…)，n表示引脚号(0，1，…，15)。
2. 复位后GPIO处于何种状态？A：复位后，除了调试引脚外（对于EFM32系列微控制器来说，一共有3个调试引脚，分别为：SWCLK、SWDIO和SWV。
...the world's most energy friendly microcontrollersI2C Master and Slave OperationAN0011 - Application NoteIntroductionThe EFM32 I2C module allows simple, robust and cost effective communicationbetween integrated circuits using only one data and one clock line.This application note demonstrates how to use the EFM32 I2C module to talk to anI2C temperature sensor. It also includes a software example where two EFM32s are connected; each EFM32 will operate in either slave or master mode and talk to theother one.This application note includes:•This PDF document•Source files (zip)•Example C-code•Multiple IDE projects1 I2C Theory1.1 GeneralThe I2C allows connection of up to 128 individually addressable devices using only two bi-directional lines: clock (SCL) and data (SDA). The only additional hardware required is a pull-up resistor for each of the lines. Each of the connected devices can be either a master or slave device. Only master devices are allowed to drive the clock line.The I2C protocol and the EFM32 I2C module feature several mechanisms for handling bus conflicts and contention. A possible I2C connection scheme is illustrated in Figure 1.1 (p. 2) .Figure 1.1. I2C BuspS DAS CLAt the physical layer both SCL and SCA lines are in open-drain, hence the pull-up resistors. Increasing the number of devices on the I2C bus will also increase the line capacitance and thus reduce the slew-rate. The slew-rate can be controlled by changing the drive strength in the GPIO module for the I2C pins. The size of the pull-up resistors can be calculated as a function of the maximum rise time allowed for the given bus speed and the estimated bus capacitance Cb as shown in Equation 1.1 (p. 2)Pull-up Resistor EquationRp(max) = tr/0.8473 x Cb(1.1)The maximal rise times for 100 kHz, 400 kHz and 1 MHz I2C are 1 µs, 300 ns and 120 ns respectively.1.2 I2C Signals/FramesSTART and STOP conditions are used to initiate and stop transactions on the I2C-bus. All transactions on the bus begin with a START condition (S) and end with a STOP condition (P). As illustrated in Figure 1.2 (p. 3) , a START condition is generated by pulling the SDA line low while SCL is high, and a STOP condition is generated by pulling the SDA line high while SCL is high.Also illustrated in Figure 1.2 (p. 3) is I2C bit transfer. Note that data must be stable for the whole duration of the SCL high period.Figure 1.2. Start, Stop and DataS CLS DAS P S TART condition S TOP condition S CLS DAData stableData changeallowed Data changeallowedI2C S tart and S top I2C Bit transferA master initiates a transfer by sending a START followed by the address of the slave it wishes to contactand a single R/W bit telling whether it wishes to read from (R/W = 1) or write to the slave (R/W = 0).After the 7-bit address and the R/W bit, the master releases the bus, allowing the slave to acknowledge the request. During the next bit-period, the slave pulls SDA low (ACK) if it acknowledges the request, or keeps it high if it does not acknowledge it (NACK). Following the address acknowledge, either the slave or master transmits data, depending on the value of the R/W bit. After every 8-bit byte transmitted on the SDA line, the transmitter releases the line to allow the receiver to transmit an ACK or a NACK. Both the data and the address are transmitted with the most significant bit first.The master ends the transmission after a (N)ACK by sending a STOP condition on the bus. After a STOP condition, any master can initiate a new transfer.An example of a master writing to a slave is shown in Figure 1.3 (p. 3) . The identifiers used are: S - Start bit, ADDR - Address, W - Write(0), A - ACK, N - NACK, DATA - Data, P - Stop bit.Figure 1.3. Master Write to SlaveFor further details about I2C and the EFM32 I2C module, please see the EFM32 reference guide. 1.3 ArbitrationAs the I2C bus is a multi-master bus it is possible that two devices initiate a transfer at the exact same time (e.g. RTC tick). When this happens the first device attempting to transmit a logical 1 while another device transmits a logical 0 will lose arbitration. The device attempting to transmit 1 will detect that the line is low when it should actually be high so assumes that another master is active and immediately stops its transfer. This device will then wait until the next STOP condition before trying to transmit again.1.4 Clock stretchingAn addressed slave device may hold the clock line (SCL) low after receiving (or sending) a byte, indicating that it is not yet ready to process more data. The master communicating with the slave will try to raise the clock to transfer the next bit but will verify that the clock line will remain low. The master will then have to wait for the slave to release the line so that the clock signal can be transmitted. If a master wants to slow down the rate of data transfer it just delays the next clock edge.2 Software Examples2.1 Master Operation with InterruptsThis software example uses the efm32_i2c library to read a DS75 digital thermometer mounted on the EFM32_G890_DK development kit. The tempsens driver includes an interrupt routine to demonstrate how to use the efm32_i2c library in interrupt driven mode.2.1.1 Program FlowThe EFM32 reads the temperature sensor every 2 seconds and stays in a low power mode between measurements. The measurement results are converted to either Celsius or Fahrenheit and displayed on the segment LCD.The efm32_i2c library can be used both in polled and interrupt driven mode. This example uses the interrupt driven approach, but still has a while loop which blocks the function reading the temperature until the transfer is finished. The I2C interrupt routine is entered every time the I2C module generates an interrupt, then it is up to the state machine in the efm32_i2c library to handle and clear the active interrupt flags.Interrupts are generated every time the I2C-peripheral is finished with an autonomous task, or when it detects fault conditions which should be handled by software. Not all possible interrupts are handled or used by this code example.2.1.2 ConnectionsThe software example is specifically made for the development kit and includes the board support package to enable the correct connections and initialize the temperature sensor from software.2.2 Master and Slave OperationThis software example makes the EFM32 operate in both master and slave configuration. Two EFM32 I2C modules are connected and set up to both transmit (master mode) and receive data between each other (slave mode) using a common I2C bus.The code example included is written for the EFM32_Gxxx_DK development kit, but is easily ported to any EFM32 part with an I2C-peripheral.2.2.1 Program FlowEach EFM32 has enabled I2C address match interrupt and Real Time Counter (RTC) interrupt. Both these interrupts are capable of waking up the EFM32 from Deep Sleep mode (EM2), hence the idle state current consumption is extremely low.The I2C is continuously monitoring the I2C line. If a start condition followed by the I2Cs defined address, an address match interrupt is issued and data is received until a stop condition is detected.The Real Time Counter (RTC) is set to wake up the EFM32 regularly. If a reception is not in progress at the time of wake-up, a master transmission is initiated. The address match interrupt is disabled during the transmission and re-enabled afterwards.The operation is illustrated in the state diagram shown in Figure 2.1 (p. 5)Figure 2.1. Program state machineDuring transmission, the PC0 pin is set in order to determine transfer direction for example by using a logic analyzer. On the starter kit, this pin is connected to LED0, which is lit during transmission.Please refer to the source code for further details.2.2.2 ConnectionsThe software example uses location 1 for the SCL (PD7) and SDA (PD6) pins. Connect the PD6 pins and the PD7 pins of the EFM32s, respectively. The configuration is illustrated in Figure 2.2 (p. 5) Figure 2.2. ConnectionIn the GPIO module of the EFM32 the pull-up resistors have been enabled, hence external pull-up resistors are not necessary to make the example work. However, external resistors are generally preferable as they keep the lines defined at all times. For example, when the EFM32 is in reset-state, the pull-up configuration in the GPIO module is not available, which leaves the I2C bus undefined.3 Revision History3.1 Revision 1.062013-09-03New cover layout3.2 Revision 1.052013-05-08Added software projects for ARM-GCC and Atollic TrueStudio.3.3 Revision 1.042012-11-12Adapted software projects to new kit-driver and bsp structure.3.4 Revision 1.032012-04-20Adapted software projects to new peripheral library naming and CMSIS_V3.3.5 Revision 1.022012-03-22Added description on slew rate control.Added arbitration and clock stretching sections (1.3 and 1.4).Added a software example with interrupt driven master operation.Changed name of application note.3.6 Revision 1.0116-11-2010Removed clearing of RXDATAV interrupt flag through I2C_IFC since this operation is ignored.Changed example folder structure, removed build and src folders.Added chip-init function.3.7 Revision 1.0020-09-2010.Initial revision.A Disclaimer and TrademarksA.1 DisclaimerSilicon 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.A.2 Trademark InformationSilicon Laboratories Inc., Silicon Laboratories, the Silicon Labs logo, Energy Micro, EFM, EFM32, EFR, logo and combinations thereof, and others are the registered trademarks or 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.B Contact InformationSilicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701Please visit the Silicon Labs Technical Support web page:/support/pages/contacttechnicalsupport.aspx and register to submit a technical support request.Table of Contents1. I2C Theory (2)1.1. General (2)1.2. I2C Signals/Frames (2)1.3. Arbitration (3)1.4. Clock stretching (3)2. Software Examples (4)2.1. Master Operation with Interrupts (4)2.2. Master and Slave Operation (4)3. Revision History (6)3.1. Revision 1.06 (6)3.2. Revision 1.05 (6)3.3. Revision 1.04 (6)3.4. Revision 1.03 (6)3.5. Revision 1.02 (6)3.6. Revision 1.01 (6)3.7. Revision 1.00 (6)A. Disclaimer and Trademarks (7)A.1. Disclaimer (7)A.2. Trademark Information (7)B. Contact Information (8)B.1. (8)List of Figures1.1. I2C Bus (2)1.2. Start, Stop and Data (3)1.3. Master Write to Slave (3)2.1. Program state machine (5)2.2. Connection (5)...the world's most energy friendly microcontrollers List of Equations1.1. Pull-up Resistor Equation (2)。
目录1. 概述 (1)2. FAQ (2)3. 实验指导 (3)3.1 实验目的 (3)3.2 实验设备 (3)3.3 实验内容 (3)3.4 试验步骤 (3)3.5 实验参考程序 (3)3.6 实验结果 (4)4. 免责声明 (6)1. 概述液晶显示驱动(Liquid Crystal Display Driver，简称LCD)是EFM32片上的低功耗外设，其能够直接驱动段式液晶实现图形显示，并能够工作于EM0~EM2模式下，在EM2模式下工作时其最低功耗小于900nA。
EFM32片上LCD模块具有升压功能，其能够在电压低至2.0V时将电压升压至3.6V，即使在电池供电应用中当其电压不足时也能够让LCD正常显示。
同时为了更好的适应不同的液晶面板和外部环境变化，LCD模块可以根据实际应用调节显示对比度，使得LCD模块的应用更加灵活；并且LCD模块还具备动画、闪烁等特性，让LCD能够在不需要CPU干预的情况下即可完成动画显示和闪烁功能，因此MCU可以长时间处于低功耗模式，降低系统功耗。
2. FAQ1. LCD的供电方式有哪些？A：LCD供电可以选择内部V DD或是外部电源/V BOOST供电。
当使用V BOOST功能时，需要在LCD_BEXT引脚连接一个1μF的电容到地，并在LCD_BCAP_P和LCD_BCAP_N引脚之间加一个22nF的电容。
根据实际需求，LCD模块的升压功能可以将LCD电压升压至3.0～3.6V。
2. 如何使能或禁能LCD模块的V boost功能？A：LCD模块V boost功能的使能或禁能位于CMU模块中，通过配置CMU_LCDCTRL 寄存器中VBOOSTEN位可实现V boost功能的使能或禁能，该位置0则禁能，置1则使能。
3. LCD调节对比的目的是什么？A：不同LCD面板之间它们的特性略有不同，即使是同一LCD面板在不同的温度下其特性也会发生变化。
当由于某种因素导致控制LCD显示的电压与LCD面板当前的显示阀值电压过于接近时候会产生重影或者显示异常等现象，此时可以通过调节LCD对比度让控制LCD显示的电压与当前LCD面板的显示阈值电压之差变大的方式解决上述问题。
...the world's most energy friendly microcontrollersLow Energy UARTAN0017 - Application NoteIntroductionThis application note demonstrates how to use the Low Energy UART (LEUART™)module on the EFM32 microcontrollers. The LEUART is able to run full UART communication even when the device is in deep sleep mode EM2. Together withintelligent interrupt functions and flexible DMA integration, this enables simple andenergy friendly communication .This application note includes:•This PDF document•Source files (zip)•Example C-code•Multiple IDE projects1 LEUART Theory1.1 General theoryThe EFM32 LEUART is a unique Low Energy UART that offers two-way communication on a very strict power budget. Only a 32.768 kHz clock source is needed to allow UART communication up to 9600 baud/ s. This means that the EFM32 LEUART can operate in deep sleep mode EM2, and wait for an incoming UART frame while consuming extremely little energy. When a UART frame is completely received by the LEUART, the CPU can quickly be woken up. Alternatively, multiple frames can be transferred to memory by the DMA before waking up the CPU. The EFM32 LEUART also incorporates functionality to handle higher level communication protocols, e.g. the option to block incoming frames until a configurable start frame is detected, and to detect a configurable signal frame (to indicate e.g. the end of a transmission). In the same way as received, data can be transmitted in EM2 either on frame by frame basis with data directly from the CPU, or in larger groups of frames trough the DMA. The EFM32 LEUART includes all needed hardware support to make asynchronous serial communication possible with minimum software interference, while consuming extremely small amounts of energy.The advantage of the LEUART is the ability to operate in EM2, while most other modules are turned off for energy conservation. The option to enable low energy serial communication, in combination with the DMA's ability to read and write from memory without CPU intervention, offers wide functionality for system designers using the EFM32 in low energy applications.Figure 1.1. LEUART two link full duplex connection2 LEUART Configuration2.1 Frames, Transmission & ParityThe LEUART relates to frames for data transmission. A LEUART frame consists of a start bit, 8 or 9 data bits, an optional parity bit, and 1 or 2 stop bits (Figure 2.1 (p. 3) ). A transmission is initiated by a start bit that pulls the line down from its idle high state. After that the data and parity bits are sent sequentially until the frame transmission is ended by the stop bits that holds the line high. Then the line either enters its high idle state, or a new start bit is sent. Technically, when a frame is ready to be transmitted, it is transferred from the transmit register to a shift register where the bits are sent one by one, least significant bit first. The entire frame format can be inverted, to e.g. allow use of low idle state. The parity bit at the end of the data transmission is an optional method for light error detection. Three different parity modes are available: that is no parity, even parity and odd parity. All parity generation and checking are done in hardware, and interrupt flags are available to indicate if parity error in the frame is detected. The frame format wanted is set during initialization of the selected LEUART. The emlib offers a initialization function that defines all the necessary settings to start communication using the LEUART. All parties of the communication channel must agree on the frame format for communication to be possible. For more extensive information on the LEUART registers and opportunities, refer to the reference manual for the device.Figure 2.1. LEUART frame formatS0*******[8]S top S tart or idleS top or idle[P]2.2 Clock SourcesThe LEUART, like other LE peripherals in the EFM32 microcontrollers, can be driven by three different clock sources, the Low Frequency RF Oscillator (LFRCO), the Low Frequency Crystal Oscillator (LFXO) and the High Frequency Core Clock divided by 2 (HFCORECLK_LE/2). The HFCORECLK_LE can in turn be driven by either the High Frequency RC Oscillator (HFRCO), High Frequency Crystal Oscillator (HFXO) or even any of the LF oscillators mentioned. This flexibility in assigning clocks, gives the system designer a wide range of possibilities for using the LEUART features. This means that beside running on a LF clock source during low energy operation in EM2, the LEUART can also be utilized as a supplement to the UART when more UART communication channels are needed. However for the LEUART to achieve baud rates above 9600 baud/s, the chosen clock source must be the HFCORECLK_LE/2 which is only available in EM1-EM0.2.3 Baud ratesThe selected LEUART clock source defines the baud rates that are obtainable through the LEUART. In standard Low Energy operation, the LEUART offers baud rates between 300 to 9600 baud/s on a 32.768 kHz clock. For details on which baud rates are supported, refer to the reference manual for the device. The emlib also includes methods for calculating which baud rates are available, extracting the current baud rate, and setting the baud rate. With the HFCORECLK_LE/2 selected as th LEUART clock source, higher baud rates are obtainable, but this also implies that the LEUART it will not operate below EM1 and more energy is needed. In addition, since one of the HF clock need to be running, both the UART and USART are also available.2.4 DMA IntegrationThe LEUART has full DMA support even in EM2. In integration with the LEUART, the DMA is a very powerful tool to minimize the need for CPU interference.•The LEUART can be configured to request DMA for data either when the transmit buffer is empty or if both the transmit buffer and the shift register are empty.•The LEUART can be configured to request the DMA to read when the receive buffer is full.•When a frame of parity error is detected in the receive register, the ERRSDMA bit in the LEUARTn_CTRL register can be set to omit the read request to the DMA.When operating in EM2, the DMA controller must be powered up in order to perform the transfer. This is automatically performed for read operations if RXDMAWU in LEUARTn_CTRL is set and for write operations if TXDMAWU in LEUARTn_CTRL is set. To make sure the DMA controller still transfers bits to and from the LEUART in low energy modes, these bits must be configured accordingly. In EM2 the DMA runs off the HFRCO which is also woken up and shut off automatically. The DMA must also be enabled and configured correctly to handle the LEUART data. For more information on how to initialize an interaction between the LEUART and DMA, see the supplied software examples and the reference manual for the device.2.5 Pulse Generator and ExtenderThe LEUART has an optional pulse generator for the transmitter output, and a pulse extender on the receiver input. It will change the input and output format of the LEUART from NRZ to RZI. The width of the pulses from the pulse generator can be configured from 31.25 µs to 500 µs. At 2400 baud/s or lower, the pulse generator is also able to generate RZI pulses compatible with the IrDA physical layer specification.2.6 InterruptsA wide variety of interrupts are available, both during receive and transmit, to support the low energy advantages of interrupt driven applications. An interrupt can be triggered when the receive or transmit registers are empty, or if any errors are detected during transmit. Also there is the ability for the LEUART to trigger an interrupts when specific configurable frames are detected. This allows the construction of higher level communication protocols on top of the LEUART. A special multi processor mode is even available to enable individual addressing and trigger only the desired MCU to receive and act on the data sent. This is a useful feature in systems where multiple UART ICs are communicating on the same channel. In this way the desired receiver can be addressed by starting and ending the transmission with certain frames that will only trigger an interrupt in the desired receiver. In the software examples supplied, the Signal Frame Interrupt functionality is used to wake the CPU only when a specific frame is detected. All other frames are loaded into the memory by the DMA and do not generate any response from the CPU until the preconfigured Signal Frame is detected by the LEUART.2.7 Freeze Mode and LF Domain SynchronisationSynchronization into the low frequency (LF) domain is necessary to modify some of the LEUART registers. To avoid unnecessary stalling when multiple registers are to be modified, all register writes should be done inside a block initiated by void LEUART_FreezeEnable(LEUART_TypeDef *leuart, bool enable) where enable is set true, and ended by the same function call where enable is set false. In this way all register modifications will be performed during a single synchronisation. See the reference manual for the device for more information on accessing and modifying asynchronous registers.2.8 Half-Duplex OperationThe LEUART offers an option to locally loopback the transmitted data to the receive pin. This is useful for debugging, as the LEUART can receive the data it transmits, but it is also used to allow the LEUART to read and write to the same pin, which is required for some half duplex communication modes. When doing full duplex communication, two data links are provided, making it possible for data to be sent and received at the same time. In half duplex mode, data is only sent in one direction at a time. There are several possible half duplex setups. Both single and double data-links, or with an external driver. When communicating over a single data-link, the transmitter must be tristated whenever data is not transmitted. The LEUART can automatically tristate the transmit pin whenever the transmitter is inactive, if the AUTOTRI pin in the LEUARTn_CTRL register is set.2.9 GPIO and RoutingThe LEUART modules have the ability to route its TX and RX pins to some different predefined locations on the MCU pinout. The LEUARTn_ROUTE register must be set to enable and route the pins to the desired location.To enable the LEUART to interact with any external system components, like the RS232 port or another peripheral IC, the GPIO I/O pins must be configured accordingly. The GPIO has a variety of different pin modes available, and in the supplied code examples the TX pins are configured as push-pull output. The RX pins are enabled as inputs with a pull-up. The pull-up helps to define the input state in case line is not driven to a defined value by the other part. This can happen if you enable the RX module before the TX module. Refer to the application note "AN0012 GPIO" more examples on GPIO mode setting.3 Software ExamplesThe following software examples demonstrates a way to achieve full UART communication, using the LEUART functionality of the EFM32.3.1 Listening and Receiving in EM2.In this example, LEUART communication is initialized using the DMA to transfer received data from the LEUART receive register to the system memory. When a preconfigure signal frame is received, the LEUART generates a interrupt, and the CPU wakes up and writes all the received data from the memory to the LCD.3.1.1 Example 1: Receiving on DVKThis DVK can receive data both trough RS232, and directly through the pinout on the Prototype Board. This means that the example can be run in a variety of different setups, receiving data both from another DVK, a STK or a PC trough the RS232 port on the DVK. The LEUART1 RX pin is located on pin J10 on the DVK Prototype Board, and needs to be connected to the TX pin on the transmitting DVK or STK, or trough a RS232 cable to a PC. Note that the sender and received must have same ground and supply voltage when connecting the RX and TX lines directly without using the RS232 port.3.1.2 Example 2: Receiving on STKOn the STK the data can be received trough the pinout located along the rim of the board. The LEUART1 RX pin is located on the PC7 pin on the bottom row.3.2 Transmitting in EM2.In this example, LEUART communication is initialized using the DMA to transfer data from a location in the local system memory to the LEUART, on given RTC(Real Time Clock) interrupts. Every other second, the RTC interrupt initializes the DMA to start feeding the LEUART TX transmit register with data, and returns to EM2. One of two predefined strings is then transmitted trough the LEUART to anyone listening. The two strings will alternate.3.2.1 Example 3: Transmitting from DVKThe DVK can send data both directly through the pinouts on the Prototype board, and through the RS232 port provided. The example can in this way be set up and run in several different setups, both transmitting to another DVK, a STK or a PC. The LEUART1 TX pin is located on the pin J9 on the DVK Prototype Board, and needs to be connected to the RX pin on any receiving device, or to a PC through the use of a RS232 cable to a PC. Note that the sender and received must have same ground and supply voltage when connecting the RX and TX lines directly without using the RS232 port.3.2.2 Example 4: Transmitting from STKOn the STK the data can be transmitted through the pinout located along the rim of the board. The LEUART1 TX pin is located on the PC6 pin on the bottom row.4 Revision History4.1 Revision 1.082013-09-03New cover layout4.2 Revision 1.072013-05-08Added software projects for ARM-GCC and Atollic TrueStudio.4.3 Revision 1.062012-11-12Adapted software projects to new kit-driver and bsp structure.4.4 Revision 1.052012-08-13Adapted software projects to new peripheral library naming and CMSIS_V3.4.5 Revision 1.042011-11-15Updated transmit examples to use DMA callback to allow sleeping while transmitting.4.6 Revision 1.032011-10-21Updated IDE project paths with new kits directory.4.7 Revision 1.022011-05-18Updated projects to align with new bsp version4.8 Revision 1.012010-11-16Changed example folder structure, removed build and src folders.Updated chip init function to newest efm32lib version.Updated register defines in code to match newest efm32lib release.4.9 Revision 1.002010-09-24Initial revision.A Disclaimer and TrademarksA.1 DisclaimerSilicon 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.A.2 Trademark InformationSilicon Laboratories Inc., Silicon Laboratories, the Silicon Labs logo, Energy Micro, EFM, EFM32, EFR, logo and combinations thereof, and others are the registered trademarks or 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.B Contact InformationSilicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701Please visit the Silicon Labs Technical Support web page:/support/pages/contacttechnicalsupport.aspx and register to submit a technical support request.Table of Contents1. LEUART Theory (2)1.1. General theory (2)2. LEUART Configuration (3)2.1. Frames, Transmission & Parity (3)2.2. Clock Sources (3)2.3. Baud rates (3)2.4. DMA Integration (4)2.5. Pulse Generator and Extender (4)2.6. Interrupts (4)2.7. Freeze Mode and LF Domain Synchronisation (4)2.8. Half-Duplex Operation (5)2.9. GPIO and Routing (5)3. Software Examples (6)3.1. Listening and Receiving in EM2. (6)3.2. Transmitting in EM2. (6)4. Revision History (7)4.1. Revision 1.08 (7)4.2. Revision 1.07 (7)4.3. Revision 1.06 (7)4.4. Revision 1.05 (7)4.5. Revision 1.04 (7)4.6. Revision 1.03 (7)4.7. Revision 1.02 (7)4.8. Revision 1.01 (7)4.9. Revision 1.00 (7)A. Disclaimer and Trademarks (9)A.1. Disclaimer (9)A.2. Trademark Information (9)B. Contact Information (10)B.1. (10)List of Figures1.1. LEUART two link full duplex connection (2)2.1. LEUART frame format (3)。
...the world's most energy friendly microcontrollers USART/UART - AsynchronousmodeAN0045 - Application NoteThis application note describes how to configure the EFM32 UART or USART tooperate in asynchronous mode.An included software example for the EFM32GG-DK3750 Giant Gecko DevelopmentKit shows how to implement interrupt driven receive and transmit, utilizing the on-board RS-232 transceiver.This application note includes:•This PDF document•Source files (zip)•Example C-code•Multiple IDE projects1 Universal Asynchronous Receive Transmit (UART)1.1 Basic TheoryA UART is a well established standard for low cost, low speed serial communications over a simple 2-wire (plus ground) interface.Asynchronous communications differs from synchronous communications in that synchronization between transmitter and receiver are encoded into the transmitted signal, rather than using a separate wire to transfer the transmitter clock to the receiver.Embedding the synchronization information in the data reduces the cost of cables and connectors, and may also be beneficial on a space constrained PCB or if one wants to keep the pin-usage low. On the other side adding synchronization information to the datastream increases overhead, causing the effective data rate to be lower than the baud rate.Normally, asynchronous communication modes facilitate somewhat lower data rates compared with synchronous modes. Some of the reason is the above mentioned overhead, but also because asynchronous communications may impose stronger requirements on the transceivers and the transmission lines between receiver and transmitter.Low cost and low power transceivers usually don't have advanced clock recovery mechanisms, but simply rely on the combination of oversampling and that the receiver and transmitter clock frequencies are sufficiently close.1.2 RS-232UART does not specify any electrical characteristics such as signal levels etc. Instead, several separate electrical interface standards can be applied. Most common is RS-232, but other well known standards include RS-422, RS-485, and also some standards that don't use electrical signalling such as IrDA.In this application note, the included software example uses the RS-232 transceiver that is included on the Development Kit.1.3 Using the EFM32 UART/USARTThe information necessary to configure and use the UART/USART modules on an EFM32 microcontroller are contained in the device family reference manual. This application note also presents some further details and clarifications.1.3.1 Clock SourceOften, the HFRCO is too unprecise to be used for communications. So using the HFXO with an external crystal is recommended when using the EFM32 UART/USART.In some cases, the internal HFRCO can be used. But then careful considerations should be taken to ensure that the clock performance is acceptable for the communication link.1.3.2 Baud Rate CalculationThe baud rate is given by the following expression:Baud rate(1.1)Where•br is baud rate,•f HFPERCLK is the frequency of the HFPERCLK branch of the high frequency clock tree (See figure on CMU Overview in device family specific reference manual),•OVS is the oversampling factor, and•DIV is the configurable part of the fractional divider in the UART/USART module.When rearranged, one can compute a clock divider setting that will obtain a wanted baud rate by the following formula:Clock divisor(1.2) The clock divider is a fractional divider dividing by (1+DIV/4) where DIV is a 15 bit value ranging from 0 to 32767. I.e. the clock can be divided by a factor from 1 to 8192.75. Depending on the configurable oversampling factor the baud rate is given by a further division by a factor of 4, 6, 8 or 16. This results in a baud rate that is the clock frequency divided by 4 to 131,084. If the HFXO is run at 32 MHz, baudrates between 8 Mbps and 244.11 bps can be generated as long as the HFPERCLK prescaler is set to 1.It is worth noting that the equations in this application note differs somewhat from the reference manual. The reason is that the reference manual refers to CLKDIV which is the entire 32-bit register value, of which only the 15-bit wide bitfield DIV is actually used to control the fractional divider. In this document, the bitfield DIV is consistently used.2 Software ExampleThe included software example is made for the EFM32 Giant Gecko Development Kit, EFM32GG-DK3750. However, with minor modifications the project will also work on our other EFM32 development kits. It can also be ported to the starter kits. But because the starter kits don't include RS-232 line drivers, please ensure that signal levels are compatible before establishing a communication link between two parties. Connecting the EFM32 UART directly to a PC serial port will damage the EFM32.The kit's on-board RS-232 transceiver is used to demonstrate a possible interrupt based asynchronous mode configuration of an EFM32 U(S)ART peripheral.The example uses interrupt driven transmit and receive. When transmitting a block of data, the data is first copied into a transmit queue. The U(S)ART TXBL interrupt is enabled. When the UART is ready to transmit, the TXBL interrupt goes high. The interrupt handler function fetches one byte from the transmit queue and copies it to the UART transmit buffer (UARTn->TXDATA). While transmitting, the CPU is free to perform other tasks. In the example project, the MCU spends this time in Sleep Mode (EM1).The same principle is used on receive. When an RXDATAV interrupt is received, the Rx interrupt handler copies the incoming data to a receive queue.2.1 Kit ConfigurationThe development kit's on-board RS-232 line driver is used. This transceiver is normally disconnected from the MCU, so before it can be used, it must be enabled by software. To do this, the kit library functions are used. The kit libraries are included in the kit software packages that can be installed via Simplicity Studio. Documentation can be found in a sub-folder of the Energy Micro library installation folder. It is usually located at: [energymicro]\kits\EFM32GG_DK3750\bspdoc\html\index.html where [energymicro] is the Simplicity Studio data folder. The location of this folder is system dependent, and can be found through "Simplicity Studio->File->Browse Installed Files"The RS-232 transceiver is connected to UART1, location 2 on the EFM32.2.2 InstructionsA serial cable and terminal emulator software is required to try this example. On Windows, the OpenSource terminal Tera Term can be used.First, connect a serial cable between a computer and the 9-pin RS-232 connector on the development kit. Configure the serial port as follows•Baud rate = 115 200•Data bits = 8•Parity = none•Stop bits = 1•Flow control = nonebefore opening a connection with the terminal emulator.One should also configure the terminal emulator to handle new line in the same way as the SW example.In Tera Term the proper configuration is to use LF on receive and CR+LF on transmit. If this can't be configured on the chosen emulator, the example can of course be altered to match the emulator settings.When connected, start typing. After entering some characters, press '.' which is predefined as a "termination character" causing the MCU to echo the contents of the RX queue back out on the UART.2.3 TransmitTransmit is handled by two functions: uartPutData() and UART1_TX_IRQHandler().uartPutData() copies data to send into a transmit queue. The queue is implemented as a circular buffer.The data is copied into the queue starting at the write index (wrI). When finished, the pending byte counter is updated. Finally the TX interrupt for the UART is enabled.UART1_TX_IRQHandler() reacts when the TXBL interrupt goes high, signalling that the UART transmit buffer is empty. When this happens, one byte is copied from the read index (rdI) position in the TX queue into the UART transmit buffer. The read index is updated, and the pending byte counter is decremented.If the transmit queue becomes empty, the TXBL interrupt is disabled.2.4 ReceiveIn the same way, receive is also handled by two functions: UART1_RX_IRQHandler and uartGetData.UART1_RX_IRQHandler()reacts on the RXDATAV interrupt, meaning that the UART RX buffer contains valid data. When this happens, the incoming byte is copied from the UART RX buffer into the RX queue. The queue write index (wrI) is updated, and the pending byte counter is incremented. The IRQ handler will also disable the TXBL interrupt if the transmit queue becomes empty.uartGetData() pulls a number of bytes from the receive queue. The copy starts at the read index (rdI).When data is copied, the read index is updated and the pending byte counter is decremented.Also, for the sake of the example, the RX interrupt handler checks if the received byte is a predefined termination character.3 Revision History3.1 Revision 1.032013-09-03New cover layoutRemoved unnecessary read of IF in TX IRQ Handler3.2 Revision 1.022013-05-08Added software projects for ARM-GCC and Atollic TrueStudio.3.3 Revision 1.012012-11-12Adapted software projects to new kit-driver and bsp structure.3.4 Revision 1.002012-06-28Initial revision.A Disclaimer and TrademarksA.1 DisclaimerSilicon 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.A.2 Trademark InformationSilicon Laboratories Inc., Silicon Laboratories, the Silicon Labs logo, Energy Micro, EFM, EFM32, EFR, logo and combinations thereof, and others are the registered trademarks or 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.B Contact InformationSilicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701Please visit the Silicon Labs Technical Support web page:/support/pages/contacttechnicalsupport.aspx and register to submit a technical support request.Table of Contents1. Universal Asynchronous Receive Transmit (UART) (2)1.1. Basic Theory (2)1.2. RS-232 (2)1.3. Using the EFM32 UART/USART (2)2. Software Example (4)2.1. Kit Configuration (4)2.2. Instructions (4)2.3. Transmit (4)2.4. Receive (5)3. Revision History (6)3.1. Revision 1.03 (6)3.2. Revision 1.02 (6)3.3. Revision 1.01 (6)3.4. Revision 1.00 (6)A. Disclaimer and Trademarks (7)A.1. Disclaimer (7)A.2. Trademark Information (7)B. Contact Information (8)B.1. (8)List of Equations1.1. Baud rate (2)1.2. Clock divisor (3)。
