Beta testers: Is anyone creating a HAL implementation for the cRIO?

[virtuald]

Seems like it should be reasonably easy to do. Just wondering if anyone is going to do it.

[jhersh]

Seems like it should be reasonably easy to do. Just wondering if anyone is going to do it.

WPI decided not to do this and not to support the cRIO at all. It was more of a move for the future if I understand correctly, but it's certaily a babystep. There are still plenty of implementation details that leak through the HAL API. Perhaps when a completely different hardware target is ported the API will become more generic.

[virtuald]

Ok, so WPI isn't doing it -- which makes sense.

Anyone else doing it yet? I'm sure someone will do one at some point.

[SoftwareBug2.0]

Our team basically had this last year and is porting it to the roboRIO but the roboRIO version isn't in a usable state yet.

[virtuald]

Our team basically had this last year and is porting it to the roboRIO but the roboRIO version isn't in a usable state yet.

Well, close, but not quite what I want. This year, the python wpilib will be 100% python, using ctypes to interact with the HAL library. So, to make it work for the cRio, it seems like the best way would be to implement an API compatible HAL. There are a lot of cRios out there, and I suspect for most teams they'd be useful to use for testing.

[Cel Skeggs]

Well, close, but not quite what I want. This year, the python wpilib will be 100% python, using ctypes to interact with the HAL library. So, to make it work for the cRio, it seems like the best way would be to implement an API compatible HAL. There are a lot of cRios out there, and I suspect for most teams they'd be useful to use for testing.

Maybe you could implement the abstraction at a higher level? It seems like you should be able to detect which platform the code is running on, and then dispatch to one of two implementations.

Instead of detecting the platform, you could also just download the correct version of your libraries to each platform. (That's what we've done with our framework to make it completely work on both platforms.)

[virtuald]

I suspect that writing an abstraction over the hardware abstraction layer is a bad idea. :)

The goal of the python WPILib project is to be a python implementation of WPILib, so that it is 100% (ish) compatible, as opposed to a framework extending WPILib such as CCRE. Given that the HAL is supposed to be the hardware independent piece, I think that makes the most sense to use as our bottom edge.

If one cannot port the HAL to the cRio, perhaps it should be made more abstract ;)

[Cel Skeggs]

I suspect that writing an abstraction over the hardware abstraction layer is a bad idea. :)

There already IS an abstraction layer over the hardware abstraction layer.

It's called WPILib. ;)

More seriously, the point is that someone's going to have to implement some abstraction for the cRIO either way - the question is at which level, and the HAL might or might not be the best level.


The goal of the python WPILib project is to be a python implementation of WPILib, so that it is 100% (ish) compatible, as opposed to a framework extending WPILib such as CCRE.

That doesn't disallow you from the first suggestion, which was to detect dynamically which platform you're on and choose the proper implementation. You can do that with still offering the same WPILib-like interface.


Given that the HAL is supposed to be the hardware independent piece, I think that makes the most sense to use as our bottom edge.

If one cannot port the HAL to the cRio, perhaps it should be made more abstract ;)

The HAL may work as a layer at which to do the abstraction. However, doing so will require a significant amount of null code for things like the PDP, PCM, Power API, builtin accelerometer, analog outputs, etc. Besides that, there appear to be a large number of platform-specific calls. (These may, however, be very similar to the cRIO calls. The bird's-eye-view of the HAL looks surprisingly similar to the cRIO's FPGA interface.)

While I would agree that it should be made abstract enough to cover both platforms, I doubt that the WPILib team would see this to be important enough to spend time on, as they have a large enough backlog of more relevant tasks.

Still - this is your project. I suspect you could ask the WPILib team for the parts of the HAL code that they're okay with making public (or access them directly after talking to them) and then start the project of supporting the cRIO with it yourself. If you stick it on GitHub or somewhere similar, you might be able to get other teams to help out.

[virtuald]

There already IS an abstraction layer over the hardware abstraction layer.

It's called WPILib. ;)



Fair enough. Don't need yet another abstraction for my purposes then. :)


The HAL may work as a layer at which to do the abstraction. However, doing so will require a significant amount of null code for things like the PDP, PCM, Power API, builtin accelerometer, analog outputs, etc. Besides that, there appear to be a large number of platform-specific calls. (These may, however, be very similar to the cRIO calls. The bird's-eye-view of the HAL looks surprisingly similar to the cRIO's FPGA interface.)


Yep. Given that they both use the underlying NI chipobject stuff as their interface to the hardware, it's not that surprising that it's similar -- which is why I think it would be easy for anyone wanting to create a HAL to do so. I suspect that the initial implementation of HAL involved cut/paste all the ChipObject stuff from the existing WPILib implementation into the HAL code.


Still - this is your project. I suspect you could ask the WPILib team for the parts of the HAL code that they're okay with making public (or access them directly after talking to them) and then start the project of supporting the cRIO with it yourself. If you stick it on GitHub or somewhere similar, you might be able to get other teams to help out.

The source for HAL is all included in the WPILib source, so that part is covered. I might do a HAL implementation at some point if someone else doesn't do it first. I also have a large backlog, which is why I was hoping someone else had already done it.

[Cel Skeggs]

Fair enough. Don't need yet another abstraction for my purposes then. :)

True - but that also means that you can have multiple implementations behind WPILib. We're actually doing that in the main source code for WPILib, with the actual code and the simulation code. It's cut into three projects - common, simulation, and real, and both the real and simulation project implement some of the classes separately.

Yep. Given that they both use the underlying NI chipobject stuff as their interface to the hardware, it's not that surprising that it's similar -- which is why I think it would be easy for anyone wanting to create a HAL to do so. I suspect that the initial implementation of HAL involved cut/paste all the ChipObject stuff from the existing WPILib implementation into the HAL code.

Fair enough.

The source for HAL is all included in the WPILib source, so that part is covered. I might do a HAL implementation at some point if someone else doesn't do it first. I also have a large backlog, which is why I was hoping someone else had already done it.
Well, I don't think they want the WPILib source code public yet - which is the issue, unless you plan to keep you work private for a while.

I'd also consider helping, but I also have a large backlog of pending work.