The JVM itself (and WPILib’s HAL backing) is written in C++, so there is already native code running on the RoboRIO. If you want to run both, you’re going to have to dive into the wonderful world of the Java Native Interface (JNI). Since WPILib’s ANT build system won’t really support this out-of-the-box, you may want to use your own build system. If you want a project for reference, you can take a look at how my Pathfinder library communicates between its Core and Java libraries via the JNI. https://github.com/JacisNonsense/Pathfinder
That’s the “could” part. Here’s the part where we ask whether you “should”. Some things to take into consideration:
-
JNI calls are SLOWWWWWW. Each time you call a native method, the JVM has to try and lookup where that function is (remember, C++ isn’t reflective like java). This can take a while, so try to avoid repetitive calls to native functions.
-
It makes the codebase more confusing. Jumping between two languages can be a pain (especially for if you have multiple programmers, most of which will not quite understand the underlying architecture of the JVM). The C/++ bindings for the JVM are also really, really ugly. Honestly, this is just going to make your development speed so very very slow, getting worse the more java to C++ and visa-versa interfacing you have.
-
Yay, a good point! Having written your own JNI code is worthy of bragging rights. It also means that for particularly ‘heavy’ tasks (motion profiling, vision, etc), you can rid yourself of how slow the JVM is and do large processing in C++, with smaller bits in java.
-
Oh no, another bad point. You’ll want to use Java to do your robot I/O interfacing. Although it’s possible to do it through the C++ side of things, you’ll run into a lot of problems really easily. Because of this, use C++ for processing, sending back values to Java for it to send to WPILib.
As for your other questions, let me try to answer them:
The RoboRIO acts like any other computer running a program. It reads an executable, and sends the instructions to the CPU and/or OS, or other IO. The RoboRIO has special memory registers that it uses to interface with the FPGA, which in turn runs the I/O (pwm, can, dio, aio, relay, etc). WPILib’s HAL interface talks to these registers for you, allowing you to manipulate the outputs and read the inputs of the robot, interfacing your software instructions with real-life hardware actions.
The main file the RoboRIO will run is called the FRCUserProgram (stored in /home/lvuser/FRCUserProgram). It contains a version of the WPILib library that you compiled against, and your code. This executable is launched by the robotCommand file (/home/lvuser/robotCommand), which contains the shell command to run when wanting to start your code.
FRCUserProgram also talks to other, native libraries on the RoboRIO, which allow it to talk to the RoboRIO’s special functions (I/O), and also FRC’s non-wpilib libraries (like the network comms that talk to the driverstation). WPILib uses these as dependencies in order to function properly.
The RoboRIO runs a background process that constantly checks whether an instance of your code is running. If your code isn’t running, it will run robotCommand in an attempt to get the robot up and running.
NetworkTables is handled by the NT-Core library, which serializes the data you give it and sends it over the network to be read.
JNI is a really fancy way of saying “a bridge between Java (the language), and the JVM.” (in reality, it’s not really Java, but Java Bytecode, but that’s beyond the scope of this explanation). The JVM (at least on Oracle’s implementation of the JVM), is written in C++, and, at runtime, interprets the Compiled Java code you have written (this is what allows java to be cross-platform). To interface between the two, the JNI exists. It basically adds mappings to the JVM that will enable a Java function to be bound to a C function.
Hopefully this helps. I know it’s a big wall of text, but hopefully it helps at least a bit