New Power MOSFET Drivers Feature Thermally Efficient, Small Packages

Microchip Technology recently announced the first power MOSFET drivers in a new product family—the MCP14A005X and MCP14A015X. The drivers feature a new driver architecture for high-speed operation.MicrochipMCP14

The new devices’ small packaging (SOT-23 and 2 mm × 2 mm DFN packages) enables higher power densities and smaller solutions, while the design targets fast transitions and short delay times that allow for responsive circuit operation. In addition, the MOSFET drivers include low input threshold voltages that are compatible with low-voltage microcontrollers (MCUs) and controllers, while still maintaining strong noise immunity and hysteresis.


The MCP14A005X and MCP14A015X MOSFET drivers low input threshold is compatible with various Microchip PIC microcontrollers and dsPIC Digital Signal Controllers (DSCs), even when operating at lower voltages. This enables you to design applications with MCUs operating as low as 2 V, using the MOSFET driver to boost the output signals to 18 V, reducing power loss in the controller and minimizing conduction loss in the power MOSFET. The threshold levels balance the need for noise immunity with the ability to function with a wider variety of controller products, including Microchip’s devices. These drivers are designed for use in power supply, lighting, automotive, and consumer electronics markets, including embedded power conversion, brushed DC motor, unipolar stepper motor and solenoid/relay/valve control applications, among others.


The MCP14A005X and MCP14A015X are available now for sampling and volume production in  SOT-23 and 2 × 2 mm DFN packages. Prices range from $0.50 to $0.61 each in 10,000-unit quantities.

Source: Microchip Technology 

µTrace Supports New LPC54100 Series Microcontrollers

Lauterbach has announced its support for the new NXP Semiconductors LPC54100 Series of microcontrollers. NXP recently introduced its LPC54100 series, which achieves industry leading power efficiency and is ideally suited for “always-on” sensor-based products.utrace nxp lpc54100 series microcontrollers

Lauterbach has supported the LPC54100 Series of microcontrollers since the beginning with µTrace, a proven and popular debug and trace tool for Cortex-M-based processors. The tool uses USB 3.0 for connection to the host and connects to the LPC54100 via Serial Wire Debug (SWD) interface. The developer can control the operation of the program and analyze the data in C and C++ by the use of simple and complex breakpoints. An analog probe can be connected to µTrace to read the current and voltage measurements for energy profiling, which enables developers to fine-tune their software for minimal power usage.

The LPC54100 Series features an asymmetric dual-core architecture to enable scalable active power and performance by using a Cortex-M0+ and a Cortex-M4F for different sensor-processing tasks to optimize power efficiency. µTrace fully supports this type of asymmetric multicore processing (AMP) debugging by starting an individual TRACE32 instance for each core.

Source: Lauterbach

Embedded Chip = Subdermal Chip?

Forget stashing your cash under your mattress. Now you can stash it under your skin. Sort of.

The Telegraph reported Tuesday that Martijn Wismeijer, a Dutch innovator, recently implanted a 12-mm xNTi NFC chip in his body to store Bitcoin. The small glass chip stores 888 bytes and comes with a syringe for installation.

According the Dangerous Things site, the kit includes:

  • Glass chip preloaded in EO gas sterilized injector
  • A skin antiseptic
  • Gauze pads, a bandage, and non-latex surgical gloves


Source: Telegraph

New Digitally Enhanced Power Analog Controllers

Microchip Technology recently announced its latest Digitally Enhanced Power Analog (DEPA) controllers—the MCP19118 and MCP19119—which offer analog PWM control for DC-DC synchronous buck converters up to 40 V with the configurability of a digital microcontroller. MicrochipMCP19118

Interestingly, the devices bring together 40-V operation and PMBus communication interfaces for power-conversion circuit development with an analog control loop that is programmable in the integrated 8-bit PIC core’s firmware.  According to Microchip in a product release, “this integration and flexibility is ideal for power-conversion applications, such as battery-charging, LED-driving, USB Power Delivery, point-of-load and automotive power supplies.”

As expected, Microchip’s MPLAB X, PICkit 3, PICkit serial analyzer, and MPLAB XC8s support the MCP19118/9 DEPA controllers. The MCP19118 and MCP19119 are now available with prices starting at $2.92 each in 5,000-unit quantities.


One Professor and Two Orderly Labs

Professor Wolfgang Matthes has taught microcontroller design, computer architecture, and electronics (both digital and analog) at the University of Applied Sciences in Dortmund, Germany, since 1992. He has developed peripheral subsystems for mainframe computers and conducted research related to special-purpose and universal computer architectures for the past 25 years.

When asked to share a description and images of his workspace with Circuit Cellar, he stressed that there are two labs to consider: the one at the University of Applied Sciences and Arts and the other in his home basement.

Here is what he had to say about the two labs and their equipment:

In both labs, rather conventional equipment is used. My regular duties are essentially concerned  with basic student education and hands-on training. Obviously, one does not need top-notch equipment for such comparatively humble purposes.

Student workplaces in the Dortmund lab are equipped for basic training in analog electronics.

Student workplaces in the Dortmund lab are equipped for basic training in analog electronics.

In adjacent rooms at the Dortmund lab, students pursue their own projects, working with soldering irons, screwdrivers, drills,  and other tools. Hence, these rooms are  occasionally called the blacksmith’s shop. Here two such workplaces are shown.

In adjacent rooms at the Dortmund lab, students pursue their own projects, working with soldering irons, screwdrivers, drills, and other tools. Hence, these rooms are occasionally called “the blacksmith’s shop.” Two such workstations are shown.

