Quote:
Originally Posted by Danny Diaz
I think it would add extreme value - even Microsoft finally "saw the light" with its new driver architecture framework in Windows Vista. In order to perform "standard operations", there was a "list of things every driver had to do." Finally someone said, "Hey, if we always have to do this, why not give us an interface so that we give you the information for the specific thing we're doing, and you do all that boiler plate code FOR US."
-Danny
|
A standard i/o & driver framework definition exists within VxWorks, its pretty orthagonal to the driver framework in linux/unix, but NI chose not to use this standard. Instead the cRIO driver is implemented in a different/custom fashion. So your statement may in general be true, but even NI finds instances where it isn't.
Currently there are between 250-300[*] different component libraries within VxWorks kernel each with a average of 8-10 interface calls... device drivers as being supplied by WPILIB represent 5% or less of that total API call interface. I just don't see the WPILIB providing all the templates needed to hide the other 95% of the operating system interface so C/C++ programmers don't have to call any OS functionality.
For example, I doubt that the WPILIB will provide a callable inertial navigation system (INS) whereby you can customize at the call interface specifying how many sonar, IR, quad encorders, gyros, accelerometers, GTS, and other specific sensors exist on your particular robot. To implement your own INS, you will need to use various services of the operating system plus the drivers supplied by WPILIB.
[*] from "VxWorks, KERNEL API REFERENCE Volume 1: Libraries"; some of these are undoubtedly not implemented in the cRIO port of VxWorks, but most should be there.