Tag Archives: multicore

AMD has unveiled a lower-powered version of the Ryzen Embedded V1000 SoC called the Ryzen Embedded R1000 with dual quad-threaded cores, 12-25 W TDPs, triple 4K displays, and support for dual 10GbE ports.
When AMD unveiled the Ryzen Embedded V1000 in Feb. 2018, the chipmaker claimed the x86-based CPU delivered twice the performance of its earlier R-Series chips. Now, the chipmaker has introduced a stripped-down Ryzen Embedded R1000 variant with the same low power consumption as the old R-Series while still offering considerably better CPU and GPU performance.

The Ryzen Embedded R1000 offers the same Zen CPU and Vega GPU cores as the V1000 while providing “3x generational performance improvement per watt” compared to the R-Series Merlin Falcon. The Linux-friendly chips are hardware and software compatible with the V1000.

The R1000 is designed for fanless embedded systems in applications including digital displays, high-performance edge computing, networking, and thin clients. Early adopters include Atari, which is using it for its VCS console, and Ibase, which announced an SBC and signage player (see farther below).

Ryzen Embedded R1000 models
(click image to enlarge)

The 14 nm FinFET fabricated Ryzen Embedded R1000 is available initially in two very similar R1606G and R1505G models. Like the lowest end V1202B version of the V1000, the new SoCs offer dual-core, quad-threaded CPUs, triple-core GPUs, and 12-25 W TDPs. They similarly provide 1 MB L2 and 4 MB L3 cache. Like all the Zen-based chips, they ship in an FP5 BGA form factor.

Although the R1000 lacks the support for 4x independent 4K@60 displays available with all the V1000 models, it does offer triple 4K displays. The first two models are also faster than the V1202B. The R1606G has a 2.6GHz (3.5GHz boost) CPU and the R1505G goes to 2.4 GHz / 3.3 GHz.

Like the V1202B, the lower-end R1505G has a 1GHz GPU, while the R1606G clocks its Vega GPU cores to 1.2GHz. Video support includes VP9 10-bit decode, H.265 10-bit decode and 8-bit encode, and H.264 encode and decode.

Security features are the same as those on the V1000, including an AMD Secure Processor “that encrypts data before it feeds to the I/O” and Platform Secure Boot capabilities, says AMD. One-time programmable (OTP) capabilities enable system designers to manage their own keys.

Ryzen Embedded R1000 and block diagram
(click images to enlarge)

Like the two lower-end V1000 models, the R1000 SoCs support up to 2400MT/s DDR4 instead of 3200MT/s on the two higher end V1000 chips. As with the V1000 models except the dual-core V1202B, the R1000 chips support up to dual 10GbE ports as well as various 1GbE and 2.5GbE configurations.

Like Intel’s latest 8th Gen, low-power Whiskey Lake-U CPUs, the chips support USB 3.1 Gen2 for up to 10Gbps throughput. Like the V1000, the R1000 SoC can drive up to 4x USB 3.1 ports as well as a USB Type-C port with DP support. PCIe support tops out at 8x lanes rather than 16x on the V1000. Other I/O support is mostly the same, including dual SATA and NVMe support.

The default OS for the R1000 is Mentor Embedded Linux (MEL) from Siemens. This Yocto Project flavored distro is now called “MEL Flex OS” to differentiate it from the new binary Debian version, called MEL Omni OS. AMD also lists support for Ubuntu 18.04.1, Yocto 2.5, and Windows 10.

Atari VCS

Early adopters: Atari VCS, Ibase SBC, and more

Early R1000 adopters include Advantech, ASRock Industrial, Atari, Axiomtek, DFI, Ibase, Kontron, MEN, Netronome, Quixant, Sapphire, Stratacache, and zSpace. Atari will be using it for its Ubuntu powered Atari VCS in place of the originally announced AMD A1 CPU. “With the AMD Ryzen Embedded R1000 powering the Atari VCS, we can support the 4K 60fps HDR content that users expect from a modern, secure gaming and entertainment system,” stated Michael Arzt, COO of Atari Connected Devices.