Oscilloscopes, function generators, multimeters, and power supplies are of an intermediate price range. I am fond of analog scopes, because they don’t lie. I wonder why neither well-established suppliers nor entrepreneurs see a business opportunity in offering quality analog scopes, something that could be likened to Rolex watches or Leica analog cameras.

The orderly lab at home is shown here.

The orderly lab in Matthes’s home is shown here.

Matthes prefers to build his  projects so that they are mechanically sturdy. So his lab is equipped appropriately.

Matthes prefers to build mechanically sturdy projects. So his lab is appropriately equipped.

Matthes, whose research interests include advanced computer architecture and embedded systems design, pursues a variety of projects in his workspace. He describes some of what goes on in his lab:

The projects comprise microcontroller hardware and software, analog and digital circuitry, and personal computers.

Personal computer projects are concerned with embedded systems, hardware add-ons, interfaces, and equipment for troubleshooting. For writing software, I prefer PowerBASIC. Those compilers generate executables, which run efficiently and show a small footprint. Besides, they allow for directly accessing the Windows API and switching to Assembler coding, if necessary.

Microcontroller software is done in Assembler and, if required, in C or BASIC (BASCOM). As the programming language of the toughest of the tough, Assembler comes second after wire [i.e., the soldering iron].

My research interests are directed at computer architecture, instruction sets, hardware, and interfaces between hardware and software. To pursue appropriate projects, programming at the machine level is mandatory. In student education, introductory courses begin with the basics of computer architecture and machine-level programming. However, Assembler programming is only taught at a level that is deemed necessary to understand the inner workings of the machine and to write small time-critical routines. The more sophisticated application programming is usually done in C.

Real work is shown here at the digital analog computer—bring-up and debugging of the master controller board. Each of the six microcontrollers is connected to a general-purpose human-interface module.

A digital analog computer in Matthes’s home lab works on master controller board bring-up and debugging. Each of the six microcontrollers is connected to a general-purpose human-interface module.

Additional photos of Matthes’s workspace and his embedded electronics and micrcontroller projects are available at his new website.




New 40-nm Microcontrollers for Motor Control

Renesas Electronics Corp. recently announced the RH850/C1x series of 32-bit microcontrollers (MCUs), which it said are designed for motor control in hybrid electric vehicles (HEVs) and electric vehicles (EVs). Based on Renesas’s 40-nm process, the RH850/C1x series features the RH850/C1H and RH850/C1M MCUs, which enable embedded designers to enhance efficiency, reduce system costs, and achieve higher safety levels for HEV/EV motor control systems.

Source: Renesas Electronics Corp.

Source: Renesas Electronics Corp.

The new RH850/C1x devices can be used with the RAA270000KFT RH850 family power supply management IC (PMIC), which is currently available in sample quantities. The power management IC integrates into one device all the power supply systems required for MCU operation, two external sensor power supply tracks, and a full complement of monitoring and diagnostic functions, significantly reducing the user burden associated with power supply system design.

The RH850/C1H and RH850/C1M MCUs incorporate large memory capacities achieved through 40 nm MONOS process technology. The RH850/C1x series is based on Renesas’s metal oxide nitride oxide silicon (MONOS) embedded flash, which has an extensive track record in mass production. The MONOS characteristics include fast readout, low power consumption, and large storage capacity. The RH850/C1M and RH850/C1H devices offer memory capacities of 2 MB and 4 MB, respectively. In addition, 32-KB data flash memory, with essentially the same functionality as EEPROM, is included for data storage.

The microcontrollers also feature an extensive set of peripheral functions for HEV/EV motor control. The RH850/C1x MCUs can implement three types of motor control in hardware: sine wave PWM, over modulation, and square wave.

Samples of the RH850/C1H and RH850/C1M MCUs are scheduled to be available from the beginning of 2015 and will cost $45 and $50 per unit, respectively. Mass production is scheduled for May 2016 and is expected to reach a scale of 100,000 units per month.

Source: Renesas Electronics Corp.

DIY Arduino-Based ECG System

Cornell University students Sean Hubber and Crystal Lu built an Arduino-based electrocardiography (ECG) system that enables them to view a heart’s waveform on a mini TV. The basic idea is straightforward: an Arduino Due converts a heartbeat waveform to an NTSC signal.

Here you can see the system in action. The top line (green) has a 1-s time base. The bottom line (yellow) has a 5-s time base. (Source: Hubber & Lu)

Here you can see the system in action. The top line (green) has a 1-s time base. The bottom line (yellow) has a 5-s
time base. (Source: Hubber & Lu)

In their article, “Hands-On Electrocardiography,” Hubber and Lu write:

We used the Arduino Due to convert the heartbeat waveform to an NTSC signal that could be used by a mini-TV. The Arduino Due continuously sampled the input provided by the voltage limiter at 240 sps. Similar to MATLAB, the vectorized signal was shifted left to make room at the end for the most recent sample. This provided a continuous real-time display of the incoming signal. Each frame outputted to the mini-TV contains two waveforms. One has a 1-s screen width and the other has a 5-s screen width. This enables the user to see a standard version (5 s) and a more zoomed in version (1 s). Each frame also contains an integer representing the program’s elapsed time. This code was produced by Cornell University professor Bruce Land.

As you can see in the nearby block diagram, Hubber and Lu’s ECG system comprises a circuit, an Arduino board, a TV display, MATLAB programming language, and a voltage limiter.

The system's block diagram (Circuit Cellar 289, 2014)

The system’s block diagram (Circuit Cellar 289, 2014)

The system’s main circuit is “separated into several stages to ensure that retrieving the signal would be user-safe and that sufficient amplification could be made to produce a readable ECG signal,” Hubber and Lu noted.

