Wednesday’s Newsletter: Analog & Power

Coming to your inbox on Wednesday: Circuit Cellar’s Analog & Power newsletter. This newsletter content zeros in on the latest developments in analog and power technologies including ADCs, DACs, DC-DC converters, AD-DC converters, power supplies, op amps, batteries and more.

Bonus: We’ve added Drawings for Free Stuff to our weekly newsletters. Make sure you’ve subscribed to the newsletter so you can participate.

Already a Circuit Cellar Newsletter subscriber? Great!
You’ll get your Analog & Power newsletter issue tomorrow.

Not a Circuit Cellar Newsletter subscriber?
Don’t be left out! Sign up now:

Our weekly Circuit Cellar Newsletter will switch its theme each week, so look for these in upcoming weeks:

Microcontroller Watch. (1/8) This newsletter keeps you up-to-date on latest microcontroller news. In this section, we examine the microcontrollers along with their associated tools and support products.

IoT Technology Focus. (1/15) Covers what’s happening with Internet-of-Things (IoT) technology–-from devices to gateway networks to cloud architectures. This newsletter tackles news and trends about the products and technologies needed to build IoT implementations and devices.

Embedded Boards.(1/22) The focus here is on both standard and non-standard embedded computer boards that ease prototyping efforts and let you smoothly scale up to production volumes.

DC-DC Power Regulator Eases Data Center Cooling Costs

Analog Devices (ADI) has expanded its suite of Power by Linear µModule regulators with the LTM4700 step-down DC/DC power regulator. The device features energy efficient performance that reduces data center infrastructure cooling requirements. Configured as dual 50 A or single 100A configuration, the power µModule’s packaging technology enables an increasing server density and boosts data center throughout and computational power with minimal impact on system size and cooling costs.

The LTM4700 µModule’s highly integrated, component-on-package design includes on-board memory, data conversion circuitry and digital interface, reducing it to nearly half the size of competing devices, according to ADI. Applications include cloud computing, high-speed computing and optical networking systems, communication infrastructure, and PCIe boards, as well as medical, industrial and test and measurement equipment.

The LTM4700 operates at 73°C using heatsink packaging technology. That’s much cooler compared to modular solutions from competitors which typically run at 90°C, says ADI. The device can deliver full 100 A at 12 VIN to 0.8 VOUT with 200 LFM air flow up to 70°C ambient temperature. Peak conversion efficiency at 12 VIN to 0.8 VOUT reaches 90%.  The µModule’s architecture also enables system designers to combine up to eight devices, delivering up to 800A of load current to meet the higher power needs of data center processors, including FPGAs, ASICs, GPUs and microcontrollers.

The LTM4700 operates from a 4.5 V to 16 V input range, with output voltages digitally controlled from 0.5 V to 1.8 V. Integrated A/D converters, D/A converters and EEPROM enable users to digitally monitor, record and control power parameters using an I²C PMBus interface. Switching frequency is synchronized to an external clock from 200 kHz to 1 MHz for noise-sensitive applications. The LTM4700 also has self- and load-protection features against fault conditions such as over- and undervoltage, overcurrent and overtemperature.

Summary of Features:

  • Dual 50 A or Single 100 A Digitally Adjustable Outputs with Digital Interface for Control, Compensation and Monitoring
  • Wide Input Voltage: 4.5 V to 16 V
  • Output Voltage Range: 0.5 V to 1. 8V
  • ~90% Full Load Efficiency from 12 VIN to 1 VOUT at 100 A
  • ±0.5% Maximum DC Output Error Over Temperature

Pricing for LTM4700 starts at $97.26 (1,000s) in a 15 mm x 22 mm x 7.87 mm BGA package.

Analog Devices | www.analog.com

Secure MCU Family Targets Low Power, Small Footprint Designs

STMicroelectronics has added the new STM32G0 microcontrollers (MCUs) to the STM32 family. The new G0 series targets entry-level applications that require greater energy efficiency, functionality, security, and value, in a smaller footprint. Extremely flexible packaging and memory options enable designers to do more within less space, and save cost. A new power-distribution architecture reduces external power and ground connections to just a single pair of pins, allowing more of the package pins—a precious resource in many embedded projects—to be allocated for user connectivity.

In addition, ST is making large memory densities available in small and economical low-pin-count packages. On top of this, the new generation features power-saving innovations that trim consumption close to that of specialized ultra-low-power devices.

To provide robust security for today’s connected devices, the STM32G0 series introduces a variety of hardware-based features including memory protection to support secure boot. Some devices in the series add to these features an AES-256 hardware cryptographic accelerator with a true random number generator (TRNG) to aid encryption.

Another valuable feature that anticipates a growing need is support for the latest USB Type-C specifications that allow easy, high-speed connectivity and battery charging, including Power Delivery version 3.0.

