Use Arduino BOBs to Quickly Evaluate Sensors and Peripherals

By Clive "Max" Maxfield

Contributed By Digi-Key's North American Editors

The rise of the Internet of Things (IoT) has inspired many innovative startups looking to connect the next big thing. However, many of these startups have smaller and leaner design teams, yet still face ever tighter time to market constraints. As a result, individual designers are being stretched across multiple engineering domains and tasks, including analog, digital, radio frequency (RF), and wireless/wired networking. Naturally, they are constantly on the lookout for ways to accelerate and lower the cost of evaluating ICs, sensors, and peripherals.

One option is to use evaluation and development kits provided by IC vendors to support their solutions. Assuming there’s a good degree of support, this is a perfectly fine approach. However, another option is to look at the Arduino ecosystem. This has evolved from a hobbyist’s playground to a full-fledged design and support ecosystem.

This article will show how designers can use Arduino to start evaluating ICs, peripherals and sensors early on in the design cycle using open source hardware in the form of sensor and peripheral breakout boards (BOBs), in conjunction with open source software in the form of libraries and example programs. As an example, it will use real-time clocks (RTCs) from Maxim Integrated and BOBs from Adafruit Industries

The rise of the IoT

One of the first real examples of the IoT dates from the early 1980s when a Coca-Cola machine at Carnegie Mellon University was wired up so programmers could use the internet to check if drinks were available and if they were cold, before actually visiting the machine. The IoT as a concept wasn’t officially named until 1999.

The exact time the IoT really came into being is subject to debate. Perhaps the best definition of the birth of the IoT as we know it is, “That point in time when more “things” or “objects” were connected to the internet than people”. On this basis, it is estimated that the IoT was born sometime between 2008 and 2009, with the things/people ratio growing from 0.08 in 2003 to 1.84 in 2010.

The rise of the Arduino

The gestation of the IoT coincided with the rise of the maker movement in the early 2000s. The first worldwide deployment of the Arduino took place in 2005, which was the same year that Make magazine launched, and only one year before the first Maker Faire took place.

Since its inception, the Arduino has evolved sophisticated open source software and hardware ecosystems. What was required was a way to bring the well-supported ecosystems of Arduino into the realm of professional designers to simplify their jobs and speed time to market.

In fact, the solution came about organically: the huge ecosystem that grew around the Arduino spawned an unanticipated side-effect – professional engineers using the Arduino to evaluate sensors and peripherals before deploying them in their own designs. There are many examples of this now, such as an RTC.

Example peripheral evaluation using an RTC

Nearly every modern 32-bit microcontroller comes with an integrated RTC, as do many 16-bit and even 8-bit microcontrollers. Although this shrinks the board real estate, reduces the bill of materials (BOM), and decreases the cost of the final product, using an internal RTC does have disadvantages.

One disadvantage is that the microcontroller has to enable and disable its internal RTC under software control, so if something occurs like a power glitch and the microcontroller locks up or its code wanders off into the weeds, the RTC could be inadvertently disabled. By comparison, an external RTC is considered more robust as it has a separate power rail and crystal, and it’s less likely to be turned off accidentally by the code running on the microcontroller. Furthermore, the external RTC is typically implemented using a larger chip fabrication process node than is the microcontroller, and its larger silicon footprint makes it less susceptible to bit-flips, i.e., single event upsets (SEUs) caused by radiation, such as cosmic rays.

Example RTC ICs: Maxim Integrated DS1307 and DS3231

Two very popular RTC ICs are the DS1307 and DS3231 from Maxim Integrated. Both of these devices keep track of seconds, minutes, hours, day, date, month, and year information; automatically adjust for months with less than 31 days; take account of leap years; and support 24- or 12-hour modes. Also, both devices communicate with the host microcontroller by means of a serial I2C bus, and they include a sense circuit that detects power failures and automatically switches over to the backup supply (usually a battery), in which case timekeeping operations are able to be maintained (Figure 1).

