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

romanetz wrote:

This is the topic to discuss my contribution into Linuxcnc. 

I have been looking through the pull request from December:
github.com/LinuxCNC/linuxcnc/pull/1422
Have you made any of the changes requested? I would quite like to get this merged before the 2.9 release.
 

Hi cncwhacko,

as requested: please find the modified files attached.

I'm still testing, so do not use with real equipment.

Make sure, to connect directly to the host and turn off any ARP or mDNS messages from the host to the colorlight card.


** UPDATE: Colorcnc.c itself does send two packets close to each other. It first sends the data from linuxcnc to the card and then immediately requests input data with another packet. Linux usually sends them immediatly ( so there is a small time gap between these packets on the wire) but sometimes linux delays the first packet and sends them close to each other. This seems to be a problem too.

There is already a (commented)  "DELAY 50" in the colorcnc.c from earlier tests.  Change it to
#define DELAY 400
This will cause a delay of 400 usec between the two packets. As the update function is called once a millisecond, this will distribute the packet sends as evenly as possible. This will not reduce the update speed of the card.

( No longtime tests by now as they take many hours. But I have seen one crash that happend right after linux sending these two packets together without the usual minimal time gap.)

Cheers,
Inga

@muvideo I'll report that but I'm still thinking how to make a good bug report from my findings.

Back on the project now with a running Raspberry Pi (the first version that is!) and a working installation. On Github I've made a small change to the halcomile file to include the JSON. I'm still wanting the get the code as clean as possible so it can be extended in the future. To work with the modified halcompile, just replace the original file (located at /usr/bin/halcompile) with the modified function from Github. At line 1110 I've added  , in order to get the libraries linked correctly. It would be nice for future development if halcompile would support these extra flags from the command-line.

I'll post this week whether I can write to the digital pins from the litex-cnc project.

Could not believe I could be so happy with som blinking LED's. Run today two test for GPIO out and PWM. I compiled a very simple version of the card, just a few GPIO out (located next to a GND pin for easy connection) and a single PWM. The configuration file for the board can be found   here

1. GPIO out - blinking a LED From this code I found out that I had to do a little bug-fixing. My driver assumed the address of all RW-registers started at 0x00, but by accident they started at 0x04 because I put the GPIO in at the wrong location. Solved this in the firmware by switching some statements in the MMIO. Note to my self: always double check whether the registers in the firmware and the driver are in exactly the same order. 

The way I found this bug was the fact that I could blink the LED by using litex_server and litex_client on the PC. This takes the actual register addresses into account. This showed that in principle there was nothing wrong with the FPGA, bu there was an communication issue between the firmware and the driver. From there the problem was readily spotted.

2. PWM - Knight rider
Also in the PWM there was a small bug. The control registers were created two times, making it impossible to change them. Also fixed in the firmware and the LED was happily blinking.

Reading data
I've noted one bug in the driver. As soon as the write-function is added to a thread, the driver breaks down. Somewhere in the process there is a mistake, making the driver to panic. Want to fix this issue this evening...

Edit: The board name is now part of the pin and function names. Was promised to @cncwhacko. Updated the examples to correspond with current code.

I have attached the (hopefully) last version of my driver version (based on the romanetz verison). 

This version checks the packet output queue to be empty before sending a new packet. I have also reordered the input request and output send order. The driver now requests input first and waits for the response. The output data is then after the response is received. Please so 0_Info.txt for more details about the changes.

I have also chanded the real tie scheduler to "round robin" as this causes less jitter in the timing. Average processing time is 160 usec on a RPI4. Typical max is 460 usec. But there are delays in the range of 5000 usec and more, depending on the system load. DO NOT USE ON A MACHINE THAT CAN BE DAMAGED BY DELAYS OR SUDDEN STOPS FROM THE WATCHDOG. Statstics output is also included.

I have had not a single card freeze since i use this driver version.