Stratacache will use the R1000 in upcoming multi-output digital signage players across its Stratacache, Scala, X2O Media, and Real Digital Media product families. Netronome plans to make R1000-based networking solutions, security appliances, and edge cloud computing systems. Quixant will deploy the SoC in a lower-end version of its V1000-based QXi-7000 casino gaming system called the QXi-7000 LITE.

Ibase SI-323-N and IB918
(click image to enlarge)

Ibase Technology offered more details on an upcoming 3.5-inch IB918 SBC and SI-323-N signage player. The IB918 supports either R1000 model. You can load up to 32GB DDR4-2400 including ECC memory.

The IB918 SBC offers a SATA III port and an M.2 M-key interface for storage as well as 2x M.2 slots for 2280/2230 card expansion. Other features include 2x HDMI, 1x eDP, 2x GbE, and 4x USB 3.1 ports. There’s a 12-24V DC input and an optional heatsink with fan.

Dialog Semiconductor has announced its SmartBond DA1469x family of Bluetooth low energy SoCs, a range of multi-core MCUs for wireless connectivity. The devices’ three integrated cores have each been carefully chosen for their capabilities to sense, process and communicate between connected devices, says Dialog. To provide the devices’ processing power, the DA1469x product family is the first wireless MCU in production with a dedicated application processor based on the Arm Cortex-M33 CPU, according to Dialog.

The M33 is aimed at compute intensive applications, such as high-end fitness trackers, advanced smart home devices and virtual reality game controllers. The DA1469x devices have a new integrated radio that offers double the range compared to its predecessor together with an Arm Cortex-M0+ based software-programmable packet engine that implements protocols and provides full flexibility for wireless communication.

On the connectivity front, an emerging application is for manufacturers to deploy accurate positioning through the Angle of Arrival and Angle of Departure features of the newly introduced Bluetooth 5.1 standard. With its world-class radio front end performance and configurable protocol engine, the DA1469x complies with this new version of the standard and opens new opportunities for devices that require accurate indoor positioning such as building access and remote keyless entry systems.

To enhance the sensing functionality of the DA1469x, the M33 application processor and M0+ protocol engine is complemented with a Sensor Node Controller (SNC), which is based on a programmable micro-DSP that runs autonomously and independently processes data from the sensors connected to its digital and analog interfaces, waking the application processor only when needed. In addition to this power-saving feature, a state-of-the-art Power Management Unit (PMU) provides best-in-class power management by controlling the different processing cores and only activating them as needed.

The SoCs feature up to 144 DMIPS, 512 KB of RAM, memory protection, a floating-point unit, a dedicated crypto engine to enable end-to-end security and expandable memories, ensuring a wide range of advanced smart device applications can be implemented using the chipset family and supporting a range of key value-add interfaces to extend functionality even further.

The PMU also provides three regulated power rails and one LDO output to supply external system components, removing the requirement of a separate power management IC (PMIC). Additionally, the DA169x product family come equipped with a range of key value-add interfaces including a display driver, an audio interface, USB, a high-accuracy ADC, a haptic driver capable of driving both ERM and LRA motors as well as a programmable stepping motor controller.

Developers working with the DA1469x product family can make use of Dialog’s software development suite – SmartSnippets – which gives them the tools they need to develop best-in-class applications on the new MCUs. The DA1469x variants will start volume production in the first half of 2019. Samples and development kits are available now.

Renesas Electronics has announced an update to its Embedded Target for RH850 Multicore model-based development environment for multicore MCUs for automotive control applications. The update supports development of systems with multirate control (multiple control periods), which is now common in systems such as engine and body control systems. This model-based development environment has become practical even in software development scenarios for multicore MCUs, and can reduce the increasingly complex software development burdens especially in control system development of self-driving cars.Renesas’ earlier RH850 multicore model-based development environment automatically allocated software to the multiple cores and although verifying performance was possible, in complex systems that included multirate control, it was necessary to implement everything manually, including the RTOS and device drivers. Now there’s ever-increasing requirements to boost engine and vehicle performance, and at the same time shorten product development time. By making this development environment support multirate control, it is possible to directly generate the multicore software code from the multirate control model. This has made it possible to evaluate the execution performance in simulation.

