Custom roboRIO HAL: Where to find C library for roboRIO fpga?

[CodeYeti]

Hello. I noticed that WPIlib uses a C++ api to access the roborio fpga (this api appears to be generated). I was wondering if there is anyplace I could either find or (even better), generate, a C version of this api to the roboRIO fpga?

I found this document from NI seemingly explaining how to get the c support library for roborio, but when I go to http://ni.com/info and enter the code roboriocsupport2015, nothing comes up.

It would be really advantageous if I could somehow just do the code generation myself rather than rely on an NI mirror, but I bet the FPGA definitions required to generate that are probably proprietary.

tl;dr Where is wpilib getting it's fpga libraries/headers for the roborio? And where can I find a C (instead of C++) equivalent?

Beyond that, I'd be stuck with writing C-ish bindings to the c++ version of the api, which seems easily breakable and just wrong.

Thanks in advance for the help,
Matt Coffin

[Thad House]

Originally Posted by CodeYeti

Hello. I noticed that WPIlib uses a C++ api to access the roborio fpga (this api appears to be generated). I was wondering if there is anyplace I could either find or (even better), generate, a C version of this api to the roboRIO fpga?

I found this document from NI seemingly explaining how to get the c support library for roborio, but when I go to http://ni.com/info and enter the code roboriocsupport2015, nothing comes up.

It would be really advantageous if I could somehow just do the code generation myself rather than rely on an NI mirror, but I bet the FPGA definitions required to generate that are probably proprietary.

tl;dr Where is wpilib getting it's fpga libraries/headers for the roborio? And where can I find a C (instead of C++) equivalent?

Beyond that, I'd be stuck with writing C-ish bindings to the c++ version of the api, which seems easily breakable and just wrong.

Thanks in advance for the help,
Matt Coffin

You can get a link to clone the repository here. In there, in the HAL folder, there are already C bindings for the HAL. Both the python and the .NET teams use those directly to interface with the HAL. It's actually fairly easy to do.

[CodeYeti]

Originally Posted by Thad House

You can get a link to clone the repository here. In there, in the HAL folder, there are already C bindings for the HAL. Both the python and the .NET teams use those directly to interface with the HAL. It's actually fairly easy to do.

Thanks for the quick reply! I've actually already gotten that working (and will probably be using that for any actual code I'll write). What I want to do is do a proof-of-concept for writing my own HAL (i.e. interfacing directly with the NI fpga code, manipulating registers myself). The version of THIS that wpilib seems to use is here as far as I can see. What I'm seeing here is a C++ api to the actual FPGA stuff.

Now, with a little more searching on the ni site, I was able to find what appears to be the c support files that the user manual mentioned. They're VERY different from the C++ api, and don't seem to be something that will be kept up to date in the future, but they might work for now.

It would still be great, however, to find where wpilib is getting it's "ChipObject" C++ version of the fpga code. From the HAL readme, it seems that they get it from http://github.com/first/ni-libraries, but I don't have access to that, so it's not incredibly helpful. I wonder if they have the C api in there as well as the C++ one? One will never know.

If you're curious about what I'm doing, I'm one of the developers of zinc, a bare-metal embedded stack written in pure Rust. I'm hoping to adapt some of the stuff I've written there to do a proof-of-concept of a completely wpilib-free frc development environment.

[Thad House]

Originally Posted by CodeYeti

Thanks for the quick reply! I've actually already gotten that working (and will probably be using that for any actual code I'll write). What I want to do is do a proof-of-concept for writing my own HAL (i.e. interfacing directly with the NI fpga code, manipulating registers myself). The version of THIS that wpilib seems to use is here as far as I can see. What I'm seeing here is a C++ api to the actual FPGA stuff.

Now, with a little more searching on the ni site, I was able to find what appears to be the c support files that the user manual mentioned. They're VERY different from the C++ api, and don't seem to be something that will be kept up to date in the future, but they might work for now.

