Crowd Funded Arduino Board Measures 0.5. x 0.5 Inches

Crowd funded via Crowd Supply, a project called µduino is an Arduino measuring in at 12mm (0.5 inches) x 12mm. While similarly sized micro-controller boards do exist, their power is severely limited to using chips such as the Attiny85 (with up to 6 I/O ports). The µduino makes use of the power of the ATMEGA32U4 chip found in the Arduino Leonardo (a board over 20 times larger), offering 20 I/O ports, including PWM and ADC ports. In addition, the µduino can be powered by batteries or directly by micro-USB. The µduino can also operate in one of two power modes, 3.3V or 5V, which can be selected using a jumper on the board. This way, users can tailor µduino to match their sensors and power supplies.

microduino-10_jpg_project-body

The prototype measures 14mm (0.55 inches) square, and the final design measures just 12mm (0.47 inches) square. Unlike many other Arduino-based boards, the µduino uses smaller hole separation (1.27mm vs 2.54mm). While vastly cutting down on size, standard sized wires are still compatible and can be soldered fairly easily.

Crowd Supply | www.crowdsupply.com/uduino

RISC-V and Moore’s Law : An Interview with Krste Asanovic

During his busy sabbatical, Krste Asanovic took time to share his thoughts on developments n the world of processors and the open sourcing of processor architecture.

Moore’s Law and the Chip Industry’s Perfect Storm

By Wisse Hettinga

With the end of Moore’s Law in sight and a silicon manufacturing world that is struggling to protect their investments, the RISC-V foundation is throwing its nets out on the other side of the boat. How? By creating an opensource platform for future new silicon development.

“There is a lot of friction in the market,” Asanovic explains. Being a professor at Berkeley University in Computer Architecture, he knows what he is talking about. “With RISC-V we want to reduce this friction in the industry. One of the problems is the IP protection and business involvement in the industry. With SiFive you don’t have to deal with complicated contracts. Users can just come and take the material that’s all published and open source and use it in their future chip design.”

Lead Opening Image

Krste Asanovic is a SiFive founder and Professor of Computer Architecture at Berkeley University.

“The Barcelona Computer Centre is showing great interest in what we are doing with RISC-V. And the UPC computer architecture department is one of the strongest architecture group in Europe. Here—and also in the rest of Europe—there is a lot of interest in RISC-V for research projects and also for possible industrial use,” says Asanovic.

HETTINGA: Can you explain what RISC-V is?

ASANOVIC: RISC-V is an instruction set architecture (ISA). An ISA is what you use to encode software to run on hardware. In the industry there are common standards like the x86 from Intel and AMD. There’s also the ARM architecture we all know from our mobile phones and tablets. RISC-V uses different encoding which is meant to be free and open so that everyone can use without paying license fee—which is unlike the existing proprietary standards. Our goal is to have an open standard anybody can use.

HETTINGA: And what’s the level of interest from the market today for RISC-V?

ASANOVIC: If you look at the market, the x86 architecture is dominant in desktops and servers. ARM is dominant in mobile phones and tablets—and it will probably remain so. But what is interesting is that there are always new markets coming along: IoT (Internet of Things) and automotive are big markets. At the high-end of the market we see storage controllers and machine learning accelerators. These are all new greenfield areas where people are looking at new chip designs. They don’t have a large legacy of software and they are open to a new instruction set—particularly ones that are free of all sorts of legal and financial strings and give them flexibility to bring new things into the controller architecture.

HETTINGA: Give us a little history of RISC and of RISC versus CISC.

ASANOVIC: The RISC architecture goes a long way back and it’s still alive. I trace the roots of RISC way back to Seymour Cray’s early machines—like the CDC 6600—from 1964. RISC machines are register rich and have a load/store architecture. They have a lot of general registers and all operations are between registers except for the memory operations. That style of machine has remained popular for over 50 years and has outlived Moore’s Law.

Meanwhile, CISC has also been around for some time. CISC was a product of the time before integrated silicon started replacing the vacuum tubes and magnetic core memory systems. It is interesting to see that over the last couple decades there has been very little new development in the CISC architecture arena. I think everyone will agree that if you start from scratch, CISC is not a great idea.

RISC-V follows the heritage of the earlier RISC processor designs developed at Berkeley University. “RISC-V” means it is the fifth generation. We started on the project in 2010 and we were tired of using commercial ISAs for research. They were sometimes too complicated for what we wanted to do, and with the IP entanglements it is very difficult to share that research with others.

As academics, we like to share our work with others. We realized we did not want to invest in proprietary architectures. Also, a lot of commercial products are not that good. There was a quality problem and we thought we could do a lot better.

The response was overwhelming and very quickly it was getting too big for Berkeley and we started the RISC-V foundation. The goal of the foundation is to maintain the RISC-V ISA standard and we have grown to over 60 companies—including the biggest names like Qualcomm, Samsung, Microsoft, Western Digital, IBM and Google.

HETTINGA: From there, how did RISC-V lead to the creation of the SiFive organization?

ASANOVIC: At Berkeley we’ve done a great deal of research into RISC architecture, involving teams and activities. They did implementations, ported the compilers and Linux and got other operating systems up and running. Having a ‘critical mass’ of graduate students working on this project allowed people from outside to pick it up and do real work with it. It started off as an idea to have a consultancy activity around RISC-V. The co-founders—Andrew Waterman and Yunsup Lee—soon realized the opportunity and that’s why I also decided to get involved as a founder.

