[dcbrown]

Originally Posted by Dave Flowerday

...except only the things that FIRST and/or NI has thought of are committed to hardware. Since the FPGA is not user-programmable, any novel ideas or sensors which would need interrupt support are not possible - I think this is what Alan was getting at above. In my opinion this is a HUGE step backwards from the current control system and a very disappointing revelation.

Dave you quoted my post, but I also wrote the following in the same post:

Originally Posted by dcbrown

if you want to tweak the servicing of the hardware or integrate data differently or add some weird/unusual sensor that isn't already allowed for, you're pretty much stuck as the FGPA is off-limits to teams.

I guess I wasn't clear. Anyway, I think we're in violent agreement. By logical extension, as Kevin mentioned, this also means that the FGPA may have limits in the number of same type supported devices. For example, the FPGA may only be programmed with support for 4 quad encoders plus 2 GTS plus 2 sonar. (I suspect sonar is a bad example and could see a design decision not to support the sonar sensors in FPGA but rather on I2C ala NXT w/the built-in PIC controller within the sensor box doing all the work and then using the possible I2C bus off the digital sidecar to retrieve data as needed - again polling). So if you wanted to use n+1 sensors of a specific type on your robot, where 'n' is the number implemented in the FPGA, then your kinda out of luck. Although the sensor processing with the FPGA has not yet been completed, I would find it difficult that at least design intent isn't known at this point and its too bad that type of information isn't shared.

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. In that case, much like configuring a work truck you'd choose from one of a number of standard FPGA setups provided. There are only so many digital input lines to choose from after all, so how you dedicate them to what sensor suite may be selectable. That is, one image supports 6 encoders plus other stuff and another supports only 2 encoders plus other things. With multiple FPGA images provided the likelyhood of finding one close enough to match the robot you want to design becomes greater.

Originally Posted by Greg McKaskle (NI Team)

Realtime OSes don't necessarily have the same division of kernel and user modes. Specifically, the RIO peek and poke are allowed to be called from user code.

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. Of course there is always the possibility that PEEK/POKE are implemented as custom system calls for the cRIO from the RTP into the kernel or the open of the FPGA isn't as a normal device. It probably doesn't ultimately matter to programmers, but as an engineer I kinda like to know how my request is being routed as it effects how I design the processing flow of the code as the route "distance" in software can effect performance.

Originally Posted by Greg McKaskle (NI Team)

To this point, the C/C++ for the cRIO has been for internal consumption. To this point, all cRIO customers have used LabVIEW.

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.