My understanding is that one of the “special” things about the RoboRio is that it has an FPGA, which is used for a handful of signalling things on the Rio. The two that come to mind are:
(1) Dealing with encoders (which, if each click interrupted the main processor, would royally slow things down), and
(2) PCM output
The encoders appear to be increasingly going off-board – the Talon SRX and SparkMax, for example, are each able to deal with encoders directly. And, since motor controllers appear to be moving to CAN, I don’t know that the Rio is driving PCM that much.
Basically every interface (other than USB and Ethernet) on the Rio uses the FPGA. So analog inputs, analog outputs, relay outputs, digital inputs and outputs, PWM, SPI, and I2C all use the FPGA; this includes the MXP interface.
The FPGA provides a precise time stamp (off a 16 MHz clock) on nearly everything. This includes the ability to do periodic notifications/interrupts, which is how we get precise timing on PeriodicRobot and PIDController.
The FPGA has the ability (albeit little-used by teams) to DMA time-stamped data from multiple interfaces simultaneously, so it’s possible for example to have an external trigger such as a limit switch and know what an encoder value was at exactly the time the switch was pressed.
More commonly used by teams, the FPGA also offloads the RoboRIO CPU for things like gyro integration–it reads and accumulates the values on a precise time interval, which improves accuracy and dramatically decreases CPU load over having software periodically read SPI.
On analog inputs, the FPGA provides oversampling, filtering, and threshold/rollover detection.
As a point of reference, this configuration of a main processor, with one or more coprocessors is quite common for higher end controllers.
It obviously costs more to increase the chip count, but if you have a rough idea of what processing is required, it’s very useful to bump the high priority jobs to a separate processor, or specialized hardware. This might take the form of an FPGA, a secondary processor, or some other special circuit
Oh yeah, I totally understand why it’s happening. I’m just wondering if we’re slowly moving to a different architecture where, instead of having most of those functions in the Rio itself, they’re put on the CAN bus. Some of that would make little sense (e.g. the precise timing) . But, other parts might work – you could easily see a microcontroller on the CAN bus dealing with digital inputs, for example.
One thing about offloading, especially offloading inputs, is there is latency to any external system. For things like motor controllers, this is usually fine, as the motor controller can handle its PID internally at a very fast rate, and just receive setpoints over CAN.
However, if you were to attempt to read an encoder value over CAN, PID, and then send the motor value directly back to the motor controller, you have just introduced latency to the system for the read you wouldn’t have had if the encoder was directly hooked into the controller. You wouldn’t be dependent on the CAN status send rate, but instead would just always have the newest value instantaneously.
CAN is fantastic for motor controllers, especially when using the built in PID functionality most of them have, but if I needed to read the encoder value for anything other then a high level PID loop or just value checking, I would much rather have it hooked directly into the RIO. Then I get instant data.
One nice thing about the FPGA in the RIO is it is directly attached to the CPU (its on the same chip), and they even share a memory buffer. This means that reading an FPGA input value is literally just a memory access, no need to even access a bus or anything. It’s pretty fantastic.
Fun facts - the FPGA in the Rio is on the same piece of silicon as the processor (so no increased chip count). Half is a dual ARM core microcontroller, running Linux, and the other half Xilinx 7 Series FPGA fabric.