HETTINGA: This seems to be a very significant time in the semiconductor industry. How would you characterize where we’re at today?

ASANOVIC: The semiconductor industry is in this perfect storm where we see that Moore’s Law is ending and that new technologies and developments are getting more and more expensive. There are fewer and fewer companies capable of pulling off a new design and making money out of it. At the same time there is a growth in demand for custom chips. Everybody is talking about the Internet of Things and all those devices will need a processor—and that cannot be the same processor for all solutions. There will be a growth in silicon products, but that growth will be in many fragmented markets. The old semiconductor business model—having one design and selling many millions of it— doesn’t work anymore. That has worked with the traditional computer and mobile phone markets, but the future will see perhaps hundreds of designs in lower volumes.

With SiFive we try to figure out how this works. The traditional users of the chips are now becoming the new manufacturers. Google. Microsoft, Amazon and a lot of other companies will design and make their own chips—not to sell to others, but to use them in their own products. It will allow them to add capabilities that are not available in standard off-the-shelf chips.

Our mission is to find out if we can help smaller companies and startups to do custom silicon design and invent new products with new capabilities. We believe there is a lot of untapped innovation there. But the problem is the barrier to enter custom silicon design is too high and those great ideas do not become a product. Solving that problem is the goal of SiFive.

Photo 1

SiFive’s RISC-V Arduino board makes it easy for small companies to get started with new designs.

HETTINGA: Tell us about SiFive’s RISC-V Arduino reference design board.

ASANOVIC: Our business model is to do quick developments of new chipsets and help the client to get into production at very low costs. To enable that, we made an Arduino board (at the time of the interview the new Arduino Cinque was introduced / WH) that runs very fast. And by putting it into the Arduino format a lot of small design companies will see it and can use it for new designs. The interesting thing about this product is that it will take the focus from the board to the chip level. Not only the board is open source but the chip design is too. That can open up completely new perspectives for makers, start-up companies and medium-sized businesses. All the design files of the chip are open source are on Github. This is unique in the semiconductor business. With SiFive we want to get rid of the friction in the industry. We don’t have a costly structure with NDAs and lawyers. A lower cost structure will also mean lower costs for our clients. You can come and take the designs as they are and use them.

SiFive | www.sifive.com

Don’t Miss Circuit Cellar’s Newsletter: Embedded Boards

Board-level embedded computers are a critical building block around which system developers can build all manor of intelligent systems. Circuit Cellar’s Embedded Boards themed newsletter is coming to your inbox tomorrow. COM Express mm

The focus here is on module types like Arduino, Raspberry Pi, COM Express, and other small-form-factor modules that ease prototyping efforts and let you smoothly scale up to production volumes.

Already a Circuit Cellar Newsletter subscriber? Great!
You’ll get your “Embedded Boards” themed newsletter issue tomorrow.

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

Remember, our new enhanced weekly CC Newsletter will switch its theme each week, so look for these in upcoming weeks:

Analog & Power. This newsletter content zeros in on the latest developments in analog and power technologies including DC-DC converters, AD-DC converters, power supplies, op-amps, batteries, and more.

Microcontroller Watch. 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. The Internet-of-Things (IoT) phenomenon is rich with opportunity. This newsletter tackles news and trends about the products and technologies needed to build IoT implementations and devices.

The Most Technical

Input Voltage

–Jeff Child, Editor-in-Chief

JeffHeadShotIt is truly a thrill and an honor for me to be joining the Circuit Cellar team as the magazine’s new Editor-in-Chief. And in this—my first editorial in my new role—I want to seize the opportunity to talk about Circuit Cellar. A lot of factors attracted me to this publication. But in a nutshell its position in the marketplace is compelling. It intersects with two converging trends happening in technology today.

First, there’s the phenomenon of the rich set of tools, chips, and information resources available today. They put more power into the hands of makers and electronics DIY experts than ever before. You’ve got hardware such as Arduino and Raspberry Pi. Open source software ranging from Linux to Eclipse make integrating and developing software easier than ever. And porting back and forth between open source software and commercial embedded software is no longer prohibitive now that commercial software vendors are in a “join them, not beat them” phase of their thinking. Easy access has even reached processors thanks to the emergence of RISC-V for example (click here for more). Meanwhile, powerful FPGA chips enable developers to use one chip where an entire board or box was previously required.

The second big trend is how system-level chip technologies—like SoC-style processors and the FPGAs I just mentioned—are enabling some of the most game-changing applications driving today’s markets: including commercial drones, driverless cars, Internet-of-Things (IoT), robotics, mobile devices and more. This means that exciting and interesting new markets are attracting not just big corporations looking for high volume play, but also small start-up vendors looking to find their own niche within those market areas. And there are a lot of compelling opportunities in those spaces. Ideas that start as small embedded systems projects can—and are—blossoming into lucrative new enterprises.

What’s so exciting is that Circuit Cellar readers are at the center of both those two trends. There’s a particular character this magazine has that separates it from other technology magazines. There are a variety of long-established publications that cover electronics and whose stated missions are to serve engineers. I’ve worked for some of them, and they all have their strengths. But you can tell just by looking at the features and columns of Circuit Cellar that we don’t hold back or curtail our stories when it comes to technical depth. We get right down to the bits and bytes and lines code. Our readers are engineers and academics who want to know not only the rich details of a microcontroller’s on-board peripherals, but also how other like-minded geeks applied that technology to their DIY or commercial project. They want to know if the DC-DC converter they are considering has a wide enough input voltage to serve their needs.

