ColorCNC Colorlight 5A-75E/5A-75B as FPGA controller board

What you describe sounds a little more like a config tool than a driver?

I think I expressed myself not clear. It is definitely a driver, however the number of pins, stepgen, etc. is configurable using the JSON config file.

The driver can be part of LinuxCNC. On the wiki of LinuxCNC we can then point to the proces on obtaining, configuring and building the firmware which is in an external repository. 

Please note that with LitexCNC uses a modified halpcompile. I needed an external library to be linked. It would be nice to grab the chance to make halcompile a little more flexible and let user link their own libraries when needed.
 

TOLP2 wrote:

Please note that with LitexCNC uses a modified halpcompile. I needed an external library to be linked.

You might not need to modify halcompile to do that, you can use an undocumented feature of halcompile, "include"

See, for example: github.com/LinuxCNC/linuxcnc/blob/master...s/mesa_7i65.comp#L46

Didn't know that (it was after all undocumented). I will try that at my next compilation round how it works and will update the repo accordingly.

This project is really interesting to me. I have both the 5A-75B as well as the RV901T. I'm setting myself up to join in. Just for my understanding: why do you use your own protocol and reimplement stepgen etc. instead of using the hostmot2 design and protocol, making the card mesa-compatible? Not that I'm against it, i just want to understand the reasoning behind it.

The honest answer is: it has grown this way. The first version by Romanetz was a combination of PlutoStep stepgen with (I think) own implementation of gpio, pwm and encoders. That has been my starting point.

The goal for me was to make the design more flexible, i.e. the end user should be able to choose which pins have which function, regardless which supported card they choose. Also, I strive to mimic the Hal pinout of the normal Linuxcnc components which you use with the parport (which it will replace in my machine). The latter did not completely work out for the stepgen however.

For using the bit-file for Mesa cards, I think that is only possible for the Rv901t, however I'm not 100% sure. Both Mesa and the Rv901t use the Spartan chipset. The 5a-series uses ECP chipsets.

Your more then welcome to try out the LitexCNC drivers. I would like to recommend to try it first with 5A-75B, as that tool chain is fully open source and the easiest. For the Rv901t we discovered that the Verilog generated by Litex requires some hand work to get it work. Also the Xilinx software is very large and I found it hard to obtain.

The branch with the latest version is 'stepgen_improvement'. As we speak I get a Joint following error due to a refactoring I did. I have to revert the last commit, that will restore it in a working order.

Thanks for the explanation. I wasn't talking about using the mesa bitfiles, but parts of the source code. I was in the process of porting the hostmot2 code to colorlight when I discovered this project. Using Litex as a basis is a great idea to cover a broad range of cards. I really like that, although I have no experience with Litex, but some experience with nmigen/amaranth.
Although the hostmod code is vhdl, I think it should still be possible to port the stepgen etc implementations (the "hostmot2" module) into the litex framework. That way, we could make use of the existing host driver as well as having a tried and tested implementation for stepgen etc. Having this as a starting point would enable me to quickly move away from LPT (new Servos and 3d touch probe just arrived . Going from there, we could gradually improve or replace existing components, as well as switching to a different protocol.
But these are just my first thoughts. First I have to get your project to run. I managed to install xilinx ISE on my arch, as well as the yosys/nextpnr-ecp5 toolchain. Next step is to get a good understanding of litex.