[taichichuan]

VxWorks is a flat memory model for FIRST purposes. All code can see all memory and all applications (kernel modules) run in supervisor state. The RTP interface is a way of running code in user state instead of the normal supervisor state. But, we don't have access to that in FIRST. For FIRST applications, think of it as running everything in the kernel of Linux or QNX and you've got the right idea.

VxWorks is a thread-based O/S. The scheduler only schedules threads and not processes. Also, each thread is independently schedulable (a 1-to-1 scheduling model). The default scheduler is a preemptive, priority-based model. Essentially, "run till you block or get preempted by a higher priority thread". There is no attempt at fairness. Real-time operating systems are notoriously unfair by design. Highest priority always wins.

The VxWorks RTP looks remarkably like a Linux user-space process right down to the stack guard pages. But, because the RTP runs in user state, it can't easily get to services provided by the kernel (like WPILib). So, I'd avoid RTPs even if you had access to them.

Now, if you want a challenge that can improve the performance of your 'bot, look at using separate threads. WPILib supports the concept and the 2011 code is much easier to follow than the 2010 code. This allows you to avoid all of the polling business in the continuous teleop loop and go event driven which reduces the CPU load on the cRIO. In addition, consider offloading the sensor inputs to a processor like the Arduino and communicate with the cRIO using sockets.

The Arduino can be used as a sensor platform and further offload the cRIO. Just don't control anything via the Arduino. That violates the rules, I think. All of the control is supposed to come via the cRIO.

HTH,

Mike