Q&A: Embedded Systems Training Expert

Professional engineer Jason Long worked as an embedded systems designer for more than a decade. In 2010 he founded Engenuics Technologies. Jason lives in Victoria, BC, where he continues growing his company alongside the MicroProcessor Group (MPG) embedded systems hardware teaching program he developed in 2000.

 

CIRCUIT CELLAR: In 2010 you founded your company Engenuics Technologies (www.engenuics.com) based on the success of the MicroProcessorGroup (MPG) program. Give us a little background. How did the MPG begin?

JASON: MPG started way back in 2000 at the University of Calgary when I was doing my undergraduate studies. I figured out that embedded systems was exactly what I wanted to do, but struggled to find enough hands-on learning in the core curriculum programs to satisfy this new appetite. I was involved in the university’s Institute of Electrical and Electronics Engineers (IEEE) student branch, where someone handed me my first Microchip Technology PIC microcontroller and ran a few lunchtime tutorials about getting it up and running. I wanted more, and so did other people.

Jason Long

Jason Long

I was also very aware that I needed to drastically improve my personal confidence and my ability to speak in public if I was going to have any luck with a career outside of a cubicle, let alone survive an interview to get a job in the first place. The combination of these two things was the perfect excuse/opportunity to start up the MPG to ensure I kept learning by being accountable to teach people new stuff each week, but also to gain the experience of delivering those presentations.

I was blown away when there were almost 30 people at the first MPG meeting, but I was ready. Two things became very clear very quickly. The first was that, to be able to teach, you must achieve a whole new level of mastery about your subject, but it was also okay to say, “I don’t know” and find out for next week. The second was that I could, in fact, get my nerves under control as long as I was prepared and didn’t try to do too much. I’m still nervous every time I start a lecture, even 14 years later, but now I know how to use those nerves! The best part was that people really appreciated what I was doing and perhaps were a bit more tolerant since MPG is free. I found a love for teaching that I didn’t expect, nor did I get how rewarding the endeavor would be.

When I was wrapping up the ninth year of the program, I considered giving it one more year and then calling it quits. I took a moment to look back at what the program was when I started and where it had come to—it had indeed evolved a lot, and I figured I had put in about 2,000 h by this point. It seemed like a waste to throw in the towel. I also looked at the relationships that had come from the program, both personally and professionally, and realized that the majority of my career and who I had become professionally had really been defined by my work with MPG. But the program—even though it was still just in Calgary—was too big to keep as a side project. I had $10,000 in inventory to support the development boards, and although all monies stayed in the program, there were thousands of dollars exchanging hands. This was a business waiting to happen, though I had never thought of myself as an entrepreneur. I was just doing stuff I loved.

This ARM-based development board is made by Jason’s company, Engenuics Technologies.

This ARM-based development board is made by Jason’s company, Engenuics Technologies.

Around the same time I discovered SparkFun Electronics, and more importantly, I discovered the story of how the company got started by Nathan Seidie. That story begins almost exactly how MPG began, but clearly Nathan is a lot smarter than I am and has built an amazing company in the same time it took me to get to this point. I feel quite disappointed when I think about it that way, but thankfully I don’t think it’s too late to do what I should have done a long time ago. I hope to meet Nathan one day, but even if I don’t, I consider him a mentor and his story provides validation that the MPG platform and community may be able to grow and be sustainable.

I think MPG/Engenuics Technologies can find similar success as SparkFun. We can do that without ever having to compete against SparkFun because what we do is unique enough. There might be a bit of overlap, but I’m always going to try to complement what SparkFun does rather than compete against it. We simply become another resource to feed the voracious and infinite appetite for information from students, hobbyists, and engineers. Win-win is always the way to go.

I decided I should grow the program instead of ending it, so I started Engenuics Technologies, which would be built on the decade of MPG experience plus the decade of embedded design experience I had from the industry. It seemed like a pretty solid foundation on which to start a company! Surely I could promote all of the content and find students of the same mindset I was in when I started MPG? They could lead the program at different universities and develop those infinitely valuable communication and leadership skills that MPG fosters, except they’d have the advantage of not having to put in hundreds of hours to write all of the material. Even if groups of people weren’t playing with MPG, individuals could make use of the technical resource on their own and we could have a solid online community. I also wanted to keep students engaged beyond the single year of their engineer degrees in which MPG existed.

CIRCUIT CELLAR: What other products/services does Engenuics Technologies provide?

JASON: I describe Engenuics Technologies as a four-tier company as there are three significant aspects of the business in addition to MPG. The main purpose of the company is to fill a gap in the industry for specific training in embedded systems. There is very little formal training to be found for low-to-mid-level embedded hardware and firmware development and quality/value is often hit or miss. From teaching for 10 years while being an embedded designer for the same amount of time, I felt like I had the right skills to create great training. I had already created a LabVIEW course that I delivered internally for a company while I worked there, and people were blown away by the quality and content. I saw a huge need to develop embedded-specific training to help new graduates transition to the industry as well as junior engineers who were lacking in some fundamental engineering knowledge.

We have an embedded boot camp course that is about 20% hardware and 80% firmware focused, which I think is essential for new engineering graduates getting into embedded design. Though the course is based specifically on a Cortex-M3 development board, we ensure that we focus on how to learn a processor so the knowledge can be applied to any platform.

Engenuics Technologies has several courses now and we continue to offer those periodically though never as often as we would like, as we’ve become too busy with the other parts of the company. We finally got an office last August with an onsite training room, which makes the logistics much easier, and we’re ramping up the frequency of the programs we offer.

CIRCUIT CELLAR: You earned your BSEE from the University of Calgary in 2002. Can you describe any of the projects you’ve worked while you were there?

