Official Blog of Silicon Labs

    Publish
     
      • May 2016 Member Spotlight: klangdon79

        Siliconlabs | 05/152/2016 | 10:32 AM

        We are featuring one of the Silicon Labs Community members who is active or new in the community on a monthly basis to help members connect with each other.

         

        Meet our May member of the month: klangdon79

        user profile pic.png

         

        Q: Congrats on becoming our featured member of the month! Can you introduce yourself to our community members? 

         

        My name is Kevin Langdon (http://www.kevinlangdon.com/). I am the CTO for a startup named Play Impossible, based in Seattle, Washington, but I live and work in Milton, Pennsylvania. We are using Silicon Labs products to build a connected sports ball. I am primarily a computer programmer, but over the last few years have become more and more interested in hardware development. 

         

         

        Q: How did you know about the Silicon Labs Community?

         

         We evaluated a number of different BLE modules and chose the BLE113 and BGM111 for their low power and long range.

         

        Q: What features would you like to see added to the community?

         

        I would like to see more transparency and discussion about product road maps and rough estimates on when the community can expect fixes and features.

         

        Q: What pages do you usually visit in the Silicon Labs Community, and why? 

         

        Forums and links to datasheets.

         

      • One Giant Leap in Connectivity

        Lance Looper | 05/152/2016 | 08:50 AM

        There’s no denying the role connectivity plays in regards to devices and how efficiently they communicate information. While wireless capabilities continue to make headlines, there’s still a great deal of value in wired specifications, first and foremost with USB connections.

         

        USB connectors are easy to confuse. They’ve come in many shapes and sizes over the years beginning with Mini, Micro, Type-A, Type-B and now Type-C. For reference, a USB type simply refers to the shape of the ports and plugs while the version, such as 1.1, 2.0, or the current USB 3.1, usually denotes speed. The Type-A connector connects into a host, such as a laptop, while the Type-B connector plugs into a peripheral device. Type-A is always the flat and wide connector shown in the figure below while Type-B can show up in many different shapes due to the differences in devices it connects into.

         

        USB Dongles.png

         

        USB Type-C was first introduced in 2014, implemented to some degree in 2015 (more notably on Macbooks), and is increasingly becoming a standard for many devices in 2016. It’s being called “a leap forward” in connectivity and for good reason.

         

        USB Type-C separates itself from its predecessors because it:

         

        • Can send or deliver up to 100W of power to charge a high-current device
        • Supports USB 3.1 with data transfer speeds of up to 10 Gbps
        • Will support up to two 4K displays at a 60Hz refresh rate
        • Maintains backwards compatibility with USB 2.0
        • Has reversible connectors so it does not matter which end is used and in what direction
        • Cuts down on waste by eliminating the need for multiple connectors

         

        Though it can handle a wide variety of tasks that previously took multiple cables, Type-C’s versatility comes at a cost because USB’s once-simple inner workings of cables, ports, dongles, and hubs have been replaced by more complex embedded components. There are two main complications that arise when developing Type-C solutions. The first relates to power distribution. A Type-C connector can send or receive up to 100W of power, but this can be a problem for devices that don’t require that much power.

         

        The second common roadblock when developing a Type-C solution deals with the potential for communication failures due to the increase in supported communication standards. Since communication between hosts and devices requires detecting and processing digital and analog signals, an embedded MCU is required. Silicon Labs can alleviate these issues through the creation of it’s new MCU, which integrates more functionalities in a package as small as 3X3 mm².

         

        USB Type-C WP Image.png

         

        Although it’s clear USB Type-C represents a new wave of enhanced connectivity, it unfortunately can cause problems for developers and designers. To learn more about how we’re simplifying Type-C development, download this whitepaper.

         

        We’ve also released a comprehensive reference design featuring cost-effective, ultra-low-power EFM8 microcontrollers (MCUs), USB Power Delivery (PD) protocol stacks certified by the USB Implementation Forum (USB-IF), and USB Billboard Device source code.

         

         

         

        Our reference design provides a complete solution for a USB Type-C to DisplayPort (DP) adapter, making it easy to communicate with legacy products that do not support USB-C. Available to qualified developers at no charge, the reference design includes schematics, software libraries and stacks, source code, code examples and access to Simplicity Studio™ development tools, enabling developers to design USB-C cables and adapters quickly, easily and at minimal cost.

         

         

        Get all the details about the USB Type-C reference design including software stacks, schematics, documentation, tools, and EFM8 MCU information at www.silabs.com/usb-type-c.

         

        usb-type-c-board.jpg 

      • Helping Drones Take Flight

        Lance Looper | 05/148/2016 | 09:30 AM

        About eight years ago while attending NAB Show, the massive industry event hosted by the National Association of Broadcasters, I noticed a considerable amount of floor space dedicated to showing off the latest camera-equipped drones. Marketed then as a more cost-effective way for cinematographers to capture aerial footage, these quadcopters were still priced significantly out of reach for casual users.

         

        But like any new technology, as it developed it became more accessible. Over the last few years in particular, drones have gained popularity in large part because of the quality of the cameras they are being outfitted with and the lengths manufacturers are going to in order to make them easier to fly (I bought a mini quadcopter last winter and promptly flew it into a tree).

         

        Drone copy.jpg

         

        This week Xiaomi announced its Mi Drone, an exciting development for potential drone customers given the company’s reputation for balancing sophisticated design and affordability.

         

        Two important design considerations when developing unmanned aerial vehicles (UAVs) are precise motor control and small form factor and Xiaomi is using our C8051 F85x 8-bit microcontroller, joining a growing number of drone manufacturers that like its combination of fast PWM modulation and small footprint.

         

        In addition to the highly-integrated, AEC-Q100 qualified MCUs, we offer a reference design that has everything you need to start a motor spinning in five minutes or less.

         

        The C8051F850 Motor Control Reference Design  includes a 12-bit ADC, precision internal reference voltage, two with programmable hysteresis, and built-in hardware shutdown capability independent PWM channels.

        The C8051F850 Motor Control Reference Design includes:

        • C8051F850 MCU Motor Control Board
        • Powertrain Board
        • Motor Mount Board with Turnigy 3800 kV Series Outrunner Motor
        • USB Cable
        • Power Supply
        • World Wide Plug Adaptors
        • Quick Start Guide

         

        We also have a Development Kit for the C8051 F85x family that provides everything needed to evaluate hardware and develop code, including a C8051F850 MCU board, wall-mounted power supply, USB cable and quick-start guide.

         

         

      • IoT Security Part 7: Key Exchange using Elliptical Curve Cryptography

        kberringer | 05/147/2016 | 08:17 PM

        Isn’t Elliptical Curve Cryptography (ECC) overkill for a small embedded IoT device? This is a question we hear from time to time, but based on its computation requirements and security properties, ECC might be a better choice for IoT devices than RSA.

         

        Because asymmetric encryption methods require much more computation than symmetric AES encryption, most systems use asymmetric encryption only for key exchange and then use symmetric AES encryption for basic communications.

         

        ECC and RSA are both asymmetric encryption algorithms. The RSA algorithm is based on the problem of factoring the product of two large numbers. It requires first the generation of large random numbers, checking for primeness, and then multiplying two large numbers. RSA not really an acronym, but an abbreviation of the authors last names – Rivest, Shamir, & Adleman.

         

        Implementing RSA at 2048 bits on a small embedded 32-bit processor is not going to be fast. Multiplication of two 2048 bit numbers requires a 64 word by 64 word long multiply operation. This requires is 4096 long multiply with 64-bit resultant and accumulate (UMLAL) instructions on the M3 or M4 processor, or 32768 multiply with 32-bit resultant (MULS) and add (ADDS) instructions on the M0.

         

        The approximate computation times for a 2048 bit multiply on the Cortex M processors running at 25 MHz are:

        • Cortex M4 – 500 us
        • Cortex M3 – 1.5 ms
        • Cortex M0 – 25 ms

         

        An RSA key of 2048 bits is equivalent to a symmetric AES key of 128-bits. The NSA suite B standard requires a 3072 bit RSA key, which is equivalent to 256-bit symmetric key encryption. The computation time for increasingly higher levels of security increases exponentially using RSA.

         

        Elliptical Curve Cryptography is based on solving the Discrete Logarithm problem. Stated simply, it is not easy to find the discrete logarithm of a point on an elliptical curve. The main benefit of ECC is that it provides a high level of security using a relatively short key. Shorter keys use less memory and dramatically decrease the computational requirements. ECC using a 256-bit key and the 256-bit prime curve is roughly equivalent to RSA 2048.

         

         

        ECC Chart.png

         

        With a little bit of extra hardware to accelerate modular multiplication, ECC can potentially offer better performance and use less memory than RSA.

         

        Internet security suites provide a comprehensive solution for security which includes key agreement, symmetric encryption with authentication, hash codes, and digital signature. The Transport Layer Security (TLS) specification includes several security suites using different algorithms.

         

        Note that RSA is a full security suite by itself that provides asymmetric encryption and signature. However, the alternatives to using RSA for everything are generally to use one method for key exchange and a different method for signatures.

         

        RSA specified a method for generating key pairs. Rather than using RSA generated key pairs, the alternative is to use the Diffie-Hellman (D-H) key exchange algorithm. This is another algorithm named for the authors - Whitfield Diffie and Martin Hellman.

         

        Diffie-Hellman has some advantages over RSA. However, both RSA and Diffie-Hellman require relatively long keys (2048-bits or more). A variant of the Diffie-Hellman Algorithm using elliptical curve cryptography is Elliptical Curve Diffie-Hellman (ECDH). This key exchange algorithm allows the use of much smaller keys and is well suited for small IoT wireless devices.

         

        The alternatives to using RSA for digital signatures are the Digital Signature Algorithm (DSA) and the variant Elliptical Curve DSA (ECDSA). Again, the elliptical curve variant has the advantage of using a smaller key.

         

        While various combinations are possible, the three passionate solutions are -- use RSA for everything, use DH for key exchange and DSA for signatures, or embrace ECC and use ECDH for key exchange and ESDSA for digital signatures.

         

        Going forward, there is a strong preference for ECDH-ECDSA. Most TLS clients will send a list of security suites in order of preference. The preference for Mozilla Firefox lists ECDH-ECDSA first and RSA as a last resort.

         

        You can check out the Given Cipher Suites supported by your browser using How’s My SSL?

         

        As of this writing, the draft of TLS1.3 does not support using RSA for everything and also deprecates DSA as a signature option. RSA remains as a signature option in combination with DH or ECDH for key exchange.

         

        Diffie-Hellman and Elliptical Curve Diffie-Hellman are favored because they support ephemeral keys and forward secrecy. The Diffie-Hellman algorithm generates a new unique ephemeral key for each key exchange process.

         

        Forward secrecy is a property of a security suite that ensures that if the present key is compromised this does not compromise past session keys. Without forward security, it may be possible to record sessions, then by breaking one key the whole past history is unraveled. 

         

        As proposed, TLS 1.3 will only support ephemeral keys and methods with forward secrecy. DH and ECDH support ephemeral keys and forward secrecy, but RSA does not.

         

        Based on the lower computational requirements of ECC and the desirable properties of Diffie-Hellman key exchange, we predict that IoT products will increasingly use ECDH for key exchange and ECDSA for digital signatures.

         

      • Discover the Industries and Applications Being Driven by Bluetooth

        Lance Looper | 05/147/2016 | 09:17 AM

        Smartphones, wearables, and other connected devices have become indispensable parts of our everyday lives. And the rush to add connectivity to things is giving rise to the adoption of the Bluetooth standard. Specifically, Bluetooth with low energy functionality has become the de facto choice since its introduction as part of the Bluetooth 4.0 core specification release in 2010.

         

        Bluetooth Webinar Banner.png

         

        In that time, we’ve seen the growth of the standard expand as our preference for portable mobile devices has also grown. The Internet of Things that we hear so much about owes its broad adoption to Bluetooth and the advances in low-power computing.  

         

        Join Adnan Nishat, our MCU and Wireless product manager as he explores some of the industries and application areas being driven by Bluetooth. In this webinar we’ll explore some of these industries, from the wearable revolution to its growing popularity beyond our personal space and into industrial automation and home networking.

         

        Date / Time 
        EMEA: Wed, June 8 - 10 AM CEST
        AMER: Thur, June 9 - 10 AM PDT
        APAC Mandarin: Wed June, 22 - 10 AM HKT
        APAC English: Wed, June 22 - 10 AM JST

         

        Bluetooth Webinar CTA.png

      • Busy Bee Gets an Industrial Upgrade

        Lance Looper | 05/146/2016 | 04:19 PM

        Today we announced an expansion to our EFM8 Busy Bee 8-Bit MCUs, our cost-effective and high-performance MCUs for embedded applications. When performance in demanding environments matters, the new EFM8BB3 devices deliver. And they do it in a package as small as 3x3 mm2without compromising performance.

         

        The BB3 family includes new industrial grade (I-grade) devices as well as more memory (64 kB) and additional peripherals including four DACs, four configurable logic units, higher speed ADC, and higher pin count options. An extended temperature range of -40 to +125 °C (ambient) expands the utility of these devices into industrial applications including motor control, lighting, and others.

         

        The BB3 MCUs includes configurable logic module that can be used for a variety of digital functions, such as replacing system glue logic, aiding in the generation of special waveforms, or synchronizing system event triggers. Since the function of the logic is completely programmable, it reduces the challenge of interfacing other chips in the system. It also reduces the cost and board space required for glue logics. This reduces the PCB space and also allows for faster time-to-market.

         

        For applications operating at a wide temperature range, maintaining high performance throughout is important. This eliminates the need for external thermistors to measure temperature and adjust analog trimming coefficient accordingly. There’s also no need for costly and time consuming calibration and trimming based on operating temperature.

         

        As modern designs require smaller packages and wider temperature ranges, the EFM8BB I-grade MCUs offers 2-64 kbyte flash, 0.5-4 kbyte RAM, along with high-resolution 12-bit ADC, high-speed 12-bit DACs, low power comparators, voltage reference, enhanced throughput communication peripherals, and internal oscillators in packages as small as 3x3 mm2. This saves both cost and board space for applications that needs to operate at wide temperature range.

         

        For more information, click here, and to test drive the EFM8 MCU check out our starter kits for evaluation and development.

         

         

         

         

      • Bluetooth in Action Part 5: Build a Bluetooth-Enabled Alarm System

        Lance Looper | 05/146/2016 | 12:42 PM

        Welcome to the fifth part of the “Bluetooth in Action”, a mini-series dedicated to learning about the Blue Gecko Bluetooth Smart Module Wireless Starter Kit, specifically what separates the BGM111 module from the typical setup and how to incorporate it into your Bluetooth setup. After tinkering with some of the demo programs found in the SDK, it’s time to create an application that would be useful in the real world. 

         

        Those of us that frequently travel know how easy it is to “misplace” a bag while trying to navigate through airport terminals. Part five shows James Landbridge creating an alarm system to prevent the loss or theft of an item. In this example, a Bluetooth unit attached to a piece of luggage would connect via BGScript to your cell phone. If the sensor became out of range with the paired phone (causing a broken connection), a loud beeping noise would occur alerting those in the nearby area. This product would be a no brainer for anyone that has ever been in an unfamiliar place with no trace of their personal items.

         

        Luggage Tag.png 

        There are three different programming methods for this Bluetooth module but in this case, since we want to use the BGM111 as a standalone device, we are going to use the BGScript coding language we learned about in part 4.

         

        We hope you’re enjoying these BGM111 module educational videos by James Landbridge. In the next episode, James will show us how to compile and flash our application to properly test it out. Good luck!

         

        Special thanks to blog contributor @NicholasSirris 

      • 20th Anniversary: A Short History of MCUs

        Lance Looper | 05/145/2016 | 06:51 PM

        It's hard to believe that the first microcontroller unit (MCU) became commercially available in 1974. Today, MCUs are integrated into every part of our lives. Virtually every appliance or electronic device in our homes use microcontrollers, and today’s cars use dozens of MCUs.

         

        MCU History 3.png

         

        In 1997, the year after Silicon Labs was founded, the market for MCUs was already robust and growing. That year alone, there were two billion 88-bit MCUs sold worldwide.

         

        Building on early success with our DAA products, Silicon Labs began looking to diversify our products lines. The company decided to enter the multibillion-dollar, 8-bit MCU market in 2003 with the acquisition of Cygnal Integrated Products. By the end of 2004, we had more than 70 MCU products that captured, computed and communicated signals in a single system-on-a-chip (SoC). This provided customers with design flexibility, improved time-to-market and superior system performance. One of the intriguing things about MCUs was the ability to use the same MCU part in a toy or cellular phone – allowing a single product to address multiple new markets.

         

        By 2006, our MCUs achieved an annual growth rate five times that of the industry, primarily due to the broadening of our portfolio, expansion of our sales network, and first-of-a-kind offering that fully integrated a very fast CPU and high-performance analog in an industry-leading footprint.

         

        MCUs continued to fuel growth and in 2013, Silicon Labs acquired Energy Micro, a company that had the industry’s most energy-efficient portfolio of 32-bit microcontrollers (MCUs) based on the industry-leading ARM® Cortex™-M architecture.

         

        Energy-Efficient Innovation

        When the Cortex-M architecture was introduced in 2007, most of the industry was focused on power, in this case, measuring active and sleep current. Yet active and sleep current are measured at two random points in time, not taking into consideration what the application is doing between those two points in time.

         

        Low Energy MCU History.jpg 

        In April 2008, Energy Micro announced that it licensed the ARM Cortex-M3 core – and the team made the decision that their 32-bit MCUs would focus instead on “energy” – the use of power over time (energy = power x time), because they realized that future products and applications would be powered by batteries. Batteries are limited by how much energy they can store, so optimizing the use of that stored energy would be critical. This led to a more whole-system approach that created a whole new style of MCU, the EFM32, which the company launched in 2009.

         

        The EFM32 included a highly efficient CPU that solved things faster, which resulted in much lower energy use. In addition, the peripherals – components surrounding the CPU including memory, input/output (I/O), timers, LCD controllers – were built so that the EFM32 could solve problems and interact with the world without using the CPU. This meant that instead of having the CPU “brain” do all the work, the CPU could sleep and only solve problems when the peripherals had completed their tasks.

         

        After the acquisition of Energy Micro, this energy-efficient technology – now called Gecko Technology – is at the heart of all Silicon Labs’ powerful 32-bit ARM®-based processors. Gecko Technology provides a multitude of benefits including innovative low energy techniques, short wake-up time from energy saving modes, and a wide selection of low-energy peripherals that can operate autonomously. Pearl and Jade, the two newest members of the family, take Gecko Technology to a whole new level by providing more functionality while sleeping and even lower active current.

         

        In addition, Energy Micro built the foundation of what is now known as Simplicity Studio.

        Originally, Simplicity Studio only supported EFM32. It included breakthrough tools that made it possible to measure the energy consumption of your application without any additional tools – an industry first. Today, Simplicity Studio is the development hub for all Silicon Labs MCUs (8- and 32-bit), as well as wireless products. We give customers the ability to scale across all the MCU options and into Wireless development with a single software development platform.

         

        The history of MCUs at Silicon Labs has been an exciting one that continues to break new ground. Energy efficiency, simplicity and connectivity are now an integral part of Silicon Labs strategy, creating smart, battery-operated nodes that empower the growing Internet of Things.

         

      • Chapter 11.4: Control RGB LEDs with an LED Controller Part 4

        lynchtron | 05/144/2016 | 02:18 AM

        In the last section, we built a software driver for the TI TLC5940 LED driver and used it to illuminate some test LEDs.  We also figured out how to debug the driver with the help of the Simplicity Studio tools.  In this section, we will create some data structures to make it easier to work with named colors, and then improve that driver to make use of the DMADRV library.  This library allows us to more easily develop code that invokes the DMA peripheral.

         

        Setting Specific Colors

        We can develop some helper functions to turn on individual colors per LED driver channel and a color mixer to create standard blended colors such as purple. 

         

        typedef struct color_code_bits
        {
              uint8_t red;
              uint8_t green;
              uint8_t blue;
        } color_code_struct;
         
        #define WHITE     { 0xFF, 0xFF, 0xFF }
        #define RED       { 0xFF, 0x00, 0x00 }
        #define GREEN     { 0x00, 0xFF, 0x00 }
        #define BLUE      { 0x00, 0x00, 0xFF }
         
        #define PURPLE    { 0xFF, 0x00, 0xFF }
        #define YELLOW    { 0xFF, 0xFF, 0x00 }
        #define ORANGE    { 0xFF, 0x0F, 0x00 }
         
        // Sets the color in memory but does not write it
        void set_color_buffer(uint8_t led_number, color_code_struct color)
        {
              const uint8_t ch0 = led_number * 3;
              const uint8_t ch1 = ch0 + 1;
              const uint8_t ch2 = ch1 + 1;
         
              // Shift the 8-bit RGB code over by 4 to get to 12 bits of GS
              stream.channel[ch0].grayscale = (uint16_t) (color.red << 4);
              stream.channel[ch1].grayscale = (uint16_t) (color.green << 4);
              stream.channel[ch2].grayscale = (uint16_t) (color.blue << 4);
        }

         

        These functions can then be used to set whatever color codes we want per channel, like purple/yellow/purple:

         

              const color_code_struct purple = PURPLE;
              set_color_buffer(0, purple);
         
              const color_code_struct yellow = YELLOW;
              set_color_buffer(1, yellow);
         
              set_color_buffer(2, purple);
         
              // Now send the stream to the TLC5940
              stream.mode = GRAYSCALE_MODE;             // Now write the GS data
              write_serial_stream();

        This resulted in a nice purple color on the first and third LED, but the yellow LED had a bit of a greenish tint.  Likewise, setting all colors to 0xFF resulted in a blue-ish white.  It seems necessary to compensate for the relative brightness of each color LED in the RGB set to get the blended colors just right.

         

        Introduction to Direct Memory Access (DMA)

        We used DMA in the last chapter with the help of the SPIDRV library, but we didn’t have to program anything in the DMA engine ourselves.  We could use SPIDRV again here, but instead we will learn another way to set up DMA ourselves so that we gain a deeper understanding of how it works.

         

        The DMA peripheral is a highly-configurable tool that moves data from one place to another, and it does so without help from the MCU once the transfer is started.  This allows the MCU to sleep or do other things.  There are multiple channels available to perform multiple transfers between different sources and destinations.  The DMA transfer can be triggered through many sources and generates an interrupt when it is done moving the data. It is a simple mechanism, but it is sometimes difficult to understand and can be harder to debug than sequential programming.  The toughest part is understanding how to set it up.  Fortunately, Silicon Labs has provided a DMA driver called DMADRV.  To use this driver, all you need to do is include the dmadrv.h file at the top of your source code as well as copy the required files from the Simplicity Studio emdrv directory.  See the example in Github here for the required files that I have copied into the project src directory.

         

        The DMA peripheral can also be set up through use of the em_drv library.  There are examples in Application Note AN0013 Direct Memory Access that configure things more manually.  In short, the DMA peripheral looks for something called a descriptor table located in RAM that holds the configuration of the data transfer.  This configures the DMA behavior, along with  the configuration registers that reside inside the DMA peripheral.  All of these things need to be configured, and then the DMA peripheral can do the transfer once its trigger event occurs.  The descriptor table is used by the DMA peripheral at the trigger event to determine how to complete the transfer, including end addresses, address increment size, number of transfers, etc.  When the transfer is complete, the DMA peripheral can be configured to issue an interrupt.

         11_dma_basic_mode.png

         

         There are four modes of operation of the DMA peripheral. DMADRV only simplifies the use of the Basic DMA mode, but does not do too much to help with the other advanced modes.  That is good for this example, since we only need Basic DMA mode for transferring data from our array in RAM to the USART peripheral.

         

        To use the DMADRV, all we need to do is put a bit of code in the beginning of our main program to initialize the DMADRV and let it find an open DMA channel for us.  This is great, because we don’t have to worry about using the same channel that SPIDRV or some other module is already using.

         

        // These variables are global, at the top of the file
        unsigned int dma_channel;
        // Transfer Flag
        volatile bool dma_in_progress;
         
        // The following code is in the main function
              Ecode_t result;
         
              // Initialize DMA.
              result = DMADRV_Init();
              if (result != ECODE_EMDRV_DMADRV_OK)
              {
                    DEBUG_BREAK
              }
         
              // Request a DMA channel.
              result = DMADRV_AllocateChannel( &dma_channel, NULL );
              if (result != ECODE_EMDRV_DMADRV_OK)
              {
                    DEBUG_BREAK
              }

        Now, we have a DMA channel that we can pass into the DMADRV functions.  To make the transfer, we can replace the for loop that we used inside of the write_serial_stream function with the DMADRV_MemoryPeripheral function.  First, we define the callback function that is called when the DMA transfer is complete:

         

        void dma_transfer_complete(unsigned int channel, bool primary, void *user)
        {
              // Clear flag to indicate that transfer is complete
              dma_in_progress = false;
        }

        Next, we have to change a few things inside of the write_serial_stream function to handle the DMA transfer.  If you recall from the previous section, we incremented through the serial_stream array backwards in order to send the most significant byte first on the USART, as the TLC5940 expects to see the data. 

         

              // Now write the stream, MSByte first
              for (int i=length-1; i>=0; i--)
              {
                    USART_Tx(USART1, stream_buffer[i]);
              }

        But we can’t do that with DMA, as it can only iterate through memory in the forward direction.  So we have to fill the serial_stream array backwards instead, and then the direction in which the DMA peripheral fetches the data from memory and pushes it to the USART will be in the correct order.

         

        // This must be global to be used for DMA
        uint8_t stream_buffer[MAX_STREAM_BIT_LEN/8];
         
        void write_serial_stream()
        {
              int length;
         
              // Must pack the bits in backwards for DMA driver
              if (stream.mode == DOT_CORRECTION_MODE)
              {
                    length = DC_STREAM_BIT_LEN / 8;
                    for (int i=0; i < length; i++)
                    {
                          stream_buffer[length-i-1] = pack_dc_byte(i);
                    }
              }
              else
              {
                    length = MAX_STREAM_BIT_LEN/8;
                    for (int i=0; i < length; i++)
                    {
                          stream_buffer[length-i-1] = pack_gs_byte(i);
                    }
              }
         
              // Set/clear the VPRG pin
              if (stream.mode == DOT_CORRECTION_MODE)
              {
                    GPIO_PinOutSet(CONTROL_PORT, VPRG_PIN);
              }
              else
              {
                    GPIO_PinOutClear(CONTROL_PORT, VPRG_PIN);
              }
         
              dma_in_progress = true;
         
              // Start the DMA transfer.
              DMADRV_MemoryPeripheral( dma_channel,
                                               dmadrvPeripheralSignal_USART1_TXBL,
                                               (void*)&(USART1->TXDATA),
                                               stream_buffer,
                                               true,
                                               length,
                                               dmadrvDataSize1,
                                               (void *) dma_transfer_complete,
                                               NULL );
         
              while (dma_in_progress)
                    ; //EMU_EnterEM2(true);
         
              for (volatile int i=0; i < 10000; i++)
                    ;
         
              // Latch the data
              GPIO_PinOutSet(CONTROL_PORT, XLAT_PIN);
              for (volatile int i=0; i < 100; i++)
                          ;
              GPIO_PinOutClear(CONTROL_PORT, XLAT_PIN);
        }

        You can see that we replaced for loop that sent data to the USART within write_serial_stream with the DMADRV_MemoryPeripheral function, which means that the data is flowing from memory to a peripheral.  There is a companion function that goes the other way.

         

        Before the DMA_MemoryPeripheral function, we set a flag for dma_in_progress, and then waited for it to clear before moving on. The flag clear  takes place inside the dma_transfer_complete callback function when the DMA transfer completes.  However, instead of waiting in a while loop for the DMA to finish, we could have let the MCU go work on something else or entered into a sleep state, as long as we take care ahead of time to configure the DMA interrupt to wake the MCU from sleep.

         

        You should notice that the serial_stream array was moved outside of the write_serial_stream function.  It is super important that you make all variables that are referenced by DMA globally persistent. In our example, it makes no difference because we wait for the DMA transfer to finish, but as soon as we remove that blocking logic and allow the system to leave this function, the local variable serial_stream will be reclaimed by the system for other purposes and the data will become mangled.  By making serial_stream global, it is preserved even after the write_serial_stream function exists, when the DMA transfer might still be in progress.

         

        This should have been an easy introduction to DMA transfers.  We will revisit DMA in future chapters to set up more complicated modes and really try to melt your brain. 

         

        This completes the chapter on interfacing with an external LED driver over a non-standard serial stream interface.  By now, you should be well on your way to becoming a competent solderer and getting to know your way around the initialization of a few EFM32 peripherals.  You should also feel like something of an expert in the types and applications of LEDs.

         

         PREVIOUS | NEXT

         

         

         

         

         

      • Bluetooth in Action 4 - Event-Driven BGScript Code

        Lance Looper | 05/141/2016 | 10:47 AM

        In part 3 of the “Bluetooth in Action” mini-series, James Langbridge introduced BGScript: an exclusive scripting language built by Silicon Labs. The strength of this coding language is its ability to communicate protocols to BLE modules without the need for an IAR compiler license or custom C programming.

         

        Part 4 inspects the event-driven BGScript code, its governing “If this, then that” language type, and the corresponding directives, procedures, and parameters set up within. Part 4 also covers additional features, such as how to add comments to relate information to readers about what each part of the code does or is supposed to be doing.

         

        Screen Shot 2016-05-20 at 9.41.12 AM.png

         

        We’ll be using what we learn here to eventually write a real application, so pay extra close attention to these steps.

         

        Special thanks to blog contributor @NicholasSirris