How did you get into electronics/engineering and when did you start?

I was born in Montreal, Canada and I got into electronics when I was about 15 (1972). I was invited by friends to go to a concert and they had a really cool light show with strobe lights and light chasers. A chaser is an electronic device that controls a series of lights. Each light is individually controlled. An 8-channel chaser would have 8 individual outputs. Output #1 would be connected to light #1, #9, #17, #25, et cetera. Output #2 would be connected to light #2, #10, #18, #26, et cetera. The outputs would be turned on in sequence giving the illusion that light was actually moving and thus ‘chasing’ around. This got me interested in figuring out how strobes and chasers worked. Back then, there was no Internet and to find information I had to go to the library or my local Radio Shack, which was some 15 miles from home. I started with figuring out how to do a strobe light and eventually got into digital electronics to come up with a chaser.

In 1974, I started a company called Mephistronique with a friend of mine to create disco lighting systems (discos were quite popular back then). We sold strobe lights, color organs (lights controlled by music) and our first chaser. I started with a 4-channel chaser using a couple of JK flip-flops and I was able to actually do neat things with switches and logic gates. For one thing, we could change the chase sequence. Specifically, we were able to easily change the chase direction and the pattern of the chasing light. The patterns we had were 1-2-3-4, 1-3-2-4, 4-3-2-1 and 4-2-3-1. The rate of chasing was controlled by a ubiquitous 555 timer. Once we had our first prototype, we went to a local theatrical lighting store and offered to build these for $200 each, our cost was about $100. The store immediately ordered 10 and we were quite surprised by this initial order. We delivered the 10 units a couple months later and the store asked for a more complex device. So, my partner and I set out to design an 8-channel chaser. At the time, I was investigating the use of EPROMs to generate the patterns, and in fact, I believe I was the first to come up with a chaser using this technology. I designed quite a few models of chasers and the business was doing well, but I wanted to get an engineering degree so I sold my share of the business to my partner who continued developing products based on the technology we had created. During my college days, I still helped with designs to help him out. I used to document everything I did to make it easier for my friend to understand how the electronics worked.

Can you tell us about your work history/journey to becoming the Founder, CEO and President of Micriµm?

During my undergraduate (around 1980), I got interested in microprocessors and programming. Microprocessors were quite new, and at the time there were only two choices: either you used a Z80 from Zilog or a 6800 from Motorola. I actually played with both and each one had its strong points and weaknesses. I immediately fell in love with this field even though the tools were quite crude at the time. I simply could not have enough classes on microprocessors, so I decided to pursue a Master’s degree and take computer science classes such as high-level languages, data structures and algorithms. When I graduated, I was offered the opportunity to work for a medical electronics company in Princeton, NJ. The company was called Biostim and they manufactured Transcutaneous Electrical Nerve Stimulators (T.E.N.S.) devices. These devices were used as electronic pain killers. I designed the very first microprocessor-based T.E.N.S. units on the market using an Intel 8049 and another unit using a more powerful MC68711 microcontroller unit (MCU). These were battery operated devices and the microprocessors offered us a lot of flexibility when it came to the user interface and the type of patterns we could generate out of this device. I worked for Biostim for two years, and after one year I was promoted to head of engineering and had seven people working for me.

I left Biostim to pursue a dream to work in California and found a job with Allied Signal in San Diego designing engine controls for large reciprocating engines. These engines were the size of a single-car garage and contained between six and 16 cylinders. The engines are used to pump natural gas which is extracted from the Gulf of Mexico and moved up north to supply gas to heat homes. Each engine station could have between one and 10 or so engines. Obviously a very different application than when I worked at Biostim so I had to learn quite a lot about this industry. I worked on the hardware and software design of a MC68000-based (32-bit CPU) engine control. I was responsible for the infrastructure software and a colleague was handling the control algorithms. One of the first things I put in place was a coding standard so that we could have one programming style for all the software we’d create for this product. We also decided to use a real-time kernel to help us with the architecture of the system. The real-time kernel made designing the system a lot easier, and was then convinced that I would no longer want to design products without one. I worked for Allied Signal for four years and then was offered a job in Fort Lauderdale, Florida to design much larger engine control systems. At Allied our controls were supervisory, which meant that they basically provided setpoints to other devices that controlled actuators and the like. Dynalco wanted to create full authority controls and were thus much more complex and demanding systems. And that was a direction I was interested in going.

