Electromagnetic compatibility (EMC) optimization is a core competence of Silicon Labs. As well as implementing chip-level circuits to improve performance in a system, we have a very strong understanding of board-level design to ensure best-in-class EMC performance. We have helped many customers optimize PCBs to meet emissions standards and use our EMC lab to help solve our customers' board-level emissions problems.
EMC determines the ability of a product like MCU to coexist in its intended electromagnetic environment without causing or suffering functional degradation or damage to itself or to other devices that may reside in that environment – it neither is susceptible to nor causes Electromagnetic Interference (EMI). Since EMC involves the presence of a source of electromagnetic radiation, a receptor of that electromagnetic radiation and a path for that electromagnetic radiation, it is only necessary to remove two of these to achieve acceptable EMC. In general, it is not practical to completely eliminate electromagnetic radiation from a digital integrated circuit. However, by incorporating many fundamental techniques to control electromagnetic emissions from an integrated circuit and to then incorporate new methodology to reduce “leakage” of these emissions outside of the chip. From the overall system point of view, it is always more cost effective to design a product with suppression at the integrated circuit level as opposed to addressing these issues at the PCB or system level .
By designing our MCUs with EMC optimization in mind, Silicon Labs delivers solutions that reduce system level noise and interference. The following resources will enable designers to better understand system level considerations to reduce EMI, how to measure it and how to ‘design-it-out', of your PCB designs.
Most electronic products require radiated EMI testing to ensure that they don't interfere with other RF systems, such as television and radio broadcast and cell phones. After meeting the required standards, an endorsement from a calibrated and certified EMI test house is issued. A TEM cell allows companies like Silicon Labs (who are in the semiconductor or product business, not the EMI testing business) do "pre-compliance" testing before going to a certified test house. The TEM cell along with an EMI receiver or spectrum analyzer comprise a system capable of making calibrated radiated field strength measurements. The TEM cell acts as a calibrated antenna and shielded enclosure, which both captures the radiated energy and blocks outside signals from the measurement. The spectrum analyzer is the receiver, which, with custom software, measures and displays the frequencies emitted and their strengths.
In the 8-bit SDK, the capsense library has been updated from SDK versions 4.08 to 4.09. This update primarily changed how capsense thresholds are assigned. Previously, threshold values were global - one set of threshold values applied to all capsense inputs. This works fine for situations where all capsense inputs are approximately the same size, but it is incompatible with systems with varying capsense input button sizes, or for situations where different thresholds are needed on a per-button basis.
This change was reflected in Hardware Configurator.
Previously, the global thresholds were located in the Capsense Library peripheral screen:
Now, the individual thresholds are located in each pin's settings, in the Port I/O tab.
The settings that were moved are: Average Touch Delta, Active Threshold, and Inactive Threshold.
Keil uVision debug MCU时，如何查看直接寻址的片内RAM、间接寻址的片内RAM、扩展的外部RAM和代码存储空间 ?
建议在debug时使用Silabs推出的Simplicity Studio V4, 其界面更为直观，debug更为高效。
Where can I find example code for the C8051xxxx MCU?
Example code for Silicon Labs's MCUs is available in two main locations.
The first is the Application Note webpage:
On the Application Note webpage, the example code is organized by topic, such as ADC or UART. Check the beginning of the application note to determine if the application note is applicable to your MCU.
Example code is also part of the Silicon Labs IDE. The Silicon Labs IDE is available for download at:
If the IDE is installed to the default directory, the example code is installed at:
In the Examples directory, the example code is organized by the MCU family. There are over 1000 pieces of example code currently available in this directory.
Where can I find Ethernet examples for Silicon Labs MCUs?
Ethernet examples for the 'F12x and the 'F34x are attached to this article. These are the lowest layer, hardware-level routines intended to be interfaced with a Ethernet stack.
Most of the C8051 devices include an external oscillator drive circuit to driver an external crystal, ceramic resonator, capacitor, or RC network.
For a crystal or ceramic resonator configuration, the crystal/resonator must be wired across the XTAL1 and XTAL2 pins as shown in the figure below. And a 10M ohm resistor must be wired across the XTAL2 and XTAL1 pins for the crystal/resonator configuration.
The 10 M ohm resistor between XTAL1 and XTAL2 is required to provide proper DC bias to the internal crystal driver. And the parallel impedance (10M ohm) decides the loop gain. Having a larger impedance is usually desired because it will increase the loop gain, and hence reduce start up time and increase negative impedance. So it shouldn't try to reduce this 10M ohm impedance.
With regard to the unstable or unable to start up oscillation, please check the items below one by one.
1. Review the PCB layout:
Crystal oscillator circuits are quite sensitive to PCB layout.
AN203 provided a good starting point in the design and layout of a PCB, and the methods presented in this application note should be taken as suggestions.
2. Check the capacitors value connected to the crystal.
The capacitors shown in the external crystal configuration provide the load capacitance required by the crystal for correct oscillation. These capacitors are "in series" as seen by the crystal and "in parallel" with the stray capacitance of the XTAL1 and XTAL2 pins.
The desired load capacitance CL depends upon the crystal and the manufacturer. Refer to the crystal data sheet when completing these calculations below.
The equation for determining the load capacitance for two capacitors is as follows:
C is the capacitor value connected to the two crystal leads, in general, will connect a same capacitor on each lead. CS is the total stray capacitance of the PCB, and the stray capacitance for a typical layout where the crystal is as close as possible to the pins is 2-5 pF per pin.
For example, a tuning-fork crystal of 25 MHz has a recommended load capacitance of 12.5 pF. With a stray capacitance of 3 pF per pin (6 pF total), the 13 pF capacitors yield an equivalent capacitance of 12.5 pF across the crystal.
12.5 pF = C/2 + 6
C = 13 pF
3. Choose a reasonable driver level
Please refer to the KB below to choose a reasonable driver level.
The KB describe how to specify the XFCN to issue a reasonable crystal driver current considering the required Drive Level (DL) and Equivalent Series Resistance (ESR) of the crystal rather than only considering the frequency.
4. Measure the actual driver level on board
If the crystal still unstable or cannot start up after checking the items above, you should measure the actual driver level on board (Crystal vendor should be able to provide the test report). If the measured driver level is way larger than the maximum specification, the crystal will be over-driven and may result to the crystal circuit not working, and the crystal operational lifetime will be reduced.
The recommended method is adding a series resistance Rd to the crystal to reduce the driver level.
Why does the datasheet say the Fast Mode (400 KHz Class) SMBus has a maximum operating frequency of 255 kHz?
The SMBus peripheral is internally clocked at 3 times the target bit rate and generates clock low from 1 clock cycle and clock high from 2 clock cycles.
The SMBus 400 kHz fast speed specifies clock low must be at least 1.3 us. So 1/(3x1.3us) = 256 kHz. If you set the SCL frequency to higher than 256 kHz, then the clock low time will be less than 1.3 us and violate the spec.
In practice, many I2C devices will work fine above 256 kHz, but the device will be in violation of the timing requirements, so full compatibility can't be guaranteed for strict systems.
I am trying to use ADC on the C8051F35x and am having problems figuring out how the offset DAC works.
First of all, I am not sure if the offset DAC is added to or subtracted from the AIN+ and AIN- inputs such that it has the effect of level-shifting, is applied to only one input, or even if its doing the opposite on both inputs (half the value subtracted from AIN+ and half value added to AIN-, which would cancel any offset completely.
Also, application note AN217, which has the same block diagram as the 'F35x datasheet...
...shows that the offset should be applied before the gain, but in my tests it seems to be done afterwards.
From what I can tell, the offset voltage is substracted after the amplification. Is this expected behavior, or am I doing something wrong?
As the customer has noted, there appears to be a notable difference in how the offset DAC behaves relative to the PGA, and, in this case, the customer is correct: the offset DAC operates after the PGA. So, for starters, the block diagram above should be modified as follows:
Furthermore, consistent with the customer's experiments, the ODAC output is subtracted from AIN+ and added to AIN- as a signed value, where bit 7 and bits [6:0] of the ADC0DAC register represent the sign value (0 = positive, 1 = negative) and the magnitude, respectively.
When trying to do isochronous transfers with the USB Peripheral Driver Library, you may notice that the library only supports isochronous transfers on Endpoint 3 even though the device's datasheet says endpoints 1-3 support isochronous transfers.
The device does support isochronous transfers on endpoints 1 through 3, but the library was only designed to support isochronous transfers on endpoint 3 by default. All Silicon Labs designs use endpoint 3 for isochronous transfers, so the library was built around this as well as with the idea of keeping the code simple in mind. The library can be modified to support isochronous on other endpoints, but the library does not support this out of the box.