Quote:
Originally Posted by gvarndell
Things would have been be very different.
I am terribly disappointed that Wind River withheld vxsim from the FIRST packages.
Even better, far better, would be a virtual cRio that could run the same target binaries as the real hardware.
My concerns are not with Linux.
I am concerned that supporting another target OS would spread even thinner the apparently already over-burdened target software development resources being applied to FRC control systems.
|
Yes, maybe a QEMU implementation with a virtual set of hardware. I know that WRS uses QEMU for its training classes. However, I think they're doing ARM rather than PPC. I believe QEMU does support a PPC instruction-set simulator, but I'm not sure about a virtual PPC 5200 that could run the FRC binaries. But, something like that would certainly go a long way to giving folks a chance to work with the code without needing the physical cRIO hardware.
As for software development resources, I certainly understand your concerns. However, reworking the WPILib to make it O/S independent might actually be a good thing overall. There are several places where there are good examples in the WPILib already like the "CRITICAL_REGION/END_REGION" code. If they followed that pattern, the O/S-specific code could be limited to a small header file and some glue code.
Personally, I found that the WPILib itself had a significantly steep learning curve. Certainly, the documentation on the theory of operation on WPILib left much to be desired. As someone who has been working in the controls biz as long as I have, I found the WPILib inscrutable in many cases (such as how to create and monitor a thread). Thank goodness I had access to some great mentors on the team who had prior experience that could answer my questions. I'm not sure where that leaves rookie teams.
And, as an example of what you *should* do in real-time control code, WPILib has many examples of how academics and field practice differ. Of course, I'm talking about the C++ code. I can't speak to the Java or Labview code. IMHO, WPILib is a good effort at trying to hide the details. But, the devil is in the details for embedded code.
As I watched the threads here on CD, I began to get the feeling that many teams were simply shotgunning the problems. Without the understanding of what was really going on under the hood in the WPILib, many just seemed to be trying stuff at random. Yes, the WPILib code is available for download. And, believe me, I would have had a hard time understanding much without the sources to go look at. But, I feel that the kids are encouraged to treat the code as a black box and simply accept what it does. We're missing a good teaching moment by not looking under the hood to understand how it works.
So, we come back to the reason I started this thread. The goal is to make the code more accessible by providing a less expensive way to get it into the kid's hands and allow them to play with it, test code, and understand what's going on both during and outside of the build season. I feel that getting a good simulator may be one way to make this happen. But, I also feel that getting the code and interfaces running on a less expensive platform may be another.
Let me emphasize here. These are simply my opinions. They're probably worth what you paid for them ;-) .
Mike