JASON: The professors at the U of C were a phenomenal bunch and it was a privilege to get to know them and work with them during my undergraduate studies. I remain in contact with many of them, and several are very good friends. Aside from blinking some LEDs on breadboards, the first complicated device I built was an attempt at the IEEE Micromouse competition. That proved to be a little much and my robot never did do anything beyond go forward, sense a wall, and then back up.

While studying at the University of Calgary, some of Jason’s first embedded designs included a programmable phase-locked loop project, a robot built for an IEEE Micromouse competition, an MPG dev board, and a binary clock.

While studying at the University of Calgary, some of Jason’s first embedded designs included a programmable phase-locked loop project, a robot built for an IEEE Micromouse competition, an MPG dev board, and a binary clock.

I originally thought I would base MPG around building robots, but that proved impossible due to cost. Building a robot is still on my bucket list. I’ll likely get there once my two boys are old enough to want to build robots. I continue to fantasize about building an autonomous quadcopter that can deliver beer. I better get busy on that before its commonplace!

Our IEEE student branch had a Protel 99 SE license and somehow I learned how to design PCBs. The first board I designed was a binary clock that I still use. I then did a PIC programmer and later I built a combined development board and programmer for MPG.

I also designed the PCB for our fourth-year Capstone design project, which initially was a very boring implementation of a phase-locked loop, but became a lot more fun when I decided to make it programmable with a keypad and an LCD. I brought all these things to my BW Technologies job interview and proudly showed them off. For any students reading this, by the way, landing your first engineering job is probably 5% technical, 10% GPA, and 85% enthusiasm and demonstrated interest and achievement. It’s really boring to interview someone who has done nothing extracurricular.

CIRCUIT CELLAR: How long have you been designing embedded systems? When did you become interested?

JASON: My dad was a high school science teacher and my mom was a nurse, so I didn’t have a lot of technical influence growing up. I loved talking physics with my dad, and I’m one of the few engineers who can cook (thank you, mom).

Aside from really liking LEGO and dismantling anything electronic (without ever a hope of putting it back together but always wondering what all those funny looking components did), I barely demonstrated any interest in EE when I was young. But somehow I figured out in grade 12 that EE was probably what I should study at university.

I’m sure I still had visions of being a video game designer, but that nagging interest in learning what those funny components did steered me to EE instead of computer science. It wasn’t until my second year at university when someone gave me my first PIC microcontroller that I really knew that embedded was where I needed to be. That someone was a student named Sean Hum, a brilliant guy who is now an associate professor at the University of Toronto.

CIRCUIT CELLAR: Which new technologies excite you?

JASON: I particularly like the 2.4-GHz radio technologies that hold the potential to really make our environment interactive and intelligent. I think the world needs more intelligence to address the wasteful nature of what we have become whether it is by actively doing something like turning the lights or heat off when we’re not around, or by simply making us more aware of our surroundings. I love ANT+ and am just getting into BLE—obviously, smartphone integration will be critical.

I think technology will drive change in education and I hope to see (and perhaps be a driving force behind) a more cohesive existence between academics and the industry. I hope MPG becomes a model to the industry of what can be achieved with not a lot of financial resources, but has immense payback for employees who become mentors and students who can connect with the industry much earlier and thus get more from their degree programs and graduate with substantially higher capabilities.

You can read the entire interview in Circuit Cellar 289 (August 2014).

Q&A: Joe Grand – Engineer to the Core

From his grade-school Atari obsession and his teenage involvement in the L0pht Heavy Industries hacker group, to co-hosting Discovery Channel’s Prototype This! and starting his own company, Grand Idea Studio, Joe Grand has always maintained his passion for engineering. Joe and I recently discussed his journey and his lifelong love of all things engineering.—Nan Price, Associate Editor

NAN: Give us some background information. When and how did you discover electronics. What was your first project?

 

Joe Grand

JOE: I got involved with computers and electronics in 1982, when I was 7 years old. My first system was an Atari 400 computer, an Atari 810 floppy disk drive, and an Atari 830 acoustic coupler modem. I spent every waking hour playing computer games, trying to write my own programs, and connecting to local bulletin board systems. I was continually experimenting and questioning. I remember learning hexadecimal by poking around with a binary editor and figuring out how to replace names on game title screens with my own.
My brother, who is six years older than me, was also interested in computers and electronics. He would repair audio equipment, build telephone and computer gadgets, and disassemble broken electronics to scavenge them for parts. He had a cabinet that served as a junk bin for components and broken boards. When I did chores for him, like doing his laundry or cleaning his room, he’d let me pick something from the cabinet.

I was 13 years old when I hand-etched my first circuit board to make a “ring-busy device.” The device was simply a resistor across the tip and ring of the telephone line that had an RJ-11 plug for easy insertion/removal. It would make the telephone switch at the central office believe your phone was off the hook (thus, providing a busy signal to any incoming caller), but would still enable you to make outgoing calls. It was a fun, mischievous device, but also very practical to prevent annoying phone calls during dinner.

Right from the start, I had a strong emotional connection to all things electronic. I could just understand how technology was working even if I was unable to explain why. I knew early on that I wanted to be an electrical engineer. I wore this proudly on my sleeve, which didn’t help my ranking in the social hierarchy of elementary school!

NAN: What have been some of your influences?

