Silicon Labs always mentions low power, but some competitors say they are the lowest power. What resources are available power benchmarks, comparison, etc.?
Answer
We have several application notes and white papers included in Simplicity Studio that addresses this. In particular, please see AN0007, AN0027, and TM0008.
Files in the EFM32 SDK are available under the following licenses. Note that the kits and reptile directories contain some software with OSS licenses, such as the GPL.
Support for this feature is included in CMSIS, and a system reset can be invoked by performing the following steps:
1. Include the appropriate CMSIS header file from the following list: core_cm0plus.h, core_cm3.h, or core_cm4.h. The appropriate CMSIS core file is automatically included by em_device.h.
Consult the list of 32-bit Families to determine the device architecture type.
2. Call NVIC_SystemReset() to perform a software reset.
What USB audio examples are available for the EFM32?
Answer
There are two USB audio examples (USB Audio Class 1.0) for the EFM32. These examples can be found using the Software Examples tile in Simplicity Studio. The two examples are:
usbdheadphone
usbdmicrophone
Both of these examples are available for the EFM32GG, EFM32LG, and EFM32WG Development Kits.
These examples can also be found on disk here by default:
There is no STK for EFM32JG. Since the only difference between Jade Gecko and Pearl Gecko is the core, the hardware and software development for EFM32JG can be done using an EFM32PG STK.
Any projects developed for EFM32JG should be set to use the ARM Cortex M3 core so the DSP extensions and FPU operations of EFM32PG (ARM Cortex M4) will be disabled by default.
What are the new features of GPIO interrupts in EFM32 Gecko Series 1 and EFR32 Wireless Gecko Series 1 device?
Answer
All GPIO pins within a group of four (0-3,4-7,8-11,12-15) from all ports are grouped together to trigger one interrupt.
So pins within the same group from different ports (e.g. PA0 & PC0) can be selected for the same interrupt source. The example code below demonstrates how to set up PC6 and PF6 as a GPIO interrupt on EFM32JG/PG.
Note: The Gecko SDK V5.0.0 fixed GPIO_ExtIntConfig() to enable correct interrupt number so this feature does not function properly on previous Gecko SDK.
I have followed this example to set-up bit-banding macros for my own application using EFM32. The SRAM bit-banding works as expected, but the peripheral bit-banding only works for bits [7:0] of a given 32-bit register. Is there something wrong with my code or is bit-banding broken on EFM32?
Answer
Bit-banding does work on EFM32; the problem is a lack of specificity in ARM's own documentation. For example, the aforementioned application note (see section 2.5 Bit-banding), states that "this allows every individual bit in the bit-banding region to be directly accessible from a word-aligned address using a single LDR instruction." However, the example code in that same section uses the 8-bit type unsigned char for the pointer to the bit-band alias region.
The requirement for aligned word accesses to the bit-band alias region is not stated in the Cortex-M3 Devices Generic User Guide or the Cortex-M4 Devices Generic User Guide. In fact, these documents state quite the opposite that "bit-band accesses can use byte, halfword, or word transfers. The bit band transfer size matches the transfer size of the instruction making the bit band access." Similar statements can be found in the reference manuals for ARM's version 4- and 5-series C compilers.
So, which statements and documentation about bit-band transfer sizes and access alignment are true?
It turns out that the latter statements regarding bit-banding are the correct ones. In simple terms, whatever access size is presented to the bit-bander is the same access size that accompanies the resulting bus cycle(s) for reads or atomic read-modify-writes.
This actually makes sense when you think about it. Every ARM MCU vendor has their own implementations of peripherals like timers, serial ports, etc. Each vendor can choose what size accesses a particular peripheral might support. For example, it's not uncommon for a simple timer to have only a 16-bit counter and 16-bit registers. GPIO ports are often organized into 8-port ports with associated 8-bit registers.
So, in this respect, the bit-bander is designed to work with whatever peripherals might be mapped into the bit-banded peripheral address space, regardless of whatever access sizes might be supported.
ARM's example code cited above assumes as much. Why, then, can the peripheral bit-band macro issue 8-bit writes to bits [7:0] of a peripheral register in the bit-band region but not otherwise write bits [31:8]? The answer is simple:
On the Gecko devices, the peripheral registers are 32 bits wide, and writes, specifically, must also be 32 bits in size.
For example, if you use this loop to set each bit in GPIO_PD_DOUT one at a time with bit-banded accesses...
for(i =0; i <16; i++)*((volatileuint32_t*)(0x42000000+0x6078*0x20+ i *4))=(uint32_t)0x1;
...it works as expected because the writes to the bit-band space are 32-bit, and the resulting atomic read-modify-write cycles are also 32-bit. However, if you try to clear each bit, one after another, in reverse order using this loop...
for(i =15; i >=0; i--)*((volatileunsignedchar*)(0x42000000+0x6078*0x20+ i *4))=(unsignedchar)0x0;
...it doesn't work. Bits [15:8] remain unchanged, but when the code gets to bit 7, it and each subsequent bit is cleared as expected. This all comes back to the peripheral registers on Gecko requiring 32-bit writes. Anything else will not behave as expected.
If you would like to use bit-banding in your application, there are two options for making sure it to works:
Use em_bitband.h and the bit-banding macros it provides. You'll get the benefit of properly constructed bit-band addresses, and you don't have to use the higher-level functions of emlib if you don't want/need them.
Make sure whatever bit-band macros you construct use a 32-bit type for all integers, e.g. int, unsigned int, uint32_t, etc.
Please note that none of this applies to EFM32 devices that use the Cortex-M0+ like Zero Gecko or Happy Gecko. Bit-banding is not a feature of the M0+ core as delivered by ARM, and neither Zero nor Happy Gecko incorporates any logic to implement it.
32-bit Knowledge Base
Application Notes Covering Low Power Benchmarks
Software licensing for EFM32
Files in the EFM32 SDK are available under the following licenses. Note that the kits and reptile directories contain some software with OSS licenses, such as the GPL.
How to perform a software reset
USB audio examples for EFM32
Energy Profiler background color
EFM32JG/PG HFXO frequency
STK for EFM32JG
Clock source for LETIMER and RTCC in EFM32JG/PG
GPIO interrupt in EFM32 Gecko Series 1 and EFR32 Wireless Gecko Series 1 device
Understanding Peripheral Bit-banding on EFM32 Microcontrollers