It's been a while since I've posted on ChiefDelphi hasn't it?
I'll try and keep this one as short and sweet as possible (not likely).
An RTOS on our future controller - absolutely. What people might be forgetting is we *almost* have one already with our controller's "Master Code." It manages all the lower level functions (radio, timeslicing, etc), and exposes an abstraction layer for us to access all the I/O on the RC. Some of the hardcore here will probably berate me for using an analogy like this, but I'm calling it as I see it.
An RTOS is not a giant leap of faith, especially if we're going to get a significant microcontroller upgrade. To me, it's an evolution of something we're already doing, except it would be more well-defined, widely accepted, and extensible if we go with one of the more popular RTOSes.
Do I think Linux should be that RTOS? How about QNX? VxWorks? LabView RealTime Embedded? Or any other RTOS?
SHOULD I LOOK IN TO ECOS?
It's a loaded question, as is my answer: As an FRC programmer, it doesn't matter at all, because we HAVE TO BE GIVEN another secured abstraction layer, in which we'll be limited to: accessing robot and OI related I/O, and executing sequential code. I'm on the fence if we programmers should even be able to spawn a thread. We SHOULDN'T ever see an interface with the RTOS directly, at least never in a competition environment.
Regardless of the underlying RTOS, I'm pretty sure the abstraction layer presented to us FRC programmers could be made exactly the same - in fact, my money is that it will look very similar to the one we're given now through the current IFI headers / MPLAB toolchain.
NOW, if you put me in the position of being the head honcho at FIRST who gets to call the shots on this project, my answer changes dramatically:
1) Who's on my dev team? Who can I get with significant experience with Arena Controllers/RCs/OIs (read: did I poach anyone from IFI =P)? What RTOSes do they already know?
2) What's my bottom line on each control unit? Can I afford licensing on a commercial RTOS? How much am I paying my developers? Can I afford to pay them to learn an open RTOS if they don't already know it? Does the licensing $ vs learning curve $ make sense? What about the support costs if/when something blows up during development, or god forbid, competition week 1?
3) Am I toying with any crazy ideas like putting all wireless communications on WiFi, or Bluetooth, or ZigBee? What's each RTOSs support for those stacks?
and finally
4) Is any commercial RTOS developer willing to pony up the cash, support, and time for the privilege of putting their product into the hands of thousands of the world's best future embedded developers?
At the end of the day, FRC programmers won't and shouldn't have any say in a decision like this. And that's not a knock on Kevin, or anyone else in this forum, but this is me with my business hat on, and I think I'm making a lot of sense on this one.
Cheers, and I looking forward to what we end up with in 2009!
-Shawn T. Lim...