Another cool thing for me about Circuit Cellar is the magazine’s origin story. Back when I was in high school and in my early days studying Computer Science in college, Steve Ciarcia had a popular column called Circuit Cellar in BYTE magazine. I was a huge fan of BYTE. I would take my issue and bring it to a coffee shop and read it intently. (Mind you this was pre-Internet. Coffee shops didn’t have Wi-Fi.) What I appreciated most about BYTE was that it had far more technical depth than the likes of PC World and PC Computing. I felt like it was aimed at a person with a technical bent like myself. When Steve later went on to found this magazine—nearly 30 years ago—he gave it the Circuit Cellar name but he also maintained that unique level of technical depth that entices engineers.

With all that in mind, I plan to uphold the stature and legacy in the electronics industry that I and all of you have long admired about Circuit Cellar. We will work to continue being the Most Technical information resource for professional engineers, academics, and other electronics specialists world-wide. Meanwhile, you can look forward to expanded coverage of those exciting market-spaces I discussed earlier. Those new applications really exemplify how embedded computing technology is changing the world. Let’s have some fun.

Don’t Miss CC’s Newsletter: IoT Technology Watch

The Internet-of-Things (IoT) phenomenon is rich with opportunity. Circuit Cellar’s IoT Technology Focus themed newsletter is coming to your inbox tomorrow. The newsletter will update you on the latest news and trends including IoT gateways, IoT device security, IoT wireless connectivity and IoT cloud implementations.

Already a Circuit Cellar Newsletter subscriber? Great!
You’ll get your “IoT Technology Focus” themed newsletter issue tomorrow.

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

Remember, our new enhanced weekly CC Newsletter will switch its theme each week, so look for these in upcoming weeks:

Embedded Boards. This content looks at embedded board-level computers. The focus here is on modules (e.g., Arduino, Raspberry Pi, COM Express, and other small-form-factor modules) that ease prototyping efforts and let you smoothly scale up production volumes.

Analog & Power. This newsletter content zeros in on the latest developments in analog and power technologies including DC-DC converters, AD-DC converters, power supplies, op-amps, batteries, and more.

Microcontroller Watch. 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.

August Circuit Cellar: A Sneak Preview

The August (325) issue of Circuit Cellar magazine is jammed packed with useful technical information and inspiring, intriguing embedded electronics design stories.

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

 

Here’s a sneak preview of August Circuit Cellar:

FUN WITH GUITAR AMPLIFIERS!

Digital Guitar Amplifier/ Effects Processor—Part 2
Brian Millier details the digital guitar amplifier/effects unit he built using two Teensy Arduino modules.

A Range of Power Supplies for Hollow-State Guitar Amplifiers
Richard Honeycutt compares several different power supplies used for hollow-state guitar amplifiers.

MICROCONTROLLERS & PROCESSORS!

Firmware Upgrade with the PIC32
Nick Sicalides delves into performing firmware upgrades using a bootloader on the Microchip PIC32

Getting Started with PSoC Microcontrollers (Part 2): Putting PSoC to Work
Nishant Mittal goes even deeper on the Cypress PSoC providing some useful design examples.

Moore’s Law and the Chip Industry’s Perfect Storm
In this Interview Q&A Krste Asanovic explains RISC-V and the open sourcing of processor architecture.

SECURITY & RELIABILITY & ENCRYPTION!

Power Analysis of a Software DES Encryption Routine
Columnist Colin O’Flynn examines how to break a software implementation of the DES security routine.

Reliability and Failure Prediction: A New Take
Craig Armenti and Dave Wiens discuss a better way to simulate PCB vibration and acceleration.

Preventing Unwanted Entry
Columnist Jeff Bachiochi takes us inside his exploration of electronic lock systems, getting down to the fine details.

Future of Embedded Security: Wi-Fi to the Danger Zone
This guest essay by Adam Cecchetti, CEO of Deja vu Security, explains how memory leaks in your embedded system could have life or death consequences.

AND MORE FROM OUR EXPERT COLUMNISTS:

Automatic Control (Part 4) The Implementation
George Novacek describes the PID temperature controller he built for a meat smoker.

Fully Differential Amplifiers
Robert Lacoste sings the praises of fully differential amplifiers and presents a few designs using them.

Build an Embedded Systems Consulting Company (Part 5) Axiom Wrap-Up
Bob Japenga shares more insights on running a successful embedded design firm built to last.

Circuit Cellar Newsletters to Focus on Microcontrollers, IoT and More

Circuit Cellar’s ongoing mission is to provide important information to help you make smart choices with your engineering projects—from prototype to production. As part of that effort, we’re now offering themed newsletter content each week that focuses on critical areas of system development.

Already a Circuit Cellar Newsletter subscriber? Great!
You’ll get the first “Microcontroller Watch” themed newsletter issue tomorrow.

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

Our new enhanced weekly CC Newsletter will switch its theme each week, covering these four areas every month:

Microcontroller Watch. 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. The Internet-of-Things (IoT) phenomenon is rich with opportunity. This newsletter tackles news and trends about the products and technologies needed to build IoT implementations and devices.

