Good presentation and good Q & A by the group and presenter. It seems they first want you to write code, then they want you to debug it - what is task partitioning for then? Also, now they are saying that LOC is not necessarily linked to productivity? :)

Liked the pro/con on "roll your own." You have an app to write. Do you *really* want to design and debug your own RTOS while writing that app? Don't reinvent the wheel. Save yourself a huge amount of time and purchase an RTOS with good tech support.

Jack, are there any viable alternatives to the C Standard Library for embedded work? Legacy mistakes like "printf" abound...

The problem is that the library tends to be very compiler-dependent, and so is supplied by the compiler vendor. There are a few minor replacements, like the SMX GoFast floating point library I mentioned yesterday.

Comment about selecting an RTOS. If you let the h/w guys pick the ucontroller, you could get stuck trying to find an RTOS that will fit. That's how I ended up using Salvo because uC just would not fit. Turn the process around. Pick the RTOS/IDE that best suits your application, then tell the h/w guys to find you a ucontroller that meets the firmware requirements.

Absoultey agreed. The h/w and s/w people need to work together to pick a CPU. Seldom happens, though.

Comment about selecting an RTOS. If you let the h/w guys pick the ucontroller, you could get stuck trying to find an RTOS that will fit. That's how I ended up using Salvo because uC just would not fit. Turn the process around. Pick the RTOS/IDE that best suits your application, then tell the h/w guys to find you a ucontroller that meets the firmware requirements.

kenstan: you say you have a relay. Be sure that you have a reverse diode accross the coils or a zener or other snubber to stop the spikes where they are generated; kill noise as quick as possible at the source and at all I/O line.

Salvo is a cooperative RTOS. $1200 gets you the source, tech support, no per-unit royalties. The FDA will sign off on it as well, unlike many other RTOS's. If you're not doing a med device then maybe you don't care about the FDA...

For an implanted class 2 med device, I used a PIC18F45J10 (32k of flash, 1k of ram). Using Salvo required 4k of flash and 254 bytes of ram, to run 13 tasks. Note that Salvo is not pre-emptive, but it is deterministic. No RMA hand-waving.

The FreeRTOS manual is good for people like me with no experience with RTOS. It starts out discussing Scheduling strategies and explains why some things work and others don't. It also discusses priorities.

Jack, I have recently purchased an LPC1114 ARM cortex M0 and quite new to this. Before loading a RTOS a bootloader is required from what I understand, whats the best way to select such a bootloader or do I have to write my own?

Often the chip vendor will have code. Otherwise you'll have to write it. Or, get an eval board and use the code from that (if legal).

Jack, I have recently purchased an LPC1114 ARM cortex M0 and quite new to this. Before loading a RTOS a bootloader is required from what I understand, whats the best way to select such a bootloader or do I have to write my own?

FrankBishop, you can usually pick whatever time scale you like as a variable. Some RTOSes will have different limits than others, but the one that typically operates in the time scale you want will likely be better for your application.

You said during the discussion of slide 27 that the RTOS should be chosen based on the Prossor selected and the Compiler used. Doesn't it make more more sense to chose a Compiler that is optimised for the Processor selected and the RTOS?

Kind of a simple quetion: with Round Robin tasking, if the duration is user selectable, does one try to choose a duration long enough for most tasks to complete, or are these durations typically only a small percentage of the average task time?

A: Actually, mutex is what creates the possibility of deadlock. Only with a low-priority or ill-behaved task taking a mutex and never releasing it, or with two tasks that take multiple mutexes in opposite orders, can deadlock occur. Of course, without a mutex, the shared resources will get corrupted and likely the system will fail, often spectacularly

As things stand, if you want a piece of hardware designed for Hard Real-Time needs, you have to settle for a consumer chip that was targeted to general purpose devices, which receive little development priority for Hard Real-Time needs, because the chip companies want to target the general market.

My main beef is this... as was noted yesterday, developments like Cache make Hard Real-Time performance incredibly complicated. If desktop computing hardware had to satisfy Hard Real-Time needs from the ground up, Commercial Off-The-Shelf hardware would be better designed for Hard Real-Time needs, because everyone wants their desktop to go faster.

Let's put it this way, Bruce McLaren... I strongly suspect that Real-Time physics simulations would benefit from a Hard Real-Time OS. I'm sure Video Game developers would appreciate some determinism as well, once they get used to the idea.

@TenTech: I admit I'm out of my core expertice, so correct me if I'm talking non-sense. Can desktop OS be made real time without undue effort (undue effort a term I am unable to define)? Is it needed, or just a nice feature to have?

RTOS memory/resources footprint determines MCU size. Usually need at least 1MB memory. 1/2MB RAM, 1/2MB ROM(or Flash). As long as MCU can handle that and have enough timers for RTOS tick, you are good to go.

I would dispute that, Bruce... Desktop Computers are meant to be generalized computing platforms. As they stand, they are insufficiently generalized for my purposes. That being said, it should be noted that, if Hard Real-Time issues aren't going to be tackled by the desktop community, then COTS computing hardware is going to continue to diverge from Hard Real-Time needs.

Anyway, Hard Real-Time versions of LInux tend to break compatibility with typical Linux software, so there is virtually no compatibility benefit to using a Hard Real-Time version of Linux over something else, for Hard Real-Time applications. That being said, I've heard Xenomai is very good for a Hard Real-Time Linux.

jl - yes, most RTOSs have functions which will cause the task to wait for some period of time. However, if you find yourself using it, think carefully about your design. It might make sense to break the operation up into multiple tasks.

franchzilla, an RTOS is not an alternative to Linux or iOS. An RTOS is a requirements driven thing; if you REQUIRE Hard Real-Time performance, then you use an RTOS. If Soft Real-Time performance is "kind of nice" for your application, you use something more common, like Linux, or whatever operating system runs on your device.

The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.

Industrial workplaces are governed by OSHA rules, but this isn’t to say that rules are always followed. While injuries happen on production floors for a variety of reasons, of the top 10 OSHA rules that are most often ignored in industrial settings, two directly involve machine design: lockout/tagout procedures (LO/TO) and machine guarding.

Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.