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

@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 LEDFrom 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.


 

I think I was able to reproduce the lockout problem on the default target file of litex, on my PC running plain Ubuntu 20.04.
Submitted a sort of bugreport to litex people. I Hope they can reproduce and fix the problem.

I managed to implement the read function as well, using separate functions for read and write. Took some iterations, but with the version I have now, no more hangups of the board, even using a WiFi router to control it. 

Now working on a watchdog. This one consist of two sections:
- on the card, which have to be petted (during write) before time out happens (5 ms default, param exported to change this). Will put all outputs to zero, because the board does not support three-state controlled by the FPGA. When the watchdog is happy, one or more (configurable up to your liking) will be HIGH, when the watchdog bites, this pin will be Low. This gives a way to disable drives physically. 
- the driver also watches for dropped packets during read. Dropped packets adds to a counter, when the counter is to high (5 subsequent missed packets), the axe falls and communication is stopped. This means that the watchdog on the card will trigger 5 ms later as petting has stopped. The counter of missed packets is decreased every time a packet has successfully been sent. 

Will keep you updated when this has been pushed to the repo (at this moment only driver side has been done). 

Edit: Watchdog is done and reading data implemented (although packet collisions can occur).​​​​​
​​​​

Well, that was not the last version of the colorcnc driver

The original driver did some strange calculations on the step count that resultet in wrong stepper movements. I have fixed that. 

I have also included code to set the static ARP entry for the card from the driver. That unfortunately implies that the driver needs to know on which interface the card is connected, e.g. "eth0". This is defined in colorcnc.c.

I really hope that is now the last update. I will now move to the mechanics of my mill.

Cheers,
Inga
 

Thanks Inga for your improvements on the stability on the connection. Saw the issue as well at the LiteX-repository. Hope you won't mind I'll incorporate your changes in my version of   LiteX-CNC   .

Small update: included PDM with a resolution of 16-bit. Can be enabled by setting the PWM frequency to 0.

Also, I bought a second card to test the firmware out: a  RV901T  , which is also dirt cheap with 16 Euro + 7 Eur shipping. This card brings:

• dual Ethernet;
• 64 inputs / outputs. Direction can presumably be set by the FPGA in groups of 8;
• 32 outputs only (the buffer is hard-wired;
• The pins are nicely located in two headers and is designed to have a hat on top. Let's make a dedicated CNC hat for this card as soon as it is working.

The Colorlight 5A-75B/E boards are supported by IceStudio IDE for (Linux, Windows or Mac systems)
You only need a FT2232H, FT232H or USB Blaster JTAG programmer
More information in : icestudio.io/

 

And in my Github that explains how to connect and configure the JTAG boards in Windows --> github.com/benitoss/ColorLight_FPGA_boards

Can this IDE open the firmware of ColorCNC posted in the forum.