Compact rio not being able to use C

[BradAMiller]

Originally Posted by rwood359

Please lobby for the have-nots. Some dialog can start as soon as we have the documentation and tools. Getting some things cleared up now may reduce your work load when everyone gets the full system.

Everyone on the project is 100% behind that goal. We hope to make it available as soon as possible.

This sounds like fun! I have some concerns about breakpoints and motors. Are breakpoints tied into the FPGA to pause PWMs?

This particular issue caused lots of discussion. Sometimes it's desirable to have the motors running while debugging and the robot is up on blocks. Other times it isn't, and possibly dangerous.

We implemented a user watchdog timer that is enabled by default (but can be disabled) and will automatically stop the motors if your program doesn't periodically call a method. If used, it would shut down the motors on a breakpoint. But like seat belts, if you don't use them you can get in trouble. And this gets even more complicated by the fact that multiple tasks can be running - but you can set the debugger to interrupt all running tasks on a breakpoint as an option.

There is also a system level code that will shutdown the motors in the event of a communications failure, disable or e-stop.

Thanks for the information on the gyros. My real question is about the level of documentation of the FPGA that is sitting between the code and the devices. One of your earlier posts in this thread described both specific device interfaces and generalized tools to build an interface. How detailed as to timing and timing constraints will the documentation be?
For example, in your response above, you described the functionality of the gyro driver without giving any data rates. Will the functional document have the data rates for the sampling and such? You don't need to give details here.

I wouldn't expect to see documentation on the FPGA interfaces, not because we're keeping secrets from people, we're just out of time. You can look at the code to understand what's going on.

We are trying to document as much of the specs as possible, like data acquisition rates and subsystem block diagrams. And you can always ask questions.