@Rick, I was struck by the number of Linux variants in the group. Add them up (arguably, even including Android) and it becomes a very large percentage. I would also be curious as to how many are using buildroot, Yocto, or the other Linux kernel personalization systems to create tailored distributions. That used to be the realm of the specialists, but now they are very mature and approachable.
FreeRTOS is not an RTOS it is only a small kernel thar runs on virtually all mid size and larger MCU devices. Written in C is is very portable and because it has no I/O and higher level protocols or significant demos, There is not much else to know. SafeRTOS was the 12 function call version of this the last time I looked.
I think that the popularity of this reflects the general lack of business training in the community with respect to time to market, software reuse and software engineering economics.
FreeRTOS is really a build your own RTOS with a free kernel and months of effort put into I/O models, I/O drivers, testing, integration, and documentation before you start your actual development. Engineers do like to build their own solutions but this is definitely a money loosing strategy unless you see engineering time as very low cost.
For a few thousand dollars, you can purchase quality offerings which provide standard APIs, connectivity of your choice, documentation, testing and integration of modules and support for the entire offering. What is the benefit of spending tens of thousands more and months of development time to ernable FreeRTOS or worse still SafeRTOS development with a poorer quality alternative?
If you know anything about FreeRTOS, this is what you should know and understand. Free is definitely very very expensive if you really understand the costs involved.
I should mention that I work for a company that sells complete RTOS solutions. The facts are the same for a FreeRTOS vs an actual RTOS comparison regardless of which RTOS you choose.
I was shocked when I saw this data at the ESC session. The reasons behind this were also interesting, so I hope we'll have a follow-up 'blog on the FPGA results alone.
I do FPGA design professionally, and what I find is that a lot of design organizations are scared of FPGAs and don't have people who know how to design with them. In a way that's good for a free-lancer like moi, but cuts down the overall volume of work. One effect I think is happening is that IDEs and development boards with good communities are making it easier for people to use embedded CPUs, but the same is not happening with FPGAs. My own experience is that each new release of FPGA tools is harder to use and runs slower. Perhaps that's only because it does more, but if my impression is true it could be one of the reasons you're not seeing as many FPGAs getting designed in.
It could also be that what people are designing these days has shifted away from FPGAs. For example, all these Internet of Digital Things products just need a standard SoC with standard interfaces. It's not like a data comm box that has to speak strange protocols or have extremely high data channel density, which is an excellent fit for an FPGA.
So tell me, did the FPGA vendors find out about this result ahead of time and decide not to exhibit at the show? :-)
I see an interesting correlation in the trends. It seems to me that the increase in the use of out-house operating systems correlates with the increase in project lateness. Personally, I prefer in-house because if there's a problem or a necessary change, you're familiar with the code so you can get in there and make the change with minimal impact elsewhere in the code. With out-house, it might be very difficult even to find where to make the change, and the side-effects of the change could be hard to predict. It seems to me that estimating how much effort is involved would be quite difficult, making it hard to maintain the schedule.
I think that it is easy to change something you know and understand for sure. For sourced operating systems I think that high quality technical support fully addresses (or should fully address) any feature additions and changes. We certainly make sure this happens and happens in a timely fashion. It is easy for an RTOS vendor to make these changes and this leads directly to a solution to change the OS for a customer.
The real cost of in house is the delay and expense of lost time to market. The market share that is lost costs far more than the purchase price of the RTOS so you immediately end up loosing money doing your own RTOS before you have started development.
RTOS vendors spend millions on product development, even smaller vendors. How can an in house effort possibily do better unless they spend similar amounts? Yes with in house you can change it easily but you don't have to if you have purchased a quality product with support.
Think about the cost of documentation and testing as well as the lost time if you throw away the documentation because your project is taking too long. You need to think about how much better your product will be if you focus on your value added application and use the rich feature set that you can purchase.
The economics clearly are not there for build your own OS except for very specialized cases.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.