The first stage is the conditioning stage, which ensures user safety through DC isolation by initially connecting the dry electrode signals directly to capacitors and resistors. The capacitors help with DC isolation and provide a DC offset correction while the resistors limit the current passing through. This input-conditioning stage is followed by amplification and filtering that yields an output with a high signal-to-noise ratio (SNR). After the circuit block, the signal is used by MATLAB and voltage limiter blocks. Directly after DC isolation, the signal is sent into a Texas Instruments INA116 differential amplifier and, with a 1-kΩ RG value, an initial gain of 51 is obtained. The INA116 has a low bias current, which permits the high-impedance signal source. The differential amplifier also utilizes a feedback loop, which prevents it from saturating.

Following the differentiation stage, the signal is passed through multiple filters and receives additional amplification. The first is a low-pass filter with an approximately 16-Hz cutoff frequency. This filter is primarily used to eliminate 60-Hz noise. The second filter is a high-pass filter with an approximately 0.5-Hz cutoff frequency. This filter is mostly used to eliminate DC offset. The total amplification at this stage is 10. Since the noise was significantly reduced and the SNR was large, this amplification produced a very strong and clear signal. With these stages done, the signal was then strong enough to be digitally analyzed. The signal could then travel to both the MATLAB and voltage limiter blocks.

Hubber and Lu’s article was published in Circuit Cellar 289, 2014. Get it now!

New DSP “Lab-in-a-Box” for ARM-Based Audio Systems

Cambridge, UK-based, ARM and its partners will start shipping a DSP “Lab-in-a-Box” (LiB) to universities worldwide to help boost practical skills development and the creation of new ARM-based audio systems. This will include products such as high-definition home media and voice-controlled home automation systems. The LiB kits contain ARM Cortex-M4-based microcontroller boards by STMicroelectronics and audio cards from Wolfson Microelectronics and Farnell element14.ARMDSPLiBWeb

As the centerpiece of the ARM University Program, LiB packages offer ARM-based technology and high-quality teaching and training materials that support electronics and computer engineering courses. DSP courses have traditionally used software simulation packages, or hands-on labs using relatively expensive development kits costing around $300 per student. By comparison, this new DSP LiB will cost around $50 and will allow students to practice theory with advanced hardware sourced from widely-available products.

“Our Lab-in-a-Box offerings are proving hugely popular in universities because of the low-cost access to state-of-the-art technology,” said Khaled Benkrid, manager of the Worldwide University Program, ARM. “The DSP kits, powered by ARM Cortex-M4-based processors, enable high performance yet energy-efficient digital signal processing at a very affordable price. We expect to see them being used by students to create commercially-viable audio applications and it’s another great example of our partnership supporting engineers in training and beyond.”

The DSP LiB will begin shipping to universities in July 2014. It is the latest in a series of initiatives led by ARM which span multiple academic topics including embedded systems design, programming and SoC design. The DSP kits will also be offered to developers outside academia at a later date.