Diagram of Maxim DS1307 external RTCFigure 1: The DS1307 is a good example of an external RTC. These have the advantage of having their own local crystal and power rail, as well as not being subject to code misfires. It communicates with the host microcontroller over an I2C interface. (Image source: Maxim Integrated)

Of course, it's important to check the datasheets to determine the differences between these devices. For example, the DS1307 requires a 5 volt supply along with an external crystal. By comparison, the more precise DS3231 can operate with a supply from 2.3 to 5.5 volts and comes equipped with an integrated temperature-compensated crystal oscillator (TCXO) and crystal.

Sometimes, differences between these components aren’t immediately obvious. For instance, both devices provide an SQW (square wave) output, which, if activated under software control, requires an external pull-up resistor. However, in the case of the DS1307, the SQW output can be programmed to generate a 1 Hertz (Hz), 4.096 kilohertz (kHz), 8.192 kHz, or 32.768 kHz signal. By comparison, in the case of the DS3231, this output can be programmed to generate a 1 Hz, 1,024 kHz, 4.096 kHz, or 8.192 kHz signal.

In the case of the DS1307, the accuracy of the clock is dependent upon the accuracy of the crystal and the accuracy of the match between the capacitive load of the oscillator circuit and the capacitive load for which the crystal was trimmed. By comparison, the temperature-compensated DS3231 has a more specific accuracy figure of within ±2 minutes per year from -40°C to +85°C (Figure 2).

Diagram of Maxim DS3231 temperature-compensated crystal oscillatorFigure 2: The DS3231 is a temperature-compensated crystal oscillator with an accuracy of ±2 minutes per year over a temperature range of -40°C to +85°C. (Image source: Maxim Integrated)

So, assuming that there are no "deal breakers" between these two devices datasheet-wise, how would designers go about evaluating them in the real world? One solution would be to design and build custom breakout boards (BOBs), and to also develop the code to drive them from the ground up. A faster and more cost-effective solution would be to use off-the-shelf BOBs and code developed as part of the Arduino hardware and software ecosystems.

Example RTC BOBs: Adafruit DS1307 and ChronoDot

Two popular BOBs for the DS1307 and DS3231 ICs are the Adafruit 3296 DS1307 Real-Time Clock BOB (Figure 3) and the 255 ChronoDot Ultra-Precise Real-Time Clock V2.1 BOB (Figure 4).

Image of Adafruit DS1307 RTC BOBFigure 3: Adafruit DS1307 RTC BOB. (Image source: Adafruit Industries)

Image of ChronoDot Ultra-Precise Real-Time Clock v2.1 BOBFigure 4: ChronoDot Ultra-Precise Real-Time Clock v2.1 BOB. (Image source: Adafruit Industries)

When coupled with an appropriate microcontroller development board, such as an Arduino Uno R3 for example, in conjunction with open source libraries and example code that can be downloaded over the internet, professional designers of embedded systems and IoT devices are immediately prepared to hit the ground running.

Once the designers' evaluations are complete, they can take appropriate portions of the open-source hardware designs for the BOBs and incorporate these portions directly into their own designs. Similarly, they can take the open source libraries and the code they developed based on the open source examples and use them as part of their products.

Hardware tips and tricks for software developers

As was previously noted, both the DS1307 and DS3231 RTCs communicate with the host microcontroller via a serial I2C bus. One of the "gotchas" that often bites software developers is that both the signals forming this bus (named SCL and SDA) require pull-up resistors.

Neither the DS1307 or the DS3231 (ChronoDot) BOB from Adafruit includes these resistors, although the ChronoDot does include pads with R1 and R2 annotations where they can be added.

The reason for not including pull-up resistors is that an I2C bus can have multiple devices (ICs or BOBs) attached to it. The I2C bus uses a 7-bit address, where 27 = 128. However, address 0000000 is a general call address that is used to address all the devices on the bus, leaving the bus theoretically capable of supporting 127 discrete devices. In practice, the real number of devices that can be supported is dictated by the capacitance of the bus, including the capacitance of the traces and the loads, which is limited to a total of 400 picofarads (pF).