The STM32G0 series is based on the Arm Cortex-M0+ core, which is conceived to deliver sharp performance within a tight power budget. It targets fast-evolving products in the connected world, including smartphones, smart kitchen equipment, and appliances, air conditioning, consumer or industrial motor controls, advanced user interfaces, IoT devices, rechargeable connected devices, drones, lighting systems and more.

Package options are available from 8-pin, enabling developers to easily upgrade aging 8-bit MCU designs, to 100-pin. Flash from 16 KB to 512 KB, with 512 KB available in packages as small as 32-pin, enables more sophisticated applications on small, low-cost products.

The maximum CPU frequency of 64 MHz permits high execution speeds, compared to typical entry-level MCUs. On the other hand, extremely flexible clock configuration allows users to tailor performance within the available power budget. The internal clock is remarkably stable and comparable to high-end devices, being accurate to within ±1% from 0-85°C and ±2% over the wider range from -40°C to 125°C. This not only saves the board space and pins needed to connect a dedicated external timing device, but also can trim at least 10 cents from the bill of materials.

The STM32G0 series is extremely efficient, running at less than 100µA/MHz in run mode, and provides multiple reduced-power operating modes to save energy and extend battery runtimes. Devices draw as little as 3-8µA in stop mode with the real-time clock (RTC) running, and just 500 nA in standby with RTC (all at 3.0V, 25°C).

Moreover, peripherals are upgraded to enhance performance, speed, and accuracy. The devices feature a 12-bit 2.5 MSPS ADC, with hardware oversampling for 16-bit precision. There is also a 2-channel DAC, fast comparators, and high-accuracy timers with 7.8 ns resolution.

In addition to permitting extra user-assignable I/Os, the internal (ST-patented) power-distribution scheme also helps save BoM costs by reducing the number of external power-supply decoupling components.

Enhanced internal prevention of electromagnetic susceptibility (EMS) is yet another feature that saves board space and BoM costs. Protection against fast-transient bursts above 4.5kV, in accordance with IEC 61000-4-4, relaxes the demands for surrounding filtering components and eases board layout. For product-development teams, the ability to easily ensure good electromagnetic behavior facilitates EMC certifications for faster time to market.

ST is planning several STM32G0 lines, including the STM32G071 and similar STM32G081 with hardware cryptographic enhancement. There are also Value Line STM32G070 devices for mass-market applications. Pricing starts from $0.69 for the STM32G070CBT6 Value Line MCU in a 48-pin package, with 128 KB flash, for orders of 10,000 pieces.

STMicroelectronics | www.st.com

Connecting USB to Simple MCUs

Helpful Hosting

Sometimes you want to connect a USB device such as a flash drive to a simple microcontroller. The problem is most MCUs cannot function as a USB host. In this article, Stuart steps through the technology and device choices that solve this challenge. He also puts the idea into action via a project that provides this functionality.

By Stuart Ball

Even though many microcontrollers (MCUs) may have a USB device interface that can connect to a host, rarely is a host interface available on simple MCUs. There are various reasons for this, including the complexity of implementing a USB host interface on a simple processor, the need to enumerate and recognize many device types and the memory required to do so. Functioning as a single USB device is much simpler. Implementing a host interface also puts some constraints on the MCU for throughput and clock speed choices.

I have been working on a retro CPU board design, using the Z80180 processor that can run the old CP/M-80 operating system. This is just a fun project, with no real practical use. But the project needed storage that could replace the floppy disk normally used in CP/M. I considered using SD cards, but in experimenting with them, I decided that they are just not what I wanted. What I did want was the ability to plug a USB flash drive into the circuit.

Even though my CP/M project is not that useful, there are other applications where the ability to plug a USB flash drive into an MCU-based circuit is desirable. Examples include:

• Capturing logging or debug data
• Flashing new code into the MCU
(if the MCU has self-programming flash)
• Downloading crypto keys or other
one-time data to the MCU
• Downloading configuration information
to enable or disable features
• Downloading language translation
information
• Retaining critical data
• Serving as a “key” to restrict access to
maintenance mode functions only
to authorized personnel
• Downloading GPS coordinates or map
information
• Updating stored part numbers, serial
numbers or any stored value that can
change.

There are ways to implement USB host capability on an MCU, especially if it has a USB interface that supports OTG (on-the-go) USB capability. But no matter how you do it, you have to write or obtain drivers and integrate the functionality into your software. You will also be constrained as to which MCUs you can use, based on availability of USB host capability. But for a simple design, you may not want to be forced to use a part just because it has USB host capability.

VDrive3

FTDI makes a USB host module called the VDrive3 that provides a limited USB host interface and can connect to an MCU (or even a PC) using an asynchronous serial port. The module also has an SPI interface, although I did not use that in my design. A link to the datasheet is provided on the Circuit Cellar article materials webpage.