Not only does this allow execution performance to be estimated from the earliest stages of software development, this also makes it easy to feed back the verification results into the model itself. This enables the completeness of the system development to be improved early on in the process, and the burden of developing the ever-larger scale, and increasingly complex, software systems can be significantly reduced. Renesas is accelerating the practical utility of model-based development environments in software development for multicore processors and is leading the evolution of green electric vehicles as proposed in the Renesas autonomy concept.

Control functions development requires multirate control, such as intake/exhaust period in engine control, the period of fuel injection and ignition, and the period with which the car’s status is verified. These are all different periods. By applying the technology that generates RH850 multicore code from the Simulink control mode to multirate control, it has become possible to directly generate multicore code, even from models that include multiple periods, such as engine control.

Renesas also provides as an option for the Integrated Development Environment CS+ for the RH850, a cycle precision simulator that can measure time with a precision on par with that of actual systems. By using this option, it is possible to estimate the execution performance of a model of the multicore MCU at the early stages of software development. This can significantly reduce the software development period.

The JMAAB (Japan MBD Automotive Advisory Board), an organization that promotes model-based development for automotive control systems, recommends several control models from the JMAAB Control Modeling Guidelines. Of those, Renesas is providing in this update the Simulink® Scheduler Block, which conforms to type (alpha) which provides a scheduler layer in the upper layer. This makes it possible to follow the multirate single-task method without an OS, express the core specifications and synchronization in the Simulink model, and automatically generate multicore code for the RH850 to implement deterministic operations.

Along with advances in the degree of electronic control in today’s cars, integration is also progressing in the ECUs (electronic control units), which are comparatively small-scale systems. By supporting multirate control, making it easier to operate small-scale systems with different control periods with a multicore microcontroller, it is now possible to verify the operation of a whole ECU that integrates multiple systems.

The updated model-based development environment is planned to support Renesas’ RH850/P1H-C MCU that includes two cores by this fall, and also support for the RH850/E2x Series of MCUs that include up to six cores is in the planning. In addition, Renesas plans to deploy this development environment to the entire Renesas autonomy Platform, including the “R-Car” Family of SoCs.

Renesas is also continuing to work to further improve the efficiency of model-based software development, including model-based parallelization tools from partner companies and strengthening of related multirate control support execution performance estimation including the operating system. Moving forward, Renesas plans to apply the model-based design expertise fostered in its automotive development efforts in the continually growing RX Family in the industrial area which is seeing continued increases in both complexity and scale.

The types of displays available for embedded applications are as diverse as embedded applications themselves. Whether your requirement is for small, smart, rugged or rain-proof, there’s probably a display solution that suits your system design needs.

By Jeff Child, Editor-in-Chief

Long gone are the days when the Graphics Processor Unit (GPU) market was filled with many semiconductor vendors jockeying for position. A combination of chip integration: graphics function moving inside microprocessors—and business consolidation: graphics chip vendors getting acquired, has narrowed the technology space down to mostly Intel, AMD and NVIDIA. And while these vendors tailor their products for high-volume markets, embedded applications must adapt those same GPUs to their needs.

With that in mind, makers of displays for embedded applications are constantly evolving their products to keep pace with the latest GPU technologies and both new and legacy display interface standards. Technologies range from small e-paper displays to rugged sunlight readable displays for the outdoors to complete Panel PC solutions that embed PC functionality as part of the display.

Mobile Dominates GPU Market

Although this article is focused on displays in embedded systems, it’s helpful to first understand the larger markets that are driving GPU technology. For its part, Jon Peddie Research (JPR), a market research and consulting firm focused on graphics and multimedia saw mobile devices as the dominate market when they did their annual review of GPU developments for 2017. In spite of the slow decline of the PC market overall, PC-based GPU sales (which include workstations) have been increasing, according to the review. In the mobile market, integrated GPUs have risen at the same rate as mobile devices and the SoCs in them. The same is true for the console market where integrated graphics are in every console and they too have increased in sales over the year.

