[Greg McKaskle]

This thread has hit on a number of topics, and I'm playing catchup, so I'll comment on what I can.

Protected Memory Model:
The VxWorks OS version NI adopted for the cRIO only supports the unprotected, flat memory model. Because it would be such a nice feature, we investigated RTP support for FRC, with protected kernel and process layers, but this would involve upgrading to a newer version of VxWorks, redoing the OS image, redoing many of the drivers, etc. Additionally, the NI engineers who had already investigated this found the overhead of kernel transitions would have a big impact on the industrial I/O customer. Keep in mind that as sold to industry, the cRIO is a LV target. LV is a safe language, so running it on a safe OS benefits the NI engineers and the professionals who are writing their own .out extensions in C/C++, but isn't needed by the general user.

Since RTP turned out to be expensive to build, and unlikely to happen soon, I'd like to see the lib ported to a protected OS and run with an emulation layer. I'm currently looking at doing this for LV. This will be library level, not the entire OS, but I think it will be appropriate for finding logic bugs, compile problems, and teaching exercises as long as the feedback mechanisms are good.

As for the availability of cRIOs, and other control systems, NI and its suppliers are doing what they can for the pricing of the existing HW. Since the system will evolve, I'd love to hear the value of different features. I think everyone will agree that the industrial temperature spec has high cost and is of little value to FRC. Feedback on the other aspects of the HW that makes up the control system will be invaluable for FIRST to select or design the next control system.

Finally, there have been vague statements about how WPILib should be improved, but nothing specific enough to be actionable. Let me give my view of what WPILib is and is trying to be, then once again, ask for feedback.

My metaphor for WPILib is that of a big community swimming pool. It needs to have several pretty well defined zones that offer different levels of challenge and safety. It needs to support wading, general swimming activities, and for the daring, diving in head first trying to touch the bottom of the pool.

The framework and examples hopefully act as the wading zone. Lots of hand-holding, lots of prebuilt code that does simple things, allows for safe exploration as well as retreat. Since it exposes source, hopefully it serves to learn the next zone.

The general swimming is the actuator and sensor libraries themselves. You leave the framework entirely, or heavily modify it to add in and use many new elements in the library. Since it is distributed in source, it also supports exploration beneath the surface to see the dependencies, and the notification mechanisms that make up the higher level interfaces.

The deep diving, at least in LV is the NIFPGA interface. This exposes accumulators, triggers, and other raw forms of I/O which the general and wading layers are built from. It should allow for alternate implementations, alternate frameworks, and external sensors and actuators to be added in. At the moment this is as deep as the pool can go since the FPGA implements the safety mechanisms, and it doesn't seem appropriate for teams to modify the safety layer. Ideally, that layer will be opened up too, showing how to do encoders, PWM generation, triggers, integrators, etc on an FPGA.

Obviously, the current implementation is only one potential way of doing things, and honestly, the pool was opened while still under construction, and probably always will have some areas under construction. Again, feedback is super important. All of the zones were built at the same time, not enough documentation exists, and there are many alternate implementations that should be considered.

I've created three feedback threads on the technical/control systems/FRC control systems and on the technical/programming pages. Hopefully that will allow for the feedback to take place without intruding on this thread.

Greg McKaskle