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

I tried to start in my virtual machine and got this....

 full_name [Peter van Tol]: peter
email [This email address is being protected from spambots. You need JavaScript enabled to view it.]: This email address is being protected from spambots. You need JavaScript enabled to view it.
module_name [Litex-CNC module]: test_module
module_slug [test_module]: test_module_slug
version [0.1.0]: 0.1.1
module_short_description [Module Boilerplate contains all the boilerplate you need to create a Litex-CNC module.]: description
fingerprint [0x923e1bd0]: 0x923e1bd0
Traceback (most recent call last):
  File "/home/oj/.local/bin/cookiecutter", line 10, in <module>
    sys.exit(main())
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/oj/.local/lib/python3.7/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/cli.py", line 207, in main
    accept_hooks=_accept_hooks,
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/main.py", line 120, in cookiecutter
    accept_hooks=accept_hooks,
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/generate.py", line 351, in generate_files
    unrendered_dir, context, output_dir, env, overwrite_if_exists
  File "/home/oj/.local/lib/python3.7/site-packages/cookiecutter/generate.py", line 205, in render_and_create_dir
    name_tmpl = environment.from_string(dirname)
  File "/home/oj/.local/lib/python3.7/site-packages/jinja2/environment.py", line 1105, in from_string
    return cls.from_code(self, self.compile(source), gs, None)
  File "/home/oj/.local/lib/python3.7/site-packages/jinja2/environment.py", line 768, in compile
    self.handle_exception(source=source_hint)
  File "/home/oj/.local/lib/python3.7/site-packages/jinja2/environment.py", line 936, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<unknown>", line 1, in template
jinja2.exceptions.TemplateSyntaxError: unexpected '}'

Did some bughunting and the last commit a } was missing. The error description was not very clear, so it took some time to find the error. With the latest commit it should be solved.

The goal of this template is to make extra modules easier. The two projects I have now in mind:

• toolerator. Basically a port of an old project for my Emco 5 turret. The caroussel component still requires some work to get it working, so I decided I want to send a tool number to the FPGA and it selects the correct tool.
• hy_vfd: A little more far fetched, as my current mill does work well, but I just want to have less cables.This module should offer the same functionality as the component with the same name: sending commands to a HuangYang VFD. 

Nice.
I also would like to have a serial port on the board. With a rs232 to rs485 converter I send commands to my VFD.
Wrote a hal component for my Mesa 5i25 and it works good.
On my 7i96 I get warnings, because the hostmot serial driver seems to have some problem over ethernet....

I would be more then interested if such a component / module is available for LitexCNC as well. For me, the VFD is secondary priority now, as I want to finish the Emco5 first. 

Thanks to the power of Python (or OOP in general), I was able to re-use large parts of the stepgen module for the toolerator. I have added a position mode to the stepgen. In this mode the stepgen will move to the commanded position while adhering speed and acceleration limits. In this mode it is not required to (ab)use the motion planner of LinuxCNC. The accuracy of the position mode is depending on the acceleration of the stepper motor. The motion is stopped whenever the error is smaller then 5 times the acceleration per clock cycle. When using an acceleration of 200,000 steps/s² and a FPGA clock speed of 40 MHz, the accuracy is within 10E-7 steps!

A caveat is that changing from velocity to position change (if required) can only be done at stand-still, or otherwise the movement might overshoot a little (10E-4 steps) the first time the stepper comes to a standstill. This overshoot might trigger an extra step.

When a tool change is requested, the toolerator:

• translates the tool-number to a position in the turret, this position is send to the FPGA;
• based on the current position of the turret, the turret will move forward to the new position plus some amount of overtravel;
• to lock the tool in place (it is a ratchet type), the tool changer is moved backwards;
• when the turret has stopped moving, the tool change is reported to be ready.

This means that all the heavy lifting is done by the FPGA and the motion planner is not bothered by this addition. When simulating this design (the driver is not ready for testing), the profile generated is given in the picture below.



I believe that this module gives some possibilities to create programs with the FPGA, not necessarily tied to LinuxCNC
 

Think am not far enough into this yet to write a module.
Is there a How To?
Is it Python? All I see is in C...

EDIT: Sorry...I found the folder with the Python Code example

github.com/enjoy-digital/litex/blob/mast...ex/soc/cores/uart.py

There is already an UART core in LiteX.
Can you use it out of the box?
My big quastion is, how is the assignment to a pin done?

you can either assign them as pads as well as other pins or through multiplexers if you need runtime-configurable firmware
UART communication needs FIFOs and a kind of flow-control in driver and in firmware. In order to make Modbus communication possible (remember allowed delays and turnaround time)

As I look at the source code of Litex UART, I see even some code for UART to wishbone. This means you could send the same packages over UART as we now send over Ethernet and the card should still work. With Litex-CNC all you need would be a driver for the UART.

One challenge though would be the timings and speed. If anything like USB is used to create a serial port, this solution will not work in real-time. That's because of the nature of USB, any re-indexing or interrupt will cause a unacceptable delay on the port. However, it might be interesting for the UART on a RPI4, because you would be directly using the GPIO.

A bummer would be the speed of the UART. Let's assume a cycle period of 1 ms, or 1,000 updates per second. Every update consists of read (which starts with a write of the addresses to be read) and write. On average the read and write are something like 30 bytes; which means every cycle we have to transfer 100 bytes. This means the data-transfer required is 100 kb per second. The speed of UART is 115,200 baud tops, so in the best case scenario we can transmit is 14k4 bytes.

With the speed of UART it will be very difficult to send the required data to the FPGA. It might hamper the amount of functions / modules you want to have (128 GPIO only asks for four bytes and will most likely work) or the update speed / cycle period.

But I like the idea! Would love to have / write a driver for this.

Litex has an udp streaming module and FIFOs, therefore, 2 simultaneous udp connections are needed: one is for etherbone exchange and another for serial communication. As long as realtime drivers work with polling principle, an user has to write another driver which works on user threads.

Maybe I think to easy.
But all I would use the UART for is to send bytes to a RS232 / RS485 converter and read bytes back from it. These data should be transfered together with the other data from / to LinuxCNC.

I do not want to control stepeers, encoders, etc over UART.
So maybe, the part from lines 54 to 150 looks like it takes the data byte and shift it right out to a fpga pin. And the "rx"pin into a data-byte.
  

EDIT:
I attached my component for the Mesa card, so maybe you know what I want.
It maybe not the perfect C programming, but it works
I changed the Bit-file, so the Mesa card has an UART and then I used the "mesa_uart.comp" to send and receive the bytes I need.