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

Tried to swap first and last input pins in json file, the problem
follows the last pin defined, now I have j4:6 as first and j3:0 as last,
and j3:0 is not working.
As personal preference (so take it as-is, just my opinion) I would
have used progressive numbering for inputs and outputs, not
linked to connector naming.
I would have used the same rule used fo stepgens:  ...0.in ..1.in etc
the same for out, this way connector naming is not present in hal conf file,
and the hardware configuration can be changed without touching
the hal files.
I'm attaching my configuration used for tests of yesterday.

Thanks!

 

About the mod for inputs, for 5a75b I've swapped U9 U12 U15 with 74LC245 ic's.
I'v removed the old buffers, cut the connection of pin 1 and 20 in order to rewire them.
Then soldered on the new buffers, connect pin 1 to pin 10 of the nearest chip (GND)
then connect pin 20 to 3V3 trace nearby.

This mod is IMHO a dirty hack, in future I'll replace buffer with simple bridges and
then connect external pcb with proper pull-up/downs, filtering and optocoupling as needed. 

 

Thanks for your clear mods, testing and suggestions. Unfortunately I fell ill yesterday, so no progression. Seems like I have some challenging bugs for the weekend...

Edit: 
I resolved one of the bugs in GPIO (driver-side):

• by accident the last GPIO out pin was not written to the FPGA due to an error in the loop boundary. 
• the same bug was also present in GPIO in, resolved there
• also stumbled on an error in GPIO in, which would cause dumping the core if the number of GPIO in was larger then the number of GPIO out pins.

Above changes have been pushed to the repository, so it can be tested.

I also started to rewrite the GPIO in and out for the firmware to resolve the error on the non-responsive GPIO inputs. Did some work on GPIO out, but didn't push it yet, as I could get the tests running on the RV901T. Tomorrow I'll switch back to my 5A-75E to check whether it is a problem with the card or the program.

Edit2:
I pushed the re-write of the GPIO. Tested voor GPIO out only, @muvideo could you give a try to get this working on your modified board. 

Have to say that I found something which is 'less' nice from LiteX. The jumpers and pin-numbers are zero-based, so pin 1 on J1 should read J1:0. Costed me an evening to test why my GPIO was not working, was testing the wrong pins.

Hi, yes the pin numbering Is a Little inconsistent, didnt have time to test yet.
On GitHub i see only the commit 851b0de
Is this correct?

Hello!
Try to make firmware and get this error

svb@LiteX-dev:~/CNC/LiteX-CNC/firmware$ python3 soc.py --build --no-compile
Traceback (most recent call last):
  File "/home/svb/CNC/LiteX-CNC/firmware/soc.py", line 20, in <module>
    from firmware.stepgen import StepGen
ModuleNotFoundError: No module named 'firmware'
svb@LiteX-dev:~/CNC/LiteX-CNC/firmware$

Where i can find module "firmware"?
Litex installed ok and more other projects builded ok

If i clone branch envoders, get another errors

svb@LiteX-dev:~/CNC/LitexCNC-e/firmware$ python3 soc.py --build --no-compile
Traceback (most recent call last):
  File "/home/svb/CNC/LitexCNC-e/firmware/soc.py", line 9, in <module>
    from .encoder import EncoderConfig
ImportError: attempted relative import with no known parent package

Best regards,
Sergey

@muvideo: that commit was indeed old, the correct commit is now on GitHub. Also, please be aware that the naming scheme of PWM and GPIO has been modified to your suggestion. If anyone wants to have the old behavior (like me ) they can use the 'name' field to give it a specific name.

@svb: The problem lays in that you are one level to deep in the directory structure, i.e. you should be in the folder ~/CNC/LiteX-CNC/ and then run the following command:
The Pythonic explanation is that the firmware is a module (hence the -m tag) and is not designed to be used by running it directly. With the -m tag the code which resided in the __main__.py file is called. In some file you might see that it could be theoretically possible to run them directly (i.e if __name__ == '__main__', but those are present there only for testing purposes.

At this moment I recommend to use the `envoders` branch. These have the latest bug-fixes for issues contributed by this community.