Rewrite CAN APIs

[ThadHouse]

With the requirement to support multiple CAN buses, the CAN API's need to massively change. We'll start this from the high level and go lower.

PCM, PH and PowerDistribution classes now take an explicit busId parameter, for which bus they are attached to. There is no default busId, this is always a required parameter.

The constructor for the CAN API takes a bus id now. For the sending APIs, there is now a flags parameter. This flag is for specifying FD data length and FD bitrate switching. In Java, these are separate parameters, whereas in C++ there is a single struct for these 3. For receiving APIs, theres a required output parameter passed into the APIs where all the info will be stored. This will contain the flags.

For the Low level CAN direct access API, there is no longer a way to read messages by mask and filter. This functionality was problematic on the old roborio anyway, as there was no specification for messages would be selected for the mask if multiple messages matched. Instead, you can read or write explicit CAN IDs. If you need to read a mask and filter of message IDs, either use socketcan directly, or use the stream APIs.

[auscompgeek]

In Java, these are separate parameters, whereas in C++ there is a single struct for these 3.

Curious what the reason is here. Is it because the separate parameters are simpler to pass over JNI?

[ThadHouse]

In Java, these are separate parameters, whereas in C++ there is a single struct for these 3.

Curious what the reason is here. Is it because the separate parameters are simpler to pass over JNI?

Yeah. To avoid the overhead of an extra object that isn't really needed.