It would still be great, however, to find where wpilib is getting it's "ChipObject" C++ version of the fpga code. From the HAL readme, it seems that they get it from http://github.com/first/ni-libraries, but I don't have access to that, so it's not incredibly helpful. I wonder if they have the C api in there as well as the C++ one? One will never know.

If you're curious about what I'm doing, I'm one of the developers of zinc, a bare-metal embedded stack written in pure Rust. I'm hoping to adapt some of the stuff I've written there to do a proof-of-concept of a completely wpilib-free frc development environment.

The shared library files for that are provided directly by NI to the WPILib. The code for those is not public in order to keep the FPGA safe and fair for all teams. The actual builds of the libraries can be found here, but I highly doubt that you will be actual to get a copy of the actual code.

[CodeYeti]

Originally Posted by Thad House

The shared library files for that are provided directly by NI to the WPILib. The code for those is not public in order to keep the FPGA safe and fair for all teams. The actual builds of the libraries can be found here, but I highly doubt that you will be actual to get a copy of the actual code.

Gotcha. That's what I expected; it's understandable. The issue with the included ni-library bindings is that (I assume based on the headers) that they only include the C++ bindings to the FPGA. These seem to be the C bindings, along with a few example projects, but because it was so difficult to find, I guess I'd just be left hanging as to whether something similar would be provided in later seasons.

Also: am I even correct to say that the C stuff there is analogous to the FRC_ChipObject stuff that WPIlib and the WPIlib HAL use? I assume this is the case, but it does look drastically different in some aspects.

Thanks again for the help!

[Thad House]

Originally Posted by CodeYeti

Gotcha. That's what I expected; it's understandable. The issue with the included ni-library bindings is that (I assume based on the headers) that they only include the C++ bindings to the FPGA. These seem to be the C bindings, along with a few example projects, but because it was so difficult to find, I guess I'd just be left hanging as to whether something similar would be provided in later seasons.

Also: am I even correct to say that the C stuff there is analogous to the FRC_ChipObject stuff that WPIlib and the WPIlib HAL use? I assume this is the case, but it does look drastically different in some aspects.

Thanks again for the help!

The header files here are what are provided to the WPILib. When compiling the libraries for that, they might use the C stuff, but I don't know. We only have access to what was found in that folder.

[CodeYeti]

Originally Posted by Thad House

The header files here are what are provided to the WPILib. When compiling the libraries for that, they might use the C stuff, but I don't know. We only have access to what was found in that folder.

Alright, I guess I'll inquire of NI if they plan on providing something like these C bindings in future years as well. Thanks for your help, I'll be sure to report back with results if/when I get this working.

Any idea of a good way to contact them?

EDIT: Also: is there any documentation on the operation of the registers for the FPGA or is that all fairly secretive as well?

EDIT2: I'm thinking I could write a parser to parse the lvbitx file and dump out my necessary register definitions for zinc's ioreg macro. This way I can access libNiFpga directly instead of having to go through the roborio-specific frontend. I was able to get some rudimentary parsing done with a crappy python script.

[jhersh]

Originally Posted by CodeYeti

Alright, I guess I'll inquire of NI if they plan on providing something like these C bindings in future years as well. Thanks for your help, I'll be sure to report back with results if/when I get this working.

Those C bindings are for a different FPGA image running on the roboRIO. That API and that FPGA are designed to closely mimic the myRIO counterparts. This will certainly be updated in future years (it was only released yesterday!). However, I don't believe it is what you are looking for.

Originally Posted by CodeYeti

Any idea of a good way to contact them?

I found you!

Originally Posted by CodeYeti

EDIT: Also: is there any documentation on the operation of the registers for the FPGA or is that all fairly secretive as well?

There is a higher level presentation floating around the Internet that I wrote years ago. As for registers, WPILib is the most accurate documentation.

Originally Posted by CodeYeti

EDIT2: I'm thinking I could write a parser to parse the lvbitx file and dump out my necessary register definitions for zinc's ioreg macro. This way I can access libNiFpga directly instead of having to go through the roborio-specific frontend. I was able to get some rudimentary parsing done with a crappy python script.

