RoweBots1 wrote: RTOS vendors spend millions on product development, even smaller vendors. How can an in-house effort possibily do better unless they spend similar amounts?
A RTOS vendor has to write an OS for a general customer base. An in-house OS only has to support the features needed for the product. An in-house OS may be as simple as a single main thread plus interrupt service routines, with no preëmptive multi-tasking and little or no memory management.
RoweBots1 also wrote: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.
Funny you should mention documentation. My main experience with a vendor RTOS was for a datacom product that originally had its own "OS": single thread plus ISRs. All the code was developed in house. We needed to add a vendor stack for an optional feature, and that stack required an RTOS. However, the RTOS had a per-unit royalty, so we only wanted to ship the RTOS if it used the optional comm feature. The solution was easy: if we wanted the RTOS present we simply ran our main thread as one of the OS tasks.
Our product was originally based on a Motorola (now Freescale) 68360 QUICC. The RTOS had excellent documentation for 68K and it was easy to link in the main thread and ISRs because the ASM-level ISR conventions were clearly documented.
A couple of years later we switched to PowerQUICC. Well, for PowerPC the documentation was terrible -- no documentation of the ASM-level ISR conventions. The vendor wanted you to use one of their "board support packages" and we weren't on the list. Plus, the vendor wanted you to buy their C compiler.
So I ended up creating my own "documentation". Specifically, I had to disassemble the task switch machine code to see how they were saving registers and all. Once I had this information, it was straightforward to get it working. But I learned to get out the salt shaker when an RTOS vendor tells me that the RTOS will save time to market.
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.
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 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? :-)
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.
@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.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.