Embedded Boards. This content looks at embedded board-level computers. The focus here is on modules (e.g., Arduino, Raspberry Pi, COM Express, and other small-form-factor modules) that ease prototyping efforts and let you smoothly scale up production volumes.

Analog & Power. This newsletter content zeros in on the latest developments in analog and power technologies including DC-DC converters, AD-DC converters, power supplies, op-amps, batteries, and more.

Expansion Connector Sample Kits Target Makers

Samtec has announced the release of four unique Expansion Connector Sample Kits for Makers. These new kits allow continued growth and stacking of the most popular electronics platforms using standard 0.100″ (2.54mm) centerline IDC cables, sockets and headers. Rapid prototyping of innovative projects using open-source electronic platforms typically requires basic connectors and cable assemblies.

Samtec RasberryPi3Kit

Samtec has developed Expansion Connector Sample Kits for four of the most popular platforms:

  • Arduino Uno R3 Expansion Connector Sample Kit
  • BeagleBone Black Expansion Connector Sample Kit
  • ARM mbed Application Board Expansion Connector Sample Kit
  • Raspberry Pi 3 Expansion Connector Sample Kit

Samtec | www.samtec.com

Interview: Massimo Banzi, Codeveloper of Arduino

It’s no secret that the Arduino development board has changed the way we look at working with electronics. All over the world, the little board has enabled millions of engineers, students, artists, and makers to get electronics projects up and going. We recently traveled to DotDotDot in Milan, Italy, to chat with Arduino codeveloper Massimo Banzi, who talked about the history of Arduino, the importance of makerspaces, and more.

Watch the video

Mouser Stocks STM32 LoRaWAN Discovery Board

Mouser Electronics currently offers the STMicroelectronics STM32 LoRaWAN Discovery Board. The new Discovery Kit and I-NUCLEO-LRWAN1 STM32 LoRa Arduino-compatible extension board (available to order from Mouser) offer you a development platform for learning and evaluating solutions based on LoRa and FSK/OOK radio frequency (RF) communication.Mouser_STSTM32LoRaWAN

The ST STM32 LoRaWAN Discovery Kit is based on an all-in-one Murata Type ABZ open module solution to address low-power wide area networks (LPWAN) and support the LoRaWAN long-range wireless protocol. An STM32L072 ARM Cortex-M0+ microcontroller—featuring 192 KB of flash memory, 20 KB of RAM, and 6 KB of EEPROM—powers the Type ABZ mdoule. The STM32L0 ultra-low-power microcontroller offers low-power design features, targeting battery-powered and energy-harvesting applications.

ST’s I-NUCLEO-LRWAN1 STM32 LoRa extension board includes a LoRaWAN module powered by an STM32L052 microcontroller, an SMA connector, a 50-Ω antenna, and headers compatible with Arduino Uno R3 boards. The board features three ST environmental sensors: an LSM303AGR accelerometer and magnetometer, an HTS221 relative humidity and temperature sensor, and an LPS22HB pressure sensor.

Both the Discovery board and NUCLEO board come with LoRaWAN class A-certified I-CUBE-LRWAN embedded software that enables designers to set up a complete LoRaWAN node.

Source: Mouser Electronics

Arduino-Based Liquid Level-Sensing Hardware

SST Sensing and Sparkfun recently developed an easy-to-use solution for single-point liquid detection using infrared technology. Highly accurate and reliable, the solution features an Optomax Digital liquid level switch, which is connected to an Arduino board via the TTL output and powered by the 5-V source. SST Sparkfun

Whether you’re a professional engineer or DIYer, you’ll find it easy to program the Arduino’s LEDs to indicate when the sensor is immersed in liquid (and thus determine if the liquid level is too high or low). The compact switch lends itself will to space-constrained applications. With long cabling, you can place the sensor near a liquid without putting the other electronics at risk. Since this is an optical solution, you can avoid a variety of issues (e.g., jamming and wear and tear) and ensure long operational lifespan.

SST offers the liquid level switch in a robust housing tip with either a Polysulfone or Trogamid construction (depending on the particular application requirements). The complete solution has an operational temperature range of –25°C to 80°C.

Source: SST

Arduino Program Timing

Ed Nisely explains how output pulses can reveal the progress of invisible firmware routines. After presenting a straightforward way to instrument your code, he covers the detailed timing produced by Arduino statements and functions.

While writing the Arduino program for the RGB LED lights mentioned in my May column (Circuit Cellar 310), I wondered how much time the floating-point trigonometric calculations required. Rather than wrap a software measurement around the code, I added a pair of instructions to flip an output bit, then watched the results on an oscilloscope. It’s a classic technique that helps you debug software when there’s no other way to see what’s going on inside your code or when elaborate tracing routines will disturb the firmware’s normal operation.

In this column, I’ll show a simple way to instrument your code, then take a look at the detailed timing produced by Arduino statements and functions. You’ll need an oscilloscope or logic analyzer for this technique, but even the least-expensive instruments will suffice.

FUNDAMENTAL PULSE WIDTHS

Listing 1 shows the simplest Arduino program that produces a visible output. Those two lines toggle Pin 13, the LED found on nearly all Arduino boards, to form the 5.1 µs pulses in Photo 1, with each pulse marking one iteration of the loop() that executes continuously after finishing the configuration in the setup() section. Although the oscilloscope cursor readout provides three fractional digits, the true resolution is considerably worse, because each horizontal pixel covers 0.040 µs.

