Previously with the PIC, "system programmers" had the advantage and "application programmers" who wanted all that h/w stuff hidden were at a disadvantage. The advent of WPILIB and EasyC closed some of that gap, but still the plaform was more systems programmer friendly.
The platform was kinda backwards, often requiring a lot of systems knowledge before you could become an applications programmer. This typically meant new programmers were at a disadvantage.
The new platform is more the norm/inverse of that. The entry level for all is as applications programmers using the API of the RT/OS either within kernel tasks or RTPs (real time process). If you want to be a systems programmer, the entry costs in terms of time, effort, and knowledge just increased. But that is usually how it is. The new platform should align better with both sets of folks.
The WPILIB will be just another library/plugin option on top of the RT/OS that provides an API to access the pins, PWMs, etc. that we're familiar with on the PIC. Having the source may or may not help much unless the NI drivers for the modules have the source included in the cRIO kit also. But this library will be *the* method of accessing DIO, ADC, PWM, and relays for almost all but a few teams.
For example, lets say the device special file for the digital io module was /tyDIO and pins 0-15 were /tyDIO/0 .. /tyDIO/15. Then WPILIB would need to do something like the following to read an input pin.
Code:
fd = open( "/tyDIO/0", O_RW, 0 ); // open DIO driver for NI module, pin 0
bytes_read = read( fd, &byte, 1 ); // read value of pin 0
close(fd); // close device
** this is pure swag -- there are several ways of doing this, but this is the
most direct but again depends on the device naming scheme for the
modules and its subparts.
This assumes the VxWorks io driver model is used and not bypassed in some bizarre fashion. Or instead of using the provided NI module driver, WPILIB may decide to directly implement their own replacement NI module driver to collapse some of the details but that sounds like way too much effort and then they'd need to support that flavor of NI module driver... Anyway in the PIC, systems programmers knew how to directly access the h/w. In the new model it isn't that simple, its easier to just access the NI drivers. It will be nice to get at least some documentation on the NI module driver APIs -- it would go a long way to understand how some of the system pieces fit together.
The biggest problem I'm having wrapping my head around is the sheer size of the API and doc set for VxWorks along with a lack of information on what the NI driver/library interfaces look like. But all in good time...