That's actually what I would recommend. Except not manually parsed. Use the NiFpga API for accessing registers. That's all the ChipObject does.

[CodeYeti]

Originally Posted by jhersh

Those C bindings are for a different FPGA image running on the roboRIO. That API and that FPGA are designed to closely mimic the myRIO counterparts. This will certainly be updated in future years (it was only released yesterday!). However, I don't believe it is what you are looking for.

Yea I definitely see that now. Feeling pretty dumb.

Originally Posted by jhersh

That's actually what I would recommend. Except not manually parsed. Use the NiFpga API for accessing registers. That's all the ChipObject does.

Any chance of getting the generated C API for the FRC roboRIO FPA? The ioreg macro I've been working on for zinc is fairly hard-coded to use compiler intrinsic memset, etc. to set raw memory locations rather than using an api, so a comprehensive update would be required to get it to use NiFpga_WriteU8 and friends. The process would be greatly simplified by having the raw C bindings as well. Admittedly, the WPIlib HAL is pretty darn good, but it would be wonderful to have around purely for experimentation and fun-having purposes. There's no way I'd be letting my team develop in Rust for the actual competition anyways, teaching a bunch of high-schoolers Java is hard enough, let alone a language that's (sometimes) more complex than C++.

[jhersh]

You might try this tool on our website:

http://www.ni.com/download/fpga-inte...-14.0/4946/en/

However, it doesn't support fixed-point or structured registers, so it won't generate a complete API in C.

The rest of the API that uses FXP and structured registers would have to be added afterward.

As for the C++ generator that we currently use, only C++ and Java were ever supported, and Java support has been disabled ever since the WPILib HAL replaced the need for it.

I think you should either use the generator I linked above and manually add accessors for any missing-but-needed-by-you registers or you should write a C wrapper around the C++ chip object library that the HAL uses for at least the registers you care about.

[ShawnTheProgram]

Originally Posted by CodeYeti

Alright, I guess I'll inquire of NI if they plan on providing something like these C bindings in future years as well. Thanks for your help, I'll be sure to report back with results if/when I get this working.

Any idea of a good way to contact them?

EDIT: Also: is there any documentation on the operation of the registers for the FPGA or is that all fairly secretive as well?

EDIT2: I'm thinking I could write a parser to parse the lvbitx file and dump out my necessary register definitions for zinc's ioreg macro. This way I can access libNiFpga directly instead of having to go through the roborio-specific frontend. I was able to get some rudimentary parsing done with a crappy python script.

Okay, so I work with the BXD team for creating the BXD:Synthesis simulator for robots. My specific job is to work on exactly what you are talking about and to configure the wpilibs for the simulator. Earlier this year we got access to the repository for the wpilibs. If you need any help directly you can always email me at shawn.hice@autodesk.com

My little tidbits for some of these questions:
Please for your sanity use C++ for the development of the fpga unless you want to completely recreate it, in that case look at how you can access networks and how you would be able to send and receive data efficiently.

If you do not want to go through an actual robot and field system you are going to have to use a couple of things to make your life ALOT easier. Use a fixed IP that is configured on your computer with a loopback adapter.

The FPGA is of course an interface layer between the robotcode and the wpilib in order to interpret commands that are being sent. So naturally you need to start with doing a couple of things:
-Compile your base version of WPILibs for C++
-Use Visual studios 2013 or higher because you will need C++11

Finally, a little hint into finding a good way to figure out how to use this is to use a windows computer and find the version of the fpga meant for 2014 and reconfigure the FRCComm.h file to the packets that you receive with the 2015 driverstation. If you want any specific help with that you can feel free to email me.

I wish you luck in your ventures!

[CodeYeti]

Originally Posted by ShawnTheProgram

The FPGA is of course an interface layer between the robotcode and the wpilib in order to interpret commands that are being sent.

Do you maybe have the driver station communications (network tables, FMS) confused with the FPGA because little of that made sense to me. Maybe I'm just nuts though.