Specs & Code Matter (EE Tip #136)

No matter how many engineering hours you’ve logged over the years, it’s always a good idea to keep in mind that properly focusing on specs and code can make or break a project. In 2013, Aubrey Kagan—an experienced engineer and long-time Circuit Cellar author—explained this quite well in CC25:

There was a set of BCD thumbwheel switches that I was reading into a micro. In order to reduce the number of input lines required, each 4 bits of a digit was multiplexed with the other digits and selection was made by a transistor enabling the common line of each switch in turn. This was standard industry practice. The problem was that in order to economize, I had used the spare transistors in a Darlington driver IC. Everything worked fine in the lab, but on very hot days the unit would fail in the field with very strange results.

Long story short, the saturation voltage on the Darlington transistor would increase with temperature to above the digital input threshold and the micro would read undefined switch settings and then jump to non-existing code. I learned three things: read and understand all the specifications on a datasheet, things get a lot hotter in a cabinet in the sun than the lab, and you should make sure your code can handle conditions that are not supposed to occur.—Aubrey Kagan, CC25 (2o13)

Want to share an EE tip of your own? Email our editors to share your tips and tricks.

July Issue Offers Data-Gathering Designs and More

The concept of the wireless body-area network (WBAN), a network of wireless wearable computing devices, holds great promise in health-care applications.

Such a network could integrate implanted or wearable sensors that provide continuous mobile health (mHealth) monitoring of a person’s most important “vitals”—from calorie intake to step count, insulin to oxygen levels, and heart rate to blood pressure. It could also provide real-time updates to medical records through the Internet and alert rescue or health-care workers to emergencies such as heart failures or seizures.

Data Gathering DesignsConceivably, the WBAN would need some sort of controller, a wearable computational “hub” that would track the data being collected by all the sensors, limit and authorize access to that information, and securely transmit it to other devices or medical providers.

Circuit Cellar’s July issue (now available online for membership download or single-issue purchase)  features an essay by Clemson University researcher Vivian Genaro Motti, who discusses her participation in the federally funded Amulet project.

Amulet’s Clemson and Dartmouth College research team is prototyping pieces of “computational jewelry” that can serve as a body-area network’s mHealth hub while being discreetly worn as a bracelet or pendant. Motti’s essay elaborates on Amulet’s hardware and software architecture.

Motti isn’t the only one aware of the keen interest in WBANs and mHealth. In an interview in the July issue, Shiyan Hu, a professor whose expertise includes very-large-scale integration (VLSI), says that many of his students are exploring “portable or wearable electronics targeting health-care applications.”

This bracelet-style Amulet developer prototype has an easily accessible board.

This bracelet-style Amulet developer prototype has an easily accessible board.

Today’s mHealth market is evident in the variety of health and fitness apps available for your smartphone. But the most sophisticated mHealth technologies are not yet accessible to embedded electronics enthusiasts. (However, Amulet has created a developer prototype with an easily accessible board for tests.)

But market demand tends to increase access to new technologies. A BCC Research report predicts the mHealth market, which hit $1.5 billion in 2012, will increase to $21.5 billion by 2018. Evolving smartphones, better wireless coverage, and demands for remote patient monitoring are fueling the growth. So you can anticipate more designers and developers will be exploring this area of wearable electronics.

In addition to giving you a glimpse of technology on the horizon, the July issue provides our staple of interesting projects and DIY tips you can adapt at your own workbench. For example, this issue includes articles about microcontroller-based strobe photography; a thermal monitoring system using ANT+ wireless technology; a home solar-power setup; and reconfiguring and serial backpacking to enhance LCD user interfaces.

We’re also improving on an “old” idea. Some readers may recall contributor Tom Struzik’s 2010 article about his design for a Bluetooth audio adapter for his car (“Wireless Data Exchange: Build a 2,700-lb. Bluetooth Headset,” Circuit Cellar 240).

In the July issue, Struzik writes about how he solved one problem with his design: how to implement a power supply to keep the phone and the Bluetooth adapter charged.

“To run both, I needed a clean, quiet, 5-V USB-compatible power supply,” Struzik says. “It needed to be capable of providing almost 2 A of peak current, most of which would be used for the smartphone. In addition, having an in-car, high-current USB power supply would be good for charging other devices (e.g., an iPhone or iPad).”

Struzik’s July article describes how he built a 5-V/2-A automotive isolated switching power supply. The first step was using a SPICE program to model the power supply before constructing and testing an actual circuit. Struzik provides something extra with his article: a video tutorial explaining how to use Linear Technology’s LTspice simulator program for switching design. It may help you design your own circuit.

This is Tom Struzik's initial test circuit board, post hacking. A Zener diode is shown in the upper right, a multi-turn trimmer for feedback resistor is in the center, a snubber capacitor and “stacked” surface-mount design (SMD) resistors are on the center left, USB D+/D– voltage adjust trimmers are on top center, and a “test point” is shown in the far lower left. If you’re looking for the 5-V low dropout (LDO) regulator, it’s on the underside of the board in this design.

This is Tom Struzik’s initial test circuit board, post hacking. A Zener diode is shown in the upper right, a multi-turn trimmer for feedback resistor is in the center, a snubber capacitor and “stacked” surface-mount design (SMD) resistors are on the center left, USB D+/D– voltage adjust trimmers are on top center, and a “test point” is shown in the far lower left. If you’re looking for the 5-V low dropout (LDO) regulator, it’s on the underside of the board in this design.


Engineering Consultant and Roboticist

Eric Forkosh starting building his first robot when he was a teenager and has been designing ever since. This NYC-based electrical engineer’s projects include everything from dancing robots to remote monitoring devices to cellular module boards to analog signals—Nan Price, Associate Editor

NAN: Tell us about your start-up company, Narobo.


Eric Forkosh

ERIC: Narobo is essentially the company through which I do all my consulting work. I’ve built everything from dancing robots to cellular field equipment. Most recently I’ve been working with some farmers in the Midwest on remote monitoring. We monitor a lot of different things remotely, and I’ve helped develop an online portal and an app. The most interesting feature of our system is that we have a custom tablet rig that can interface directly to the electronics over just the USB connection. We use Google’s Android software development kit to pull that off.

ERIC: The DroneCell was my second official product released, the first being the Roboduino. The Roboduino was relatively simple; it was just a modified Arduino that made building robots easy. We used to sell it online at for a little while, and there was always a trickle of sales, but it was never a huge success. I still get a kick out of seeing Roboduino in projects online, it’s always nice to see people appreciating my work.


The DroneCell is a cellular module board that communicates with devices with TTL UARTs.

The DroneCell is the other product of mine, and my personal favorite. It’s a cellular module board geared toward the hobbyist. A few years ago, if you wanted to add cellular functionality to your system you had to do a custom PCB for it. You had to deal with really low voltage levels, very high peak power draws, and hard-to-read pins. DroneCell solved the problem and made it very easy to interface to hobbyist systems such as the Arduino. Putting on proper power regulation was easy, but my biggest design challenge was how to handle the very low voltage levels. In the end, I put together a very clever voltage shifter that worked with 3V3 and 5 V, with some calculated diodes and resistors.

NAN: Tell us about your first project. Where were you at the time and what did you learn from the experience?


Eric’s Butler robot was his first electronics project. He started building it when he was still in high school.

ERIC: The Butler robot was my first real electronics project. I started building it in ninth grade, and for a really stupid reason. I just wanted to build a personal robot, like on TV. My first version of the Butler robot was cobbled together using an old laptop, a USB-to-I/O converter called Phidgets, and old wheelchair motors I bought on eBay.

I didn’t use anything fancy for this robot, all the software was written in Visual Basic and ran on Windows XP. For motor controllers, I used some old DPDT automotive relays I had lying around. They did the job but obviously I wasn’t able to PWM them for speed control.

My second version came about two years later, and was built with the intention of winning the Instructables Robot contest. I didn’t win first place, but my tutorial “How to Build a Butler Robot” placed in the top 10 and was mentioned in The Instructables Book in print. This version was a cleaner version of everything I had done before. I built a sleek black robot body (at least it was sleek back then!) and fabricated an upside-down bowl-shaped head that housed the webcam. The electronics were basically the same. The main new features were a basic robot arm that poured you a drink (two servos and a large DC motor) and a built-in mini fridge. I also got voice command to work really well by hooking up my Visual Basic software with Dragon’s speech-to-text converter.

The Butler robot was a great project and I learned a lot about electronics and software from doing it. If I were to build a Butler robot right now, I’d do it completely differently. But I think it was an important to my engineering career and it taught me that anything is possible with some hacking and hard work.

At the same time as I was doing my Butler robot (probably around 2008), I lucked out and was hired by an entertainer in Hong Kong. He saw my Butler robot online and hired me to build him a dancing robot that was synced to music. We solved the issue of syncing to music by putting dual-tone multi-frequency (DTMF) tones on the left channel audio and music on the right channel. The right channel went to speakers and the left channel went to a decoder that translated DTMF tone sequences to robot movement. This was good because all the data and dance moves were part of the same audio file. All we had to do was prepare special audio files and the robot would work with any music player (e.g., iPod, laptop, CD, etc.). The robot is used in shows to this day, and my performer client even hired a professional cartoon voice actor to give the robot a personality.

NAN: You were an adjunct professor at the Cooper Union for the Advancement of Science and Art in New York City. What types of courses did you teach and what did you enjoy most about teaching?

ERIC: I will be entering my senior year at Cooper Union in the Fall 2014. Two years ago, I took a year off from school to pursue my work. This past year I completed my junior year. I taught a semester of “Microcontroller Projects” at Cooper Union during my year off from being a student. We built a lot of really great projects using Arduino. One final project that really impressed me was a small robot car that parallel parked itself. Another project was a family of spider robots that were remotely controlled and could shrink up into a ball.

Cooper Union is filled with really bright students and teaching exposed me to the different thought processes people have when trying to build a solution. I think teaching helped me grow as a person and helped me understand that in engineering—and possibly in life—there is no one right answer. There are different paths to the same destination. I really enjoyed teaching because it made me evaluate my understanding about electronics, software, and robotics. It forced me to make sure I really understood what was going on in intricate detail.

NAN: You have competed in robotics competitions including RoboCup in Austria. Tell us about these experiences—what types of robots did you build for the competitions?


Eric worked with his high school’s robotics team to design this robot for a RoboCup competition.

ERIC: In high school I was the robotics team captain and we built a line-following robot and a soccer robot to compete in RoboCup Junior in the US. We won first place in the RoboCup Junior Northeast Regional and were invited to compete in Austria for the International RoboCup Junior games. So we traveled as a team to Austria to compete and we got to see a lot of interesting projects and many other soccer teams compete. I remember the Iranian RoboCup Junior team had a crazy robot that competed against us; it was built out of steel and looked like a miniature tank.

My best memory from Austria was when our robot broke and I had to fix it. Our robot was omnidirectional with four omni wheels in each corner that let it drive at any angle or orientation it wanted. It could zigzag across the field without a problem. At our first match, I put the robot down on the little soccer field to compete… and it wouldn’t move. During transportation, one of the motors broke. Disappointed, we had to forfeit that match. But I didn’t give up. I removed one of the wheels and rewrote the code to operate with only three motors functional. Again we tried to compete, and again another motor appeared to be broken. I removed yet another wheel and stuck a bottle cap as a caster wheel on the back. I rewrote the code, which was running on a little Microchip Technology PIC microcontroller, and programmed the robot to operate with only two wheels working. The crippled robot put up a good fight, but unfortunately it wasn’t enough. I think we scored one goal total, and that was when the robot had just two wheels working.

After the competition, during an interview with the judges, we had a laugh comparing our disabled robot to the videos we took back home with the robot scoring goal after goal. I learned from that incident to always be prepared for the worst, do your best, and sometimes stuff just happens. I’m happy I tried and did my best to fix it, I have no regrets. I have a some of the gears from that robot at home on display as a reminder to always prepare for emergencies and to always try my best.

NAN: What was the last electronics-design related product you purchased and what type of project did you use it with?

ERIC: The last product would be an op-amp I bought, probably the 411 chip. For a current project, I had to generate a –5-to-5-V analog signal from a microcontroller. My temporary solution was to RC filter the PWM output from the op-amp and then use an amplifier with a
gain of 2 and a 2.5-V “virtual ground.” The result is that 2.5 V is the new “zero” voltage. You can achieve –5 V by giving the op-amp 0 V, a –2.5-V difference that is amplified by 2 to yield 5 V. Similarly, 5 V is a 2.5-V difference from the virtual ground, amplified by 2 it provides a 5-V output.

NAN: What do you consider to be the “next big thing” in the industry?

ERIC: I think the next big thing will be personalized health care via smartphones. There are already some insulin pumps and heart monitors that communicate with special smartphone apps via Bluetooth. I think that’s excellent. We have all this computing power in our pockets, we should put it to good use. It would be nice to see these apps educating smartphone users—the patients themselves— about their current health condition. It might inspire patients/users to live healthier lifestyles and take care of themselves. I don’t think the FDA is completely there yet, but I’m excited to see what the future will bring. Remember, the future is what you build it to be.

Bit Banging

Shlomo Engelberg, an associate professor in the electronics department of the Jerusalem College of Technology, is well-versed in signal processing. As an instructor and the author of several books, including Digital Signal Processing: An Experimental Approach (Springer, 2008), he is a skilled guide to how to use the UART “protocol” to implement systems that transmit and receive data without a built-in peripheral.

Implementing serial communications using software rather than hardware is called bit-banging, the topic of his article in Circuit Cellar’s June issue.

“There is no better way to understand a protocol than to implement it yourself from scratch,” Engelberg says. “If you write code similar to what I describe in this article, you’ll have a good understanding of how signals are transmitted and received by a UART. Additionally, sometimes relatively powerful microprocessors do not have a built-in UART, and knowing how to implement one in software can save you from needing to add an external UART to your system. It can also reduce your parts count.”

In the excerpt below, he explains some UART fundamentals:

UART stands for universal asynchronous receiver/transmitter. The last three words in the acronym are easy enough to understand. “Asynchronous” means that the transmitter and the receiver run on their own clocks. There is no need to run a wire between the transmitter and the receiver to enable them to “share” a clock (as required by certain other protocols). The receiver/transmitter part of the acronym means just what it says: the protocol tells you what signals you need to send from the transmitter and what signals you should expect to acquire at the receiver.

The first term of the acronym, “universal,” is a bit more puzzling. According to Wikipedia, the term “universal” refers to the fact that the data format and the speed of transmission are variable. My feeling has always been that the term “universal” is basically hype; someone probably figured a “universal asynchronous receiver/transmitter” would sell better than a simple “asynchronous receiver/transmitter.”

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

Before you can use a UART to transfer information from device to device, the transmitter and receiver have to agree on a few things. First, they must agree on a transmission speed. They must agree that each transmitted bit will have a certain (fixed) duration, denoted TBIT. A 1/9,600-s duration is a typical choice, related to a commonly used crystal’s clock speed, but there are many other possibilities. Additionally, the transmitter and receiver have to agree about the number of data bits to be transmitted each time, the number of stop bits to be used, and the flow control (if any).

When I speak of the transmitter and receiver “agreeing” about these points, I mean that the people programming the transmitting and receiving systems must agree to use a certain data rate, for example. There is no “chicken and egg” problem here. You do not need to have an operational UART before you can use your UART; you only need a bit of teamwork.

Using a UART is considered the simplest way of transmitting information. Figure 1 shows the form the transmissions must always make. The line along which the signal is transmitted is initially “high.” The transmissions begin with a single start bit during which the line is pulled low (as all UART transmissions must). They have eight data bits (neither more nor less) and a single stop bit (and not one and a half or two stop bits) during which the line is once again held high. (Flow control is not used throughout this article.)

Why must this protocol include start and stop bits? The transmitter and the receiver do not share a common clock, so how does the receiver know when a transmission has begun? It knows by realizing that the wire connecting them is held high while a transmission is not taking place, “watching” the wire connecting them, and waiting for the voltage level to transition from high to low, which it does by watching and waiting for a start bit. When the wire leaves its “rest state” and goes low, the receiver knows that a transmission has begun. The stop bit guarantees that the line returns to its “high” level at the end of each transmission.

Transmissions have a start and a stop bit, so the UART knows how to read the two words even if one transmits that data word 11111111 and follows it with 11111111. Because of the start and stop bits, when the UART is “looking at” a line on which a transmission is beginning, it sees an initial low level (the start bit), the high level repeated eight times, a ninth high level (the stop bit), and then the pattern repeats. The start bit’s presence enables the UART to determine what’s happening. If the data word being transmitted were 00000000 followed by 00000000, then the stop bit would save the day.

The type of UART connection I describe in this article only requires three wires. One wire is for transmission, one is for reception, and one connects the two systems’ grounds.

The receiver and transmitter both know that each bit in the transmission takes TBIT seconds. After seeing a voltage drop on the line, the receiver waits for TBIT/2 s and re-examines the line. If it is still low, the receiver assumes it is in the middle of the start bit. It waits TBIT seconds and resamples the line. The value it sees is then used to determine data bit 0’s value. The receiver then samples every TBIT seconds until it has sampled all the data bits and the stop bit.

Engelberg’s full article, which you can find in Circuit Cellar’s June issue, goes on to explain UART connections and how he implemented a simple transmitter and receiver. For the projects outlined in his article, he used the evaluation kit for Analog Devices’s ADuC841.

“The transmitter and the receiver are both fairly simple to write. I enjoyed writing them,” Engelberg says in wrapping up his article. “If you like playing with microprocessors and understanding the protocols with which they work, you will probably enjoy writing a transmitter and receiver too. If you do not have time to write the code yourself but you’d like to examine it, feel free to e-mail me at I’ll be happy to e-mail the code to you.”

Build an Automated Vehicle Locator

Several things inspired Electrical and Computer Engineering Professor Chris Coulston and his team at Penn State Erie, The Behrend College, to create an online vehicle-tracking system. Mainly, the team wanted to increase ridership on a shuttle bus the local transit authority provided to serve the expanding campus. Not enough students were “on board,” in part because it was difficult to know when the bus would be arriving at each stop.

So Coulston’s team created a system in which a mobile GPS tracker on the bus communicates its location over a radio link to a base station. Students, professors, or anyone else carrying a smartphone can call up the bus tracker web page, find out the bus’ current location, and receive reliable estimates of the bus’ arrival time at each of its stops. Coulston, computer engineering student Daniel Hankewycz, and computer science student Austin Kelleher wrote an article about the system, which appears in our June issue.

Circuit Cellar recently asked Coulston if the system, implemented in the fall 2013 semester, had accomplished its goals and might be expanded.

“The bus tracker team is tracking usage of the web site using Google Analytics,” Coulston said. “The data reveals that we get on average 100 hits a day during cold weather and fewer on warmer days. Ridership has increased during this past year, helping assure the long-term presence of the shuttle on our campus.”

“Over winter break, shuttle service was increased to a distant location on campus,” he added. “In order to better track the location of the shuttle, a second base station was added. The additional base station required a significant rework of the software architecture. The result is that the software is more modular and can accept an arbitrary number of base stations. There are no plans at present to add a second bus—a good thing, because this change would require another significant rework of the software architecture.”

Initially, Coulston looked to other real-time vehicle trackers for inspiration: “There are a variety of live bus trackers that motivated my early ideas, including the University of Utah’s Live Tracker  and the Chicago Transit Authority’s CTA Bus Tracker. Given our single bus route on campus, I was motivated to keep the interface simple and clean to minimize the amount of time needed to figure out where the bus is and how long it’s going to take to get to my stop.”

The system, as it was originally implemented in August 2013, is fully described in the June issue, now available for single-issue purchase or membership download. The following article excerpt provides a broad overview and a description of the team’s hardware choices.

Figure 1 shows the bus tracker’s hardware, which consists of three components: the user’s smartphone, the base station placed at a fixed location on campus, and the mobile tracker that rides around on the bus.

The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Figure 1: The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Early on, we decided against a cellular-based solution (think cell phone) as the mobile tracker. While this concept would have benefited from wide-ranging cellular coverage, it would have incurred monthly cellar network access fees. Figure 1 shows the final concept, which utilizes a 900-MHz radio link between the mobile tracker and the base station.

Figure 2 shows the software architecture running on the hardware from Figure 1. When the user’s smartphone loads the bus tracker webpage, the JavaScript on the page instructs the user’s web browser to use the Google Maps JavaScript API to load the campus map. The smartphone also makes an XMLHttpRequests request for a file on the server (stamp.txt) containing the bus’ current location and breadcrumb index.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

This information along with data about the bus stops is used to position the bus icon on the map, determine the bus’ next stop, and predict the bus’ arrival time at each of the seven bus stops. The bus’ location contained in stamp.txt is generated by a GPS receiver (EM-408) in the form of an NMEA string. This string is sent to a microcontroller and then parsed. When the microcontroller receives a request for the bus’ location, it formats a message and sends it over the 900-MHz radio link. The base station compares the bus position against a canonical tour of campus (breadcrumb) and writes the best match to stamp.txt.

Early in the project development, we decided to collect the bus’ position and heading information at 2-s intervals during the bus’ campus tour. This collection of strings is called “breadcrumbs” because, like the breadcrumbs dropped by Hansel and Gretel in the eponymously named story, we hope they will help us find our way around campus. Figure 3 shows a set of breadcrumbs (b1 through b10), which were collected as the bus traveled out and back along the same road.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

The decision to collect breadcrumbs proved fortuitous as they serve an important role in each of the three hardware components shown in Figure 1.

The bus houses the mobile tracker (see Photo 1). Figure 4 shows the schematic, which is deceptively simple. What you see is the third iteration of the mobile tracker hardware.

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

An important starting point in the design was how to step down the bus’ 12-V supply to the 5-V required by our circuit. In terms of hardware, the best decision we made was to abandon the idea of trying to integrate a 12-to-5-V converter onto the mobile tracker PCB. Instead we purchased a $40 CUI VYB15W-T DC-DC converter and fed the mobile tracker 5-V inputs…

We used Micrel’s MIC5205 regulator to step down the 5 V for the 3.3-V GPS receiver, which easily supplied its peak 80 mA. Since we ran a Digi International XTend radio at 5 V for the best range, we ended up with mixed voltage signals. We used a Texas Instruments TXS0102 bidirectional voltage-level translator, which handles voltage-interfacing duties between the 5-V radio and the 3.3-V microcontroller.

The mobile tracker unit

Photo 1: The mobile tracker unit

We selected Microchip Technology’s PIC18F26K22 because it has two hardware serial ports, enabling it to simultaneously communicate with the GPS module and the radio modem when the bus is traveling around campus. We placed two switches in front of the serial ports. One switch toggles between the GPS module and the Microchip Technology PICkit 3 programming pins, which are necessary to program the microcontroller. The second switch toggles between the radio and a header connected to a PC serial port (via a Future Technology Devices FT232 USB-to-serial bridge). This is useful when debugging at your desk. An RGB LED in a compact PLCC4 package provides state information about the mobile tracker.

The XTend RF modules are the big brothers to Digi International’s popular XBee series. These radios come with an impressive 1 W of transmitting power over a 900-MHz frequency, enabling ranges up to a mile in our heavily wooded campus environment. The radios use a standard serial interface requiring three connections: TX, RX, and ground. They are simple to set up. You just drop them into the Command mode, set the module’s source and destination addresses, store this configuration in flash memory, and exit. You never have to deal with them again. Any character sent to the radio appears on the destination modem’s RX line.

The GPS receiver utilizes the CSR SiRFstarIII chipset, which is configured to output a recommended minimum specific (RMC) string every 2 s…

The mobile tracker’s firmware listens for commands over the serial port and generates appropriate replies. Commands are issued by the developer or by the base station…

Burning breadcrumbs into the mobile tracker’s flash memory proved to be a good design decision. With this capability, the mobile tracker can generate a simulated tour of campus while sitting on the lab bench.

The base station consists of an XTend RF module connected to a Raspberry Pi’s serial port (see Photo 2). The software running on the Raspberry Pi does everything from running an Nginx open-source web server to making requests for data from the mobile tracker.

From Figure 1, the only additional hardware associated with the base station is the 900-MHz XTend radio connected to the Raspberry Pi over a dedicated serial port on pins 8 (TX) and 10 (RX) of the Raspberry Pi’s GPIO header.

The only code that runs on the base station is the Python program, which periodically queries the mobile tracker to get the bus’ position and heading. The program starts by configuring the serial port in the common 9600,8,N,1 mode. Next, the program is put into an infinite loop to query the mobile tracker’s position every 2 s.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

Q&A: Raspberry Pi Innovation

Orlando, FL-based web app developer and blogger Shea Silverman recently received Kickstarter funding for the latest version of PiPlay, his Raspberry Pi-based OS. Shea and I discussed his ongoing projects, his Raspberry Pi book, and what’s next for PiPlay.—Nan Price, Associate Editor



Shea Silverman

NAN: What is your current occupation?

SHEA: Web applications developer with the Center for Distributed Learning at the University of Central Florida (UCF).

NAN: Why and when did you decide to start your blog?

SHEA: I’ve been blogging on and off for years, but I could never keep to a schedule or really commit myself to writing. After I started working on side projects, I realized I needed a place to store tips and tricks I had figured out. I installed WordPress, posted some PhoneGap tips, and within a day got a comment from someone who had the same issue, and my tips helped them out. I have been blogging ever since. I make sure to post every Friday night.

NAN: Tell us about PiPlay, the Raspberry Pi OS. Why did you start the OS? What new developments, if any, are you working on?


Shea’s PiPlay Raspberry Pi OS recently reached 400% funding on Kickstarter.

SHEA: PiPlay is a gaming and emulation distribution for the Raspberry Pi single-board computer. It is built on top of the Raspbian OS, and tries to make it as easy as possible to play games on your Raspberry Pi. My blog got really popular after I started posting binaries and tutorials on how to compile different emulators to the Raspberry Pi, but I kept getting asked the same questions and saw users struggling with the same consistent issues.

I decided I would release a disk image with everything preconfigured and ready to be loaded onto an SD card. I’ve been adding new emulators, games, and tools to it ever since.

I just recently completed a Kickstarter that is funding the next release, which includes a much nicer front end, a web GUI, and a better controller configuration system.

NAN: You wrote Instant Raspberry Pi Gaming. Do you consider this book introductory or is it written for the more experienced engineer?

SHEA: Instant Raspberry Pi Gaming is written like a cookbook with recipes for doing various tasks. Some of them are very simple, and they build up to some more advanced recipes. One of the easier tasks is creating your user account on the Pi Store, while the more advanced recipes have you working with Python and using an API to interact with Minecraft.

Readers will learn how to setup a Raspberry Pi, install and use various emulators and games, a bit about the Minecraft API, and common troubleshooting tips.


The Pitroller is a joystick and buttons hooked up to the GPIO pins of a Raspberry Pi, which can act as a controller or keyboard for various emulators.

NAN: You are a member of FamiLAB, an Orlando, FL-based community lab/hackerspace. What types of projects have you worked on at the lab?


Disney director Rich Moore poses with Shea’s miniature arcade machine. The machine was based on Fix It Felix Jr. from Disney’s Wreck It Ralph.

SHEA: I spend a lot of time at the lab using the laser cutter. Creating a 2-D vector in Inkscape, and then watching it be cut out on a piece of wood or acrylic is really inspiring. My favorite project was making a little arcade machine featuring Fix It Felix Jr. from Wreck It Ralph. A marketing person from Disney was able to get it into the hands of the director Rich Moore. He sent me a bunch of pictures of himself holding my little arcade machine next to the full size version.

NAN: Give us a little background information. How did you become interested in technology?

SHEA: My mom always likes to remind me that I’ve been using computers since I was 2. My parents were very interested in technology and encouraged my curiosity when it came to computers. I always liked to take something apart and see how it worked, and then try to put it back together. As the years went on, I’ve devoted more and more time to making technology a major part of my life.

NAN: Tell us about the first embedded system you designed.

SHEA: I have a lot of designs, but I don’t think I’ve ever finished one. I’ll be halfway into a project, learn about something new, then cannibalize what I was working on and repurpose it for my new idea. One of the first embedded projects I worked on was a paintball board made out of a PICAXE microcontroller. I never got it small enough to fit inside the paintball marker, but it was really cool to see everything in action. The best part was when I finally had that “ah-ha!” moment, and everything I was learning finally clicked.

NAN: What was the last electronics-design related product you purchased and what type of project did you use it with?

SHEA: At UCF, one of our teams utilizes a ticket system for dealing with requests. Our department does a hack day each semester, so my coworker and I decided to rig up a system that changes the color of the lights in the office depending on the urgency of requests in the box. We coded up an API and had a Raspberry Pi ping the API every few minutes for updates. We then hooked up two Arduinos to the Raspberry Pi and color-changing LED strips to the Arduinos. We set it up and it’s been working for the past year and a half, alerting the team with different colors when there is work to do.

NAN: Are you currently working on or planning any projects?

SHEA: My Kickstarter for PiPlay just finished at 400% funding. So right now I’m busy working on fulfilling the rewards, and writing the latest version of PiPlay.

NAN: What do you consider to be the “next big thing” in the industry?

SHEA: Wearable computing. Google Glass, the Pebble smart watch, Galaxy Gear—I think these are all great indicators of where our technology is heading. We currently have very powerful computers in our pockets with all kinds of sensors and gadgets built in, but very limited ways to physically interact with them (via the screen, or a keypad). If we can make the input devices modular, be it your watch, a heads-up display, or something else, I think that is going to spark a new revolution in user experiences.

Execute Open-Source Arduino Code in a PIC Microcontroller Using the MPLAB IDE

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, 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.

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:

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:

Listing 2

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:

Listing 3

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.

Blink side-by-side comparison

Blink side-by-side comparison

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.

Configure the Microstick II prototype as in the following schematic. Both the schematic and prototype are shown below:

Exercise 1 schematic

Exercise 1 schematic

Exercise 1 prototype

Exercise 1 prototype

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.

Table 1

Table 1: Arduino vs Microchip Technology PIC32 core library function comparison

Talble 2

Table 2: Arduino vs Microchip Technology PIC32 core library variable 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:

Interrupt support

Interrupt support

For more information on the beta release or to send comments and constructive criticism, or to report any detected problems, please contact me here.

Four test case examples demonstrating additional core library functions are shown below as illustrations.

Serial communications

Serial communications

Serial find string test case

Serial find string test case

Serial parse INT

Serial parse INT



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.”


Tom Kibalo

Tom Kibalo

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.