search

neurogears / onix-refactor

A project for refactoring Bonsai.ONIX
MIT License
2 stars 3 forks source link

Consider where the context for the Open Ephys USB acquisition board should be packaged #130

Open glopesdev opened 3 days ago

glopesdev commented 3 days ago

@aacuevas made a reminder that we already have a working alternative host driver to the RIFFA deployed in the field, the FT600 powering the Open Ephys USB acquisition board running on ONI. @jonnew It might be useful to discuss where this would fit in the package organization related to #60 but we probably don't need to worry about it for 0.1.0.

jonnew commented 3 days ago

ONI is a general purpose acquisition spec that meets the needs of our hardware. So, when we needed to remake the FPGA for the acquisition bard because Opal Kelly discontinued the one we were using, we used ONI as a backend.

That said, it has nothing to do with ONIX and does not need to advertise its ONIness. It can live in OpenEphys.AcquisitionBoard or something generic.

aacuevas commented 3 days ago

This came from a passing remark I did, and has nothing to do with ONIX on itself.

My passing remark was, basically, that I wanted to redo the acquisition board node using part of the infrastructure we are using here. The current plugin has many downsides. It was originally meant for the OpalKelly interface and adapting it to ONI here is a bit of a hack. And both this and the OK one lack capabilities that the hw has, like the outputs.

So basically I thought "We have the tools to make a proper node, now that it has a proper interface, so why not make it?". Things like port scanning fit perfectly on steps we have now, like link config. The new one will have BNOs, which are the same HDL piece than in the hs64. For the analog and digital IOs of the acq. board, using similar approaches as we are doing with the breakout makes lots of sense.

It's definitely far from a priority, and has nothing to do with ONIX, but all to do with ONI. I think, when the moment comes to cross this bridge, it might be a good exercise to see what is common and what is not, what can be reused, what needs to be rewritten or what needs to be the same code but different binaries (i.e.: git submodules into different projects). Basically, if we want all this to be exclusively for ONIX, or are parts of it that can be used for a broader set of ONI-devices.