LISTING 1: The simplest possible Arduino program produces a single pulse on an output bit during each loop() iteration. Although the ATmega328 microcontroller can flip a bit with a single assembly language instruction, each of these high-level functions executes dozens of assembly instructions before and after the bit changes.

LISTING 1: The simplest possible Arduino program produces a single pulse on an output bit during each loop() iteration. Although the ATmega328 microcontroller can flip a bit with a single assembly language instruction, each of these high-level functions executes dozens of assembly instructions before and after the bit changes.

The Atmel ATmega328 microcontroller can toggle an output bit with a single instruction, which makes the digitalWrite() function in the Arduino runtime infrastructure seem overly elaborate: fifteen lines of code with a path length of 12 lines. Among other tasks, the code must select and verify the hardware port, produce a bitmask selecting the pin, handle the special case of a PWM pin, and disable interrupts while manipulating the port.

PHOTO 1 Each of the digitalWrite() functions producing this pulse requires 5.1 µs, roughly 50 instructions, on the 16 MHz ATmega328 microcontroller. The Arduino loop() adds 0.40 µs to the low portion of the waveform.

PHOTO 1: Each of the digitalWrite() functions producing this pulse requires 5.1 µs, roughly 50 instructions, on the 16 MHz ATmega328 microcontroller. The Arduino loop() adds 0.40 µs to the low portion of the waveform.

Homework: Find and examine the digitalWrite() function in the Arduino source code, then explain why all that additional logic isn’t optional.

The single AVR machine-level instruction that produces the waveform in Photo 1 is located near the end of the digitalWrite() function, with most of the execution time occurring before the output changes. The high part of the pulse therefore includes the short tail end of the first digitalWrite() and the longer beginning of the second, but the output pulse width shows the execution time through the complete function.

The 16 MHz crystal oscillator on the Arduino UNO clone board I used for these measurements produces a 62.5 ns instruction cycle, so each 5 µs pulse contains about 80 cycles. Most AVR arithmetic instructions require one or two cycles, branches require two or three, and subroutine CALL/RETURN pairs soak up eight, so assuming 1.6 cycles/instruction for short subroutines seems reasonable and allows you to figure the results in your head: 10 instructions per microsecond. That means the compiler translates the dozen high-level lines of code in the digitalWrite() function into 50 machine-level instructions.

Homework: Examine the compiler’s machine-level output to determine the actual number of instructions.

The low part of the pulse occurs as execution continues through the Arduino infrastructure as the loop() returns control to the first digitalWrite() line, adding 400 ns behind the scenes. That’s only six machine cycles, perhaps three or four machine instructions, and not much overhead at all.

TRACING A MISSING PULSE

Triggering your oscilloscope on the signal produced by Listing 1 should produce a steady display, but you’ll see “ghost” traces that seem to show missing pulses. Setting the trigger to produce single sweeps will eventually produce a display similar to Photo 2, with an obviously missing pulse.

PHOTO 2: A “missing pulse” occurs when a timer interrupt executes additional instructions that don’t appear in the user program. The interrupt can also occur when the pulse is high, causing an unexpectedly long pulse.

PHOTO 2: A “missing pulse” occurs when a timer interrupt executes additional instructions that don’t appear in the user program. The interrupt can also occur when the pulse is high, causing an unexpectedly long pulse.

Because the program’s logic (if you can call it that) lacks branches that could omit a pulse, the problem must lie elsewhere. Carefully examining the pulse timings shows that there’s not quite enough time for another pulse in that gap, which means the extended time came from a delay, rather than an omission.

The Arduino infrastructure includes a millis() function that reports the elapsed time in milliseconds since the microcontroller emerged from its most recent reset. A timer interrupt occurs every millisecond, with the interrupt handler updating a counter that the millis() function returns to the caller in a four byte unsigned long integer.

Because the loop() in Listing 1 iterates every 10.4 µs, the timer interrupt will occur once in every 96 pulses, stretching either the high or low part of the pulse. The advantage of an oscilloscope should be obvious: a problem that occurs 1% of the time might not appear amid all the “correct” values shown by a simple software measurement.

The if() statement in Listing 2 determines whether the return value from millis() has changed and, if so, produces a pulse on Pin 11. The lower trace in Photo 3 shows that pulse, with the oscilloscope triggering a single sweep on that pin and the trigger point at the middle of the screen. The upper trace comes from Pin 13, as before, and shows the same “missing” pulse due to the timer interrupt handler.

LISTING 2: The millis() function returns the number of milliseconds since the microcontroller emerged from the most recent reset. The comparison will be false 98.7% of the time, but that test adds 2 µs to the average loop() time.

LISTING 2: The millis() function returns the number of milliseconds since the microcontroller emerged from the most recent reset. The comparison will be false 98.7% of the time, but that test adds 2 µs to the average loop() time.

The cursors bracketing the 7.4 µs pulse in the upper trace show that the if() statement adds 2.3 µs to the execution time of the code in Listing 1, even when the value of millis() doesn’t change. The CPU uses those 35 clock cycles and two dozen instructions to call the millis() function, test its return value, then branch around the code inside the conditional block. You can see the effect of every instruction at this time scale!

PHOTO 3: The pulse in the lower trace shows that the “missing pulse” occurs when the return value of the millis() function changes. Testing the millis() value increases the loop() duration, as shown comparing the pulses in the top trace to those in Photo 2.