The VDrive3 (Figure 1) uses the FTDI Vinculum IC, which provides a USB host interface on one side and a serial or SPI interface to your MCU on the other. Since all of the hardware and software to implement the USB host interface is inside the VDrive3 module, you don’t need to develop USB stacks or drivers, or deal with licensing issues. The VDrive3 comes in a plastic housing so it is easy to mount in a rectangular cutout.

Figure 1
VDrive3 module. The module comes with the attached cable, which I modified to use a different connector on my board.

The VDrive3 has a file-based interface for USB flash drives, which means that you don’t need to manage the memory yourself. You open files, write to them, read them, close them and create directories. The VDrive3 shields the host from the memory management functionality, allowing all this to be done with simple commands over the serial interface. The VDrive3 manages the file system so you don’t have to.

In my application, I was emulating a floppy disk. I defined the “virtual floppy” to have 256 tracks of 32 sectors each. To implement that on the VDrive3, I created 256 directories named TRAK000 through TRAK0FF. In each directory, I created 32 files named SEC00 through SEC1F. So, when the CP/M operating system wants to read or write a specific sector, the AVR MCU navigates to the directory that represents the selected track and opens the sector file corresponding to the specified sector.

This is a simple mechanism that is really applicable only to the way I’m using the flash drive, but the general principles apply to any VDrive3 application. You can create a directory, and then create files within the directory that correspond to whatever information you need to store. Or you can skip the directories and store everything at the top directory level.

One advantage of using the VDrive3 is interoperability with a PC. If I used SD drives, I would either have a proprietary format that couldn’t be read in a PC, or else I’d have to manage a PC-compatible file system in my MCU. But the VDrive3 recognizes the standard FAT12, FAT16, and FAT32 file systems, so a flash drive written on a VDrive3 can be inserted into a PC and read. This could be very useful if you are collecting debug or log data from your MCU application. In my case, I could make a copy of a CP/M “floppy” on a PC.

Commands

The VDrive3 recognizes various commands, including SEK (seek to file offset), OPW (open file for writing) and WRF (write to file). The commands used in my application are listed in Table 1. VDrive3 commands can be sent in ASCII as in the command list in Table 1, or you can configure it to use a short command set that requires fewer bytes to transmit. Data can be either ASCII or binary. The VDrive3 defaults to the extended command set and binary data transfer, and I leave the module in that mode for my application.

Table 1
The VDrive3 recognizes various commands. Shown here are the commands used in my application. VDrive3 commands can be sent in ASCII as in this command list, or you can configure it to use a short command set that requires fewer bytes to transmit.

Generally, each command is sent as a string of two or three characters. If data such as a filename are needed, the command is followed by a space, the appropriate text and a carriage return character (0x0D). If no data are needed, such as for the FWV (FW version) command, the command can be immediately followed by the carriage return. Setting the baud rate requires a divisor value, so the SBD command (set baud rate) is followed by a 3-byte divisor value and then a carriage return. …

Read the full article in the January 342 issue of Circuit Cellar

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Motor Driver Provides Complete Solution for Industrial Designs

Infineon Technologies has launched the IFX007T NovalithIC motor driver for industrial applications. The IFX007T smart half-bridge provides an easy and efficient way to drive brushed and brushless motors, integrating a p-channel high-side MOSFET, an n-channel low-side MOSFET and a driver IC into one package. Along with a microcontroller and power supply, no other devices are necessary to drive a motor.

For many years, Infineon has followed this NovalithIC integrated approach for automotive applications. According to Infineon, the IFX007T now allows industrial system designers to benefit from this experience. It is qualified according to JESD47I and can be used to drive motors with supplies up to 40 V and peak currents up to 55 A. The broad application range includes pumps, healthcare, home and garden appliances as well as industrial automation, fans and many more.

Ease-of-use is a key benefit of the integrated solution. System designers save layout and manufacturing effort while reducing stray inductances and external components. Additionally, only three general purpose microcontroller pins are needed to control a full H-bridge.

The IFX007T has integrated self-protection, including over-temperature and cross-current protection. Within an H-bridge configuration, the half-bridge approach provides logic redundancy—if one device fails, the other can still stop the motor.

Another key benefit is the flexible motor control. The IFX007T can be used in either half-bridge, H-bridge or three-phase configurations. Furthermore, the motor speed can be adjusted via pulse width modulation (PWM) up to 25 kHz. Active freewheeling is possible from either the high side or the low side. An adjustable slew rate enables reduction of electromagnetic emissions.

Infineon Technologies | www.infineon.com

Tiny, Single-GbE Arm Networking SBC Runs Linux

By Eric Brown

Gateworks has spun a 100 mm x 35 mm, single-GbE “Newport GW6100” networking SBC, which follows a recent dual-GbE “GW6200” model. Both run Linux on a dual-core Cavium Octeon TX SoC and offer mini-PCIe expansion and -40 to 85°C support.