At Dynalco, I was put in charge of software engineering, and being an electrical engineer, I influenced most of the hardware designs. I was at Dynalco for a total of about 13 years. I designed many products and wrote most of the user manuals for those products. Here is a list of some of my designs:

• A few models of ignition control systems. Some of these controlled one or two spark plugs per cylinder. I designed a way to accurately control the firing of spark plugs with 1/16 of a degree irrespective of accelerations or decelerations.
• Fuel-injection control system.
• Dual-processor ‘total engine control’ system where we controlled all aspects of the engine: ignition, speed (throttle), air/fuel ratio, starting and stopping the engine, load control, flow measurement and control, and more. In all, this control system had up to 13 different sub-systems. Both processors were running a real-time kernel and communicated with each other.
• Dynalco was involved in agricultural products and I also designed control systems for hay balers and windrowers.
• A line of MCU-based smart meters.
• DOS-based data monitoring and product configuration system.

I’m sure you know that we use the term ‘embedded system’ to represent products that are typically designed around microprocessors and that have dedicated functions. Here are some examples of embedded systems:

• Washing machines
• Printers
• Alarm clocks
• Portable GPS navigation units
• Digital cameras
• Video cameras
• Cell phones (non-smart phones)
• Engine controls

Basically, an embedded system has a unique dedicated function and cannot be changed. A PC is not considered an embedded system because it can run all kinds of different applications; it’s not dedicated to one specific thing.

When I was at Dynalco, we used a real-time kernel in which we found a serious bug. After spending a year with the supplier waiting for a fix, I thought about writing my own kernel since I knew what it needed to do. So, in 1991 I set out to write a kernel I called µC/OS which stands for microcontroller operating system. µC/OS was mostly written in C and I wrote a paper about it to be published in a magazine. Unfortunately the paper was 70 pages long and no magazine wanted to print such an article because it would have had to be printed in parts over many consecutive issues and months. The publisher didn’t want to drag readers along for that much time. Embedded Systems Programming magazine decided to publish a reduced version of the paper in three separate months (May, June, September 1992). Shortly after the first issue hit the news stand, I was approached by R&D Technical books to write a book about the kernel. I thought that 70 pages was not sufficient for a book so I added a lot more material and got it up to 250 pages or so. The book actually included the full source code for the kernel on a 3.5” floppy disk and could be used to develop products without requiring a license. It’s quite possible that I actually started the Open-Source movement for the embedded community.

I continued my part-time hobby of writing and published another book which came out in 1995: Embedded Systems Building Blocks, Complete and ready-to-use Modules in C. This book contained a number of modules that made it easy to create embedded products. The book was later translated into Korean.

R&D Books sold quite a few copies of the µC/OS book, and in 1998 they asked me to revise the content and create a second edition. During the six years that led to the second edition, I received a lot of feedback and requests from readers for features and additional explanations. So I decided to rewrite µC/OS and create a new version of the software that I called µC/OS-II. The book was also completely revised and I asked CMP Books (which acquired R&D Books) to do a hard cover instead of a soft cover book. This book now had 550 or so pages and was the first hard cover book that CMP did. µC/OS-II was highly popular and was translated into Chinese and Korean. The µC/OS-II book is actually the most popular embedded systems book ever published.

I left Dynalco in 1997 and went to work for Microtec (a division of Mentor Graphics) in the consulting services group. I only stayed with Microtec for 14 months because I was always flying all over the place to visit customers and that prevented me from spending time with my family. Shortly after leaving Microtec, I was getting a large number of requests to license the use of µC/OS-II in products, so I decided to start my own business—Micriµm. The name comes from ‘micro’ and ‘ium’ (which means the universe of). Micriµm thus means the “Universe of Micros”. The µC/OS-II book was the seed that got me to start Micriµm, which I incorporated in 1999.