PHOTO 3: The pulse in the lower trace shows that the “missing pulse” occurs when the return value of the millis() function changes. Testing the millis() value increases the loop() duration, as shown comparing the pulses in the top trace to those in Photo 2.

The long pulse in the middle of the upper trace shows what happens just after the timer interrupt occurs: detecting the change, generating the sync pulse in the lower trace, and updating the Millis_Previous variable requires 22 µs, roughly 15 µs and 150 instructions more than the previous code.

A logic analyzer can trigger a capture based on the Boolean combination of many inputs, a situation that depends on having access to all those signals. A microcontroller buries those signals inside the CPU, where combining them into a trigger requires software, rather than hardware. A similar situation occurs with gate array logic, where a dab of additional logic inside an FPGA can generate suitable triggers, if you have a spare output pin, and may be the only way to isolate elusive glitches due to combinations that occur so rarely as to be invisible.

Homework: Move the statement that updates Millis_Previous between the two digitalWrite() functions, then measure the change in pulse width to determine the time required to update that variable.

As the number of statements inside the loop() increases, the likelihood that the timer interrupt will occur during the program also increases. This won’t make any difference to most programs, but when you’re watching a pulse on the oscilloscope, you don’t want a timer interrupt disturbing your measurements. The code in the next few examples will disable all interrupts just before raising the timing pulse and enable them after lowering it, forcing the timer interrupt to occur outside the critical section.

Download the entire article. This article appeared in Circuit Cellar 316 November 2016.

Ed Nisley is an electrical engineer and author in Poughkeepsie, NY. He has been writing for Circuit Cellar since Circuit Cellar 1, 1988. His regular column, “Above the Ground Plane,” appears every other month in Circuit Cellar magazine.

Tips for Predicting Product Reliability

British Prime Minister Benjamin Disraeli (1804–1881) once uttered: “There are lies, damned lies, and statistics.” I don’t say statistics lie, but not everything presented to us as a result of statistical analysis is necessarily true. Statistics are instrumental for investigation of many scientific and social subjects, but they’re just a tool. Incorrectly used, their results can be wittingly or unwittingly skewed and potentially used to prove or disprove just about anything.

One use of statistics in engineering is to predict product reliability, a topic I’ve addressed in several of my previous columns. In this article, I’ll investigate it further.

PREDICTED RELIABILITY

Predicted reliability is a probability of a product functioning without a failure for a given length of time. It is usually presented as a failure rate λ (Greek letter lambda) indicating the probable number of failures per million hours of operation. Its reciprocal Mean Time Between Failures (MTBF) or Mean Time to Failure (MTTF for irreparable products) is often preferred because it is easier to comprehend.

Having determined a product’s reliability, we can establish its criticality, the likely warranty and maintenance costs as well as to plan repair activities with spare parts quantities and their allocation. Figure 1 is the ubiquitous reliability bath tub curve. The subject of our discussion is the period called “Constant Failure Rate.”

Figure 1: Reliability bath tub curve.

Figure 1: Reliability bath tub curve.

Predicted reliability is not a precise number. It is a probability with less than 100% certainty that the product will work for the specified time. Unfortunately, many buyers, program managers, even design engineers do not recognize this and expect the predicted failure rate to be a certainty.

Most engineers aren’t expert statisticians, nor can every design organization afford such specialists on staff. Historical data to perform reliability prediction are rarely adequate in small companies. Luckily, the US military made the reliability prediction easy to calculate by following their Military Handbook: Reliability of Electronic Equipment (MIL-HDBK-217), now in version F (www.sre.org/pubs/Mil-Hdbk-217F.pdf), based on data collected over many years.

The general method for calculating failure rate during the development stages is by parts count which, once all design details are known, is refined by parts’ stress analysis.

With the parts count method, the predicted failure rate is:Novacek 314 EQ1

In this equation, λEQUIP is the total equipment failures per million hours. λg is the generic failure rate for ith generic part. πQ is the quality factor for ith generic part. Ni quantity of ith generic part. n is the number of different generic part categories in the equipment. Using a spreadsheet, for example, you follow the Military Handbook by calculating failure rates for individual components.

A typical component failure rate model is:Novacek 314 EQ2

In this equation, λp is the part’s failure rate. λb is the part’s base failure rate. p are factors modifying the base rate for stress, application, environment, and so on.

The Military Handbook provides tables with statistical data for components’ base failure rate and all the pertinent p factors. It is one of several methods for calculating predicted reliability. I was interested to see how some different statistical methods compare with each other. For my inquiry I selected an Arduino Uno, which many readers are familiar with (see Photo 1). Not having the Arduino’s design details, I estimated operating conditions. Because I used the same estimates for all the calculations, the relative comparison of the results is valid, while the absolute value may be somewhat off.

Photo 1: Arduino Uno

Photo 1: Arduino Uno

I have a number of Arduino boards, Duemilanove and Uno, which are quite similar, and through the years have collectively clocked over 600,000 hours of continuous operation without a single failure (including all their peripheral circuits which are not, however, included in my calculations). Several of my Arduinos have worked in the garage with the recorded ambient temperature ranging from –32°C (–25.6°F) to 39°C (102.2°F), which falls under the military category “ground fixed” (GF) environment. I used this for my calculations. While components’ failure rates generally increase exponentially with temperature, operation below about 50°C (122°F) does not significantly increase the stress over a room temperature, so there would not be a significant difference in failure rate between those Arduinos working in the garage and those inside the house.