In Nov. 2017, when Gateworks unveiled its Newport family of Linux-driven, Octeon TX based SBCs with the 105 mm x 100 mm, dual GbE port Newport GW6300, it promised several more models in 2018. The 140 mm x 100 mm, 5-GbE port Newport GW6400 was announced in May along with a GW6404 sibling that swaps two of the GbE ports to SFP ports. Now, the company has launched the single-GbE port GW6100 model, which had been scheduled for a 2018 Q2 arrival. There was no announcement of the GW6100, which was discovered by CNXSoft, nor of the dual-port, 100 mm x 75 mm GW6200, which now has a product page (see farther below).

 
Newport GW6100 (left) and recent Newport GW6200
(click images to enlarge)
Like the other Newport SBCs, the new entries run OpenWrt or Ubuntu on Cavium’s networking focused Octeon TX SoC, which has Cortex-A53 like ”Thunder” cores. The embedded-oriented Octeon TX competes directly with NXP’s QorIQ line. Optimized to run multiple concurrent data and control planes simultaneously, the headless SoC integrates security architecture from Cavium’s Nitrox V security processors.

While the Newport GW6300 and GW6400 both offer a choice of dual- (800MHz) or quad-core (1.5GHz) Octeon TX configurations, the GW6100 and GW6200 are limited to the 800MHz dual-core models. Volume orders are required to switch to the quad-core SoC or make other customizations, including boosting the standard 1GB DDR4 to up to 4GB or the standard 8GB eMMC to up to 64GB.

The Newport GW6100 and GW6200 provide OpenWrt or Ubuntu Linux BSPs with U-Boot. A full development kit is available with a power supply, passive PoE injector, JTAG programmer, and cables.

Newport GW6100

The tiny new GW6100 offers 1GB DDR4, 8GB eMMC, and a GbE port with PoE support. You can also draw power from the USB Type-C port, and there’s a JTAG connection and an I/O connector. The latter offers serial, analog, and digital I/O, as well as I2C, SPI, and power.


Newport GW6100 front detail view
(click image to enlarge)
A single mini-PCIe slot accompanied by a nano-SIM slot supports third-party PCIe, USB 3.0, and mSATA cards. You can also choose from several Gateworks mini-PCIe options, including USB, DIO/analog I/O, microSD/USB/SIM, Femto, and IoT Radio (Sub-1GHz) modules.


GW6100 rear detail view
(click image to enlarge)
Like all the Newport SBCs, the GW6100 provides standard -40 to 85°C support. There’s an 8-60V DC jack in addition to the PoE, Type-C, and power header options. Other features include reverse power protection, programmable wake-up/shutdown, a watchdog, real-time clock, and more. A Ublox GNSS receiver is optional.


GW6100 block diagram
(click image to enlarge)

Specifications listed for the Newport GW6100 include:

  • Processor — Cavium Octeon TX (2x ARMv8 ThunderX cores @ 800MHz); networking and security extensions
  • Memory/storage:
    • 1GB DDR4
    • 8GB eMMC
    • mSATA (SATA III) via mini-PCIe
  • Networking — Gigabit Ethernet port with passive PoE 8-60V input
  • Other I/O:
    • USB 2.0 Type-C port with 1.5A, 7.5W power support
    • Application connector (serial I/O, digital I/O, analog, I2C, SPI, and power)
    • JTAG interface
  • Expansion — Mini-PCIe slot with 8W power for “PCIe, USB 3.0 or mSATA with USB 2.0”; Nano-SIM slot
  • Other features – Watchdog; RTC with battery; LED, tamper switch support; voltage and temp. monitor; serial config EEPROM; programmable fan controller with tach support; Optional Ublox ZOE-MQ8 GNSS GPS Receiver with PPS
  • Operating temperature — -40 to 85°C
  • Power:
    • 8-60V DC jack (or PoE or Type-C)
    • 0.13A @ 24VDC typical operating current
    • Voltage reverse protection
    • Programmable shut-down and wake-up
  • Dimensions — 100 x 35 x 21mm
  • Weight — 85 g
  • Operating system — OpenWrt or Ubuntu BSPs

Newport GW6200

The 100 x 75mm Newport GW6200 adds to the GW6100 feature set with a microSD slot, a second GbE port (both with PoE), plus a second mini-PCIe slot. In place of the Type-C port you get 2x USB 3.0 ports.

 
Newport GW6200 detail view (left) and block diagram
(click images to enlarge)
The CW6200 is further equipped with side-mounted connectors for SPI, DIO, I2C, and either 2x RS232 or a single RS232/422/485 interface. A CAN bus controller is optional.

Further information

The Newport GW6100 and Newport GW6200 appear to be available now at undisclosed prices. More information may be found on Gateworks’ Newport GW6100and Newport GW6200 product pages.

Gateworks | www.gateworks.com

Linux-Driven SMARC Module Supports Up to Five Time-Sensitive GbE Ports

By Eric Brown

