Few days ago, we were honored by the visit of Jean J. Labrosse to our blog. I grasped the chance and agreed with him to have an interview with him. The interview was focused on various aspects. I tried to get the best out of it for all embedders and Micrium fans.
About Jean J. Labrosse
He founded Micrium in 1999. He is a regular speaker at the Embedded Systems Conference in Boston and Silicon Valley, and other industry conferences. He is the author of many books on embedded design. The most two famous books are MicroC/OS-II, The Real-Time Kernel and Embedded Systems Building Blocks, Complete and Ready-to-Use Modules in C. He holds a BSEE and MSEE from the university of Sherbrooke, Quebec, Canada.
Micrium Story
Q: How did Micrium Start?
I had written the uC/OS book (1992), the Embedded Systems Building Blocks book (1996) and then revised uC/OS after getting feedback from hundreds of people around the world. This thus became uC/OS-II (1998). I revised the uC/OS-II book in 2002 which is now the current version of that book. Of course, the code has evolved since then but the book has remained the same.
Since about 1994, I was receiving a lot of inquiries about pricing for licensing uC/OS and uC/OS-II for use in embedded systems. This made me decide to start a company (August 1999) to sell licenses and called it Micrium. By the way, Micrium comes from ‘Micro’ and ‘ium’ (at the time, I liked the sound of ‘ium’ as in Pentium). I wanted to have a company name that didn’t mean anything specific so that I would not be tied to the ‘uC/OS’ brand since I thought I would expand the product offering to a TCP/IP stack and other modules (which we now have). It turns out that ‘ium’ means ‘the universe of’ just like Planetarium means the universe of planets, aquarium means the universe of fishes so, Micrium means the ‘Universe of Micros’. So, I started Micrium to better support the products that I would offer through Micrium. There are currently close to 30 people working for Micrium and we plan to hire more people in 2011 and beyond.
Micrium Markets
Q: What industries do you see that Micrium products can play a role in as a backbone software solution platform?
This is difficult to answer because we are in just about every kind of products you can imagine. However, we are quite popular in medical products, avionics, industrial controls, consumer electronics, etc.
Micrium Business Models
Q: Why the business model followed for uCOS-II was not followed for the rest of Mcirium products?
Simply because it’s more difficult to ensure that companies developing products with our software would not always license the software for use. There are many countries that unfortunately don’t believe in paying the licensing fees we ask for and instead prefer stealing the software. If we were to provide the source code for all our products how can we ensure that companies and Engineers would remain honest and properly license our software? I, for one would ‘love’ to be able to expose all our software as we did with uC/OS-II but the practical reality is unfortunately different.
Micrium Role in facing the Embedded Designers Challenges
Q: What are the challenges embedded developers face and how Micrium is aiding its customers to face them?
One of the biggest challenges for embedded engineers is to overcome the tendency to go for free stuff! The internet is nice in that you can find all kinds of information from people willing to provide some of their knowledge for free. I am one of those individuals who has provide insights into how real-time kernels work and I’m glad to have contributed to the Engineering community. However, I quickly realized that it’s a lot of work to ensure that the software is 100% bug free and clean. I started Micrium to add additional products and improve on the quality of those products. Of course, as the company grew from just myself so did the expenses (office, computers, software, Engineer, sales, etc. etc.) and thus it’s difficult to compete against free stuff because Micrium’s software cost a lot to develop.
Another challenge is managing complexity of ever growing embedded applications. As clean and as documented as our software is, it’s still complex to put everything together because of the numerous combinations of CPUs, compilers, modules and evaluation boards we support. At Micrium, we work hard to make complicated things simpler to use. Most customers deal with a few different CPUs for years. We work with hundreds of CPUs on a regular basis. We try to provide ‘generic’ solutions so that customers can concentrate on the actual product they are developing.
Micrium Coping with Future Trends in Embedded Market
Q: What are the trends Micrium forsee in embedded markets and coping with?
There are a lot of trends in the industry these days and it’s easy to get sucked into most of them. There used to be Fuzzy Logic (lasted only a couple of years), Linux was and still is a big buzz, Multicore, Hypervisors, etc.
Interestingly enough, it’s difficult for some Engineers and companies to adopt an RTOS or even a simple kernel running on a single processor. Life gets a lot more complicated when you get into multicore and hypervisors. In other words, if you are not convinced about using a kernel, how can you possibly make the switch to adopting processors with multiple cores? Also, there are a LOT of embedded applications that are still candidates for running kernels and other middleware a single core. This is especially true since many MCUs now have plenty of Flash and are getting there with RAM to use an RTOS. BTW, by RTOS I mean the kernel and other modules such as TCP/IP, USB, File System, GUI, etc.
So, to answer your question, I think anything multicore is here to stay. We are starting to see multicore MCUs (Cortex-M0 and Cortex-M4 by NXP). The NXP chip is a good example of the use of multicore on an MCU. Run on the Cortex-M0 to conserve power, enable the Cortex-M4 when you need additional performance. The biggest challenge with multicore is developing applications that makes use of these cores and especially finding efficient ways to debug them. It’s already very challenging to debug a single core application, the problem gets multiplied when you deal with multicores.Micrium vs Others
Q: What specializes Micrium compared to its competitors?
We have a lot of differentiators. The quality of our source code, the documentation (books), the numerous classes we do at trade shows, the broad reach of chips we support, the creation of unique products like uC/Probe, the reasonable prices for high quality software, the FAA/FDA certification of some of our products, the great reputation we have in the industry and more.