What have been some of your influences that have helped you get to where you are today?

I think there are five things that most influenced my career: *

• My partner at Mephistronique who always demanded perfection and quality, and his thirst for knowledge got me to document everything I did.
• The C programming language which allowed code to be portable.
• The C coding standards we established early helped me write very clean and readable code.
• Using real-time kernels in products got me to appreciate the leverage that they gave me to create well-architected systems. In fact, a kernel is one of the many building blocks available to engineers today to quickly help them create products.
• The Internet.

Do you have any tricks up your sleeve?

One of the most important things I found was to establish coding conventions, document them and stick to them as much as possible when writing code. For example, I like to name things in a hierarchical fashion, such as Earth, North America, the U.S., Florida, Weston. So for software this translates to naming things based on the global picture, and then moving down to specifics. OSTaskCreate() for example indicates that the function is related to the operating system (OS)—specifically part of task services and the exact service of creating a task. API reference manual group liked things together., and this applies to all the modules we do: NetARP_RxPacketFree(), FSFile_Close(), et cetera.

The other thing is to try to find simple solutions to complex problems. This seems obvious, but it’s not always easy to do. Software should be written to be read so that others can better use what you’ve done. For this reason, approach projects with the understanding that you don’t own the code; your employer does. Write code so you don’t have to maintain it. Write code so that your replacement or colleagues will praise your work instead of saying nasty things about you once you leave. Put pride in what you do and that goes beyond just getting the product to work. Well written, clean, consistent and documented code is one of the keys to the success of Micriµm. All our engineers are indoctrinated with the Micriµm way, and in fact, out of the million or so lines of code we have, you’d be hard pressed to know who wrote what.

Another trick I have is to graphically represent concepts. I find that it’s a lot easier to explain something using an illustration that I narrate with text than to use code or only a textual description. If you look at my books, you will find hundreds of illustrations.

One final thing: Be passionate about what you do.

What has been your favorite project?

I have worked on so many exciting things over the years, but my favorite project is by far writing books—most recently, the µC/OS-III book. Writing a book like µC/OS-III allowed me to stay current with programming, processor technology, as well as find better ways to explain concepts and stay up to date with state-of-the-art technology. I have to say though that writing a book is very draining. You end up reading it four or five times over and even after it’s published, you always find some little things that could have been improved. However, there’s no better feeling than having the first finished book in your hands.

Do you have any note-worthy engineering experiences such as great accomplishments or awards?

Being in the business for so long, I would have quite a few note-worthy experiences to share. I’ll just mention one of them for brevity.

A few years ago I hired a team of Windows developers to create a Windows-based application that would allow a PC to query a target (i.e., a product) for the current values of variables (at run-time) and display those values on virtual gauges, meters, barcharts, numeric indicators et cetera, and also allow values to be changed through virtual sliders, knobs and switches. This product is called µC/Probe and can interface to any target processor, whether 8, 16, 32, 64-bit or DSP through either a J-Tag interface, RS-232C, TCP/IP or even USB. You can thus develop a headless product and still be able to see what your product is doing. µC/Probe actually doesn’t require any target resident code when used with a J-Tag interface, so you can start looking at the values of variables as soon as you download and run code on your target. µC/Probe actually won best-of-show award at Freescale Technology Forum (FTF) a couple years back.

Can you tell us about the three books you wrote about embedded design, as well as some of your articles?

I already mentioned the µC/OS-II and Embedded Systems Building Block books.

The µC/OS-III book is my latest and I decided to again completely revise both the code and the contents of the book.

When I did the µC/OS-II book, evaluation boards were fairly expensive compared to today so I wrote the book around the 80×86 running under DOS so that most people could experience µC/OS-II on their PC.

With µC/OS-III, I decided to create a book that would provide examples using a popular CPU architecture and offer a low-cost companion evaluation board and tools for readers to experience µC/OS-III on real hardware. The book/board actually contains five parts:

• Part I explains what a kernel is, how to use a kernel’s features and also how a kernel works by explaining the inner workings of µC/OS-III. Lots of details and illustrations. This part is about 700 pages.
• Part II describes the companion evaluation board and shows examples of how to setup and use µC/OS-III with an evaluation board that we designed in collaboration with STMicroelectronics. This part is about 250 pages.
• The book provides a link to IAR’s Kickstart edition of its highly popular EWARM toolchain which contains a C compiler, assembler, linker/locator and C-Spy debugger. The Kickstart edition of the tools allows the reader to create example applications having up to 32 Kbytes of code space.
• The board (called the µC/Eval-STM32F107) is based on the STMicroelectronics STM32F107 MCU which contains the highly popular Cortex-M3 ARM core. The evaluation board is also equipped with an Ethernet connector, a USB-OTG connector, an SD card socket, an RS-232C port, a temperature sensor, LEDs, a prototyping area and an on-board Segger J-Link which interface to the IAR C-Spy debugger.
• The award winning µC/Probe, which is a data visualization tool allowing target variables to be displayed in real-time on a PC via virtual gauges, meters, bar graphs, LEDs, et cetera. The user can also change the value of variable using sliders, knobs and switches.

This concept was so popular that we’ve been able to replicate it on five additional processor architectures. We now have a µC/OS-III book for the following platforms:

• NXP LPC1768, Cortex-M3 based MCU with companion MCB1700 evaluation board and Keil tools
• Texas Instruments LM3S9B92, Cortex-M3 based MCU with companion EVALBOT evaluation board and IAR tools.
• Renesas SH7216 SH2A-FPU based ultra-high performance MCU with FPU with companion YRDKSH7216 evaluation board and HEW tools
• Renesas RX62N RX600 based MCU with FPU with companion YRDKRX62N evaluation board and HEW tools
• Freescale Kinetis K50, Cortex-M4 based MCU with companion Tower system and IAR tools

What are you currently working on?

Unfortunately, this is something I prefer not to mention since we are in a very competitive environment. Needless to say, however, Micriµm is always looking at creating high quality products to help our customers reduce time to market.

How do you continue to maintain an active role in product development?

I still maintain the µC/OS-II and µC/OS-III code bases, I visit customers and semiconductor partners to determine their needs, I get involved in new and current product definition and requirements, features, planning and reviews, and I even test some of the software. I evaluate new technologies, I write books (we consider those as products), and I like to read technical magazines to see what’s happening in the industry and adjust the direction of the company accordingly.

Can you tell us more about Micriµm and the technology it is developing?

Micriµm develops and licenses a Real-Time Operating System (RTOS). An RTOS consists of a kernel (either µC/OS-II or µC/OS-III), a TCP/IP stack, a File System, a USB-Device and USB-Host stacks, a Graphical User Interface (GUI) and so on. You can basically purchase any or all components individually. If you need only the kernel, you buy that. You need only a file system, you only buy that module. Our software is delivered in source code form (mostly C) and it’s probably the nicest looking software you can put your eyeballs on.

Our focus is on creating reusable software modules that are easy to use, reliable, well written and highly documented to help our customer create high quality products and shave months off their schedules.

It’s interesting to note that years ago, developers used to start their designs by selecting a microprocessor and then figuring out which tools they needed and then how to write the software. It seems that over the past few years, developers are changing their approach. More and more we are seeing developers take more of a system view and thus decide on what high-level features they need (e.g., connectivity, HMI, data storage) and then select their tools and chips to satisfy their requirements. The fact that our software is highly portable across microprocessor platforms makes this process fairly painless and natural.

How has the company changed since it was launched in 1999?

Well, we went from a one person company to, based on the latest UBM survey, the number one commercial RTOS supplier, so I’d say quite significantly over the past 12 years. When I started Micriµm, the only product I had was µC/OS-II and now we have about 20 or so products.

I have to say that I could not have done it alone. In 2002, a longtime friend of mine, Mr. Christian Legare joined Micriµm as my partner. Together we built Micriµm to what it is today. Of course, Micriµm’s success is also attributed to the hard work and dedication of our employees and partners.