Kontron invented the ULP-COM standard that formed the basis of the SMARC form factor, and it has delivered numerous SMARC modules over the years, including Arm products such as the Nvidia Tegra K1 based SMC-NTKE1. Now it has unveiled the first module we’ve seen in any form factor with NXP’s dual-core, Cortex-A72 powered QorIQ Layerscape LS1028 SoC.

The 82 mm x 50 mm SMARC-sAL28 module runs a Yocto Project based Linux stack (with U-Boot) on the LS1028. The module exploits the SoC’s Time Sensitive Networking (TSN) support with up 2x or 5x TSN-capable Gigabit Ethernet ports.



SMARC-sAL28
(click image to enlarge)
The SMARC-sAL28 module is compliant with the IEEE 802.1 TSN standard, which offers guaranteed latency and Quality of Service (QoS) with time synchronization to enable “a timely and highly available delivery of data packets,” says Kontron. TSN Ethernet can replace more expensive, proprietary fieldbus technology while also offering the advantage of being able to “simultaneously communicate seamlessly to the IT level.”

No clock rate was listed for the LS1028 SoC, which NXP refers to as the LS1028A. The SoC integrates a four-port TSN switch and two separate TSN Ethernet controllers. Like NXP’s other networking oriented LSx QorIQ Layerscape SoCs, it supports NXP’s EdgeScale suite of secure edge computing device management tools. It’s the only LSx SoC that features a 3D graphics capable GPU.

 
SMARC-sAL28 (left) and NXP LS1028A block diagrams 
(click images to enlarge)
The SMARC-sAL28 ships with 4GB of soldered DDR3L with optional ECC, as well as 2GB to 64GB eMMC 5.1 storage. The 3V-5.25V module supports -40 to 85°C operation.

Two models are available. One has 2x TSN-capable, switched GbE controllers “that can be directly used by the carrier,” says Kontron. The second version supports 4x switched TSN-capable GbE ports via the QSGMII interface with an additional TSN-capable GbE controller. This second option provides a total of 5x TSN-ready GbE ports ports “using a quad-PHY on the carrier.” This 5x GbE model sacrifices one of the 2x PCIe x1 interfaces, which can also be deployed as a single PCIe x4 connection.

The SMARC-sAL28 provides a dual-channel LVDS interface, one of which can be swapped out for eDP as a BOM option. The second LVDS offers a BOM option swap-out for either an HDMI or DisplayPort.

The module is further equipped with a single USB 3.0, 6x USB 2.0, and 4x RX/TX serial interfaces. Other I/O includes 2x I2C, 2x SPI, 12x GPIO, and single SDIO, CAN, and I2S connections. Options include a Wibu security chip with Kontron Approtect security software, as well as an RTC.

Further information

The SMARC-sAL28 is “coming soon” at an undisclosed price. More information may be found in Kontron’s SMARC-sAL28 announcement and product page.

Kontron | www.kontron.com

Raspberry Pi HAT Serves Up Robotics Control Smorgasbord

By Eric Brown

Adafruit has released a $35 robotics HAT add-on for any 40-pin Raspberry Pi board. The Adafruit Crickit (Creative Robotics & Interactive Construction Kit) HAT is designed for controlling motors, servos, or solenoids using Python 3. The board is limiting to powering 5V devices and requires a 5 V power supply.


Adafruit Crickit HAT with Pi and connected peripherals
(click image to enlarge)

The Crickit HAT incorporates Adafruit’s “i2c-to-whatever” bridge firmware, called seesaw. With seesaw, “you only need to use two data pins to control the huge number of inputs and outputs on the Crickit,” explains Adafruit founder and MIT engineer Limor Fried in an announcement on the Raspberry Pi blog. “All those timers, PWMs, NeoPixels, sensors are offloaded to the co-processor. Stuff like managing the speed of motors via PWM is also done with the co-processor, so you’ll get smooth PWM outputs that don’t jitter when Linux gets busy with other stuff.”


 
Crickit HAT with and without Raspberry Pi
(click images to enlarge)
The Crickit HAT uses a “bento box” approach to robotics, writes Fried. “Instead of having eight servo drivers, or four 10A motor controllers, or five stepper drivers, it has just a little bit of everything,” she adds.

Specifications listed for the Adafruit Crickit HAT include:

  • 4x analog or digital servo control, with precision 16-bit timers
  • 2x bi-directional brushed DC motor control, 1 Amp current-limited each, with 8-bit PWM speed control (or one stepper)
  • 4x high-current “Darlington” 500mA drive outputs with kick-back diode protection — for solenoids, relays, large LEDs, or one uni-polar stepper
  • 4x capacitive touch input sensors with alligator pads
  • 8x signal pins, which can be used as digital in/out or analog inputs
  • 1x NeoPixel driver with 5V level shifter connected to the seesaw chip (not the Pi), so you won’t be giving up pin 18. It can drive over 100 pixels.
  • 1x Class D, 4-8 ohm speaker, 3W-max audio amplifier connected to the I2S pins on the Pi for high-quality digital audio — even works on Zeros
  • 1x micro-USB to serial converter port for updating seesaw with the drag-n-drop bootloader, or plugging into a computer; it can also act as a USB converter for logging into the console and running command lines on the Pi.


 