Nearly 28% of the world’s population bought a GPU device in 2017, and that’s in addition to the systems already in use. And yet, probably less than half of them even know what the term GPU stands for, or what it does. To them the technology is invisible, and that means it’s working—they don’t have to know about it.

The market for, and use of, GPUs stretches from supercomputers and medical devices to gaming machines, mobile devices, automobiles and wearables. Just about everyone in the industrialized world has at least a half-dozen products with a GPU, and technophiles can easily count a dozen or more. The manufacturing of GPUs approaches science fiction with features that will move below 10 nm next year and have a glide-path to 3 nm—and some think even 1 nm.

Innovative Adaptations

Throughout 2017 JPR saw a few new, and some clever adaptations of GPUs that show the path for future developments and subsequent applications. 2017 was an amazing year for GPU development driven by games, eSports, AI, crypto currency mining and simulations. Autonomous vehicles started to become a reality, as did augmented reality. The over-hyped, consumer-based PC VR market explosion didn’t happen—and had little to no impact on GPU developments or sales. Most of the participants in VR already had a high-end system and the head-mounted display (HMD) was just another display to them.

Mobile GPUs, exemplified by products from Qualcomm, ARM and Imagination Technologies, are key to amazing devices with long battery life and screens at or approaching 4K. And in 2017 people started talking about and showing High dynamic range (HDR). JPR’s review says that many, if not all, the developments we will see in 2018 were started as early as 2015, and that three to four-year lead time will continue.

Lead times could get longer as semiconductor engineers learn how to deal with chips constructed with billions of transistors manufactured at feature sizes smaller than X-rays. Ironically, buying cycles are also accelerating ensuring strong competition as players try to leap-frog each other in innovation. According to JPR, we’ll see considerable innovation in 2018, with AI being the leading application that will permeate every sector of our lives. The JPR GPU Developments in 2017 Report is free to all subscribers of JPR. Individual copies of the report can be purchased for $100.

Photo 1.The Internet of Displays is a range of miniature displays that offer small color displays with integrated Wi-Fi and a microSD/HDC slot.

Internet of Displays

Focusing on the small side of the display spectrum, in November 4D Systems announced the latest addition to its Internet-of-Display module family with its smallest LCD display yet. At 0.9-inch and powered by the Wi-Fi enabled ESP8266, it is well suited for miniature IoT projects. The Internet of Displays is the company’s range of miniature feature rich displays that offer small color displays with integrated Wi-Fi and a microSD/HDC slot (Photo 1). …

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

SiFive has launched the industry’s first Linux-capable RISC-V based processor SoC. The company demonstrated the first real-world use of the HiFive Unleashed board featuring the Freedom U540 SoC, based on its U54-MC Core IP, at the FOSDEM open source developer conference.

During the session, SiFive provided updates on the RISC-V Linux effort, surprising attendees with an announcement that the presentation had been run on the HiFive Unleashed development board. With the availability of the HiFive Unleashed board and Freedom U540 SoC, SiFive has brought to market the first multicore RISC-V chip designed for commercialization, and now offers the industry’s widest array of RISC-V based Core IP.

With the Freedom U540, the first RISC-V based, 64-bit 4+1 multicore SoC with support for full featured operating systems such as Linux, the HiFive Unleashed development board will greatly spur open-source software development. The underlying CPU, the U54-MC Core IP, is ideal for applications that need full operating system support such as artificial intelligence, machine learning, networking, gateways and smart IoT devices.

The company also announced its first hackathon, which will be held during the Embedded Linux Conference, March 12 to 14 in Portland, OR. The hackathon will enable registered SiFive Developers to be among the first test out SiFive’s HiFive Unleashed board featuring the U540 SoC.

Freedom U540 processor specs include:

4+1 Multi-Core Coherent Configuration, up to 1.5 GHz

4x U54 RV64GC Application Cores with Sv39 Virtual Memory Support

