NEW 2009 Control System Released

[Greg McKaskle]

Originally Posted by dcbrown

One brain blip I had in regards to above was that there wouldn't necessarily be just ONE FPGA programmed image to choose from - after all this is field programmable...

The early open of the FPGA must not be as a device then or I severely misunderstood the VxWorks documentation that indicated open device descriptors were not shared across the RTP/kernel interface...

Don't take this the wrong way -- just after 30 years of systems engineering at the s/w-f/w-h/w boundary this statement quietly screams "WATCH OUT!" One way of interpreting this comment is that FIRST will be the beta test customer for using C/C++ to program the cRIO. From a product roll-out risk perspective, things just got a whole lot more interesting.

There have been many postings looking into the crystal ball of the FPGA, and I'll try to give a bit more technical info on what is possible. But policy decisions as to what is allowed are of course FIRST's call, and independent of what is technically possible.

The FPGA on the cRIO is an open LV target. This means that LV code can be designated to run on the host PC, the PPC, or the FPGA. Of course LV targets the FPGA via VHDL, and therefore the cRIO is ultimately targetable with C-based .out PPC files and bitfile produced from VHDL. To promote a migration path, promote working, stable robots, and ensure safety, the decision was to keep the FPGA closed for at least the first year. After that, depending on how things go, it could be opened to the extent that there are vanilla, chocolate, and rocky road flavors. It could be opened further by providing 09 source and allowing teams to go nuts. Technically, these are all possibilities, and it is a policy decision as to what makes the most sense for the organization and competition. At this point, I'm sure FIRST is listening, but any opinions you may have honestly aren't well founded. After a season, the feedback will carry much more weight.

As for the SW stack required to peek and poke. I'm not entirely sure, as this isn't something I've used much directly. The success of the product is hinging on the performance of said calls, so I'd say that it is probably pretty performant and more importantly, deterministic. Moving forward, I will be happy to get the gory details for those who are curious about how it works. But for now, I think you can trust that the FPGA is not using dev/IO, and is instead a low-level custom driver.

Greg McKaskle