CALCULATIONS

I performed two manual calculations according to MIL-HDBK-217F and one per HDBK 217 Plus using Mathcad. The failure rate of Item 1 in Table 1 was calculated per MIL-HDBK-217F for commercial parts. The MIL handbook has been criticized for two shortcomings. First, for the unrealistic penalty on commercial parts by today’s quality standards as compared to the military-screened parts. This is understandable in view of the second shortcoming: that the handbook has not been updated since 1995. At that time, component manufacturers discontinued screening their parts for military compliance, but simultaneously and up to the present, have been improving quality of manufacturing processes, thus increasing components’ reliability. Based on experience, I modified the components’ quality factors and the result is shown by Item 2.

Table 1: Calculated reliability of Arduino Uno

Table 1: Calculated reliability of Arduino Uno

There are a number of commercially available programs to aid in reliability prediction calculations. You only need to input the bill of material (BOM) with the components’ operating specifics, such as the temperature, derating, and so forth. The programs have built-in databases and do the calculations for you. Those programs are powerful, and in addition to the predicted failure rate, they can generate analyses such as Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA), and others. Sadly, they are not inexpensive.

As there are different methodologies for calculating the predicted failure rate, these programs allow you to select which methodology you want to use. I performed 10 calculations for the same Arduino BOM and operating conditions by three computer programs per MIL-HDBK-217F, HDBK 217 Plus, Bellcore, Telcordia, Siemens, PRISM (which I believe is based on HDBK 217 Plus), and FIDES 2009 methodologies.

The results fall into two fairly consistent groups, roughly an order of magnitude (discounting Item 1) apart. Table 1 lists the calculated results and Figure 2 its graphic representation. Figure 2 displays the MTBF rather than the failure rate, which is easier to visualize.

Figure 2: Results tabulated in Table 1 shown graphically output.

Figure 2: Results tabulated in Table 1 shown graphically output.

As I already said, I discounted Item 1 which only demonstrates the MIL-HDBK-217F obsolete bias towards commercial parts. Items 3 and 4 show that the MIL-HDBK-217F implementation by commercial programs and my own adjustment, Item 2, are reasonably close. So are items 8, 10, and 13. These methodologies are geared towards tough military/aerospace applications and, therefore, I suspect, their statistical treatment is more conservative than that of Items 5, 6, 7, 11, and 12, which show the predicted MTBF up to more than a decade greater.

We should remind ourselves what those MTBF numbers mean. One hundred thousand hours MTBF represent 11.5 years of continuous operation! That’s a long time. It would be 23 years if operated only 12 hours daily. Many products become obsolete or fall apart before then. Consequently, I am rather skeptical about the predicted 578 years MTBF of Item #11.

Bellcore methodology was developed for telephone equipment, FIDES 2009 is the result of the efforts of the European aerospace manufacturers and the results are close to MIL-HDBK-217F. HDBK 217 Plus, Telcordia, Siemens and PRISM provided results by an order of magnitude greater.

It is important to strive for a realistic predicted failure rate because other analyses, not to mention design and manufacturing costs, warranty and spare parts allocation are affected by it. Later refinements of the calculated prediction by stress analyses, reliability testing and especially field experience should bring us close to the real value.

CHOOSE A METHOD

Which methodology should you use? My customers have always required MIL-HDBK-217, so I never had the headache of having to make and then justify my own choice. Despite its age, MIL-HDBK-217 continues to be alive and well to this day in the aerospace and military industries. In comparison with the results of Items 5, 6, 7, 9, 11, 12 MIL-HDBK-217 seems rather conservative, but when it comes to safety critical designs I much rather err on the safe side. My experience with the Arduinos doesn’t provide sufficient data to draw a general conclusion, although it appears to be better than the MIL-HDBK-217 predicts.

Ultimately, the field results will be the only thing that counts. All the calculations will be meaningless if the product’s reliability in field is not as required by the customer’s specification. Then you will be called upon to fix the design or the manufacturing process or both.

Reliability calculations differ from methodology to methodology, but if you are consistent using the same methodology, those numbers, coupled with experience, will enable you to judge what the field results will be. All my MTBF calculations met the specifications, but the field results have always exceeded those calculations. And that’s what really counts in the end.

George Novacek is a professional engineer with a degree in Cybernetics and Closed-Loop Control. Now retired, he was most recently president of a multinational manufacturer for embedded control systems for aerospace applications. George wrote 26 feature articles for Circuit Cellar between 1999 and 2004. Contact him at gnovacek@nexicom.net with “Circuit Cellar” in the subject line.

Build an Accurate Milliohm Meter

A milliohm meter is a handy benchtop tool for measuring small electrical resistance values. In this article, Mark Driedger details how to build a microcontroller-based milliohm meter that accurately measures DC resistance from 10 mΩ to 10 kΩ.


I built an Arduino-based milliohm meter that accurately measures DC resistance from 10 mΩ to 10 kΩ. I used careful design techniques to cancel many error sources rather than resort to costly components. The milliohm meter is useful for tasks such as measuring transformer and inductor winding resistance, ammeter current shunts, and resistance of PCB tracks.

The finished milliohm meter

The finished milliohm meter

Measurement Method

The milliohm meter calculates the value of the resistor under test (Rx) by measuring the voltage across it and the voltage across a series-connected, known reference resistor (Rr) when driven by a test current. The measured resistance is simply: Rx = Vx/Vr × Rr.