JOE: In the early 1990s, when I was still a teenager, I joined a group called L0pht Heavy Industries (pronounced “loft” and spelled ell-zero-ph-t, http://en.wikipedia.org/wiki/L0pht). The L0pht was a clubhouse for Boston-area hackers who had met on local bulletin board systems and it was one of the first publicly known “hackerspaces.” The L0pht simply started as a place to store computer equipment, tinker with technology, and hang out, but it ended up as seven close-knit friends changing the face of computer security vulnerability research and disclosure.

We would examine networks, software applications, and hardware products for security flaws. If we discovered a vulnerability, we would challenge the vendor to not only acknowledge the problem, but to fix it. This is now common practice, but back then, it was a feat practically unheard of.

I looked up to the other guys in the group. All were at least six years older than me and they became my mentors (whether they knew it or not) for nearly the next decade. They helped me to focus my energy on projects that would have positive impacts for other people. They also helped reinforce the hacker mindset—that is, not being afraid to try unconventional solutions to problems, pushing the limits of technology, being dedicated to learning through constant experimentation, and sharing my passion with others. Being involved in the L0pht was a very special time for me and shaped much of how I view the world.

NAN: You grew up and went to school in Boston. How did you end up in California?

JOE: Being in Boston for nearly 28 years left me with a lot of history (both good and bad). Everywhere I looked, I had a story, a feeling, or a connection to a time or event. I needed a clean slate. I had just left @stake, a computer security consulting firm that we started out of the L0pht, and my wife (girlfriend at the time) had just finished graduate school. She was also looking for new adventures, so we packed up our stuff and drove across the country not really knowing what we were going to do when we got to California. We lived in San Diego for a few years and ultimately settled in San Francisco when I started work on Discovery Channel’s Prototype This! television show.

San Francisco was a natural fit for us, and when the show ended, we decided to stay. Being close to Silicon Valley and its electronics stores (e.g., Jameco Electronics, WeirdStuff Warehouse, and HSC Electronic Supply) is quite useful, and I always get a thrill driving by the offices of chip vendors I use on a daily basis.

NAN: You started your own product design firm, Grand Idea Studio, in 2002. Tell us about the company.

JOE: Grand Idea Studio (www.grandideastudio.com) is a product design and licensing firm specializing in consumer/household devices and modules for electronics hobbyists. I started the company to create an environment that suited me best and would enable me to focus on what I loved to do. The majority of my work stems from ideas developed in-house or with my industrial design/mechanical engineering partners. I prefer to design simple, effective devices that serve a specific purpose. I’m all for using technology—but only where it’s needed—to make a product better.

Much of my time is spent building prototypes or proof-of-concepts of ideas (though many of those don’t ever see the light of day) that are sold and/or licensed to suitable partners. Some projects I’ll release as open source (usually through a Creative Commons Attribution license), so others can learn from my experiences and build upon my work to make something better.

I also teach a hardware hacking course at public and private events (www.grandideastudio.com/portfolio/hardware-hacking-training). The course focuses on teaching board-level hardware hacking and reverse-engineering techniques and skills. It’s a combination of a lecture and hands-on exercises covering the hardware hacking process, proper use of tools and test measurement equipment, circuit board analysis and modification, embedded security, and common hardware attack vectors. The course concludes with a final hardware hacking challenge in which students must apply what they’ve learned to defeat the security mechanism of a custom circuit board. Design engineers and computer security researchers don’t often join forces. Being both, I feel like it’s part of my responsibility to help make that connection.

NAN: Tell us about your engineering experience prior to Grand Idea Studio.

JOE: My most relevant and memorable engineering experience was when I worked for Continuum (formerly Design Continuum, www.continuuminnovation.com), a design and innovation consultancy based in West Newton, MA. I had worked on and off at the company during college and took a full-time engineering position in 1998. I was one of only two electrical engineers. We worked very closely with industrial designers, mechanical engineers, manufacturers, and clients to create innovative new products. Some key projects I contributed to were the A.T. Cross iPen (an early digital writing tablet) and the FluidSense FS-01 portable infusion pump (voted one of the best inventions of 2000 by Time magazine). It was during my time at Continuum that I learned about the product development and production manufacturing processes and sharpened my skills as an engineer.

NAN: Tell us about your experience working on Discovery Channel’s Prototype This! television show. Do you have a favorite project?

 

Prototype This! Giant Boxing Robot

JOE: Prototype This! (http://en.wikipedia.org/wiki/Prototype_This!) was a short-lived engineering entertainment show that followed the real-life design process of a unique prototype each episode. Although we only filmed for one season (comprising 13 episodes), the show gained a “cult” status of sorts among engineers and makers. It aired on Discovery Channel in the US in late 2008, but is now airing elsewhere throughout the world. The show is also available on Netflix, making it accessible to viewers who may have missed the show the first time around.

To be clear, I’m an engineer to the core, and I never had any intention of being in front of a camera as part of my job. But, the opportunity to show off engineering to the world in a way that was fun, entertaining, and somewhat educational seemed too good to pass up. Producing the show turned out to be a difficult and frustrating process, as we not only had to be on-screen television hosts trying to convey complex, technical builds in a way most viewers would understand, but we also had to actually engineer, design, build, and test the prototypes.

Prototype This! The PyroPack

We ended up building ridiculously crazy contraptions including “Mind Controlled Car” (Episode 1), giant 10’ “Boxing Robots” (Episode 2), and a “Traffic Busting Truck” that could elevate itself over other traffic and move in any direction (Episode 3). Each build had its own special flavor and design challenges and I actually enjoyed working on all of them. From an engineering point of view, I was most proud of the AirTrax control system (Episode 3), the PyroPack (Episode 6: “Robotic Firefighter Assistant”), and the underwater ROV controller (Episode 10: “Virtual Sea Adventure”). All of the documentation for my contributions to the builds, including schematics, source code, and development notes, is available at www.grandideastudio.com/prototype-this.

Ultimately, the show proved to be unsustainable (from financial and time perspectives), but it was an unforgettable experience. The best thing is how the show continues to inspire future engineers. Nearly every day I receive e-mails from viewers asking for details about a particular build or what it takes to become an engineer, and I do my best to point them in the right direction.

NAN: You’ve designed dozens of things—from computer memory-imaging tools to children’s products to medical devices. Tell us about your design process. Do you have a favorite project?

JOE: I think my design process is very typical. I start by identifying and sourcing key components for the project. I’ll put together a preliminary block diagram and then build a proof-of-concept or prototype using a breadboard or PCB (depending on complexity and/or other constraints).

If the design is an embedded system that requires firmware, I’ll start writing it as soon as the prototype hardware is ready. This lets me validate that each hardware subsystem behaves as required and, if necessary, I can easily make changes to the design.

Once the hardware design has been sufficiently proven, I’ll move to a production design and form factor. Then, I’ll finish up the firmware, refine my documentation (which I work on throughout the process), and either release the design or move to production. If things go wrong, which they can sometimes do, then I may make multiple iterations of a design before it’s ready for production.

When I’m in the throes of the design process, I’m obsessed with the work. I think about it constantly—on my daily runs, in the shower, at bedtime, and sometimes while sleeping. I try to anticipate worst-case scenarios, component tolerances, failure modes, and how the end user will interact with the device (both correctly and incorrectly).

Every project I work on is currently my favorite and each project comes with its own challenges, successes, and failures. As soon as I’m done with one project, I’m looking for the next thing to do.

DEFCON 17 Badge

I’m particularly fond of my work on the DEF CON badges. Held every summer, DEF CON (www.defcon.org) is the largest and oldest continuously running hacker event of its kind. It’s a mix of good guys, bad guys, government officials, and everyone in between, all having fun, sharing information, seeing old friends, and learning new things.

For five years (2006–2010) I had the honor of designing the official conference badges, which were artistic, fully functional electronic devices. I believe we were the first large-scale event to provide electronic badges to attendees. It changed what people have come to expect from a conference badge. The challenge was to create something that scrutinizing hackers would enjoy, appreciate, play with, and modify, while staying within the budget (around $10 per badge in 10,000-unit quantities).

The various badge designs have displayed custom scrolling text messages, turned off your television, transferred files over infrared, pulsed to music using fast Fourier transforms (FFTs), and provided USB functionality for computer control. They have incorporated technologies such as capacitive touch, RGB LEDs, microelectromechanical systems (MEMS) based microphones, “zero power” cholesteric LCDs, and microcontrollers ranging in size from tiny six-pin devices to powerful 64-pin behemoths. The physical PCBs used extremely complicated mechanical outlines, multiple layers of custom solder mask colors, and laser etching onto single-sided aluminum substrate PCBs.

DEFCON 18 Badge Backside

DEFCON 18 Badge close-up

Full details about the badges, along with schematics, source code, pictures, attendee hacks, and related articles, are available at www.grandideastudio.com/portfolio/defcon-x-badge (where x = 14, 15, 16, 17, 18).

NAN: Are you currently working on or planning any projects? Can you tell us about them?

JOE: There will (hopefully) never be a shortage of cool projects to work on. I like to keep multiple plates spinning at one time, though I can only talk about some of those plates.
At the recent 2013 DESIGN West conference, I released the JTAGulator (http://jtagulator.com), which is an open-source, Parallax Propeller-based hardware tool that assists in identifying on-chip debug (OCD) and/or programming connections from test points, vias, or component pads on a target device. Discovering available interfaces is a common step in hardware hacking or reverse engineering, as they are usually left unprotected and can be used to extract memory or affect the state of a system on the fly.
A few similar tools exist, but they are either incomplete, closed source, or proof of concept. I wanted to create something that could be used in actual, real-world situations and that would help new people get involved in hardware hacking. The tool will also help to highlight the insecurity of leaving OCD interfaces enabled in production devices and hopefully serve as a catalyst for change in the engineering community (where convenience often trumps security). The JTAGulator currently supports JTAG and I will be making continued refinements to the firmware to add support for additional OCD protocols.

Last year, I finished up the Emic 2 Text-to-Speech module (www.grandideastudio.com/portfolio/emic-2-text-to-speech-module), which has just started to appear in lots of interesting projects. The module is a self-contained, multi-language voice synthesizer that converts a stream of digital text into natural-sounding speech. It’s based on the Epson S1V30120 text-to-speech (TTS) IC, which uses the familiar DECtalk engine and is easy to interface to any microcontroller through a standard serial interface. Though embedded speech synthesis has been around for a while, there was no small form factor, low-cost solution readily available. So, I made one. A search for “Emic 2” on YouTube will result in various projects that use the module, including a tweet reader, a color-to-voice converter, a talking thermometer, an interaction with Apple’s Siri, and some singing demonstrations.

Some other projects I have planned include experimenting with PCB reverse-engineering techniques, hacking with a BeagleBone Black and OpenCV, and designing a new RFID system.

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

JOE: I’ve been increasingly concerned with the improper and (sometimes) socially unacceptable use of technology. From cameras at every street corner to mobile devices tracking your every move to Facebook and Google (among others) controlling your personal data, privacy has become something we’re slowly (and willingly?) losing. It’s a slippery slope that I don’t think many people will notice until it’s too late. The problem is largely driven by our society’s mass adoption of technology and taking that technology for granted. As an engineer and hacker, I strive to educate others about the unintended consequences of blindly using technology and hope it will make them more aware.

Member Profile: Tom Kibalo

Tom Kibalo

Location: Annapolis, MD

Education: BS, Electrical Engineering (City College, NY), and MS Electrical Engineering (University of Maryland)

Occupation: Tom is Principal Engineer of a large defense firm and CEO of KibaCorp, which he says is “dedicated to innovative educational technologies for the hobbyist, student, and practicing engineer.” He is also an adjunct faculty member at a local community college.

Member Status: Tom has been a subscriber for more than eight years.

Technical Interests: He is interested in robotics, embedded programming, microcontrollers, wireless applications, and engineering education.

Most Recent Embedded Tech-Related Acquisition: Tom’s most recent purchase was a Raspberry Pi with direct GPIO connections.

Current Projects: He is working on a battery-powered Wi-Fi sensor network that uses low-power Microchip Technology PIC32 components. (His project is shown in the photo.)

Thoughts on the Future of Embedded Technology: Tom thinks these are “exciting times where system-on-a-chip (SoC) technologies are extending the domain of embedded applications with Linux OS and a large base of language libraries.”

Q&A: Chris Paiano (Problem Solving & Design)

Chris Paiano is an Elko, NV-based problem engineer. His father introduced him to programming at an early age, and Chris has continued to team with his father to write software and firmware for some of his hardware designs. Chris has written dozens of unique application notes for the Cypress Semiconductor Programmable-System-on-Chip (PSoC) chipset. He is currently using PSoC in an innovative household project and dreams of finishing his concept for environmentally friendly electric/hybrid vehicle wheeldrive retrofit kits.

Chris Paiano working with his “office assistants” (bearded dragons)

You can read the complete interview in Circuit Cellar 272 March 2013.

NAN PRICE: Tell us a little about your background.

CHRIS PAIANO: I went to school in Orlando, FL, all the way through college at the University of Central Florida, where I obtained my bachelor’s degree in Computer Engineering.

I started at a very young age. My father always had an electronics workbench and I spent time there when I could. When I was 2 years old, he brought me home an Apple ][ with some floppy disks and told me there were games to be played—if I could only figure out how to make them work.

The Apple ][ was not the most user-friendly or intuitive computer system, by any means. In order to accomplish my important goal of playing video games, I had to learn how to work with the computer’s clunky command-line interface (CLI). Once I figured out how to make all the games work, I wanted to fully automate them so I didn’t have to go through all the manual steps to play them every time (also, so my friends could start them up without me). So, I spent much time developing automatic start-up scripts, from the Applesoft HELLO program to MS-DOS configuration start-up menus, supporting whatever memory management method was required to play certain games, along with icon-driven pre-Windows menu systems that made these early systems usable by my friends, family, and clients.

This evolved into more elaborate scripting and programming to fill the gaps where the tools I needed did not exist, so I had to create them. My possibilities really opened up when I began developing firmware to complement my father’s hardware designs.

NAN: Tell us about your company, Christopher Paiano Engineering (CpE).

CHRIS: I design and program prototypes for various clients. I provide them with ideas at various development stages, which I turn into something that they can mass produce. I’ve just redesigned my website (www.cpeproto.com), by the way. It has a sleeker, simple interface and is easier to navigate now. No more Java menu with annoying sound effects!

NAN: Several of your projects are built around the Cypress Semiconductor programmable system-on-chip (PSoC). Is that your go-to chipset?

CHRIS: Yes, mainly because of how versatile and capable it is. It seems to be sufficient to take care of most any embedded task or set of tasks that come to mind.

For example, recently, the proprietor of a local game/tech/arcade business approached me to build a custom, inexpensive door chime. He wanted customers to hear random, recognizable portal sounds from popular video games whenever customers entered or exited his shop.

I started with an inexpensive motion sensor product from a local superstore. I added a Cypress CY8C27443 PSoC, as I have several lying around for general projects. I made a copy of my “Playing WAV Files with a PSoC” app note project to modify.

I added code to randomly cycle through available sound clips in the memory and I was able to provide 1.9805 s of audio at 8 kHz with the 16 KB of RAM available in this chip. The client was happy with this. He settled on two portal sounds (from The Legend of Zelda and Super Mario Brothers) and the chime has been in use for several months now. Customer feedback has been excellent. Everyone entering the place immediately recognizes the sounds and loves it!

NAN: You’ve written more than 30 application notes for the Cypress chipset, including PongSoC and the Video RTA. Can you explain the process?

CHRIS: Sometimes Cypress would post bounties for app notes that they’d like to see written on a certain topic or capability. Other times, I’d have an interesting personal project for which I decided to utilize a PSoC. I would then decide it might make a good app note, so I’d write it up and submit it. Either way, I’d usually develop the project side-by-side with my father. (We make an excellent hardware/software team.) I work out whatever firmware and PC/smartphone apps may be necessary, and he builds the PSoC circuit board with which to test. Then, I document it all, arrange it, and edit it into an app note (or, in some cases, an article).

Sometimes a project is just too complex to squeeze into a single PSoC’s resources and the simplest solution is to just add another PSoC. Communication between PSoCs can be quick and easy to implement, so distributing tasks and maintaining synchronization is not too difficult. This was the solution for the video real-time analyzer (RTA) app note where, realistically, there were only enough internal analog resources to provide three filters in each PSoC. With the Video RTA, one just adds as many PSoCs to the bus as is necessary to achieve the desired analyzer resolution.

The PongSoC was a fun one! Once I learned it was possible to combine some internal PSoC modules and algorithms to generate a stable composite video signal, I immediately decided I wanted to try and utilize this new capability to recreate a Pong-like embedded game-on-a-chip. I could already generate sound effects and read potentiometers for paddle inputs, I just needed to work it all out. I had a great time doing so, testing it with friends and playing with the variables to tweak the gameplay, and so forth.

Additionally, all 40 of my PSoC application notes are now available in some capacity on my updated website, as Cypress does not actively market the older PSoC families that many of my projects utilized in the past. I get enough e-mail requests for source code and documentation from this collection, so I have just gone ahead and taken the time to restore as many as I could find from my archives to the new website.

NAN: Your two-part article series “PSoC Design Techniques” describes how to build an eight-channel mixer and how DSP effects and a user interface can be added to it (Circuit Cellar 216–217, 2008). Describe the design and why you chose this design concept.

CHRIS: This was a great challenge. In a chip that traditionally would only allow for four full audio pathways in the provided analog resources (four PGA modules utilizing the normal I/O paths provided by PSoC Designer), we managed to figure out a way to utilize the remaining switched-capacitor blocks to act as signal mixers and gain stages with enough live reconfigurable resources to add potentiometers to control volume for each channel. Since there was still plenty of code space, I went ahead and added some DSP effects (reverb and pitch shift) along with a voice menu and flash-settings memory.

I really wanted to showcase what efficient design and algorithms could accomplish in a single piece of silicon, and I’m quite pleased with the way this project turned out. I still use the resulting device on my workbench and in my setups. It comes in handy sometimes. I have not updated it at all. I’ve been using it as is and it is still available for purchase on my website for anyone interested in experimenting with one.

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

CHRIS: Currently, I’m working on a PSoC solution for my broken dishwasher.

Chris Paiano is developing a PSoC solution for a broken dishwasher. In addition to the fix, he plans to make it smartphone-controllable.

The control module on this appliance has failed, so I am wiring it into a PSoC to make it work again as well as add some new capabilities (such as keeping a wash/rinse/door open log so it can tell when the dishes contained within it are clean or dirty, and adding a Bluetooth module so I can check the status and control/program the appliance from my smartphone).

This is the type of personal project I like to work on in my free time. It also might make a good app note or article in the future, as it involves an Android application and Bluetooth communication. It also increases my capabilities, if I have to figure out anything new. And that is always good.

I am almost ready to hook it up to the dishwasher, let it try running through the cycles, and hope I don’t flood my house in the process. Ah, the pure excitement of engineering!

The entire interview is available in Circuit Cellar 272 March 2013.

Q&A: Colin O’Flynn (Engineering and “Pure” Research)

Colin O’Flynn

NAN: Where are you located?

COLIN: I’m currently living in Halifax, Nova Scotia, Canada. I’m originally from Hamilton, Ontario, Canada, and had been living in Edinburgh, Scotland for almost two years before I moved to Halifax.

NAN: How did you become interested in electronics?

COLIN: Like many people in this area, I did start at a very young age. If I had to pin one event as the starting of my life-long interest in electronics, it was getting one of those “20-in-1” kits from RadioShack as a present. My parents always encouraged my interest in electronics, but as they were a commercial airline pilot and a chartered accountant, it wasn’t the case of them initially pushing me in the same direction they started!

My dad found me a few small “learn-to-solder” kits, which I enjoyed. At age 8, I assembled my first real kit, the LED-Tric Christmas tree featured in the December 1994 issue of Popular Electronics. My parents have kept bringing that tree out as a Christmas decoration every year since, and it still works.

Besides my parents, I also had help from local people interested in electronics and became friends with many of the local electronics store owners. I spent many hours building projects from magazines like Electronics Now, Popular Electronics, Circuit Cellar, and the various Forrest M. Mims III books. I find it interesting to see the recent surge in “maker” culture. It’s something that has really been going on for years. Growing up, there wasn’t such a thing as maker spaces, but there were local people with interesting workshops who would share projects. It’s great to see this a little more mainstream now, as it means more opportunities for people to get involved at any stage of their life in this fascinating world.

NAN: What is your current occupation? Are you still consulting for projects related to 802.15.4 wireless communications?

COLIN: I’m currently a graduate student at Dalhousie University pursuing a PhD. I decided to go back to school for the chance to do more “pure” research. It’s also fun to have access to a range of tools I wouldn’t otherwise get—the lab I sit in has an anechoic chamber, for example. And we have most of the latest versions of high-end software like MATLAB (including most of the add-ons), 3-D electromagnetic antenna simulation software, FPGA design software, and so forth.

RadioBlocks

I’m only loosely involved in 802.15.4 projects for now, and not actively following the latest developments and standards. Having said that, a friend of mine has gotten involved in creating small, wireless modules called RadioBlocks.

They use an IEEE 802.15.4 radio combined with a small ARM Cortex-M0 microcontroller. They use an open-source mesh networking software we created called SimpleMesh, so most of my recent work on 802.15.4 has been around this project. The mesh software is designed to do the basic job of sending a block of data to another node, and otherwise staying out of the way. I previously did a lot of work using IPv6 on such small sensor networks, but haven’t been active in that area lately.

At Dalhousie, I’m working on the area of side-channel analysis of cryptographic systems, specifically power analysis. This area has a simple idea: if you have a microcontroller or other embedded controller, it typically has some internal data bus. When those data lines switch state, it takes power. But the power actually depends on the data. Imagine a databus switching from all 1s to all 0s in a clock cycle, compared to staying at all 1s. Likewise, different operations, such as a MUL compared to a LDI, have different power signatures. If you measure the current consumption on each clock cycle, you can learn something about the data being processed, and then often the secret key. Practically speaking, you can measure this current even with an electromagnetic probe, so you don’t need to physically modify the circuit board.

I gave a presentation at Black Hat Abu Dhabi in December 2012 about some of this work. If you are interested, the slides and white paper are available online at Blackhat.com, or from my personal website NewAE.com. You can see the photo above showing an example of attacking a microcontroller-based smart card. The capture software might look something like where you can see different computations the card is performing directly from the power trace. In this case, each burst is a round of the AES-128 computation.

NAN: Many of your projects include Atmel microcontrollers. Why Atmel?

COLIN: It’s no secret I’ve been a big fan of Atmel’s AVR microcontroller, but it wasn’t my first. I don’t know the exact lineage of my microcontroller work, but one of the first things I learned on was an AMD 2900 Evaluation and Learning Kit. A local electronics store happened to have it in stock. They had gotten it from someone cleaning out old inventory, as even at that time it was old. I added heatsinks, as the several amps it drew when powered with 5 V made a lot of those chips very hot. And, of course, you had to keep the entire board powered up if you didn’t want to lose you program you’d been manually entering. From there, I moved onto a Z80 trainer board, which let you program with a hex-entry keypad, and eventually I moved onto programming it from the computer. I designed a Z80 computer board but never built it—I still have the piece of transparency with the taped out PCB design and photosensitive PCB on which I was to expose it. That’s more than 10 years old now, so I suspect the chemicals in it have degraded a little!

I forget exactly why I picked up the AVRs, but I had one of the first AVRs released, Atmel’s AT90S1200, which I programmed in Assembly. After Assembly, I programmed them in BASIC (using MCS Electronics’s BASCOM-AVR), going as far to write a neural network in

BASCOM-AVR. Even today, I think BASIC gets a bad rap. It was almost the original “Arduino” environment, as you could drop down LCD drivers, ADC, and so forth without ever knowing much about how it worked, and with a really intuitive feel. I moved onto C sometime later, and used C almost exclusively for embedded development since. For some time, I was fairly involved in the tools used in the AVR world, such as WinAVR. Atmel donated a considerable amount of equipment to me, as at the time I was a high school student using these devices for science fair projects. I think that’s a great example of how such corporate donations pay off. I’ve almost exclusively used AVR processors since I am so familiar with them because of that. In addition, as a student with little money but lots of time, I was happy to spend hours each day on AVRFreaks.net or working on open-source tools. While Atmel probably ended up giving me around $3,000 worth of tools, I’m sure the value of work I performed for free in terms of open-source tool contributions or forum posts would be worth many times this.

A funny story around all this work: In undergrad, we used the Atmel AVR microcontrollers. During one of the first labs they distributed a tutorial on how to set up the WinAVR tools and compile your first program. As it turned out, this guide was something I wrote years prior and had posted to the WinAVR website. Sufficient to say, I did OK in that class.

NAN: Tell us about NewAE.com. What kind of information is available on the site?

COLIN: I’ve run NewAE.com since 2001, although it’s not really designed to be the type of website one checks for new content daily. If I’ve spent some time solving a problem that I think other people could use, I’ll put a post up. Sometimes this is a complete project, such as my IEEE 802.15.4 sniffer. Sometimes it’s just a small post, such as how to set up the AVR USB keyboard for 5-V operation, which wasn’t described in the manual. I also use it for keeping copies of any published papers or presentations.

I’ve more recently been posting some ongoing research to the site, including blog posts with ongoing projects, rather than just waiting until it’s completely finished! In that vein, I started a YouTube channel with some technical videos (www.youtube.com/user/colinpoflynn). A big collection of these are from when I taught a digital logic course and recorded all my presentations from that.

My content spans a huge range of topics—everything from showing my students how to get screen captures, to a demonstration of my soldering station, to recordings of my academic paper presentations. I don’t like duplicating work. I’ll only go to the effort of making a video or website post if I really couldn’t find the information elsewhere. Because of this, I don’t have one specific topic you could expect to learn about. I’ve never been aiming to be like EEVBlog!

NAN: You wrote “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002) more than 10 years ago. Do you still use SNAP in any of your current projects?

COLIN: I have to admit that I haven’t used SNAP in probably eight years! Of course now, when needing to network devices, I’m more likely to turn to a wireless standard.

NAN: Your article “Open-Source AVR Development” (Circuit Cellar 196, 2006) provides an introduction to the AVR-GCC toolchain for AVR microcontrollers. The article references the Cygwin project and Sourceforge’s WinAVR project. How do these components work in the design?

COLIN: The Cygwin project is still something I use regularly, as it lets you run a variety of Unix-like tools on Windows. The Linux command line is extraordinarily powerful, and it is makes it simple to access things like C compilers, text parsing utilities, and scripting tools. With Cygwin, one can have a Linux-like experience under Windows, which I used in that article to build some of the tools you are developing for AVR. By comparison, WinAVR is just a number of prebuilt tools for the AVR development. While it’s more work to build your own tools, sometimes you require special features that were not available in the premade tools.

NAN: Atmel products have played a starring role in several articles you have published in Circuit Cellar. For example, an AT90S4433 microcontroller was featured in “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002), an ATmega88 AVR RISC microcontroller was featured in “Digital Video in an Embedded System” (issue 184, 2005), an AT45DB041 DataFlash and an ATmega88 microcontroller were featured in “Open-Source AVR Development” (issue 187, 2006), and an AT90USBKEY demonstration board was featured in “Advanced USB Design Debugging” (issue 241, 2010). Why Atmel microcontrollers/boards? What do you prefer about these products?

COLIN: As I mentioned before, I have a long history with Atmel products. Because of this, I already have the debug toolchains for their chips and can get projects up very quickly.

When picking boards or products, one of the most important considerations for me is that readers can buy it easily. For me, this means I can get it at DigiKey (and I’ll check Farnell for our UK friends). Part of this comes from being in Canada, where DigiKey was one of the first distributors offering cheap and fast shipping to Canada.

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

Binary Explorer Board

COLIN: My current big project is something I designed over the summer of 2012. It’s called the Binary Explorer Board and is something I used when teaching a course in digital logic at Dalhousie University. I needed a simple, programmable logic board and nothing I could find was exactly right. In particular, I needed something with an integrated programmer, several switches and LEDs, and an integrated breadboard. The students needed to be able to use the breadboard without the CPLD to learn about discretely packaged parts. All the CPLD-based trainers I found didn’t have exactly what I wanted in this regard.

The embedded part is the USB interface using an Atmel AT90USB162 microcontroller, although I plan on later upgrading that to an XMEGA for lower cost and more code room. The firmware is powered by Dean Camera’s excellent open-source USB library called LUFA (www.fourwalledcubicle.com/LUFA.php). This firmware lets students program the CPLD on the board easily over USB. But the cool thing is you can go even further and use the device as a generic programmer for other AVRs or CPLDs/FPGAs. For example, you can mount an AVR on the breadboard, connect it to the USB interface, and program that through the Arduino IDE. The entire board would retail for $35 in single-unit quantity, so it’s cheaper than most textbooks. I’m working on making it a real product with Colorado Micro Devices right now.

The design environment is the standard Xilinx toolchain, although I’ve made a number of predefined projects to make it simple enough for students with zero previous design experience to use. The idea is to get students familiar with the real tools they might see in the industry. Around this project, it’s interesting to note I choose a Xilinx CPLD because of my familiarity with Xilinx devices and design tools. This familiarity comes from years ago when Xilinx donated to me a part for a project I was working on. Now throngs of students will be exposed to Xilinx devices, all because Xilinx was willing to donate some parts to a student.

There is always an assortment of half-finished projects, too. I started designing a battery tester, which could simulate characteristics you’d typically see when driving small wireless nodes from coin-cell batteries. I started planning on using an AVR USB microcontroller and doing all the data logging myself. I then found this LabJack device, which simplified my life a lot, as they had basically a generic USB-based logging/control module.

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

COLIN: Wireless and the “Internet of Things” will eventually be a big thing, which means design engineers will need to become more familiar with things like protocols and realistic transmission characteristics. I use the word “realistic,” as part of this world is separating hype from reality. There’s certainly a huge disconnect between the marketing hype around all these various wireless protocols and how well they work in practice. When designing a product that will use a wireless technology, it’s likely some commercial off-the-shelf (COTS) module will be used, so the engineer may think they can remain blissfully unaware of RF or networking things. But the engineer still needs to have a rough idea about how many devices might fit in an area on a single network or the advantage of selecting certain protocols.

Another thing of interest to me is programmable logic, such as FPGAs. It’s been interesting to see the tools that try to turn anybody into an FPGA designer becoming more mainstream, or at least letting you program FPGAs in more common languages (e.g., C/C++). They are still fairly specialized and more likely to be used by a hardware engineer looking to improve productivity, compared to a software engineer who needs to offload an algorithm into a FPGA. But I think they could fairly quickly get to the point that engineers with some FPGA experience could implement considerably more complex designs than they would have otherwise been able to had they been required to design everything from scratch.

In a somewhat similar vein, we are starting to see the availability of multicore devices coming down to embedded levels. Learning to program them in a way to take advantage of these new cores is a useful skill to pick up. I recently started using both the OpenMP API and Cilk++ development software on some of my programs. My work wasn’t targeting an embedded project, but instead regular full-size multicore computers, but it’s still a useful (and fairly simple) skill to pick up.

NAN: Tell us a little about your workbench. What are some of your favorite design tools?

Colin’s Workbench

COLIN: My initial workbench was the kitchen table, although other family members were frequently concerned about eating in the same space as these various items with warning labels about lead. My next workbench was a long, custom-built bench in Hamilton, Ontario. My current bench in Halifax was again custom-built, and I’ll take you few of its features. I’d like to point out by “custom-built” I mean built by myself with a jigsaw and some plywood, not an artesian finely crafted piece of furniture.

Due to a back injury, I work standing up, which you can’t see in the photo. It’s actually quite refreshing, and combined with a good quality antifatigue mat and stool to lean up against means I can work long hours without tiring. A cover comes down to hide everything in my desk, which was a feature partially required by my significant other, who didn’t want guests to see the typical mess of wires it contains. When closed, it also gives it some protection against any rogue water leaks. For my computer, I use a trackball instead of a mouse, and the keyboard and trackball are mounted on a plate tilted underneath the desk in a “negative” tilt angle, adjusted to most natural angle. And, because there is no way to see the keyboard while typing, it tends to keep anyone else from borrowing my computer to look something up!

I’ve wired a ground fault interrupter (GFI) into the desk, so all my power outlets are protected. If I ever did something dumb like dropping a scope ground on a live wire, the GFI socket would at least give me a hope of protecting the scope and myself. There are many outlets above and below the desk, and also a ground jack for the antistatic strap beside the thermal wire strippers. The outlets under the desk let me plug in things in a hidden manner—printers, USB hubs, and other permanent devices get wired in there. I’ve wired a number of USB hubs to the top of my desk, so I typically have around 12 free USB slots. You always seem to run out otherwise!

Most of my tools are off the desk and stored in the drawers to either side. I made the “drawers” just pieces of wood with minimal sides—the idea being most of the time you are placing PCBs or tools down, so the lack of high sides prevents you from piling too much into them! All the cables get stored on hooks to the left of my desk, and I’ve got a whiteboard that sticks up when I’m working on a problem.

SMD Organization

I store all my SMD parts in small envelopes stored in index card holders in the bottom left of my desk. While I’m not a static-phobic, I also didn’t want to use plastic film strips or plastic bags. So the paper envelopes at least I hope don’t generate much static, even if they don’t dissipate it. It’s very easy to label all your parts and also this system holds up to a high dynamic range of stock numbers. For example, capacitors get split into 10.1–99.9 nF, 100 nF, 100.1–999.9 nF, and so forth. Because you seem to end up with loads of 100-nF capacitors, they get their own envelope. It’s trivial to change this division around as you get more parts, or to group part sizes together.

In terms of interesting tools: my soldering station is probably my favorite tool, a Metcal MX500 I got used from eBay. The response time on these is unbelievable. I put a video up to show people just because I’ve been so impressed with it. There are other manufactures that now make stations with the same RF-heating technology I believe, and I always encourage everyone to try one. I’ve been using the DG8SAQ Vector Network Analyzer (VNWA) for a while too. It’s a very affordable way to get familiar with VNA and RF measurements. It’s especially fun to follow along with some of the “Darker Side” columns in Circuit Cellar. Rather than just hearing about the mysterious world of RF, you can do experiments like viewing the response of several different decoupling capacitors mounted in parallel. I’ve got an old TiePie TiePieSCOPE HS801 parallel-port oscilloscope mounted underneath my desk, and still use it today. A lot of my work is digital, so have an Intronix LogicPort digital analyzer, a Beagle USB 480 protocol analyzer, and oodles of microcontroller programming/debug tools from different manufacturers.