Crickit HAT, front and back
(click images to enlarge)
 Further information

The Adafruit Crickit HAT is currently listed as “out of stock” at $34.95. More information may be found in Adafruit’s Crickit HAT announcement and product page.

This article originally appeared on LinuxGizmos.com on December 18..

Adafruit | www.adafruit.com

12:1 Input Quarter-Brick DC-DC Converters Target Railway Systems

RECOM has expanded its railway portfolio with two 40 W and 60 W DC/DC converter series in quarter-brick packages with an ultra-wide input voltage range from 14 VDC to 160 VDC..The 12:1 input voltage range of RECOM’s RP40Q-RUW and RP60Q-RUW series covers all input voltages from nominal 24 VDC up to 110 VDC in a single product (including EN50155 transients).

These quarter-brick DC/DC converters are designed for railway rolling stock and high voltage battery applications and offer basic isolation with regulated 5 V, 12 V, 15 V, 24 V or 48 VDC outputs, including sense and trim pins. They have a consistently high efficiency over the entire input voltage range and an operating temperature range from -40°C up to +85°C (+68°C for the RP60Q-RUW) at full load without forced air cooling.

An optional heat sink allows these converters to provide full load up to +90°C and +77°C respectively. The case is fitted with threaded inserts for secure mounting in high shock and vibration environments. The converters are CE marked, EN50155 and EN45545-2 certified and come with a three-year warranty. Samples and OEM pricing are available from all authorized distributors or directly from RECOM.

RECOM | www.recom-power.com

CompactPCI Serial Board Delivers Four Gbit Ethernet Channels

MEN Micro has announced the G211X Ethernet interface card. It ensures fast data transmission with four X-coded M12 connectors connected to the backplane via an x4 link. The G211X is a new quad Ethernet card based on CompactPCI Serial. It can be used in combination with a CompactPCI Serial or CompactPCI PlusIO CPU board in a CompactPCI Serial or hybrid system. The four Gigabit Ethernet interfaces on the front panel are accessible via robust, X-coded M12 connectors.

All four interfaces are controlled by an Ethernet controller connected to the backplane via an x4 PCI Express connection. Each interface also supports a data transmission rate of 1 Gbit/s—even if all four channels are used simultaneously. For better control, two LEDs each indicate the connection and activity status of the interfaces. The G211X is designed for the extended operating temperature and prepared for conformal coating for use in harsh and mobile environments, in particular for rolling stock applications.

  • Four 10/100/1000BASE-T Ethernet channels
  • Intel i350 Server chipset with support for 8 virtual machines
  • Full-duplex or half-duplex
  • X-coded M12 connectors
  • 500 V insulation voltage
  • -40°C to +85°C operating temperature
  • Based on PICMG CPCI-S.0 CompactPCI Serial

MEN Micro | www.menmicro.com

Tiny PLC Reference Design Serves Digital Factory Needs

Digital factories require a surprising amount of analog and power technology. Exemplifying that trend, Maxim Integrated Products offers its new programmable logic controller (PLC) reference design called Go-IO. Go-IO embeds 17 configurable I/Os in a space one-half the size of a credit card and enables productivity-enhancing self-diagnostic capabilities in automated factory subsystems. System designers are striving to bring greater intelligence into Industry 4.0 digital factory equipment while meeting the stringent size and power demands of PLCs.
Digital factories can dynamically adjust the manufacturing line on the fly based on new or changing requirements. To fully realize industrial convergence, automated equipment must also possess self-diagnostic and optimization capabilities. Go-IO pushes intelligence closer to the edge, enabling active monitoring and communication of equipment health and status information as well as higher throughput and productivity. The reference design also meets increasingly stringent size and power requirements of PLCs, providing a 10x smaller solution with 50% less power consumption compared to its predecessor, the Pocket IO.

The flexible, rugged, open-source Go-IO reference design is ideal for industrial automation, building automation and industrial robotics applications. It has 12 highly integrated ICs, 17 IOs supporting multiple digital IO configurations, a 4-channel IO-Link master to provide a universal IO interface to both analog and digital sensors, and a robust 25 Mbps isolated RS-485 communications channel that provides a reliable, multi-drop data network for uploading time-sensitive health and status information into a local data lake or the cloud.