A technique called synchronous rectification (also known as a lock-in amplifier) is used to enhance accuracy. The direction of the test current is alternated and measurements of Vx and Vr are made synchronously with the change in direction of the test current. As we will see, this cancels a number of error sources and is easy to implement on the Arduino.

Synchronous rectification can be thought of as narrowband filter at the switching frequency, implemented using a mixer (multiplier) at the switching frequency followed by a low-pass filter at DC (averaging). Normally, the switching frequency would be high enough (say, 1 kHz) to allow AC-coupled, high-gain amplifiers to be used and to move the filter passband well away from induced 60-Hz AC line voltages. In this implementation, the relatively slow ADC conversion speed prevents us from using a high switching frequency. However, we retain many other benefits of synchronous rectification with regard to reducing measurement error and we gain accuracy improvement in other ways.

Implementation

An Arduino is used to control the synchronous rectification, read voltages Vx and Vr, and then compute and display the test resistor value. The test current is derived by paralleling four I/O pins through current-limiting resistors for each of the source and sink legs.

sad dsg

The circuitry

This increases the test current to roughly 100 mA, which is still well within the 40 mA/pin and 200 mA/chip limits of the Arduino processor, and the 150 mA limit of the Pro Mini’s onboard voltage regulator. The source and sink legs are alternately driven high and low to produce the test current.

sdfg sdgf

A look inside the meter

Measurement of Vx and Vr is made with an Analog Devices ADS1115 ADC, which has two differential inputs, a programmable gain amplifier (PGA) with 16× maximum gain, and 16-bit accuracy in a very small 10 MSOP package. The device costs between $10 and $15 on a small PCB module. Series resistors and film capacitors on the analog inputs provide some overload protection and noise filtering. At the highest gain, the meter resolution is approximately 75 µΩ/bit. Each measurement consists of two cycles of synchronous rectification, with 100 samples per cycle for a total of 200 samples.

An OLED module with an I2C interface is used for the display, although other options can be substituted with corresponding code changes. The meter is powered by a 9-V battery. Battery voltage is read through one of the analog input ports. Measurements are initiated with the push of the test switch to maximize battery life and minimize self-heating errors in the reference resistor. Each measurement takes roughly 2 s. Purchased modules are used for the Arduino, ADS1115 ADC, and the 64 × 128 OLED display, making it very easy to build.

OLED

OLED for displaying data

Construction

The meter is built using purchased modules and a small piece of protoboard for the shield. The ADC and display modules are available from multiple sources, and you can use any Arduino module of your choosing. (The photos and layout are for the Pro Mini.) Keep the ADC analog input wiring short and away from the processor. Use a four-wire connection to the reference resistor. Solder the drive leads farthest from the body, and the sense leads closer. The display module is mounted on the reverse side of the protoboard. The SDA/SCL I2C connections are brought from the Arduino module to the protoboard with a short cable and connector since they are not on the regular 0.1” grid.

dsf dsf

Protoboard layout

The ADS1115 module includes the pull-ups that are needed on the I2C interface lines (SDA, SCL).  I used a six-pin GX-16-6 connector for the probes. The additional two pins were used to close the battery circuit on the ground side, turning the meter on and off when the probes are connected.


The complete article appears in Circuit Cellar 314 (September 2016).

Mark Driedger has been experimenting with tube audio and electronics for over 35 years. His earned a BSc and MSc in Electrical Engineering in his native Canada. Mark has worked in the telecom industry for the past 28 years in various technical, business, and executive roles. He is currently COO for Procera Networks and lives in Dallas, TX.

FTDI Arduino-Compatible Touch-Enabled Display Shield Now Shipping

FTDI Chip recently announced the widespread availability of its originally crowdfunded CleO product (and accompanying accessories). FTDI Chip also offers access to software tools, step-by-step tutorials, and projects. FTDI CleOCleO is a simple to program, intelligent TFT display solution that for building human machine interfaces (HMIs) with higher performance than typical Arduino display shields. The initial CleO includes an HVGA resolution, 3.5″ TFT display featuring a resistive touchscreen. An FTDI Chip FT810 high-resolution embedded video engine (EVE) graphic controller executes the HMI operation. An FTDI FT903 microcontroller handles all the additional processing tasks. The advanced display shield provides high-quality graphical animation, even at 60-fps frame rates. In addition, its antialiased graphics capabilities render images in finer detail.

When CleO is combined with FTDI Chip’s NerO—which is an energy-efficient Arduino design capable of operating up to 1 W—it offers a far more powerful solution than a normal Arduino UNO/display shield package.

CleO has an array of useful accessories:

  • AT 57.15 mm × 54.35 mm, the CleO-RIO module provides a mechanism for stacking the CleO shield and an Arduino board together.
  • The CleO-Speaker module (63 mm × 63 mm × 23.8 mm) facilitates the playback music/tones for HMIs where audio functionality has been incorporated. There is also an audio line for input of audio from external sources.
  • The CleO-Camera module has an OV5640 0.25″ 5-megapixel CMOS image sensor plus flash LEDs and a 24-pin 0.5-mm pitch FFC cable.
  • A 9-V power adaptor provides the NerO/CleO solution with up to 1 A of current.

The CleO costs $69. Refer to FTDI’s new forum, www.CleOstuff.com, for design tips, application ideas, and more.

Source: FTDI Chip