Our software is found in thousands of products worldwide and we even have products in satellites and spacecrafts.

Can you tell us about some of the new technologies Micriµm is working on in the medical, military, telecom or embedded design areas?

Well, we develop all our products following the highest quality standards and some of them are ready to be certified for safety critical system as found in medical, avionics and industrial products. A safety critical system is one that cannot afford to fail, or else could cause damage to assets or even lives. uC/OS-II has been used in countless avionics applications and has been certified in products following DO178B Level A, countless medical products (510(k) and PMA) and industrial controls following the IEC-61508 norm. Having the DO178B Level A certification is a testament to the high quality of uC/OS-II because it had to undergo extreme testing under all possible boundary conditions.

There are a lot of opportunities in the marketplace and Micriµm is well positioned to assist customers with solutions: The Internet of Things, Wireless everywhere, The Smart Grid, Alternative Energy…

However, beyond this, I’d rather not elaborate on our current and future plans.

What direction do you see your business heading in the next few years?

We will continue to develop new products to satisfy the needs of our customers. We expect to significantly improve our already dominant position in the marketplace since we recently added six global distributors (Arrow, Avnet, Digikey, Future Electronics, Premier Farnell and Mouser). We will continue to improve our processes and make it even easier for our customers to use and deploy our products.

What can we expect to see from Micriµm in the near future?

Certainly, new and innovative products as well as ways to further reduce customer product development time.

What challenges do you foresee in our industry?

It used to be that the software for a product could be developed by a single engineer. Now, average software development teams require between four and nine engineers, and in a lot of cases, each developer requires different specialties and skills. Managing such projects is certainly a challenge.

New processors/chips are being introduced at a frantic rate and it’s virtually impossible to port some of our software to all the different variances. Most of the issues are not related to CPU architectures but instead, with I/O devices. The fact that a lot of the semiconductor manufacturers are adopting identical CPU cores actually does little to change that problem since CPU architectures have long been isolated by high-level language compilers (mostly C and C++ for embedded systems). In other words, the instruction set and CPU architecture is generally hidden from the application developer anyway. So, even though the CPU architecture is the same from one manufacturer to another, the peripheral devices such as Ethernet, USB device, USB host, LCD controller and CAN-bus are all different, and in many cases, even different from within the same device family offered by a semiconductor manufacturer. From a software vendor’s point of view, it would make more sense for them to reuse as much of the same hardware IP blocks (located at the same physical address) from one device to the other so that drivers can be written once.

Another challenge is the ever increasing complexity of processors and MCUs: faster, more powerful processors, high peripheral device integration, complex power, pin and clock management, user manuals having thousands of pages, multicore, mega-lines of code, debugging, code quality or lack thereof, ever rising customer expectations and time to market pressures. The list goes on and on.

A big trend in the industry is multicore. The challenge I see here is in debugging. It’s already complex enough to debug single core systems. I believe the problem scales exponentially with multiple cores.

Linux has caused a big buzz in the industry mostly because it is open-source and people have the perception that it’s free. It’s a perception because everybody that has ever played with Linux will tell you that Linux is a complex system and that you will literally spend months figuring it out. So, unless you consider your time to be worth nothing then it’s not free. Also, because of its freeness, engineers have been embedding Linux in applications where Linux might not belong. How many times did the entertainment system (running Linux) in a plane crash? Of course, such an entertainment system is not safety critical, so apart from annoying passengers it shouldn’t be life threatening. I have a TiVo unit which is obviously Linux based. Boot up time is in the order of minutes. Remote control response time is on the edge of being unacceptable. Linux is also very large and in fact, we might not see Linux in MCUs for years to come. I make the analogy of Linux being an 18-wheel truck and RTOSs are cars. You would certainly not want to drive to work every day in a huge truck, and you would not want to move furniture in a car. Each have its market and use, and engineers should be able to determine when one is better to use than the other based on their product requirements.

So, some of the challenges:

• Satisfying customer expectations
• Creating drivers for ever changing peripheral devices
• Managing software complexity
• Software portability and reuse
• Multicore debugging
• Use of an RTOS or Linux when appropriate