Go-IO contains the following technologies:

  • MAX14819 low-power, dual-channel, IO-Link master transceiver with sensor/actuator power-supply controllers.
  • MAX22192 8-channel octal digital input with isolated Serial Peripheral Interface (SPI), wire break detection and accurate input current limiters in a 6 mm x 10 mm package. The MAX22192 was announced today as part of Maxim’s expanded Digital IO portfolio. (Read today’s digital input press release)
  • MAX14912 8-channel digital output driver featuring 640mA high-side switches or push-pull configurable outputs, capable of achieving 200 kHz switching rates while providing proprietary fast, safe demagnetization inductive kickback protection.
  • MAXM22511 integrated 2.5 kVRMS isolated power and digital isolated RS-485 transceiver module supporting 25 Mbps data rates with ±35 kV ESD protection in a compact 9.5 mm x 11.5 mm package. (Read the October 31, 2018 press release)
  • MAX14483/MAX14130 6-channel, 3.75 kVRMS galvanic low-power digital isolator in a compact 20-pin SSOP package/4-channel 1 kVRMS galvanic digital isolator in a small 16-pin QSOP.
  • MAXM15462 Himalaya uSLIC voltage regulator ICs and power modules for cooler, smaller and simpler industrial power supplies.

The Go-IO is available as MAXREFDES212# at Maxim’s website for $495. The reference design consists of an application processor, baseboard and the Go-IO module.

Maxim Integrated | www.maximintegrated.com

Tiny MCU-Based Development Platform Hosts Dual USB Ports

Segger Microcontroller has introduced emPower-USB-Host, a compact low-cost development board. With two USB host ports, many applications using USB peripherals can be realized with little effort. Precompiled applications for barcode and smartcard readers, as well as POS displays, LTE sticks and USB to LAN adapters are available for download, including complete projects for Embedded Studio with source code of these applications. The applications are using Segger’s emUSB-Host software API, which makes accessing the different types of USB devices easy.
emPower-USB-Host uses the emLoad bootloader, pre-loaded into the flash of the MCU, to easily change applications in seconds using a USB flash drive. Development of custom applications is also supported. The board has a debug connector, providing full access to the NXP LPC54605J512 MCU with its Cortex-M4 core. Schematics and PCB layout of the board are available under a Creative Commons license. This way, the hardware can be used as a blueprint for custom devices using two USB host ports.

Segger Microcontroller | www.segger.com

Internet of Things Security (Part 6)

Identifying Threats

In this final part of his Internet of Things Security article series, this time Bob returns to his efforts to craft a checklist to help us create more secure IoT devices. This time he looks at developing a checklist to evaluate the threats to an IoT device.

By Bob Japenga

A number of years ago (there were woolly mammoths around if I remember correctly), I attended a conference on the Ada programming language. Ada was created for the United States’ Department of Defense to replace the myriad of programming languages that were deployed by the DoD at that time. The language was named after the first programmer, Augusta Ada King Lovelace, a colorful character in her own right and the only legitimate daughter of the poet Lord Byron. Ada is credited with publishing the first algorithm for use on a computing machine: Charles Babbage’s famous analytical engine.

At the conference I attended a breakout session on algorithms. In the conference room next door, a popular speaker, whose name I don’t remember, held another breakout session. About ten minutes into the session, we heard a deafening chant coming from the conference room next door that repeated over and over: “I don’t care.” The speaker was making a point that, as software designers, we should not care about everything. There are legitimate things for which we need to say: “I don’t care.” We need to identify them as not relevant to the task at hand and emphatically say: “I don’t care.”
Although I remember nothing from the breakout session on algorithms, I have never forgotten this principle: “There are some things that we just don’t care to address when designing embedded systems.” Certainly, there is much to be said for thoroughness in design, but when we—with well thought through analysis—determine that some aspect of a design is a “don’t care” we need to let it go.

In designing secure IoT devices this is a very important principle. The threats are diverse and difficult to number. The assets are important and of differing value. This month we will continue to build our checklist for IoT security. Last time we created a checklist to help you identify the assets that you want to protect. This month we will add to that checklist with some questions to help you identify and quantify the threats.

Identifying the Threats

We need to start with definitions. A good working definition for a threat would be: “a person or thing likely to cause damage or danger.” Although this is a good definition, for the purpose of building our checklist, I want to expand upon it a little. Here’s why: In most cases “I don’t care” who the threat is, nor do I care what their capabilities are. Keep in mind that, if there is a threat with very little capabilities, that threat could get passed on. They can always sell either their knowledge or their access to the device to someone who has the capabilities to create a security breach with the device. Let me illustrate that. Imagine there are two threats: One is a disgruntled former employee with little or no capability of reverse engineering your design in order to find a security flaw. The second is an organization with deep pockets and highly skilled hackers. If any of the assets that we identified in the first part of the checklist are worth a significant chunk of change, the former employee can always sell what they have to this other organization. With all that in mind, in general “I don’t care” about who the threat is.

