Official Blog of Silicon Labs

    Publish
     
      • Developing Biomedical Devices with Bluetooth

        Nari | 09/274/2016 | 10:04 AM

        silabs990w.jpg

         

        Title: Developing Biomedical Devices with Bluetooth - EMEA

        Date: Wednesday, October 26, 2016

        Time: 10:00 AM Pacific Daylight Time / 10:00 AM Central European Summer Time

        Duration: 1 hour

         

        In a connected world, medical applications must be smart, low-power, and secure. Bluetooth’s complementary features and near-universal adoption make it an important and growing technology in the healthcare industry. In this webinar, we’ll examine how Bluetooth is making medicine easier and more efficient in established use cases like blood glucose monitoring and discuss new medical applications that are enabled by this wireless technology.

         

        Join our hour-long webinar on October 26, 2016 at 10:00 AM and get your questions answered during our Live Q&A session at the end.

         

        original (2).png

      • Sense Makes Everything: Introducing the Thunderboard Sense Inspiration Kit

        Lance Looper | 09/272/2016 | 04:48 PM

        IoT development is happening at a breakneck pace, with consumer demand driving pressure to get connected products to market quickly. But getting into the hands of consumers is only part of the challenge, these products need to work pretty much as-expected. Creating a positive user experience is critical for any emerging technology and IoT is no different. Great products drive demand, and demand drives innovation. Rinse and repeat.

         

        One of our goals is to help developers get to market quickly, but to also make great tools available that demonstrate the speed and effectiveness with which IoT connectivity can be achieved. This is why we’ve created the Thunderboard development platform.

         

        Over the summer we unveiled Thunderboard React, which we designed as a cost-effective prototyping vehicle to demonstrate how easy it can be to connect wireless sensor nodes to mobile devices and the cloud. It featured a battery-powered, sensor-rich demonstration board with a Bluetooth low-energy module based on an ARM Cortex-M4 CPU for IoT connectivity, plus open-source design files and software for mobile applications running on Android and iOS devices.

         
        Thunderboard Sense Lable.png

        Now we’re expanding the platform with the introduction of Thunderboard Sense. This addition to the Thunderboard family blazes new ground with a host of sophisticated sensor technology and support for not only Bluetooth low energy, but ZigBee, Thread and proprietary wireless protocols as well. To complete the picture, Thunderboard Sense is developer friendly.  Connect to Simplicity Studio and proceed to hack away, without any other debug or programming hardware needed.

         

        Once users have the opportunity to work with the embedded and mobile apps that come ready to go out of the box, we think they’ll be inspired to ask “what else can I do?” The logical next step is to incorporate the Thunderboard Sense as-is into an end product to provide device-to-cloud functionality.

         

        Users can also push the boundaries of the device by using the open source hardware design files and software source code to integrate portions of the Thunderboard React into other projects. And by modifying the firmware on the board itself, customers can program the Blue Gecko module using an adapter. 

         

        Thunderboard Sense ships with a revamped mobile app (iOS and Android) so you can demonstrate cloud connected sensors within minutes of taking it out of the box. It also comes with a powerful, multi-protocol EFR32 Mighty Gecko radio, an integrated debugger and is fully supported in Simplicity Studio.

         

        Thunderboard Sense.png

         

        The Sense brings together the best of what Silicon Labs has to offer in a single, easily accessible prototyping kit. The radio and sensors have industry-leading power consumption and the firmware and mobile app have been developed specifically to capitalize on the power saving features of each device.

         

        We can’t wait to see what you do with it! Get Started with Thunderboard Sense here.

         

         

      • Drive a TFT LCD with Capacitive Touchscreen - Part 2

        lynchtron | 09/271/2016 | 11:56 AM

        12_title.png

         

        In the last section, we covered the basics of LCD screen architectures.  In this section, we will connect the Adafruit display to the Wonder Gecko Starter Kit and light up some pixels.

         

        Connecting the Adafruit Display to the Wonder Gecko Starter Kit

        Use wire jumpers to attach all of the connections between the Wonder Gecko Starter Kit and the Adafruit display as shown in the table.  Note that most of the connections should be made on the edge of the board that has the SPI labeling (i.e. MOSI/MISO, etc.) with the two I2C connections on the opposite board edge. 

        12_lcd_pinout.jpg

        12_starter_kit_locations.png 

         

        Signal

        Adafruit LCD Display

        Wonder Gecko GPIO Pin

        LCD Chip Select (CS)

        CS

        PD3 – USART1 CS

        MISO

        MISO

        PD1 – USART1 RX (MISO)

        DC (Data/Command)

        D/C

        PD4 – Chosen at random

        GND

        GND

        GND

        MOSI

        MOSI

        PD0 – USART1 TX (MOSI)

        Clock (CLK)

        CLK

        PD2 – USART1 CLK

        Vcc

        3-5V

        V3V

        Reset

        RST

        PD5 – Chosen at random

        I2C SDA

        SDA [ Capacitive Touchscreen]

        PD7 – I2C0 SDA

        I2C SCL

        SCL [ Capacitive Touchscreen]

        PD6 – I2C0 SCL

        I2C Interrupt

        IRQ [ Capacitive Touchscreen]

        PD13 – Chosen at random

        MicroSD Chip Select (CS)

        Card CS

        PD8 – Chosen at random

         

        The application note for the display from Adafruit instructs us to close the IM1, IM2, and IM3 solder jumpers on the back of the display board in order to use the SPI interface, so warm up your soldering iron and make those connections.  This will also allow us to communicate to the MicroSD card built into the display.

        12_solder_shorts.png

        When you make these connections to the Starter Kit, the backlight to the display will automatically light up.  This is because the Adafruit board is built to give full brightness by default.  To turn off the backlight, you set the backlight pin to ground.  You can dim the display by applying a PWM pulse (with open-drain output) to the backlight pin. 

         

        Configuring the Display

        The Adafruit display is a board comprised of multiple devices bundled together on the same board.  We have worked with the fundamental communication methods already in previous chapters, and this will just be an exercise of learning how to deal with several devices at once in the same firmware.  We will communicate with the LCD and the MicroSD card over the same SPI bus (selecting each device independently with their own Chip Select (CS) signal. 

         

        We could make use of the Configurator tool in Simplicity Studio to find suitable pins for the SPI and I2C interfaces, and it would automatically generate code for our project.  We will instead set things up manually to help you get practice in learning how it is done.

         

        Remember, as we learned in chapter 11, the order in which to initialize the MCU to communicate with external devices follows a particular order:

        • Enable the GPIO clock
        • Enable the peripheral clocks (i.e. USART1 and SPI0)
        • Configure and enable the peripheral
        • Route the pins used by the peripheral through to the GPIO
        • Configure the pins used by the peripheral in the GPIO (push-pull, input, etc.)

        If you do the above in the wrong order, you can see glitches on the output which could confuse your external devices.  By following this order (and not forgetting a step!) we can ensure that the peripherals will be configured and external devices ready to be controlled.

         

        By following these steps, I created a peripheral_setup() function to do all of the above:

         

        void peripheral_setup()
        {
              // Set up the necessary peripheral clocks
              CMU_ClockEnable(cmuClock_GPIO, true);
              CMU_ClockEnable(cmuClock_USART1, true);
              CMU_ClockEnable(cmuClock_I2C0, true);
         
              // Initialize and enable the USART
              USART_InitSync_TypeDef init = USART_INITSYNC_DEFAULT;
              init.msbf = true;
         
              USART_InitSync(USART1, &init);
         
              USART1->CTRL |= USART_CTRL_AUTOCS;
         
              // Connect the USART signals to the GPIO peripheral
              USART1->ROUTE = USART_ROUTE_RXPEN | USART_ROUTE_TXPEN |
                          USART_ROUTE_CLKPEN | USART_ROUTE_CSPEN |
                          USART_ROUTE_LOCATION_LOC1;
         
              // Set up i2c
              I2C_Init_TypeDef i2c_init = I2C_INIT_DEFAULT;
              I2C_Init(I2C0, &i2c_init);
         
              /* Module I2C0 is configured to location 1 */
              I2C0->ROUTE = (I2C0->ROUTE & ~_I2C_ROUTE_LOCATION_MASK) |
                                           I2C_ROUTE_LOCATION_LOC1;
         
              /* Enable signals SCL, SDA */
              I2C0->ROUTE |= I2C_ROUTE_SCLPEN | I2C_ROUTE_SDAPEN;
         
              // Enable the GPIO pins for the USART, starting with CS
              // This is to avoid clocking the flash chip when we set CLK high
              GPIO_PinModeSet(gpioPortD, 3, gpioModePushPull, 1);         // CS
              GPIO_PinModeSet(gpioPortD, 8, gpioModePushPull, 1);         // MicroSD CS
              GPIO_PinModeSet(gpioPortD, 0, gpioModePushPull, 0);         // MOSI
              GPIO_PinModeSet(gpioPortD, 1, gpioModeInput, 0);         // MISO
              GPIO_PinModeSet(gpioPortD, 2, gpioModePushPull, 1);         // CLK
         
              // Enable the GPIO pins for the misc signals, leave pulled high
              GPIO_PinModeSet(gpioPortD, 4, gpioModePushPull, 1);         // DC
              GPIO_PinModeSet(gpioPortD, 5, gpioModePushPull, 1);         // RST
         
              // Enable the GPIO pins for the i2c signals, open drain, pulled up, with filter
              GPIO_PinModeSet(gpioPortD, 6, gpioModeWiredAndPullUpFilter, 1);         // SDA
              GPIO_PinModeSet(gpioPortD, 7, gpioModeWiredAndPullUpFilter, 1);         // SCL
              GPIO_PinModeSet(gpioPortD, 13, gpioModeInput, 1);                              // IRQ
         
        }

         

        In this initialization code for the USART, we are going to let the USART control the chip select (CS) signal for the LCD.  This requires that we set the AUTOCS flag in the USART peripheral with the code:

         

        USART1->CTRL |= USART_CTRL_AUTOCS;

        We also must route the CS pin through to the GPIO with the ROUTE statement that follows it.  This will only work up until the point where we start to control the MicroSD card on the same SPI bus, since the USART cannot automatically control multiple chip selects at a time.  But for our initial work with just the ILI9341 controller active on the SPI bus, we can let the USART control the CS signal.

         

        Now, we are ready to start sending some cycles over SPI to configure the LCD for our first try at generating some graphics.

         

        Activating Pixels

        The LCD is controlled by the ILI9341 display driver chip built into the display panel.  The ILI9341.pdf datasheet details the component package, pinout, electrical ratings, interface procedures, and provides a comprehensive guide of the different commands that the controller accepts.  However, it is very frustrating that there is no “big picture” overview or even a guide detailing how to turn the display on from a power-off state, and no examples of how to use it.  I had to scour the internet to find some examples, and even then, the examples didn’t always explain why they were doing what they were doing to initialize the display, as well as referencing registers that are not found in the datasheet.  It is at times like these that working as an embedded developer feels more like a hacker and less like a software engineer!

         

        Through my research, and some trial and error, I was able to initialize the display with just the following code.

        #include "em_device.h"
        #include "em_chip.h"
        #include "em_usart.h"
        #include "em_cmu.h"
        #include "utilities.h" 
             
        #define ILI9341_SLPOUT  0x11
        #define ILI9341_DISPON  0x29
         
        void writecommand(uint8_t command)
        {
              delay(1);
              GPIO_PinOutClear(gpioPortD, 4);
              USART_Tx(USART1, command);
              delay(1);
        }
         
        void writedata(uint8_t data)
        {
              GPIO_PinOutSet(gpioPortD, 4);
              USART_Tx(USART1, data);
        }
        int main(void)
        {
              /* Chip errata */
              CHIP_Init();
         
              if (SysTick_Config(CMU_ClockFreqGet(cmuClock_CORE) / 1000))
              {
                    DEBUG_BREAK;
              }
         
              peripheral_setup();
         
              // Reset the display driver chip
              GPIO_PinOutSet(gpioPortD, 5);
              GPIO_PinOutClear(gpioPortD, 5);
              delay(1);
              GPIO_PinOutSet(gpioPortD, 5);
         
              delay(10);
              writecommand(ILI9341_SLPOUT);    //Exit Sleep
              delay(120);
              writecommand(ILI9341_DISPON);    //Display on
              while (1) {
              }
        }

         

         

        When this code is executed, the display will go dark after it executes the ILI9341_DISPON command.  This makes sense, because when the display is in the “off” state, the pixel grid allows the backlight to pass, but when the display driver chip turns on, all of the pixels are instructed to not allow any light to pass, causing the display to go dark, or mostly dark.  If you look carefully at the screen, you can see that the backlight is still powered behind the blocking pixels.  This confirms that we can communicate with the ILI9341 in the most basic of commands.

        12_lcd_states.png

        When you examine the writedata() and writecommand() functions, you will see the code implements the procedure that is detailed in the ILI9341 specification for SPI writes and reads:

        12_ili_spec.png

        The only detail that separates “command” packets from “data” packets is the D/CX signal, which we have connected to PD4.  If it is low, the packet is seen as a command.  If D/CX is high, the packet is seen as a data packet, or as any necessary parameter(s) that immediately follows a command packet.

         

        The spec shows that pauses between commands and data/parameters (or successive data packets) are acceptable, so we don’t have to worry about keeping the CS signal low for the entire command/data operation.  In order to make sure that there is some delay between multiple commands and command/data packets, a delay of 1ms is added before and after each USART_Tx() call in the writecommand() function.  This will not degrade our screen display performance later on, because the command packet is only sent one time, which is then followed by thousands of data packets necessary to form an image on the display screen.

         

        With the screen alive and ready to display some pixels, we can turn them all on to a specific color after a few more configuration commands, which are each accomplished with a command byte followed by a configuration data byte.  After those are set, the memory write command is issued, followed by the color data for all of the pixels in the screen.

         

        #define ILI9341_TFTWIDTH  240
        #define ILI9341_TFTHEIGHT 320
        #define ILI9341_RAMWR     0x2C
        #define ILI9341_MADCTL  0x36
        #define ILI9341_PIXFMT  0x3A
              writecommand(ILI9341_PIXFMT);     // Pixel format       writedata(0x55);                   // This sets up 16-byte color data, instead of default 18-bit color data         writecommand(ILI9341_MADCTL);    // Memory Access Control       writedata(0x48);              // This configures the screen orientation         uint16_t color = ILI9341_RED;         writecommand(ILI9341_RAMWR);              //Memory write         for (int i = 0; i < (ILI9341_TFTWIDTH); i++)       {             for (int j = 0; j < ILI9341_TFTHEIGHT; j++)             {                   writedata( color >> 8);                   writedata( color );             }       }

         

        With this code placed just before the while loop in main(), the screen will slowly be painted red.  It should take about four seconds to send all of those 76,800 x 2 = 153,600 SPI cycles to be written at the default 1 MHz USART interface speed. 

         

        12_red_background.jpg

        This works because the ILI9341 knows the width and height of the screen, so every Memory Write command advances the ILI9341’s pointer into the frame buffer by one pixel.  When it gets to the end of a row, it starts on the next row, until the whole screen is painted red.  At the present speed of the SPI bus, you can actually see that happening in real time.

         

        Speeding up the SPI Bus Rate

        If the fastest frame rate were critical to our application and we required several images refreshed in every second, we would have used the parallel interface, which allows up to 18 data bits to be sent to the ILI9371 at once instead of the single bit per clock with the SPI bus.  However, we can speed up the rate of the SPI bus to improve performance by changing the MCU clock configuration.

         

        If you add the following line of code to the peripheral_setup() function, just after the USART_InitSync() call, you will be able to read the clock rate of the SPI bus:

        uint32_t baud = USART_BaudrateGet(USART1);

        You should see that the clock is initially set at 1000000, or 1MHz.  To get the fastest possible USART clock, we need to clock the MCU with the crystal oscillator with the following line of code:

        CMU_ClockSelectSet(cmuClock_HF, cmuSelect_HFXO);

        This will increase the clock rate of the core to 48 MHz, and the High Frequency (HF) clock will increase to 24 MHz, which is the fastest that the USART can operate on the Wonder Gecko MCU.  But the default SPI rate is still set to 1 MHz due to the use of USART_INITSYNC_DEFAULT during the USART initialization.  You can change that to 24 MHz with the following line of code before you call USART_InitSync():

         

        init.baudrate = 24000000; 

        Now, when you run this and check the baud rate variable again, you will see 24000000, or 24 MHz.  Beware that you cannot always get the baud rate that you request.  Always check the baud rate using the USART_BaudrateGet() call to see if you are requesting a valid and reachable clock divisor.

         

        With the SPI bus set to 24 MHz, your screen should display all red pixels in about one second.  This is still very slow and perhaps could be improved more through the use of DMA and a memory buffer, but this is good enough for the work of this chapter. 

         

        TIP: If you are wondering about all of the available commands for peripherals such as CMU and USART, for example the CMU_ClockSelectSet() function or the USART_BaudRateGet() function, you can use the Software Documentation reference available from the home screen of Simplicity Studio.  Click on that tile, and a browser will open which you can use to explore all of the possible library calls in emlib, with hyperlinks to the types of parameters that each function expects as well.

        12_sw_api.png

         

        12_sw_api_detail.png

        It should be easier to find what you are looking for in the Software Documentation than in any number of chapters of this text or looking back through all of the examples that you have ever studied.

        As a reminder, the final, complete source code for all examples in this book can be found on Github here.

         

        In the next section, we will put a crude graphic library in place to handle displaying some standard graphic primitives like lines, rectangles, and text.

         

         PREVIOUS | NEXT

      • September 2016 Member Spotlight: spiritonline

        Nari | 09/271/2016 | 09:16 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 September member of the month: spiritonline

        profile.png

         

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

         

        I'm based in the Netherlands, Alkmaar. I'm a schooled Interaction designer but I love to bring vision to live, that includes engineering.
        While not my strongsuit (yet) I try to learn something new every day.

         

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

         

        My start-up previously worked with Bluegiga which then got acquired by Silicon Labs. 

         

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

         

        I'm in desperate need for an edit button to forum posts!

         

        Q: What advice would you give to someone new to the community?

         

        The community or @JaakkoV will always get back to you, no matter how stupid you might think your question is.

         

        Q: Thanks for answering the questions. Any final comment?

         

        Thanks @JaakkoV for the ever lasting support Robot Happy

      • Connected Lighting Design Simplified

        WYALLEN | 09/270/2016 | 04:00 PM

        There’s a legend about Thomas Edison being asked about the 10,000 experiments he did leading up to his first working light bulb. As the story goes, he answered with, “I have not failed. I've just found 10,000 ways that won't work.” It’s been 137 years since the first successful light bulb test, and for most of that time the electric light has not changed as dramatically as other century-old technology. That is until recently with the Internet age ushering lighting into new territory. According to IHS report, more than 92 million wireless lights will ship this year, and that number is expected to swell to more than 243 million by 2020.

         

        Lighting.png

         

        The benefits of connected lighting are growing all the time, from cost savings and convenience to data analytics and even health and wellness, and these gains are driving adoption in commercial and industrial markets. Added to the cost benefits, the convenience of being able to control and monitor lighting is attractive. Developers in this industry are facing two external pressures. First, cost targets for this market are excruciatingly low. Second, virtually everyone knows how a light bulb should behave; flip a switch and it turns on or off. It’s simple and instantaneous. Anything that enters the market, therefore, needs to reliably work every time and in a manner consistent with the expectations built up over more than a hundred years of user experience.

         

        Delivering on these two vectors depends on being able to deal with complex hardware, firmware, and software design. While a lighting manufacturer has expertise in lighting enclosures and power electronics, bringing the necessary wireless expertise to bear on these designs can be tricky.

         

        This is why we’ve developed the Connected Lighting Reference Designs; to simplify development and provide a solution that optimizes cost and performance. The latest Connected Lighting Reference Design provides a wireless lighting solution in the industry’s smallest wireless module package and takes advantage of the latest EFR32MG chipset for multi-protocol future.

         

        Screen Shot 2016-09-21 at 2.39.07 PM.png

         

         

        In addition to being based on our proven hardware, this reference design includes the ZigBee stack, backed by years of development and testing. The multi-board kit also makes it possible for engineers to develop in the latest Simplicity Studio tools and WSTK, and then test and verify their design while the wireless module is actually inside the real-life bulb.  

         

        The latest Silicon Labs Connected Lighting Reference Design (RD-0085-0401) includes:

        • Complete kit with lighting module, interposer, and development board
        • Flexible architecture to plug into WSTK development platform
        • FCC/CE pre-certified lighting module hardware
        • ZigBee HA 1.2 pre-certified reference firmware
        • Over-the-air upgradeability (Thread support in the future)
        • Single EFR32MG SoC with ARM® Cortex®-M4 microcontroller and 802.15.4 radio
        • Integrated PA to support up to +20dBm, integrated balun to reduce total BOM cost
        • Industry leading performance (+125°C operation, network scalable to 250 nodes)
        • Simplicity Studio design environment with AppBuilder support to simplify software design

         

        Get Started with the latest Connected Lighting Reference Design

         

         

      • 3 Things to Know when Choosing a Software Framework

        Lance Looper | 09/267/2016 | 11:26 AM

        If it hasn’t happened to you already, it’s just a matter of time before you come to the conclusion that an idea you’ve been working is worth taking to the next level. You might want to bring an idea to market, or simply lay the groundwork for further exploration. One of the questions you’ll need to answer is which software framework to start from.

         

        Making a solid decision for your MCU or wireless MCU project can make the difference between coming in on-time and on-budget, or putting your investment at risk. Here are three things to keep in mind.

         

         SIL-230-R2-White-Paper-Illustrations.png

         

        What is a Software Framework?

        What you really want to write is the code that runs your special sauce, the code that differentiates your product from the rest, which is where an operating system can be useful. This makes it possible to rely on other pieces of software, like drivers for the ADC or a file system stack for the SD-card. These pieces of software are generally referred to as software components. The operating system defines the components interact with each other. Choose wisely and as you add more components to the software, they’ll continue to work well together.

         

        The scheduler is another important component because it’s what allocates resources and processing time for different tasks that might be competing for the same resources. In general, there are two ways a scheduler can work, and this is where the ‘RT’ in real-time operating system (RTOS) comes in. Real-time means there is a consistent time that a certain task will take to execute. Let’s say you get a radio package that you need to take care of no matter what your device is currently doing. An RTOS kernel will then leave the other tasks it is doing and complete this high-priority task instead.

         

        Commercial or Open Source?

        Once you’ve landed on whether or not an RTOS is needed, you’ll start to assemble the software requirements. Should you simply download the latest FreeRTOS example for your preferred MCU and continue to download open-source software to plug into it or go to a commercial vendor that has the software you need and acquire the full portfolio?

         

        This is where total cost of ownership (TCO) comes into play. The TCO is not only the monetary value you pay for software but includes the work hours spent searching for solutions, assembling the different components, integrating the different components into your project as well as development, testing, and production. Naturally, the TCO is generally lower with a commercial solution than a custom-built solution. But commercial solutions do come with an initial cost.

         

        What are the Choices?

        Frameworks like mbed and microPython are a good way of getting started if you want to get down to device development without installing a single program. However, if you’re going to create bigger deployments, a pure RTOS would be a better option. Non-commercial solutions like FreeRTOS or RIOT have the edge if it’s easier for your company to do the software investment using work hours rather than money.

         

        If the up-front investment is manageable, commercial solutions like Segger, Express Logic, and Micrium would greatly reduce your software development risk and time-to-market.

         

        For more information, read the whitepaper, “Choosing the Right Software Framework."

         

         

      • Enhancing Power Delivery Systems with CMOS ISOdrivers

        Lance Looper | 09/266/2016 | 10:00 AM

        Green standards are challenging power designers to deliver more energy-efficient, cost-effective, smaller, and more reliable power delivery systems. A critical building block within ac-dc and isolated dc-dc power supplies is the isolated gate driver. These trends push the need for greater power efficiency and increased isolation-device integration.

         

        Optocoupler-based solutions and gate-drive transformers have been the mainstay for switch-mode power supply (SMPS) systems for many years, but fully integrated isolated gate driver products based on RF technology and mainstream CMOS provide more reliable, smaller, and power-efficient solutions.

         

        Anatomy of an Isolated Power Converter

        Isolated power converters require power stage and signal isolation to comply with safety standards. The example below shows a typical ac-dc converter for 500 W to 5 kW power systems, such as those used in high- efficiency data center power supplies.

         

        From a high-level perspective, this two-stage system has a power factor correction (PFC) circuit that forces power system ac line current draw to be sinusoidal and in-phase with the ac line voltage; thus, it appears to the line as a purely resistive load for greater input power efficiency.

         

        ISO Power Converter.png

         

        The high-side switch driver inputs above are referenced to the primary-side ground, and its outputs are referenced to the high-side MOSFET source pins. The high-side drivers must be able to withstand the 400 VDC common-mode voltage present at the source pin during high-side drive, a need traditionally served by high- voltage drivers (HVIC).

         

        The corresponding low-side drivers operate from a low voltage supply (e.g., 18 V) and are referenced to the primary-side ground. The two ac current sensors in the low-side legs of the bridge monitor the current in each leg to facilitate flux balancing when voltage mode control is used. The isolation barrier is provided to ensure that there is no current flow between the primary- and secondary-side grounds; consequently, the drivers for synchronous MOSFETs Q5 and Q6 must be isolated.

         

        The secondary-side feedback path must also be isolated for the same reason.

         

         

        Gate Driver Solutions

        Optocouplers

        Although optocouplers are commonly used for feedback isolation, their propagation delay performance is not fast enough to achieve the full benefit of the synchronous MOSFET gate-drive isolation circuit.

        Optocouplers with faster delay-time specifications are available, but they tend to be expensive while still exhibiting some of the same performance and reliability issues found in lower-cost optocouplers. This includes unstable operating characteristics over temperature, device aging, and marginal common mode transient current (CMTI) resulting from a single-ended architecture with high internal coupling capacitance. In addition, Gallium Arsenide- based process technologies common in optocouplers create an intrinsic wear-out mechanism (“Light Output” or LOP) that causes the LED to lose brightness over time.

         

        Gate Drive Transformers

        Given the above considerations, gate drive transformers have become a more popular method of providing isolated gate drive. Gate drive transformers are miniature toroidal transformers that are preferred over optocouplers because of their shorter delay times. They are faster than optocouplers, but cannot propagate a dc level or low-frequency ac signal. They can pass only a finite voltage-time product across the isolation boundary, thereby restricting ON time (tON) and duty cycle ranges.

         

        These transformers must also be reset after each ON cycle to prevent core saturation, necessitating external circuitry. Finally, transformer-based designs are inefficient, have high EMI, and occupy excessive board space.

         

        CMOS-based Isolated Gate Drivers

        Fortunately, better alternatives to gate drive transformers and optocouplers are now available. Advancements in CMOS-based isolation technology have enabled isolated gate drive solutions that offer exceptional performance, power efficiency, integration, and reliability. Isolated gate drivers, such as Silicon Labs’ Si823x ISOdriver family, combine isolation technology with gate driver circuits, providing integrated, low-latency isolated driver solutions for MOSFET and insulated-gate bipolar transistor (IGBT) applications.

         

        The Si823x ISOdriver products are available in three basic configurations (see Figure 2), including:

        • high-side and low-side isolated drivers with separate control inputs for each output
        • high-side and low-side isolated drivers with a single PWM input
        • dual isolated driver

         

        The Si823x ISOdriver family supports 0.5 A and 4.0 A peak output drive options and is available in 1 kV, 2.5 kV, and 5 kV isolation ratings. The high-side/low-side versions have built-in overlap protection and an adjustable dead time generator (dual ISOdriver versions contain no overlap protection or dead time generator). As such, the dual ISOdriver can be used as a dual low-side, dual high-side or high-side/low-side isolated driver.

         

        These devices have a three-die architecture that causes each drive channel to be isolated from the others as well as from the input side. This allows the polarity of the high-side and low-side channel to reverse without latch-up or other damage.

         

        Driver Family.png

         

         

        Read the Whitepaper

        To learn more about how isolated gate drivers can significantly increase the efficiency, performance, and reliability of switch-mode power supplies compared to legacy solutions, check out this whitepaper. 

        Whitepaper Screen.png

      • Simplifying Universal Serial Bus Connectivity with USB Bridge Devices

        Lance Looper | 09/265/2016 | 10:00 AM

        The universal serial bus (USB) interface is one of the most successful communication standards in the electronics industry. It has become the standard communication interface for many industrial and consumer applications that require connectivity to a host device. USB’s extreme ease of use coupled with robustness makes it the ideal choice of interface for many embedded applications.

         

        However, for embedded designers, a USB implementation requires USB protocol expertise, time-consuming software and firmware development effort. Most often, designers of these embedded applications are required to provide an end solution that is highly cost effective. The simplest way to achieve this is by integrating the USB functionality in the microcontroller (MCU) along with other peripherals and memory. Many MCU vendors today offer USB-based microcontrollers; however, they may not offer the right peripheral set required for an application, resulting in the need for external components and increased design complexity.

         

        There’s also a no-hassle approach for adding USB to any embedded solution, with no need for USB expertise or firmware development, enabling faster times to market for designers.

         

        USB Design Challenges:

        The ease of use and robustness of USB do not come for free for embedded designers. Developers often have to spend significant time learning the USB protocol and developing a USB stack. This requires specialized tools and can increase development costs and time. There are commercially available USB software stacks; however, they result in additional costs and learning effort.

         

        Another important USB design challenge is the fact that the final product must be compatible with several common operating systems (OS) and keep up with constant OS updates. Developers also must keep the USB hardware costs to a minimum to provide a cost-effective final product. Many USB ICs require external components such as termination resistors or precision oscillators to provide USB functionality. Highly integrated USB solutions with advanced software and tools support are the cornerstone to simplifying USB design.

         

        A Practical Fix: Turnkey USB Connectivity Solutions

        Turnkey USB solutions, such as Silicon Labs’ USBXpress bridge devices, provide high integration to eliminate the need for complex firmware and driver development. USB devices with advanced tools support also reduce development time, further simplifying USB connectivity. Highly integrated USB bridge devices can be added to virtually any MCU-based solution to eliminate firmware complexity and reduce development time. These devices act as a bridge to the USB world through the use of standard UART, SPI or I2C interfaces that are readily available on most MCUs.

         

        Bridge devices are especially helpful when developers are upgrading a legacy system with USB communications. Most legacy designs have a specific means of communicating with the host system, in many cases through a UART or I2C interface. A USB-to-UART or USB-to-I2C bridge device, shown below, is the best option in this case.

         

        USB-to-UART_diagram.png

        Typical USB-to-UART Bridge

         

        Choosing the Right USB Bridge for Your Application

        Embedded designers should consider a multitude of factors when choosing a USB bridge device to ensure seamless USB integration.

         

        First, it is important to minimize hardware design cost that can easily impact an allotted budget. Most USB bridges or MCUs require external components, such as crystal oscillators or termination resistors for USB functionality. Choosing a highly integrated bridge device can eliminate the need for external components, thereby reducing hardware design time and cost.

         

        For a full-speed function, the USB device requires a 48 MHz clock input. Choosing a USB device with an internal clock that can generate a 48 MHz clock eliminates the need for an external crystal. Another important feature to look for is the clock recovery circuitry. The USB specification requires the internal clock to be highly accurate. However, most often, the frequency accuracy of the internal oscillators can vary. The clock recovery circuitry uses the incoming USB data stream to adjust the internal oscillator, and it allows the internal oscillator to meet the requirements for USB clock tolerance. Devices that use this novel clock recovery system reduce costs by eliminating the need for an external crystal oscillator.

         

        One of the major advantages of adding USB to embedded applications is the ability to power devices. Battery-powered devices can maximize the battery life when the USB device is bus-powered while connected to the host. This requires a low drop-out (LDO) or voltage regulator to drop the voltage from 5 V (host) to 3.3 V. It is also essential to use a USB function controller with an integrated transceiver and on-chip matching and pull-up resistors. The integration of the termination resistors for proper USB line termination and a 5 V regulator for direct USB connection further reduces the size of the printed circuit board (PCB).

         

        VREG.png

        Eliminate external crystal, regulator and memory with highly integrated USB bridges.

         

        Additionally, USB bridges offering GPIO control capability and clock output functions add flexibility to designs and shorten development times. Another attractive feature to consider in bridge devices is the flexibility to support multiple baud rates to fit a wide range of applications.

         

        Some modern USB bridge devices also offer advanced features to further conserve the PCB area. For example, the CP2102N device from Silicon Labs includes an integrated battery charger detection feature that detects the type of charger connected and a remote wake-up feature to wake up a suspended host. Inclusion of such advanced features on-chip not only enhances flexibility for embedded designs but also saves overall system cost.

         

        Finally, designers must minimize USB space to meet the form factor and ergonomic requirements of space-sensitive portable applications. In addition, some legacy applications may require keeping the same physical dimensions while upgrading the application to include USB connectivity. Choosing USB bridges that offer small package variants helps overcome this constraint by reducing the PCB footprint and enabling the designer to squeeze a solution into a space smaller than an RS-232 connector.

         

        USB_UART.png

        Example of a 3 mm x 3 mm USB bridge IC and complete solution in a small PCB.

         

        Accelerated USB Development with Advanced Tools

        High integration is a critical factor that determines the selection of a USB bridge to reduce costs and hardware design time, but also equally important is the software and tool set in making the right bridge choice. Consumers view USB as the perfect plug-and-play interface. While it is true that USB looks as simple as other serial interfaces such as UART, SPI or I2C, the USB protocol is not simple to implement. This hidden complexity of USB protocol and firmware development for designers can be solved by using turnkey fixed-function USB bridge devices. These devices allow designers to develop USB systems without the need for extensive USB expertise or firmware development.

         

        While there is no code development required when using fixed-function devices, designers are still looking for several configuration options to suit their designs or to differentiate their designs in the market. Each USB bridge device has many user-configurable options that determine the device’s behavior, ranging from how the device will appear to the host machine to specialized device options such as interface and pin configurations. Therefore, it is essential to make sure that the selected USB bridge devices offer advanced tools that provide configuration options and allow easy customization to differentiate the end products.

         

        The Xpress configurator from Silicon Labs is an example of a tool designed to simplify USB configuration. The intuitive GUI-based configurator allows easy customization and programming of USB fixed-function devices. Common USB attributes such as Vendor ID (VID), Product ID (PID), device strings and USB power modes can be configured easily using the GUI. Advanced features such as GPIOs, interface options and modem signals can also be configured with just a few clicks. Additionally, having a problems/warnings view in the GUI guides developers toward the settings for each USB attribute and provides a more risk-free environment for USB customization. The final desired configuration can be programmed using a single button to use turnkey devices without writing any code.

         

        Most often, developers do not have the right tool set for programming thousands of PCBs and devices with the final configurations. In such cases, it is extremely useful to select USB device vendors that offer factory programming to save significant development times for the developers.

         

        USB_simplified_screen.png

        Example of an advanced tool GUI for USB bridge configuration.

         

        Software Drivers

        A USB device is expected to work seamlessly across all operating systems. To achieve this goal, developers must create host drivers, which is not a trivial task. USB driver development requires expertise and significant testing for the best operation. It is essential to choose USB devices that offer robust certified drivers for seamless USB connectivity in systems. Some vendors offer Virtual COM Port (VCP) device drivers that allow the devices to appear as a COM port to the PC’s application software. This is especially useful when trying to update legacy serial devices with USB. With the VCP drivers, the PC software recognizes the device as a COM port, and hence existing COM port applications may be used to transfer data via USB without actually modifying the application.

         

        To further simplify and enhance plug-and-play capabilities for designers, a few USB device vendors offer innovative, fully-compliant USB-HID bridges. These devices support the USB-HID class that is natively supported by most operating systems, thereby eliminating the need for driver installation or development. The most common examples of HID-USB devices are computer keyboards and mice, and the HID-USB class is also flexible enough to accommodate many different kinds of USB designs.

         

         USB_UART_Callout.png

        Virtual COM Port USB bridge recognized as a COM port in the device manager.

         

        Conclusion

        USB bridges and turnkey USB solutions provide an easy and economical approach to add USB connectivity to new or existing non-USB systems. Their high integration reduces PCB size and BOM costs, making them ideal for space-constrained and cost-sensitive applications. Their simplicity and turnkey nature eliminate the need for USB expertise or firmware development, enabling designers to get their end products to the market faster. Advanced USB configuration tools and robust certified driver packages allow developers to differentiate their applications and provide seamless compatibility with most operating systems. It is essential to make USB easy for not only consumers but also for designers, and choosing the right USB bridge device will take the hassle out of adding USB connectivity to your next embedded design.

         

        This blog was previously published on Embedded.com. 

      • Drive a TFT LCD with Capacitive Touchscreen - Part 1

        lynchtron | 09/258/2016 | 10:16 AM

        12_title.png

         

        In chapter 7,  we made use of the segmented LCD display on the Wonder Gecko Starter Kit through the use of a pre-built LCD library and driver when designing the user interface for the sprinkler timer.  That made things easy for us, and we didn’t really need to dwell on how the driver worked.  In this chapter, we will dig into some of those details so that we can connect the EFM32 to any kind of display we choose.

         

        The display we will be using for this chapter is the Adafruit 2.8” 240x320 TFT LCD Capacitive Touch screen, shown below.  We will interface with it over SPI for transferring image data and I2C for reading the touch interface.  We will learn how to interface with it with our own drivers and build our own simple graphics libraries, as well.

         

        12_display.png

         Materials Needed for this Chapter:

         

        Types of Displays

        Segmented Display: We have already worked with the segmented LCD display in chapter 7, also known as a character display.  In such a display, there are a fixed matrix of LCD segments that are preconfigured in hardware to convey specific information.  They are not flexible enough to display an image, but they don’t require many pins on the MCU and are easier to program.  For example, the number “9” can be formed on such a display with as few as 6 signals.

          12_type_of_displays.png

         

        Graphics Display: A graphics display has a matrix of pixels, each of which are individually addressable.  Therefore, in order to display the number “9”, it can require many more pixels than the segmented display.  The benefit of a graphic display is that the letter “9” can be in any font we choose, and better yet, we can display any shapes we choose.  The drawback to a graphical display is that it takes an enormous number of signals to drive all of those pixels.  For the display used in this chapter, which has a resolution of 240 pixels wide by 320 pixels tall, there are 76,800 individually-addressable pixels, and each of those are made up of red, green, and blue components for each pixel. 

         

        In order to cut down on the number of signals required to drive such a display, each pixel is driven one at a time in a column-and-row scan technique.  This scanning only requires 240 + 320 wires for our chosen display, which are toggled on or off many times per second, even for a static image.  The pixels do not hold their color information for very long, and therefore they require periodic refreshes.

         12_grid.png

         

        Note that a new “Memory LCD” described in Silicon Labs application note AN0048 couples a memory device within each pixel so that constant refreshing is not necessary, reducing power consumption as well.

         

        Graphical display screens have many different technologies, from passive-matrix Liquid Crystal Display (LCD) or active-matrix Thin Film Transistor (TFT) LCD, Light Emitting Diode (LED), or  Organic LED (OLED).  Display technology is not the focus of this chapter.  No matter which technology you choose, you will still need to understand the topics of this chapter in order to display your images.

         

        Components of a Display


        A display is a layered device, with each part customizable by the manufacturer.  The display is constructed on top of a circuit board which houses the connector and any controller chips that are necessary.  The backlight is located on top of the circuit board, with the pixel matrix sitting on top of the backlight.  The touch sensor is optional and is located at the top of the stackup.

         

        12_display_construction.png

        LCD Pixel Matrix

        The LCD pixel matrix is the heart of the display.  This part is responsible for displaying the image and, in the case of LCD displays, it will either allow or prevent light from a backlight to pass through.  In the case of LED displays, the pixel matrix produces the light and forms the image in one step.  No matter the process, the pixel matrix is comprised of an array of pixels in height and width of a certain color depth that make up the display.  For the display used in this chapter, the color depth is 18 bits, consisting of 6 bits each for the red/blue/green components of a pixel.  That means that the information required to paint the screen one time is 240 bits wide x 320 bits tall x 18 bits of color = 172,800 bytes.  That’s a lot of data, and it is more data than we can hold in the RAM of the Wonder Gecko MCU.  Therefore, it will require some intelligent code to drive the display or an external memory buffer to store the image data.

         

        Backlight

        The backlight is necessary for TFT LCD displays to allow the display to be seen.  Without a backlight, a color TFT LCD will show no image.  A monochrome LCD is a little different, since the segments can be seen if they are in the “on” state.  The brightness of an LCD screen is sometimes controlled by applying a Pulse Width Modulated (PWM) signal to a pin (or pins) that controls the LED backlight.  This is exactly what we have already done in the last chapter to dim an LED.

         

        Display Driver Chip

        A display driver chip is used to drive 76,800 signals by rotating through all horizontal and vertical scan lines many times per second.  This component is an optional component of the display, and if it is present, it dramatically reduces work for the MCU to display (and continue to display) an image on the screen. 

         

        Frame Buffer

        A frame buffer is a block of RAM that holds all of the color information for every pixel (172 kB for this display) that is used to paint a single image (or “frame”) to the display.  This buffer is required to exist somewhere in the system because it is used by the display driver chip to refresh the LCD image many times per second.

         

        Touch interface

        A touch interface is an optional component and will often have its own control chip or control signals that are separate from the display driver chip. 

         

        A resistive touch screen is pressure sensitive.  It requires that your finger (or stylus) makes contact with the screen and causes a tiny grid of precisely controlled resistance wires to touch each other, and then measures the resistance to calculate the position.  The resistive touch screen requires four signals to interface the MCU, two of which must be fed into an Analog to Digital Comparator (ADC) in order to read the touches.  The Wonder Gecko has several ADC inputs that can be used for this purpose.  Resistive touch screens may require calibration by the user to perform accurately.

         

        A capacitive touch screen requires no physical contact between the user and the sensor.  Therefore, the sensor can be placed beneath hardened glass or plastic.  A valid touch is formed by the change in capacitance measured on the sensor.  A human finger can change the capacitance of this sensor, whereas a plastic stylus will not produce a change in capacitance.  The capacitive touch screen used in this chapter uses a controller that communicates via the I2C interface. 

         

        Graphic Display Architecture

        The type of architecture used in our display (and system) has a huge impact on how we will write our software code, as well as how well our display will perform.  You cannot assume that any model of MCU can sufficiently drive any type of display.  You must be aware of the architecture details and MCU pinout so that you can determine the best type of display for your needs.

         

         12_general_architecture.png

        In a general sense, all display architectures require the above control blocks.  The display contains a number of scan lines (depending on the resolution) and an image driver that must continually feed the scan control circuitry with pixel data, even for a static image.  The pixel control allows light to pass for an instant, and then the pixel goes dark again.  If the scan control circuitry were stopped, the display would turn dark, as all pixels would be turned off.  Therefore, the image driver needs a frame buffer of memory somewhere in the system to fetch the pixel data that is needed for every scan.  The application fills the frame buffer as new drawing operations change what is to be displayed on the screen.

         

        Displays without an Integrated Driver Chip (RGB Interface)

        In the RGB interface mode, the MCU acts as the image driver.  This means that it must constantly drive data to the display, refreshing all 320 x 240 pixels many times per second.  You can imagine the amount of work that would require of your MCU.  If the frame buffer is too big to fit in the MCU RAM, an external memory chip must be used.  The frame buffer can be attached to the MCU via serial interfaces such as I2C or SPI for static images such as device menus, but must utilize a parallel interface in order to keep up with the demands of full motion video.  The External Bus Interface (EBI) can be used with external memory for maximum speed and ease of use, as long as your particular model of EFM32 supports it.  EBI extends the RAM of your EFM32 and allows you to address external memory as if it resides within the RAM address space of the EFM32 itself.

         12_direct_architecture.png

         

         

        Displays with an Integrated Driver Chip

        When a display has an integrated device driver chip and frame buffer (such as the Ilitek ILI9341 used in this chapter), the MCU doesn’t have to perform all of the constant refreshing of the display; it only sends data to the driver chip when the image changes.  This enables the MCU to offload all of that work to stay focused on the application at hand rather than driving the display. 

         12_ILI9341_architecture.png

         

         

        These driver chips usually offer both parallel and serial interfaces to receive image data from the MCU.  Parallel interfaces are required if the display will be used for full-motion video and require 8 or more data interface pins.  Serial interfaces can be used for static images like device menus and only require 3 or 4 interface data pins.

         

        Fully Integrated Application Interface Displays

        There are displays available on the market (such as the EVE series from FTDI) which go well beyond a display driver chip.  They contain the ability to create graphical shapes such as lines, rectangles, and circles, as well as device controls such as windows, sliders, and buttons. These displays can even offer an integrated touch controller and audio capabilities.  The displays communicate over I2C or SPI, and the data that is sent is similar to a software Application Programming Interface (API).  The specs of such displays define the commands that the controller chip accepts, and the application software simply communicates each graphic primitive one-by-one to the display to paint the appropriate picture on the screen.  These types of displays can be easier to program, but are not the focus of this chapter.

         

        Software Stack

        Since graphic displays are complex devices, the code that runs them should be broken up into parts that deal with only one part of the problem.  This is known as a software stack.

         12_sw_stack.png

         

         

         Application Software

        At the top of the stack is the application software.  Application software is focused on providing a solution to the end user, such as the content of menus, fetching images from flash storage, responding to user input, and generally deciding what to do next.  Application software should not have to be bogged down with the simple task of how to write a snippet of text to the screen, or the exact details of how to display an image.  These things should be handled further down the stack to keep your application code simple.

         

        Graphics Library

        In order for your application code to stay focused on its mission, your graphics library should provide useful methods to do common things, such as paint the screen with a color, display text, create lines or shapes, and display graphic images.  We will learn how to build a very simple graphics library of our own as part of this chapter.

         

        Depending on the graphics library complexity, it may even create a full windowing capability with sliders or popups and add all of the comforts of a modern computer interface to your embedded application, all within the limited RAM available in an MCU.  Silicon Labs provides the Segger emWin graphics library as part of the Simplicity Studio installation.  We will introduce the emWin library at the end of this chapter.

         

        Software Device Driver

        At the bottom of the software stack, the device driver is the necessary code that customizes your graphics library for your particular display device architecture and physical hardware connection.  (Note that a software device driver is not the same thing as the device driver chip on the physical display.)  Graphics libraries are flexible, and can be adapted to many different display architectures, but they need to be configured for your display architecture and MCU.  The device driver provides this customization, providing the display’s resolution and color depth, mapping the data bus for the display to GPIO pins on your MCU and setting up the memory for the frame buffer (if applicable).

         

        See AN0047 Interfacing Graphical Displays and AN0048 Energy Optimized Display

        Application for more in depth technical information on using displays with the EFM32 family.

         

        In the next section, we will connect the display to the Wonder Gecko and start drawing some pictures.

         

         

         PREVIOUS | NEXT

      • Home Automation Part 5: Meeting the Multiprotocol Challenge

        WYALLEN | 09/257/2016 | 05:20 PM

        This is the last blog of the series and I want to leave you with something forward looking. There are many challenges hindering the growth of the home automation market, one of the largest I see being the fragmentation in both technologies and protocols. Many different wireless technologies appear in this market with options including Wi-Fi, Bluetooth, ZigBee, and Thread in the future for mesh networking, and even proprietary sub-GHz protocols, each fulfilling different needs.

         

        Logos Banner.png

         

        Among these connectivity technologies, there are three major blocks that make each wireless protocol unique: the physical layer, the wireless stack, and the application layer.

         

        If we were writing a “wireless novel,” the physical layer (also known as the radio) is analogous to individual words; the stack is the grammar – the rules for how the words are arranged; and the application layer forms the elaborate, descriptive sentences comprising the novel.

         

        Take, for example, a connected lighting application in a smart home: the connected light’s radio operates at 2.4 GHz, the stack is Bluetooth Smart 4.1, and the application is custom. A motion sensor, used to automatically turn on the light when someone enters the room, might use a radio operating on a different 2.4 GHz modulation scheme; operating IP-based Thread protocol stack for mesh networking; and the application is open.

         

        Home Automation Illustration.png

         

        So how do we get all of these hardware and software elements talking to each other to ensure interoperability? A rapidly emerging trend to ensure device-to-device interoperability in the smart home is the use of multiprotocol SoC devices capable of “speaking” multiple wireless languages.

         

        This type of system-on-chip implementation is a critical first step to support wireless standards, ensuring interoperability among connected devices supporting these standards. The SoC device must have enough flash memory to be able to store multiple protocol stacks in firmware and to enable dynamic switching among the protocols as devices join the network. Equally important is the application layer software that connects the end user to the hardware. This application layer such as ZigBee Cluster Libraries, OIC, AllJoyn, or Weave should be protocol agnostic, therefore providing a way to unify the underlying wireless protocol standards.

         

        A holistic hardware and software approach based on these multiprotocol hardware devices, carefully combined with firmware, software, and development tools, will enable an IoT device to effortlessly speak different wireless languages. This unified hardware and software approach to multiprotocol connectivity holds the promise of ensuring seamless interoperability among many disparate smart home devices, from lights to wireless sensors nodes to actuators.

         

        For more information on Silicon Labs’ wireless offerings, check out www.silabs.com/wireless

        For more information on Silicon Labs’ Home Automation reference designs, check out www.silabs.com/connectedhome

         

        For a refresh of other topics in this blog series, check out:

        Part 1: Wireless Technologies and Connected Lighting

        Part 2: The Components of Connected Lighting Design

        Part 3: Connected Lighting Uses Cases

        Part 4: All about the ecosystems