1x E51 RV64IMAC Management Core

Coherent 2MB L2 Cache

64-bit DDR4 with ECC

1x Gigabit Ethernet

Built in 28nm process technology

The HiFive Unleased development board specs include:

SiFive Freedom U540 SoC

8GB DDR4 with ECC for serious application development

Gigabit Ethernet Port

32MB Quad SPI Flash

MicroSD Card for removable storage

FMC Connector for future expansion with add-in cards

Developers can purchase the HiFive Unleashed development board here. A limited batch of early access boards will ship in late March 2018, with a wider release in June. For more information or to register for the hackathon, visit www.sifive.com/products/hifive-unleashed/.

For embedded developers, it’s critical to understand the types of performance problems a typical end-user might encounter and the performance metrics relevant to user
interface (UI) design. Phil examines these and other important UI design challenges.

By Phil Brumby
Mentor, Embedded Systems Division

The widespread proliferation of portable media devices has changed the way we interact with each other on a daily basis. In fact, there is now a generation of users who grew up with some type of touchscreen device. These users no longer see the UI as new or revolutionary, but rather as a standard piece of mobile device functionality. This phenomenon has created a new set of expectations. It means any device with an LCD must offer a fluid and intuitive user experience. It’s also expected that the touchscreen has to be “smartphone-like” whenever the device is powered on. Embedded system developers are now under pressure across multiple markets and device types to replicate the smartphone UI interactive experience.

The importance of getting the UI right is absolutely critical to the success of the device. Underpinning documented UI design methodologies is a need for the device to operate in a way that it will not impinge or be detrimental to the user experience. For developers, it’s necessary to understand the types of performance problems a typical end-user might encounter, and through an understanding of performance metrics employ various analyses to highlight the bottlenecks and performance degradation issues.

A key advantage to system start-up isanalyzing selected input events.

TYPICAL PERFORMANCE ISSUES

To understand how to best analyze performance, it’s important to look at typical performance issues from the end-user’s perspective. In identifying these issues, developers can begin to identify the first data points or metrics needed for feedback on system performance.

Responsiveness: Responsiveness can be thought of as the time it takes for the user to receive feedback from the UI as a result of an input action made. Typically, this consists of a touchscreen input, but also includes hard key presses. Responsiveness is important as the user must feel the device performs within a certain timeframe to avoid the feeling a UI is “laggy” or slow to respond. Delays in updating the UI in response to input can result in frustration and mistakes made by the user.

Animation smoothness: Animation smoothness relates to the visible motion or change in appearance of elements displayed within the UI. As an element transitions from one point in 3D space to another, does it do so in a smooth manner that is pleasing to the eye? Animation smoothness is important because if the user perceives jagged or staggered motion in a transition, it will degrade the overall interactive experience. …

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Featured Product: The TRACE32-ICD in-circuit debugger supports a range of on-chip debug interfaces. The debugger’s hardware is universal and enables you to connect to different target processors by simply changing the debug cable. The PowerDebug USB 3.0 can be upgraded with the PowerProbe or the PowerIntergrator to a logic analyzer.

Product Features: The TRACE 32-ICD JTAG debugger has a 5,000-KBps download rate. It features easy high-level Assembler debugging and an interface to all industry-standard compilers. The debugger enables fast download of code to target, OS awareness debugging, and flash programming. It displays internal and external peripherals at a logical level and includes support for hardware breakpoints and trigger (if supported by chip), multicore debugging (SMP and AMP), C and C++, and all common NOR and NAND flash devices.

Product Information: The P8X32A Propeller chip is a modern, easy-to-use and a powerful multicore microcontroller that has the flexibility to propel your design to the next tier of performance and reliability. With eight independent cores at your disposal, developers can easily instantiate any number of custom soft-peripherals from Parallax’s Object Exchange library to enable the chip to fill nearly any role. From generating graphics for a control system’s VGA display to managing fly-by-wire avionics equipment, the 80-MHz Propeller chip makes short work of embedded applications that require real-time execution.

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.