But I do care about the activities of these threat agents. This is in line with the way the OWASP Top Ten IoT Security Threats is laid out. The Open Web Application Security Project (OWASP) is a worldwide organization focused on improving the security of software. I introduced OWASP as a valuable resource in my August 2016 column (Circuit Cellar 313) when we discussed their list of the top ten security vulnerabilities. The list was updated in 2017 and worthwhile to review [1]. OWASP also provides what its calls the top ten threats to IoT devices. We will look at these a little later in this article. They agree with my assessment that we don’t care who it is or what their capability is. What we care about is the action that they can take.

Figure 1
Shown here are the five areas of threat I’ve identified for IoT devices.

When thinking about threats to the security of our IoT device, I would identify five areas of threat as shown in Figure 1: access to the physical device; access to the wireless services on the device; access to the network (LAN or WAN) the device is on; access to the cloud server used by the device; and access to the mobile app used by the device. Anyone who has access to one or more of these is a threat agent. So, the beginning of our checklist needs to analyze what harm could be done by such a threat agent who gained access to any of these five areas of threat. Not all of your IoT devices have all of these areas of threat but most have a majority of them. For each of the areas of threat we need to ask the question: What would be the potential cost if someone with a lot of time, highly skilled hackers and a lot of money got access to one of these areas of threat without permission?

This provides the first five elements of the Threat portion of the IoT Security Checklist. Let’s look at each of these.

Five Threat Elements

Physical access: Not all IoT device designers will consider physical access to the device an area of threat. For example, we are currently working with a client who has determined that there is very little risk of an unauthorized person having physical access to their device. For most cases this is true. The device is only touched by employees and is physically inaccessible to everyone else. But I have not pushed them to protect the assets accessible through physical access for other reasons. I have gone along with that assessment because the assets available inside the device are minimal. But if the assets were valued higher, I would push back more strongly primarily due to the potential of a disgruntled or greedy insider handing the unit off to a qualified hacker.

Figure 2
Shown here are the access areas of threat if physical access is a threat area for your device.

If physical access is a threat area for your device, then the following access areas portrayed in Figure 2 need to be protected: access to data storage; access to user interfaces; access to USB ports; access to console ports; access to side channel information; and access to debug ports.

Mobile app: Many of our IoT devices have a mobile app associated with it. Although not strictly part of the IoT, it is certainly something that needs to be considered when designing your IoT device. Certainly, one approach is to limit who can put your mobile app on their phone or tablet. This certainly provides a great physical barrier to access. But the integration of Google’s Play Store and Apple’s App Store with your phone and tablet makes for very easy deployment and is very tempting to us designers. Surely the next line of defense is to drastically limit what the mobile app can access. Again, this is the power of the mobile app interface and you hate to lose it. Requiring a username and strong password is your next line of defense. For now, our job is to identify what harm someone bent on destroying your business would do if they were given unlimited access to your mobile app. How your mobile app communicates to the device is another concern we’ll look at next.

Wireless access: Your IoT device may provide several wireless ways to connect to it: cellular, Wi-Fi, Zigbee, Thread, Bluetooth, IrDA and Near Field Communication (NFC) are some of the most common. At this point in our checklist we need to ask: What if an unauthorized person got on your device wirelessly? What harm could be done? What if someone could perform a man-in-the-middle attack? The most recent Bluetooth hacking technique [2] shows us that even secure transmissions can have holes in their implementations allowing for man-in-the-middle attacks. So, we cannot just rely on secure transmissions as our only source of protection. I think about this every time I connect over Bluetooth to my OBD2 (on-board diagnostics) interface in my car. What would happen if someone could get on that interface and muck with my on-board computer? There’s no doubt that providing good access control through usernames and passwords, encrypting and authenticating all traffic and limiting physical access are all in your arsenal of protection. For now, we are concentrating on evaluating the harm nefarious access over the wireless interfaces on your IoT device could do.

Cloud access: Like mobile access, your cloud access is not strictly part of the IoT device. But again, we must pursue the questions: What if an unauthorized person got on your cloud interface? What harm could be done? The cost of that harm will help you to evaluate the amount of security you need to provide to the cloud interface. Clearly, we don’t want to use unencrypted transmissions. HTTPS provides encryption for us. But we found that on one of our major projects the cell modem chip only supported HTTP. So, we needed to encrypt the transmissions ourselves. Secure user access is pretty standard for cloud interfaces. But again, don’t rely on these layers. Seriously address what harm a malicious hacker intent on destroying your company could do if they had full access to your IoT cloud interface.

IoT network: Some of our IoT devices still have an Ethernet interface and provide some form of local area networking (LAN) or wide area networking (WAN). But this could be any wired network interface. Again, we need to look hard at what someone could gain from watching the traffic on the network. Our company’s most serious security breach came because of a little used Ethernet port that provided unencrypted traffic to a Link Local address. A researcher sniffed it out and found a security flaw. …

Read the full article in the December 341 issue of Circuit Cellar

Bob’s IoT Checklist can be found here.

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.