There is a formula that hardware designers use to calculate the equivalent value of multiple resistors connected in parallel. For the purposes of these discussions, we can consider a simple example as follows. If two devices have pull-up resistors of the same value, the resulting resistance is half the value; if four devices have pull-up resistors of the same value, the resulting resistance is one quarter of the value.

If there is already an I2C device with pull-up resistors on the bus, then no further action need be taken. If no pull-up resistors are present, and the designer is 100% sure they won’t be adding a BOB with on-board pull-up resistors in the future, then it’s best to use a pair of 4.7 kiloohm (kΩ) resistors for the pull-ups. However, if there is a chance a BOB with pull-up resistors will be added in the future, then a pair of 10 kΩ resistors should be added at this point because these will work both before and after the other BOB is added to the bus.

Software tips and tricks for hardware designers

The "wire library" is a communications library that facilitates two-wire class communications with I2C devices. In the case of the Arduino, this is delivered as part of the integrated development environment (IDE), so all a designer has to do is add the statement #include <Wire.h> at the beginning of the program.

The real trick is to track down a suitable RTC library. One good one is Adafruit's RTClib, which can be downloaded from Github. Next, add the statement #include "RTClib.h" at the beginning of the program.

Later, usually after any constant values have been defined, it’s time to instantiate (create an instance of) the RTC using the statement RTC_ DS1307 RTC; or RTC_DS3231 RTC; depending on the BOB being used.

Still later, when setting everything up in their program (as part of the setup() function in the case of an Arduino sketch), designers need to add the statements Wire.begin(); and RTC.begin(); to initialize the I2C communications and the RTC subsystem.

The examples provided on the aforementioned Github page will quickly get a designer up and running with regard to accessing and adjusting the current date and time. What's less obvious is how to access the SQW (square wave) output. By default, this output is inactive to save power. One way in which this pin can be used is to make it active and set it running at 1 Hz, for example, and then use this signal to trigger an interrupt on the host microcontroller.

A software developer will have no difficulty tracking all of this down in the library code; however, wading through this code can be more problematic for a hardware design engineer, so a brief summary is as follows:

In the case of the DS1307, all that needs to be added are one or more statements of the form RTC.Ds1307SqwPinMode(<option>); where supported option values are ON, OFF, SquareWave1HZ, SquareWave4kHz, SquareWave8kHz, and SquareWave32kHz.

Similarly, in the case of the DS3231, add one or more statements of the form RTC.Ds3231SqwPinMode(<option>); where supported option values are ON, OFF, DS3231_SquareWave1Hz, DS3231_SquareWave1kHz, DS3231_SquareWave4kHz, and DS3231_SquareWave8kHz.


With smaller teams and tighter time to market constraints, designers have to embrace multiple engineering domains and tasks and be constantly looking for ways to accelerate and lower the cost of evaluating ICs, sensors, and peripherals. As shown, one way is to use the Arduino along with open source hardware in the form of sensor and peripheral breakout boards (BOBs), in conjunction with open source software in the form of libraries and example programs.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Clive "Max" Maxfield

Clive "Max" Maxfield received his BSc in Control Engineering in 1980 from Sheffield Hallam University, England and began his career as a designer of central processing units (CPUs) for mainframe computers. Over the years, Max has designed everything from silicon chips to circuit boards and from brainwave amplifiers to steampunk Prognostication Engines (don't ask). He has also been at the forefront of Electronic Design Automation (EDA) for more than 30 years.

Max is the author and/or co-author of a number of books, including Designus Maximus Unleashed (banned in Alabama), Bebop to the Boolean Boogie (An Unconventional Guide to Electronics), EDA: Where Electronics Begins, FPGAs: Instant Access, and How Computers Do Math. Check out his “Max’s Cool Beans” blog.

About this publisher

Digi-Key's North American Editors