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.
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.
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
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.
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.
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.
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.
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.
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.
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!
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.
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.
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 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.”
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.
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.
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.
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.
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.
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.
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 email@example.com with “Circuit Cellar” in the subject line.
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 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.
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.
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.
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.
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.
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 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. CleO 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
Nordic Semiconductor recently announced that Arduino’s new Arduino Primo features its nRF52832 Bluetooth low energy SoC. The IoT-targeted Arduino Primo PCB features native Bluetooth low energy wireless connectivity and includes Near Field Communication (NFC), Wi-Fi, and infrared (IR) technologies. In addition to being able to wirelessly connect to a wide array of Bluetooth low energy sensors, the Arduino Primo uses the nRF52832 SoC’s integrated NFC for secure authentication and Touch-to-Pair (a simple BLE pairing function requiring no user interaction), and has embedded IR for traditional remote control.
The Nordic nRF52832 SoC’s ARM processor has ample computational overhead to manage the Arduino Primo’s on-board accelerometer, temperature, humidity, and pressure sensors. The Nordic Semiconductor nRF52832’s features and specs include:
- 64-MHz, 32-bit ARM Cortex-M4F processor
- 2.4-GHz multiprotocol radio that’s fully compatible with the Bluetooth 4.2 specification and features –96-dB RX sensitivity and 5.5-mA peak RX/TX currents
- 512-KB flash memory and 64-KB RAM, and a fully-automatic power management system to optimize power consumption.
You can program via the Arduino Integrated Development Environment (IDE) programming interface. If you want to access the Arduino Prio’s most advanced features and functionality, you can use any Nordic nRF52 Series-compatible Software Development Kit (SDK) or programming tools. For example, the nRF5 SDK for IoT enables you to develop IPv6 over Bluetooth low energy applications on the nRF52832 SoC.
Source: Nordic Semiconductor
Attendance at the recent Embedded World 2016 conference in Nuremberg, Germany, increased 17% (30,063 trade visitors) over 2015. Wisse Hettinga was in attendance and took notes on some of the more interesting technologies on display. He writes:
Controllino: Open-Source PLC
Say “ino” and most engineers and electronics enthusiasts will think, “Arduino.” That also goes for “Controllino,” which is a programmable logic controller (PLC) based on Arduino hardware and software. Marco Riedesser started developing this new product after he repaired a coffee machine with parts he designed. His Controllino is intended for the new generation of automation experts who grew up with the Arduino platform. The Controllino is 100% compatible with the Arduino platform and makes use of the SDK. And, perhaps most importantly, it is an open development system. For more information, visit https://controllino.biz/.
NXP Semiconductors knows that innovative new technologies don’t appearing out of the blue, which is why it created the Hexiwear wearable development platform. Along with MikroElektronika, NXP is promoting this new piece of hardware to the design community via a Kickstarter campaign.
Due to its compact design, you can use the Hexiwear as a watch or, if you need more functionality, you can click it onto the developer’s main board. The open-source Hexiwear’s features and specs include:
- NXP Kinetis K64 MCU (ARM Cortex-M4, 120 MHz, 1M Flash, 256K SRAM)
- BLE NXP Kinetis KW40Z multimode radio SoC (ARM Cortex-M0+, Bluetooth Low Energy & 802.15.4 Wireless MCU)
- NXP FXOS8700CQ 3-D accelerometer and 3-D magnetometer
- NXP FXAS21002 three-axis digital gyroscope
- NXP MPL3115A2R1 absolute digital pressure sensor
- NXP MC34671 600-mA, single-cell li-ion/li-polymer battery charger
- TAOS TSL2561 light-to-digital converter
- MEAS HTU21D digital humidity and temperature sensor
- Maxim MAX3010x heart-rate sensor
- Haptic feedback engine
- 190-mAh 2C li-po battery
- Capacitive touch interface
- 1.1″ full color OLED display
- RGB LED
- 8 MB of additional flash memory
Intel Edison, What Did You Make?
When the Edison board was launched in 2014, it drew quite some attention from the community of makers. The board was heavy specified, wearable, and IoT ready. It allowed quick prototyping and the close connections with the Arduino world promised a smooth introduction into the world of designers and entrepreneurs with great ideas for the future. The module also came with seriously high price tag.
In the first months after the launch, there was a lot of interest. Some projects made it to the headlines, but things eventually quieted down around the platform. Was it the price, or was it the fact that the world of the x86 is different from the world of AVR or ARM? Or perhaps you need Linux knowledge to dig deeper into the system?
Embedded World 2016 in Nuremberg was a good opportunity to learn about the board’s status. According to Intel’s Ken Caviasca (VP in the IoT Group and GM of platform engineering and development), it is clear that Intel is still serious about addressing the makers community with the Edison module. A new board was announced on the Intel Developers Conference and the initiative is alive and well. Intel’s main objective for the Edison board is to get designers involved and to pick up new interest in the x86. Caviasca confirmed that the Edison project is on target and many makers are using the platform for their designs. With a confident Intel about the future of Edison, a big question remains: What will you make with it?
The Arduino single-board computer is a de facto standard tool for developing microcomputer applications within the hobbyist and educational communities. It provides an open-source hardware (OSH) environment based on a simple microcontroller board, as well as an open-source (OS) development environment for writing software for the board.
Here’s an approach that enables Arduino code to be configured for execution with the Microchip Technology PIC32MX250F128B small-outline 32-bit microcontroller. It uses the Microchip Technology MPLAB X IDE and MPLAB XC32 C Compiler and the Microchip Technology Microstick II programmer/debugger.
Your own reasons for using this approach will depend on your personal needs and background. Perhaps as a long-term Arduino user, you want to explore a new processor performance option with your existing Arduino code base. Or, you want to take advantage of or gain experience with the Microchip advanced IDE development tools and debug with your existing Arduino code. All of these goals are easily achieved using the approach and the beta library covered in this article.
Several fundamental open-source Arduino code examples are described using the beta core library of Arduino functions I developed. The beta version is available, for evaluation purposes only, as a free download from the “Arduino Library Code for PIC32” link on my KibaCorp company website, kibacorp.com. From there, you can also download a short description of the Microstick II hardware configuration used for the library.
To illustrate the capabilities in their simplest form, here is a simple Blink LED example from my book Beginner’s Guide to Programming the PIC32. The example shows how this custom library makes it easy to convert Arduino code to a PIC32 binary file.
ARDUINO BLINK EXAMPLE 1
The Arduino code example is as follows: Wire an LED through a 1-K resistor to pin 13 (D7) of the Arduino. An output pin is configured to drive an LED using pinMode () function under setup (). Then under loop () this output is set high and then low using digitalWrite () and delay () functions to blink the LED. The community open-source Arduino code is:
PIC32 EXAMPLE 1 CODE MODIFICATIONS
The open-source example uses D13 or physical pin 13 on the Arduino. In relation to the PIC32MX, the D13 is physical pin 25. Pin 25 will be used in prototyping wiring.
Now, let’s review and understand the PIC32 project template and its associated “wrapping functions.” The Arduino uses two principal functions: setup () to initialize the system and loop () to run a continuous execution loop. There is no Main function. Using the Microchip Technololgy XC32 C compiler, we are constrained to having a Main function. The Arduino setup () and loop () functions can be accommodated, but only as part of an overall template Main “wrapping” function. So within our PIC32 template, we accommodate this as follows:
This piece of code is a small but essential part of the template. Note that in this critical wrapping function, setup () is called once as in Arduino and loop () is configured to be called continuously (simulating the loop () function in Arduino) through the use of a while loop in Main.
The second critical wrapping function for our template is the use of C header files at the beginning of the code. The XC32 C compiler uses the C compiler directive #include reference files within the Main code. Arduino uses import, which is a similar construct that is used in higher-level languages such as Java and Python, which cannot be used by the MPLAB XC32 C.
The two include files necessary for our first example are as follows:
System.h references all the critical Microchip library functions supporting the PIC32MX250F128B. The Ardunio.h provides the Arduino specific library function set. Given these two key “wrapper” aspects, where does the Arduino code go? This is best illustrated with a side-by-side comparison between Arduino code and its Microchip equivalent. The Arduino code is essentially positioned between the wrapper codes as part of the Main function.
This approach enables Arduino code to execute on a Microchip PIC32 within an MPLAB X environment. Note that the Arduino code void setup () now appears as void setup (void), and void loop () appears as void loop (void). This is a minor inconvenience but again necessary for our C environment syntax for C prototype function definitions. Once the code is successfully compiled, the environment enables you to have access to the entire built-in tool suite of the MPLAB X and its debugger tool suite.
RUNNING EXAMPLE 1 CODE
Configure the Microstick II prototype as in the following schematic. Both the schematic and prototype are shown below:
Table 1 compares Arduino core functionality to what is contained in the Microchip PIC32 expanded beta library. In the beta version, I added additional C header files to accomplish the necessary library functionality. Table 2 compares variable types between Arduino and PIC32 variable types. Both Table 1 and Table 2 show the current beta version has a high degree of Arduino core library functionality. Current limitations are the use of only one serial port, interrupt with INT0 only, and no stream capability. In addition, with C the “!” operator is used for conditional test only and not as a complement function, as in Arduino. To use the complement function in C, the “~” operator is used. The library is easily adapted to other PIC32 devices or board types.
If you use interrupts, you must identify to C the name of your interrupt service routine as used in your Arduino script. See below:
For more information on the beta release or to send comments and constructive criticism, or to report any detected problems, please contact me here.
LIBRARY TEST EXAMPLES
Four test case examples demonstrating additional core library functions are shown below as illustrations.
Editor’s Note: Portions of this post first appeared in Tom Kibalo’s book Beginner’s Guide to Programming the PIC32 (Electronics Products, 2013). They are reprinted with permission from Chuck Hellebuyck, Electronic Products. If you are interested in reading more articles by Kibalo, check out his two-part Circuit Cellar “robot boot camp” series posted in 2012 : “Autonomous Mobile Robot (Part 1): Overview & Hardware” and “Autonomous Mobile Robot (Part 2): Software & Operation.”
ABOUT THE AUTHOR
Tom Kibalo is principal engineer at a large defense firm and president of KibaCorp, a company dedicated to DIY hobbyist, student, and engineering education. Tom, who is also an Engineering Department adjunct faculty member at Anne Arundel Community College in Arnold, MD, is keenly interested in microcontroller applications and embedded designs. To find out more about Tom, read his 2013 Circuit Cellar member profile.
Elektor’s latest publication on the Intel Edison is a must have for all those with an active interest in the Internet of Things. The book, Getting Started with the Intel Edison, focuses its attention on the Edison, a tiny computer, the size of a postage stamp, with a lot of power and built-in wireless communication capabilities. In 128 pages, renowned author Bert van Dam helps readers get up to speed with the Edison by making it accessible and easy to use. It is not a projects book, but a toolbox and guide that allows you to explore the wonderful world of the Intel Edison.
This book shows readers how to install the software on the Edison as well as on a Windows PC. The Edison Arduino breakout board is used because it is easy to work with. Linux, Arduino C++ and Python are also used and plenty of examples given as to how the Edison can interface with other software. Covering Wi-Fi and Bluetooth, the book also shows you a trick to program sketches over Wi-Fi. Once you have completed the book, not only will your Edison be up and running with the latest software version, but you will also have sufficient knowledge of both hardware and software to start making your own applications. You will even be able to program the Intel Edison over USB and wirelessly both in Arduino C++ and Python. This book is educational and interesting, and really helps to build your knowledge of all things Intel Edison.
Getting started with the Intel Edison is currently available for $35.
I ordered some little UHF transmitters and receivers from suppliers on AliExpress, the Chinese equivalent of Amazon.com, in order to extend my door chimes into areas of my home where I could not hear them. These ridiculously inexpensive units are currently about $1 per transmitter-receiver pair in quantities of five, including shipping, and are available at 315 and 433.92 MHz. Photo 1 shows a transmitter and receiver pair. Connections are power and ground and data in or out.
The original attempt at a door chime extender modulated the transmit RF with an audio tone and searched for the presence of that tone at the receiver with a narrow audio filter, envelope detector, and threshold detector. This sort of worked, but I started incorporating the same transmitters into another project that interfered, despite the audio filter.
The other project used Arduino Uno R3 computers and Virtual Wire to convey data reliably between transmitters and receivers. Do not expect a simple connection to a serial port to work well. As the other project evolved, I learned enough about the Atmel ATtiny85 processor, a smaller alternative to the Atmel ATmega328 processor in the Arduino Uno R3, to make new and better and very much simpler circuits. That project evolved to come full circle and now serves as a better doorbell extender. The transmitters self identify, so a second transmit unit now also notifies me when the postman opens the mailbox.
Note the requirement for Virtual Wire. Do not expect a simple connection to a serial port to work very well.
Figure 1 shows the basic transmitter circuit, and Photo 2 shows the prototype transmitter. There is only the ATtiny85 CPU and a transmitter board. The ATtiny85 only has eight pins with two dedicated to power and one to the Reset input.
One digital output powers the transmitter and a second digital output provides data to the transmitter. The remaining three pins are available to serve as inputs. One serves to configure and control the unit as a mailbox alarm, and the other two set the identification message the transmitter sends to enable the receiver to discriminate among a group of such transmitters.
When input pin 3 is high at power-up, the unit enters mailbox alarm mode. In mailbox alarm mode, the input pins 2 and 7 serve as binary identification bits to define the value of the single numeric character that the transmitter sends, and the input pin 3 serves as the interrupt input. Whenever input pin 3 transitions from high-to-low or low-to-high, the ATtiny85 CPU wakes from SLEEP_MODE_PWR_DOWN, makes a single transmission, and goes back to sleep. The current mailbox sensor is a tilt switch mounted to the door of the mailbox. The next one will likely be a reed relay, so only a magnet will need to move.
When in SLEEP_MODE_PWR_DOWN, the whole circuit draws under 0.5 µA. I expect long life from the three AAA batteries if they can withstand heat, cold, and moisture. I can program the ATtiny to pull the identification inputs high, but each binary identification pin then draws about 100 µA when pulled low. In contrast, the 20- or 22-MΩ pull-up resistors I use as pull-ups each draw only a small fraction of a microampere when pulled low.
When input pin 3 is low at power-up, the unit enters doorbell extender alarm mode. In doorbell extender alarm mode, the input pins 2 and 7 again serve as binary identification bits to define the value of the single numeric character that the transmitter sends; but in doorbell extender mode, the unit repetitively transmits the identification character whenever power from the door chimes remains applied.
Figure 2 shows the basic receiver circuit, and Photo 3 shows the prototype receiver. There is only the ATtiny85 CPU with a 78L05 voltage regulator and a receiver board.
The receiver output feeds the input at pin 5. The Virtual Wire software decodes and presents the received character. Software in the CPU sends tone pulses to a loudspeaker that convey the value of the identification code received, so I can tell the difference between the door chime and the mailbox signals. Current software changes both the number of beep tones and their audible frequency to indicate the identity of the transmit source.
Note that these receivers are annoyingly sensitive to power supply ripple, so receiver power must either come from a filtered and regulated supply or from batteries.
Photo 4 shows the complete receiver with the loudspeaker.
A few inches of wire for an antenna will reach anywhere in my small basement. To improve transmission distance from the mailbox at the street to the receiver in my basement, I added a simple half-wave dipole antenna to both transmitter and receiver. Construction is with insulated magnet wire so I can twist the balanced transmission line portion as in Photo 5. I bring the transmission line out through an existing hole in my metal mailbox and staple the vertical dipole to the wooden mail post. My next mailbox will not be metal.
I don’t have long term bad weather data to show this will continue to work through heavy ice and snow, but my mailman sees me respond promptly so far.
Operating Mode Differences
The mailbox unit must operate at minimum battery drain, and it does this very well. The doorbell extender operates continuously when the AC door chime applies power. In order to complete a full message no matter how short a time someone presses the doorbell push button, I rectify the AC and store charge in a relatively large electrolytic capacitor to enable sufficient transmission time.
This unit is fairly simple to fabricate and program your self, but if there is demand, my friend Lee Johnson will make and sell boards with pre-programmed ATtiny85 CPUs. (Lee Johnson, NØVI, will have information on his website if we develop this project into a product: www.citrus-electronics.com.) We will socket the CPU so you can replace it to change the program. The new transmitter and receiver printed circuit boards appear in Photo 6.
Dr. Sam Green (WØPCE) is a retired aerospace engineer living in Saint Louis, MO. He holds degrees in Electronic Engineering from Northwestern University and the University of Illinois at Urbana. Sam specialized in free space and fiber optical data communications and photonics. He became KN9KEQ and K9KEQ in 1957, while a high school freshman in Skokie, IL, where he was a Skokie Six Meter Indian. Sam held a Technician class license for 36 years before finally upgrading to Amateur Extra Class in 1993. He is a member of ARRL, a member of the Boeing Employees Amateur Radio Society (BEARS), a member of the Saint Louis QRP Society (SLQS), and breakfasts with the Saint Louis Area Microwave Society (SLAMS). Sam is a Registered Professional Engineer in Missouri and a life senior member of IEEE. Sam is listed as inventor on 18 patents.
Arduino enthusiasts will be excited to learn that Infineon Technologies has announced two new shields for RGB lighting and motor control. You can use the shields—which are compatible to Arduino Uno R3—with the XMC1100 Boot Kit, which is equipped with a 32-bit microcontroller of the XMC1000 family (uses the ARM Cortex-M0 processor).
The RGB LED Lighting Shield for Arduino features an XMC1202 microcontroller with its Brightness Color Control Unit (BCCU) for LED lighting control. The high-current DC Motor Control Shield for Arduino contains the Infineon NovalithIC BTN8982TA integrated half-bridge driver for motor control.
The RGB LED Lighting Shield evaluation board enables you to use different LED light engines for fast prototyping. It has three independent output channels for flicker-free control of multicolor LEDs. The BCCU automated hardware engine provides a cost-effective LED lighting solution dimming and color mixing. You can expand the shield with a DMX interface for lighting and audio nodes or a 24-GHz radar sensor for motion detection.
The DC Motor Control Shield with BTN8982TA simplifies the prototyping of DC motor control designs. It can drive two unidirectional DC motors or one bidirectional DC motor. The shield features two NovalithIC BTN8982TA fully integrated high-current half-bridge drivers optimized for motor drive applications. The BTN8982TA includes three ICs: two power chips (one p-channel high-side MOSFET and one n-channel low-side MOSFET) and an integrated driver IC with one logic circuit to control and monitor the power. Other features include are diagnosis with current sense and slew rate adjustment.
Until end of January 2015, both the RGB Lighting Shield with XMC1202 for Arduino and the DC Motor Control Shield with BTN8982TA for Arduino will be available for purchase from Newark element14. After that, they’ll also be available from Infineon and its distributors.
When Alessandro Giacomel discovered Arduino in 2009, he quickly became hooked. Since then, he’s been designing “little robots” around Ardunio and blogging about his work and findings. In this interview, Alessandro tells us about his most interesting projects and shares his thoughts on the future of robotics, 3-D printing, and more.
CIRCUIT CELLAR: How long have you been designing embedded systems and what sparked your interest
ALESSANDRO: I have been designing embedded systems for about five years. My interest arose from the possibility of building robots. When I was a kid, I found robots extremely fascinating. The ability to force matter to do something we decided always seemed to be one of the main goals conceded to man.
CIRCUIT CELLAR: Tell us about your first design.
ALESSANDRO: My first embedded system was an Arduino 2009. The availability of a huge shield, sensors, and actuators has enabled me to design many applications at an acceptable price for an amateur like me.
I started like many people, with a robot on wheels moving around avoiding obstacles. It’s a standard robot that almost all beginners build. It’s simple because it is built with only a few components and a standard Arduino 2009. The design included modified servomotors that can rotate 360° moving the robot and connected to the wheels and a servomotor to move a little head where there is an ultrasonic distance sensor. The distance sensor lets you know when the robot is in front of an obstacle and helps you decide the most convenient way for the robot to escape.
In its simplicity, this robot enables one to understand the basics for the development of a microcontroller-based robot: the need to have separate power supplies for the motors’ power circuits and for the microcontroller’s logic, the need to have precise sensor reading timing, and the importance of having efficient algorithms to ensure that the robot moves in the desired mode.
My first robot took me a long time to build. But all the elements of the robot (hardware and software) were developed by me and this was important because it let me begin to face the real problems that arise when you are building a robot. Today there are many resources on the Internet that enable one to build a robot simply replicating a set of steps anyone has described. These guides should be used as a source of inspiration, never followed exactly step-by-step, otherwise—while in the end it is true that you can build a robot—you don’t own the knowledge of what has been done.
My robot evolved with the ability to speak, thanks to a sound module. When I build a robot the goal is always to experiment with a technology and to have fun. My friends have enjoyed seeing the robot turning around, speaking, and telling funny stories.
CIRCUIT CELLAR: Your blog, Robottini (http://robottini.altervista.org), is described as “little robots with Arduino.” What inspired you to begin the blog
ALESSANDRO: I strongly believe in sharing knowledge and open-source hardware and software. I thought it was normal to try to share what I was designing when I started to build robots. When I started, I had the benefit of what others had made and published on the Internet. I thought about writing a blog in my language, Italian, but I thought also it would be a good exercise for me to try to write in English and, most importantly, this enabled me to reach a much wider audience.
The site description includes the philosophy at the basis of the blog: small robots built using Arduino. I build small robots because I’m an amateur and my house isn’t very big, so I only build robots that I can put in an armoire. I use Arduino because it is a microcontroller developed in Italy, it was obvious for me to use it, and it is really a great board for a beginner—inexpensive and robust.
The community has developed thousands of applications that can be reused. When I started the blog in 2011, I was building small robots for a few years. In the beginning, finding information was much more complicated and there were few shields that were not cheap. So, I always tried to use “poor” materials (e.g., recovered or recycled). Decreasing the cost of implementation and reusing and imagining new purposes for the things already available in a normal house seemed like a good way to work.
My achievements documented in the blog are never step-by-step guides to build the robot. I include a list of components to buy, the source code, and sometimes the wiring diagram. But I never provide a complete guide, since I think everyone should try to build their own robot because, once built, the satisfaction is enormous.
Through my blog I am available to help with problems people encounter when they are building robots, but I think it is important to give people the tools to build, rather than providing detailed explanations. Everyone can learn only by fighting the difficulties, without having someone preparing everything perfectly.
CIRCUIT CELLAR: Robottini obviously includes quite a few robotics projects. Why did you build them? Do you have a favorite?
ALESSANDRO: Many times people ask me what is the meaning of the robots I build. The answer that I give them leaves people puzzled. The answer is this: My robots are useless. They are useful only as fun—as a passion. I’m happy when I see my little son, Stefano, who is three years old, watching and laughing at a robot turning around in our house. But this does not mean I don’t follow a branch of research when I build robots.
Initially, I built robots to understand how the driver for the motors works, the sensors, and the problems related to the logic of the robot. Afterward, the first branch of research was the issue of control, how to set the proportional, integral, derivative (PID) control to follow a line or make a robot that is in balance. This has enabled me to address the management of complex sensors, such as the inertial measurement unit (IMU).
To have a robot balance on two wheels it is important to measure how much the robot is tilting from the vertical. To do this, typically a cluster of sensors is used, called IMU, which are based on multi-axes combinations of precision gyroscopes, accelerometers, magnetometers, and pressure sensors. In a more simple version, the IMU uses an accelerometer and a gyroscope, and it is mandatory to use both signals to obtain a correct value of the tilt angle from the vertical (it is called fusion of signals).
The most common method used is based on the Kalman filter, which is a mathematical tool that enables you to combine two or more signals to obtain the value of the angle. But it is a highly sophisticated and difficult for an amateur to understand, and it requires fairly advanced knowledge of mathematics. A new method that is rather simple has been proposed in the last years. It is called the “complementary filter.“
One of the studies I performed and posted on my blog compares in practice the signals of the two filters to verify if the complementary filter is able to approximate the Kalman filter in typical situations coming up in robotics. This post has had a great following, and I’ve been surprised to see that several university-level scientific publications have linked to it. I only wrote the post because I was curious to see a simple and almost trivial method that has become helpful to researchers and hobbyists. It has been a pleasure for me.
In the last year, I have followed the trend of art and interaction (i.e., the possibility of building something that can somehow marry art with technology). It was the theme of the stall I had at Maker Faire Europe in Rome, Italy, in October 2013. Arduino is an electronic circuit without a heart and without a soul. Can an Arduino be an artist? I’m trying to do something with Arduino that could be “art.” The arts include painting, poetry, music, sculpture, and so on. I’m trying to do something in different fields of art.
My first experiment is the Dadaist Poetry Box, which is a box capable of composing and printing Dadaist poems. It’s made with an Arduino and uses a printer for receipts to write poems. The box uses an algorithm to compose the poems in autonomy. You push the button and here is your Dadaist poem.
Normally, the poem is a valuable asset, the result of an intimate moment when the poet transposes on paper the emotions of his soul. It is an inspired act, an act of concentration and transport. It’s not immediate. The poem box instead is trivial, it seems almost “anti-poem.” But it’s not; it’s a Dadaist poem. A user can push the button and have an original poem. I like the machine because it gives everyone something material to take home. In this way, the experience of interaction with the machine goes beyond the moment.
Another of my favorite robots is one that is capable of drawing portraits. I’ve never been good at drawing, and I’ve always been envious of those who can easily use a pencil to make a portrait. So I tried using my technical skills to fill this gap.
The search of the algorithm that—starting from a picture—is able to detect the most important lines of the face has been particularly long and difficult. I used the OpenCV open-source libraries for computer vision and image processing, which are very powerful, but hard to handle. Installing the libraries is not a simple undertaking and using them is even more complicated. I used the OpenCV for Processing. Processing is an open-source programming language and integrated development environment (IDE) built for the electronic arts, new media art, and visual design communities with the purpose of teaching the fundamentals of computer programming in a visual context.
The algorithm initially found facial lines using the algorithms for calculation of edges of a picture. So I used the Canny edge detector, the Sobel edge detector, and all the other main edge detection algorithms, but none of these proved to be adequate to draw a face. Then I changed the course and used the Laplacian filter with threshold. I think I reached a good result because it takes less than 10 minutes to draw a portrait, which enables me to take pictures of people and make their portrait before they lose their patience.
CIRCUIT CELLAR: What new technologies excite you and why?
ALESSANDRO: I work almost strictly with Arduino microcontrollers. I was excited with the arrival of Linux-embedded mini-PCs (e.g., the Raspberry PI, the pcDuino, and BeagleBoard.org’s BeagleBone Black). Forcibly, I’m very intrigued by the new Arduino Tre, which is a mini-PC with Linux joined with an Arduino Leonardo. Combining a PC’s processing power of with Linux with the real-time management of the sensors and actuators made by an Arduino is an interesting road. It offers the possibility to manage the real-time processing of video streams through, for example, the OpenCV libraries, with the option of acquiring signals from analog sensors and the possibility of drive motors. For example, this enables one to have a completely autonomous 3-D printer and to perform the slicing and management of the 3-D printer. It also opens up new perspectives in the robotics and computer vision. The main limitation, which is now present in embedded systems, is the limited processing capacity. The ability to have in the same card a Linux system—with the world of applications and drivers already available—linked to the ability to manage physical devices brings a revolution. And I’m already excited to see the next results.
Read the complete interview in Circuit Cellar 292 November 2014.
Nordic Semiconductor’s new Arduino Uno shield-compatible nRF51 DK development kit supports Bluetooth Smart, ANT, and 2.4-GHz designs. Nordic also announced the availability of its nRF51 Dongle, which is a 16 mm × 28 mm USB dongle for the testing, analysis, and development of Bluetooth Smart, ANT, and 2.4-GHz applications.
The nRF51 DK is based on Nordic’s nRF51 Series SoC, which combines a 2.4-GHz multiprotocol radio, 32-bit ARM Corte M0 processor, flash memory, and 16- or 32-KB RAM. The SoCs can support a wide range of peripherals and are available in quad flat no-lead (QFN) and wafer level chip scale package (WLCSP) options.
Key points about the nRF51 DK and nRF51 Dongle
- You can use the nRF51 DK with a variety of third-party Arduino shield expansion boards. It also supports ARM mbed for rapid prototyping projects.
- The nRF51 DK allows access to all device peripherals, interfaces, and I/Os.
- The nRF51 DK includes four user-programmable buttons and LEDS plus voltage and current pins to measure device power consumption.
- nRF51 DK and nRF51 Dongle are supported by standard tool-chain options including Keil, IAR, and Gnu Compiler Collection (GCC).
- The 63 mm × 101 mm nRF51 DK includes a coin-cell battery holder for field testing
- You can use nRF51 DKhe DK as a programmer for other target boards that use the nRF51 Series SoC.
The nRF51 DK costs $69. The nRF51 Dongle is $49.
Source: Nordic Semiconductor