NI releasing/designing new controller for FRC

[apalrd]

The only reason it's so darn hard to do stuff now is because of inefficiency in the current system - The WPIlib in LabVIEW is so unoptimized that it's nearly impossible to run code that uses IO calls faster than 20ms task time without saturating the CPU.

The fact that we're currently saturating a 400mhz PowerPC amazes me. I don't like the idea that we should just throw more power at it to deal with it, since there's no reason to need anything near a 400mhz PowerPC.

I have a project I'm working on right now that uses a bunch of unoptimized floating-point math, a whole bunch of interpolations, and runs in two high-speed tasks (TDC and 200hz - TDC is ~5ms at 12000rpm) plus a few CAN interrupts (Jaguars should learn about CAN interrupts...). Bandwidth on a 56mhz PowerPC (MPC536) is extremely low, last time I checked it was under 30%. PWM IO is done on a PWM/timer on-chip module (MIOS), angular IO and angular synchronization are done in another on-chip module (TPU) which I did not write code for, which is essentially an optimized match/compare/timer module with microcode engine to autonomously reschedule matches and trigger ISRs. Between the MIOS and TPU, all of the current FRC FPGA non-analog functionality could be implemented with similar host-side overhead. Code includes some high-speed PI and bang-bang controllers, and LOTS of table interpolations. I did no real optimization on the math, it's about as much code/math as a complex FRC robot.