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

Thanks you for debugging ad updating the repo so fast. The error message was not very helpful to understand was was going wrong.
This evening I'll try again and update you on the results. I Hope to be able to make some quick tests on a 5a75e and 5a75b both V8

Fabio

Built the firmware, built the driver, was able to connect to the board and made a quick
survey of hal commands.
test_stepgen.hal once adapted to my path and names is working,
test_gpio_blink is making something strange and gives an error: but I have to double check my configuration.
I have worked only on 5A75E, I made some mistake on the build of 5A75B and now it's
giving an error on fingerprint, I have to rebuilt it's bitfile.
Tomorrow more testing.
All is very encouraging, wonderful work!

In the blink example I see a pattern which I don't recommend to use anymore:
The order of adding the function to the thread does matter. In above example, in each cycle:

• any data available will be written to the FPGA;
• available data is read from the FPGA;
• then the siggen will produce a new value which should turn the LED on or off. This value will be written in the next cycle.

A much tighter loop would be:

• read data available data from the FPGA (this includes the position of the encoders and stepgen);
• do something with that data and re-calculate the new state of the CNC-machine;
• write the new demanded state to the FPGA.

For the very simple example above, this would result in the following hal-file:

Made some tests
Working ok:
Pwm (3 of them)
Gpio outs
Not working:
Gpio out on j4:6 (it's the 12th gpio out in the config)
Gpio in (no one, tested 12 of them on j5 and j6)
Stepgens: strange numbers from Speed feedback.
Tested both 5a75e and 5a75b, both V8, same results.
Now I dont have the config files handy, let me know if they will be useful, in that case I'll upload them.

Thanks
Fabio

Fabio, many many thanks for testing the firmware. Good to hear PWM and GPIO out are working. Those are also the ones which I could test, because I didn't desolder the buffers yet.

It is yet strange that the GPIO out on j4:6 is not working. To verify this is a problem of the driver or firmware, could you please test by swapping the first and the last GPIO (so putting j4:6 as the first pin). When j4:6 is still not working in that case, it is possible this pin has a special function not known to me. An bug in FPGA pins has been found earlier and could be an explanation for this behavior.

With regard to the GPIO in, this I didn't test myself yet. The FPGA does not have any pull-ups active in the firmware (don't know whether this is possible nor how to activate them if they are present). Also, if you are using any modified buffer, those don't have pull-ups either. Can you confirm you are actively driving the pins with HIGH and LOW signals and not by connecting the pin to the ground? Last question: can you share your method how you modified your buffers to accept inputs (the existing buffers only allow output, if they are not replaced or removed the board cannot accept inputs).
Edit: I see now that this is possibly due to an error with how the register is designed. Should have used a MultiReg . I will change this as well this evening to the correct register. 

Regarding the velocity feedback of the stepgens: I did only test the position of the steppers, with good correlation between commanded position and position feedback. Tonight, I will create a time-series which also includes speeds (both theoretical and feedback values from the driver) and see whether this an arithmetic mistake in the procedure. Thanks for the bug-report.

For testing the encoders:

• first we have to verify that GPIO in is working correctly;
• at this moment the data is transferred (counts), but this is not converted to position yet. The original ENCODER-component of LinuxCNC states in the man-pages that it handles overflow condition - it does NOT. In the firmware I'm working on accepting overflow conditions by making the registers 64-bit and repotrting the 32 LSB as counts. The position will be based on the 64-bit value though. This is the same approach as with the stepgens, which adds to consistency within the project.
• I will add two extra options to the encoder: min_value and max_value (both in counts). When defined, it will clip the count-register to the specific bounds. This is easy for creating some rotary buttons for controlling the speed/feed override with some cheap encoders. 

I will give an update when the two latter points are ready!
 

About J4:6 and gpio inputs (and my crude implemetation of encoders) I tested 5a75b hardware on my own version of romanetz firmware, I worked on It sime time ago.
This evening I'll provide more info on my test enviroment and board mods to help you understanding what Is going on.
I'll try to make some more tests.
I was unable to use stepgens, maybe I'm not understanding their correct setup.