peter-van-tol / litex-cnc Goto Github PK

Generic CNC firmware and driver for FPGA cards which are supported by LiteX

License: GNU General Public License v3.0

Dockerfile 0.14% C 13.83% Python 8.57% Shell 0.04% Verilog 77.42%

cnc cnc-controller cnc-machine fpga linuxcnc linuxcnc-fpga litex verilog python3

litex-cnc's Introduction

Welcome to LiteX-CNC!

This project aims to make a generic CNC firmware and driver for FPGA cards which are supported by LiteX. Configuration of the board and driver is done using json-files. The supported boards are the Colorlight boards 5A-75B and 5A-75E, as these are fully supported with the open source toolchain.

RV901T
Although the RV901T is also supported by Litex, the firmware cannot be automatically build with LitexCNC, as it requires the Xilinx-software to compile the Verilog to a bit-stream. LitexCNC can be used to create the Verilog and the driver will work when the bit-stream is loaded on the board. However, there is a gap in the toolchain not covered. There are known issues with the compantibility of Litex with Xilinx.

The idea of this project was conceived by ColorCNC by romanetz on the official LinuxCNC and the difficulty to obtain a MESA card.

Acknowledgements

This project would not be possible without:

ColorCNC by romanetz link;
HostMot2 (MESA card driver) as the structure of the driver has been adopted.

Quick start

LitexCNC can be installed using pip:

pip install litexcnc[cli]

NOTE: Suffix [cli] required!
The suffix [cli] is required to install the command-line interface. Without this suffix the scripts referenced below will not work.

After installation of LitexCNC the following scripts are available to the user:

litexcnc install_driver
litexcnc install_litex
litexcnc install_toolchain
litexcnc build_driver

For a full overview on how to use the commands, please refer to the documentation.

litex-cnc's People

Contributors

Stargazers

Watchers

Forkers

wibsea v-zaburdaev orangecnc lifpnc vit74vit romanetz cdwijs rinatzakirov luiskoo darkomenz ozzyrob hilam8899 gtclive romanru1 alan717 hmnijp mfkiwl creisey smik1

litex-cnc's Issues

Installation on PC does not detect correct platform

Describe the bug
On a 64-bit PC, it is reported as i386, which is wrong. This leads to OSS-CAD-suite not being installed when using the command install_toolchain.

To Reproduce
On a 64-bit system, execute the command litexcnc install_toolchain

Additional context
Together with this bug, the following things can be improved:

install OpenOCD on all Linux platforms (currently it is only installed on ARM devices such as RPi);
install git before installing Litex, to prevent errors when this program is not present;
improve documentation, by including a tutorial with the steps as described in #35 (comment)

Module ENCODER: width of Z-index pulse not taken into account

Currently the width of the Z-index pulse is not taken into account. As soon as a rising flank is detected the count value is reset. This leads to a different index position depending on whether the encoder is moving clockwise or counter-clockwise. The behavior of the clock-pulse should be dependent on the direction:

when rotating CW, the index pulse should be detected with a rising flank;
when rotating CCW, the index pulse should be detected with falling flank.

Proposed changes:

Add signal direction with width 2. Possible values are b'00 (reset, not moved), b'01 (CW), b'10 (CCW);
Store direction of movement;
When Z-signal has changed, compare flank with direction.

Safety: Upcoming change in Watchdog

Discussed in #62

^{Originally posted by Peter-van-Tol December 10, 2023}
There are some upcoming changes in the watchdog, for safety reasons:

bug resolved in the driver. The signal when the watchdog has bitten was not relayed to the HAL.
if the watchdog has bit and the has_bitten bit is True, the user can reset it to False to resume operation.
added an physical enable_out pin to the watchdog. Which pin it has to be, can be chosen in the configuration (see example below). I use this pin with the HUB75HAT project. When the board is running enable_out is HIGH. When the watchdog times out (either due to communication disruption or LinuxCNC stops sending signals) the pin becomes LOW. On the HUB75HAT this means that all input and output will go in high-Z mode. This means the watchdog safety is completely in hardware and does not depend on LinuxCNC or the communication.

Example configuration (default for HUB75HAT):

{
    "board_name": "EMCO5_SPI",
    "board_type": "HUB75HAT v8.0",
    "clock_frequency": 50000000,
    "connection": {
        "connection_type": "spi",
            "mosi": "spi:0",
            "miso": "spi:1",
            "clk":  "spi:2",
            "cs_n": "spi:3"
    },
    "watchdog": {
        "pin":"ena:0"
    },
    "modules": [
        ...
    ]
}

Two open actions before I commit this change are:

making the physical enable_out pin optional;
create a working example where the watchdog is part of the E-stop latch circuit. This requires some additional components, to drive the has_bitten pin low before enabling the E-stop chain.

Sample stuff for testing

Hi Peter,

I've started a repo here https://github.com/ozzyrob/litex-configs with some basic hal & pyvcp files for testing, without having to fully start linuxcnc. Includes the firmware I've generated for Linuxcnc 2.9

Encoder velocity calculation

Discussed in #49

^{Originally posted by OJthe123 September 22, 2023}
Hi.
I mentioned this in another question, but it was not the main topic.

I have to multiply the encoder velocity output pin by 8 to get the right value.
Is this a bug, or do I set something wrong?

from my hal....

loadrt mult2 names=spindle-rpm-scale
addf spindle-rpm-scale	servo-thread
setp [LITEXCNC](NAME).encoder.00.position-scale 10000
setp [LITEXCNC](NAME).encoder.00.x4-mode 1
setp spindle-rpm-scale.in0 8
net spindle-rpm spindle-rpm-scale.in1 [LITEXCNC](NAME).encoder.00.velocity
net spindle-vel-fb-rps         =>  spindle.0.speed-in	spindle-rpm-scale.out #[LITEXCNC](NAME).encoder.00.velocity

when I use the encoder.00.velocity pin directly the speed is wrong

Rewite to Add files via upload (PR #25)

Hi Pete,
I was looking at the sed thing, it's not the most readable bit of code, and had a go at making it more "python-like". Now I'm not very experienced at python, actually this is my first real go at it. Anyways I came up with the following code. I was just wondering would this be a better & more readable solution. It also saves the preprocessor from making the decision from deciding which path to include. It still gets the correct path for Makefile.modinc and then decides which value for the rtlibdir variable.
I'm hoping that it would it make it easier in the future rather than that monolithic sed command.


import shutil
import subprocess
import re

def index_containing_substring(the_list, substring, start=0):
    #for i, s in enumerate(the_list,start):
    for i in range(start, len(the_list)):
        if substring in the_list[i]:
            #print(i,the_list[i])
            return i
    return -1


def get_rtlibdir():
    halcompile = shutil.which('halcompile')
    if not halcompile:
            raise SystemExit("Unable to locate halcompile, is it installed?")
    try:
        modinc_loc = subprocess.run(["halcompile --print-modinc"], check = True, shell=True, capture_output=True, text=True)
    except subprocess.CalledProcessError:
        raise SystemExit("halcompile --print-modinc failed")

    modinc_path = (modinc_loc.stdout).rstrip()
    f = open(f'{modinc_path}','r')
    lines = f.read().splitlines() # List with stripped line-breaks
    f.close()                     # Close file

    index = index_containing_substring (lines, 'RUN_IN_PLACE=')
    rip_tmp = re.sub(' ', '',lines[index]).partition('=')

    index = index_containing_substring (lines, 'RTLIBDIR :=')
    rip_tmp = re.sub(' ', '',lines[index]).partition('=')
    rip_yes = rip_tmp[2]

    index = index_containing_substring (lines, 'RTLIBDIR :=',index+2)
    rip_tmp=re.sub(' ', '',lines[index]).partition('=')
    rip_no = rip_tmp[2]

    if rip_tmp[2] == 'yes':
        return rip_yes
    else:
        return rip_no


rtlib = get_rtlibdir()
print (f"{rtlib}")
# from this section forward we can use the original code from install_driver.py
# this was just added to check the code written to out config.h
f = open('config.h','w')
print("/**", file=f)
print(" * THIS FILE IS AUTOGENERATED BY HALCOMPILE.PY, CHANGES WILL BE OVERWRITTEN", file=f)
print(" */", file=f)
print("#ifndef __INCLUDE_LITEXCNC_CONFIG_H__", file=f)
print("#define __INCLUDE_LITEXCNC_CONFIG_H__", file=f)
print("", file=f)
print(f"#define EMC2_RTLIB_DIR \"{rtlib}\"", file=f)
print("", file=f)
print("#endif /* __INCLUDE_LITEXCNC_CONFIG_H__ */", file=f)
f.close()

RV901T how to ?

There is wrote "LitexCNC can be used to create the Verilog" but no explanation how do it.

New cofig and test files.

The main repository contains obsolete and abandoned version, so to do any with that is waste time.
The 11-add-external-extensions-to-litexcnc contains new version, but without any documentation, so even if something works, only @Peter-van-Tol know how to run this...
The minimum is one example config file with one module of each type, and one example hal file, even with one axis.
But tested, not written from memory, and with typos and bugs.
Without this nobody can test new version.

New module `shift_in` and `shift_out` for using shift registers

Discussed in #52

^{Originally posted by Peter-van-Tol October 15, 2023}
When using the 5A-75B, one can get at the point that 51 pins are not enough. The Arduino platform offers two libraries for shifting data using buffers:

74HCT595 for output;
74HC165 for input;

Using these chip, one can use for example a pendant with loads of functions, connecting the MPG directly to the pins and connecting the buttons to these shift registers.

Design spec:

each module can handle up to 32 output (shift_out) or 32 inputs (shift_in);
pins required are DATA, CLK and LATCH;
input and output cannot be mixed on one channel;
support for multiple channels, no overlap in pins.

Should this prove useful?

Bugfix for RPI5 Support

Discussed in #63

TODO:

enable libgpiod in OpenOCD
Add configuration for libgpiod to the cli
Rename litexcnc_spi.* to litexcnc_spidev.* and update the inlcudes in the files

Add option invert PWM output

Is your feature request related to a problem? Please describe.
PWM should be able to be inverted without the need for tricks.

Describe alternatives you've considered

inverting the output when compiling the firmware. Easiest to implement, however not very flexible
inverting the output using a HAL parameter, similar to GPIO which can also be inverted from the HAL. One can choose to:
- either invert the duty-cycle (thus a duty-cycle of 5% will be send out as 95%, which is effectively the same as inversing the signal, however the start of the signal shifts) NOTE: this is the trick to 'invert' the signal in the current situation, by choosing scale and offset smart;
- send an extra WORD to the FPGA with the config of the PWM. This case, the start of the PWM (and thus the frequency) is always fixed.

Describe the solution you'd like
Use the most flexible option, by adding an extra WORD to the communication stream.

NOTE: by adding an extra WORD, it is required to re-compile any existing drivers after updating the driver

Installation Documentation Update for Debian 12 & Python 3.11 with venv.

Hi Peter. I like your project quite a lot and getting ready to get familiar and give it a try. Hopefully this can retire my 4 years old LPT card and so I've put a 5A-75E V.8.0 (like yours?), a FT232H programmer and a dozen SN74LVC245A buffers on order.

Challenge I'm facing now is installing LiteX-CNC's dependencies/toolchain ect. Debian 12 and Python 3.11 (pip3) forces a virtual environment and this creates a whole lot of impediments at the permission & user levels. Practically impossible to install anything without failures. e.g. Driver perms fails (sudo does not work), LiteX throws an error (--user does not work), to name a few.

Can I recommend for this to be investigated at your end (I'm nowhere a linux expert!) and documentation updated to support this environment?

Let me know if you need any trace logs etc. Happy to help despite my limited abilities and knowledge.

Thanks. Alex.

32-bit vs 64-bit integer sizes

Description
Compiling on 64-bit system leads to warnings in print statements that sizes are incorrect:

**Compiling realtime litexcnc.c
litexcnc.c: In function ‘litexcnc_register’:
litexcnc.c:250:9: warning: format not a string literal and no format arguments [-Wformat-security]
  250 |         rtapi_snprintf(fpga->name, sizeof(fpga->name), json_object_get_string(board_name));
      |         ^~~~~~~~~~~~~~
In file included from litexcnc.c:33:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:43:61: note: in expansion of macro ‘LITEXCNC_NAME’
   43 | #define LITEXCNC_PRINT_NO_DEVICE(fmt, args...)  rtapi_print(LITEXCNC_NAME ": " fmt, ## args)
      |                                                             ^~~~~~~~~~~~~
litexcnc.c:322:5: note: in expansion of macro ‘LITEXCNC_PRINT_NO_DEVICE’
  322 |     LITEXCNC_PRINT_NO_DEVICE(" - Write buffer: %d bytes)\n", LITEXCNC_BOARD_DATA_WRITE_SIZE(litexcnc));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:43:61: note: in expansion of macro ‘LITEXCNC_NAME’
   43 | #define LITEXCNC_PRINT_NO_DEVICE(fmt, args...)  rtapi_print(LITEXCNC_NAME ": " fmt, ## args)
      |                                                             ^~~~~~~~~~~~~
litexcnc.c:332:5: note: in expansion of macro ‘LITEXCNC_PRINT_NO_DEVICE’
  332 |     LITEXCNC_PRINT_NO_DEVICE(" - Read buffer: %d bytes)\n", LITEXCNC_BOARD_DATA_READ_SIZE(litexcnc));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:50:81: note: in expansion of macro ‘LITEXCNC_NAME’
   50 | (fmt, device, args...)      rtapi_print_msg(RTAPI_MSG_ERR,  LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~

litexcnc.c:359:9: note: in expansion of macro ‘LITEXCNC_ERR’
  359 |         LITEXCNC_ERR("error %d exporting read function %s\n", r, name);
      |         ^~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘char *’ [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:50:81: note: in expansion of macro ‘LITEXCNC_NAME’
   50 | (fmt, device, args...)      rtapi_print_msg(RTAPI_MSG_ERR,  LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~

litexcnc.c:359:9: note: in expansion of macro ‘LITEXCNC_ERR’
  359 |         LITEXCNC_ERR("error %d exporting read function %s\n", r, name);
      |         ^~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:50:81: note: in expansion of macro ‘LITEXCNC_NAME’
   50 | (fmt, device, args...)      rtapi_print_msg(RTAPI_MSG_ERR,  LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~

litexcnc.c:359:9: note: in expansion of macro ‘LITEXCNC_ERR’
  359 |         LITEXCNC_ERR("error %d exporting read function %s\n", r, name);
      |         ^~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘int’ [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:50:81: note: in expansion of macro ‘LITEXCNC_NAME’
   50 | (fmt, device, args...)      rtapi_print_msg(RTAPI_MSG_ERR,  LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~

litexcnc.c:367:9: note: in expansion of macro ‘LITEXCNC_ERR’
  367 |         LITEXCNC_ERR("error %d exporting read function %s\n", r, name);
      |         ^~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘char *’ [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:50:81: note: in expansion of macro ‘LITEXCNC_NAME’
   50 | (fmt, device, args...)      rtapi_print_msg(RTAPI_MSG_ERR,  LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~

litexcnc.c:367:9: note: in expansion of macro ‘LITEXCNC_ERR’
  367 |         LITEXCNC_ERR("error %d exporting read function %s\n", r, name);
      |         ^~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%s’ expects a matching ‘char *’ argument [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:50:81: note: in expansion of macro ‘LITEXCNC_NAME’
   50 | (fmt, device, args...)      rtapi_print_msg(RTAPI_MSG_ERR,  LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~

litexcnc.c:367:9: note: in expansion of macro ‘LITEXCNC_ERR’
  367 |         LITEXCNC_ERR("error %d exporting read function %s\n", r, name);
      |         ^~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/watchdog.c: In function ‘litexcnc_watchdog_prepare_write’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘hal_u32_t’ {aka ‘unsigned int’} [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:49:61: note: in expansion of macro ‘LITEXCNC_NAME’
   49 | #define LITEXCNC_PRINT(fmt, device, args...)    rtapi_print(LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/watchdog.c:113:13: note: in expansion of macro ‘LITEXCNC_PRINT’
  113 |             LITEXCNC_PRINT(
      |             ^~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 has type ‘long int’ [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:49:61: note: in expansion of macro ‘LITEXCNC_NAME’
   49 | #define LITEXCNC_PRINT(fmt, device, args...)    rtapi_print(LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/watchdog.c:113:13: note: in expansion of macro ‘LITEXCNC_PRINT’
  113 |             LITEXCNC_PRINT(
      |             ^~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%ld’ expects a matching ‘long int’ argument [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:49:61: note: in expansion of macro ‘LITEXCNC_NAME’
   49 | #define LITEXCNC_PRINT(fmt, device, args...)    rtapi_print(LITEXCNC_NAME "/%s: " fmt, device, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/watchdog.c:113:13: note: in expansion of macro ‘LITEXCNC_PRINT’
  113 |             LITEXCNC_PRINT(
      |             ^~~~~~~~~~~~~~
In file included from litexcnc.c:423:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/gpio.c: In function ‘litexcnc_gpio_out_init’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/gpio.c:37:64: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
   37 |              rtapi_snprintf(name, sizeof(name), "%s.gpio.%02d.out", litexcnc->fpga->name, i);
      |                                                          ~~~^                             ~
      |                                                             |                             |
      |                                                             int                           size_t {aka long unsigned int}
      |                                                          %02ld
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/gpio.c:48:64: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
   48 |              rtapi_snprintf(name, sizeof(name), "%s.gpio.%02d.invert_output", litexcnc->fpga->name, i);
      |                                                          ~~~^                                       ~
      |                                                             |                                       |
      |                                                             int                                     size_t {aka long unsigned int}
      |                                                          %02ld
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/gpio.c: In function ‘litexcnc_gpio_in_init’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/gpio.c:92:64: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
   92 |              rtapi_snprintf(name, sizeof(name), "%s.gpio.%02d.in", litexcnc->fpga->name, i);
      |                                                          ~~~^                            ~
      |                                                             |                            |
      |                                                             int                          size_t {aka long unsigned int}
      |                                                          %02ld
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/gpio.c:93:82: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
   93 | _snprintf(name_inverted, sizeof(name_inverted), "%s.gpio.%02d.in-not", litexcnc->fpga->name, i);
      |                                                          ~~~^                                ~
      |                                                             |                                |
      |                                                             int                              size_t {aka long unsigned int}
      |                                                          %02ld
In file included from litexcnc.c:424:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/pwm.c: In function ‘litexcnc_pwm_init’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/pwm.c:80:73: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
   80 |     rtapi_snprintf(base_name, sizeof(base_name), "%s.pwm.%02d", litexcnc->fpga->name, i);
      |                                                          ~~~^                         ~
      |                                                             |                         |
      |                                                             int                       size_t {aka long unsigned int}
      |                                                          %02ld
In file included from litexcnc.c:425:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c: In function ‘litexcnc_stepgen_init’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:95:77: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
   95 | rtapi_snprintf(base_name, sizeof(base_name), "%s.stepgen.%02d", litexcnc->fpga->name, i);
      |                                                          ~~~^                         ~
      |                                                             |                         |
      |                                                             int                       size_t {aka long unsigned int}
      |                                                          %02ld
In file included from litexcnc.c:33:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c: In function ‘litexcnc_stepgen_prepare_write’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:43:61: note: in expansion of macro ‘LITEXCNC_NAME’
   43 | #define LITEXCNC_PRINT_NO_DEVICE(fmt, args...)  rtapi_print(LITEXCNC_NAME ": " fmt, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:359:13: note: in expansion of macro ‘LITEXCNC_PRINT_NO_DEVICE’
  359 |             LITEXCNC_PRINT_NO_DEVICE("Stepgen: data sent to FPGA %llu, %llu, %lu, %lu, %lu \n",
      |             ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:43:61: note: in expansion of macro ‘LITEXCNC_NAME’
   43 | #define LITEXCNC_PRINT_NO_DEVICE(fmt, args...)  rtapi_print(LITEXCNC_NAME ": " fmt, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:359:13: note: in expansion of macro ‘LITEXCNC_PRINT_NO_DEVICE’
  359 |             LITEXCNC_PRINT_NO_DEVICE("Stepgen: data sent to FPGA %llu, %llu, %lu, %lu, %lu \n",
      |             ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:43:61: note: in expansion of macro ‘LITEXCNC_NAME’
   43 | #define LITEXCNC_PRINT_NO_DEVICE(fmt, args...)  rtapi_print(LITEXCNC_NAME ": " fmt, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:359:13: note: in expansion of macro ‘LITEXCNC_PRINT_NO_DEVICE’
  359 |             LITEXCNC_PRINT_NO_DEVICE("Stepgen: data sent to FPGA %llu, %llu, %lu, %lu, %lu \n",
      |             ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:43:61: note: in expansion of macro ‘LITEXCNC_NAME’
   43 | #define LITEXCNC_PRINT_NO_DEVICE(fmt, args...)  rtapi_print(LITEXCNC_NAME ": " fmt, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:359:13: note: in expansion of macro ‘LITEXCNC_PRINT_NO_DEVICE’
  359 |             LITEXCNC_PRINT_NO_DEVICE("Stepgen: data sent to FPGA %llu, %llu, %lu, %lu, %lu \n",
      |             ^~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:33:26: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
   33 | #define LITEXCNC_NAME    "litexcnc"
      |                          ^~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/litexcnc.h:43:61: note: in expansion of macro ‘LITEXCNC_NAME’
   43 | #define LITEXCNC_PRINT_NO_DEVICE(fmt, args...)  rtapi_print(LITEXCNC_NAME ": " fmt, ## args)
      |                                                             ^~~~~~~~~~~~~
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:359:13: note: in expansion of macro ‘LITEXCNC_PRINT_NO_DEVICE’
  359 |             LITEXCNC_PRINT_NO_DEVICE("Stepgen: data sent to FPGA %llu, %llu, %lu, %lu, %lu \n",
      |             ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from litexcnc.c:425:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c: In function ‘litexcnc_stepgen_process_read’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:428:66: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  428 |    rtapi_print("Apply time exceeding limits (too short): %llu, %llu, %llu \n",
      |                                                          ~~~^
      |                                                             |
      |                                                             long long unsigned int
      |                                                          %lu
  429 |        litexcnc->wallclock->memo.wallclock_ticks,
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~             
      |                                 |
      |                                 uint64_t {aka long unsigned int}

/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:428:72: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  428 | pi_print("Apply time exceeding limits (too short): %llu, %llu, %llu \n",
      |                                                          ~~~^
      |                                                             |
      |                                                             long long unsigned int
      |                                                          %lu
  429 |  litexcnc->wallclock->memo.wallclock_ticks,

  430 |  litexcnc->stepgen.memo.apply_time,
      |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                           
      |                        |
      |                        uint64_t {aka long unsigned int}

/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:428:78: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  428 | i_print("Apply time exceeding limits (too short): %llu, %llu, %llu \n",
      |                                                               ~~~^
      |                                                                  |
      |                                                                  long long unsigned int
      |                                                               %lu
......
  431 | next_apply_time
      | ~~~~~~~~~~~~~~~                                                   
      | |
      | uint64_t {aka long unsigned int}

/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:434:25: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  434 |         rtapi_print("%llu \n", next_apply_time);
      |                      ~~~^      ~~~~~~~~~~~~~~~
      |                         |      |
      |                         |      uint64_t {aka long unsigned int}
      |                         long long unsigned int
      |                      %lu
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:442:65: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  442 |     rtapi_print("Apply time exceeding limits (too long): %llu, %llu, %llu \n",
      |                                                          ~~~^
      |                                                             |
      |                                                             long long unsigned int
      |                                                          %lu
  443 |         litexcnc->wallclock->memo.wallclock_ticks,
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            
      |                                  |
      |                                  uint64_t {aka long unsigned int}

/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:442:71: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  442 | api_print("Apply time exceeding limits (too long): %llu, %llu, %llu \n",
      |                                                          ~~~^
      |                                                             |
      |                                                             long long unsigned int
      |                                                          %lu
  443 |   litexcnc->wallclock->memo.wallclock_ticks,

  444 |   litexcnc->stepgen.memo.apply_time,
      |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                          
      |                         |
      |                         uint64_t {aka long unsigned int}

/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:442:77: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  442 | pi_print("Apply time exceeding limits (too long): %llu, %llu, %llu \n",
      |                                                               ~~~^
      |                                                                  |
      |                                                                  long long unsigned int
      |                                                               %lu
......
  445 |  next_apply_time
      |  ~~~~~~~~~~~~~~~                                                  
      |  |
      |  uint64_t {aka long unsigned int}

/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:528:44: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  528 |             rtapi_print("Timings: %.6f, %llu, %llu, %lu, %llu \n",
      |                                         ~~~^
      |                                            |
      |                                            long long unsigned int
      |                                         %lu
  529 |                 *(litexcnc->stepgen.hal->pin.period_s),
  530 |                 litexcnc->wallclock->memo.wallclock_ticks,
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                          |
      |                                          uint64_t {aka long unsigned int}
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:528:50: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  528 |             rtapi_print("Timings: %.6f, %llu, %llu, %lu, %llu \n",
      |                                               ~~~^
      |                                                  |
      |                                                  long long unsigned int
      |                                               %lu
......
  531 |                 litexcnc->stepgen.memo.apply_time,
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
      |                                       |
      |                                       uint64_t {aka long unsigned int}
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:528:55: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
  528 |             rtapi_print("Timings: %.6f, %llu, %llu, %lu, %llu \n",
      |                                                     ~~^
      |                                                       |
      |                                                       long unsigned int
      |                                                     %u
......
  532 |                 instance->data.fpga_time,
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~               
      |                               |
      |                               uint32_t {aka unsigned int}
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:528:61: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 6 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  528 |             rtapi_print("Timings: %.6f, %llu, %llu, %lu, %llu \n",
      |                                                          ~~~^
      |                                                             |
      |                                                             long long unsigned int
      |                                                          %lu
......
  533 |                 next_apply_time
      |                 ~~~~~~~~~~~~~~~                              
      |                 |
      |                 uint64_t {aka long unsigned int}
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:560:60: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  560 |             rtapi_print("Stepgen speed feedback result: %llu, %llu, %.6f, %.6f, %.6f, %.6f \n",
      |                                                         ~~~^
      |                                                            |
      |                                                            long long unsigned int
      |                                                         %lu
  561 |                 litexcnc->wallclock->memo.wallclock_ticks,
      |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   
      |                                          |
      |                                          uint64_t {aka long unsigned int}
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/stepgen.c:560:66: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
  560 |        rtapi_print("Stepgen speed feedback result: %llu, %llu, %.6f, %.6f, %.6f, %.6f \n",
      |                                                          ~~~^
      |                                                             |
      |                                                             long long unsigned int
      |                                                          %lu
  561 |            litexcnc->wallclock->memo.wallclock_ticks,

  562 |            next_apply_time,
      |            ~~~~~~~~~~~~~~~                                   
      |            |
      |            uint64_t {aka long unsigned int}

In file included from litexcnc.c:426:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/encoder.c: In function ‘litexcnc_encoder_init’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/encoder.c:74:77: warning: format ‘%d’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
   74 | rtapi_snprintf(base_name, sizeof(base_name), "%s.encoder.%02d", litexcnc->fpga->name, i);
      |                                                          ~~~^                         ~
      |                                                             |                         |
      |                                                             int                       size_t {aka long unsigned int}
      |                                                          %02ld
litexcnc.c: In function ‘litexcnc_register’:
litexcnc.c:199:5: warning: ignoring return value of ‘fread’ declared with attribute ‘warn_unused_result’ [-Wunused-result]
  199 |     fread(buffer, filelen, 1, fileptr);   // Read in the entire file
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Linking litexcnc.so
cp litexcnc.so /usr/lib/linuxcnc/modules/
Compiling realtime litexcnc_eth.c
litexcnc_eth.c: In function ‘litexcnc_eth_read’:
litexcnc_eth.c:251:64: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
  251 |      fprintf(stderr, "Unexpected read length: %d, expected %d\n", count, this->read_buffer_size);
      |                                                            ~^            ~~~~~~~~~~~~~~~~~~~~~~
      |                                                             |                |
      |                                                             int              size_t {aka long unsigned int}
      |                                                            %ld
litexcnc_eth.c: In function ‘init_board’:
litexcnc_eth.c:323:100: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘struct json_object *’ [-Wformat=]
  323 | colorcnc: ERROR: failed to connect to board on ip-address '%s'\n", ip_address);
      |                                                            ~^      ~~~~~~~~~~
      |                                                             |      |
      |                                                             char * struct json_object *

In file included from litexcnc_eth.c:449:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/etherbone.c: In function ‘eb_read8’:
/usr/local/lib/python3.10/dist-packages/litexcnc/driver/etherbone.c:153:64: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
  153 |      fprintf(stderr, "Unexpected read length: %d, expected %d\n", count, (16+size));
      |                                                            ~^            ~~~~~~~~~
      |                                                             |               |
      |                                                             int             size_t {aka long unsigned int}
      |                                                            %ld
Linking litexcnc_eth.so
cp litexcnc_eth.so /usr/lib/linuxcnc/modules/
Compiling realtime litexcnc_debug.c
Linking litexcnc_debug.so
cp litexcnc_debug.so /usr/lib/linuxcnc/modules/
Compiling realtime pos2vel.c
pos2vel.c: In function ‘rtapi_app_main’:
pos2vel.c:161:54: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
  161 |     rtapi_print_msg(RTAPI_MSG_INFO, "PID: installed %d pos2vel converters\n", pos2vel->data.num_instances);
      |                                                     ~^                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                      |                                     |
      |                                                      int                                   size_t {aka long unsigned int}
      |                                                     %ld**

To Reproduce
Compile with warnings on on a 64-bit system.

Differential outputs

I think this is not a big problem to add to Stepgen and PWM negated output signals.
For example:
"step_pin": "J9: 0",
"step_pin_inv": "j9: 1",
This would give the possibility to control the output devices with a differential signal.
This won't spoil anything, if someone doesn't need it, they just won't use it.

Install OpenOCD and flash firmware using Litexcnc-commands

Add two more commands to litexcnc:

to install openocd, with extensions for programming the LED-card with the RaspberryPi;
to flash the firmware with openocd, optionally using the pinout for the HUB75HAT.

Reset watchdog on FPGA reset

When starting LinuxCNC, closing the instance will trigger the watchdog. When LinuxCNC is restarted, the watchdog has_bitten pin is still HIGH. This needs then to be reset by hand. Setting it in the HAL doesn't help, because the data is first read from the FPGA, thus overwriting the setting set by setp.

Solution: the watchdog needs to be reset when the card is reset.

11-add-external-extensions-to-linuxcnc litexcnc.c

Should the following code

// Between version 2.8 and 2.9 the definition of LINELEN has moved. Below
// is a check whether 2.9 is installed. If so, the header is imported to
// get the correct value of LINELEN.
#ifdef LINUXCNC_H
#include "linuxcnc.h"
#endif /* LINUXCNC_H */

#include "litexcnc.h"

// Between version 2.8 and 2.9 the definition of LINELEN has moved. Below
// is a check whether 2.9 is installed. If so, the header is imported to
// get the correct value of LINELEN.
#ifndef LINUXCNC_H
#include "linuxcnc.h"
#endif /* LINUXCNC_H */

#include "litexcnc.h"

When compiling with 2.9 the first doesn't work but the second will.

New litexcnc connections="eth:...." problem

Discussed in #38

^{Originally posted by OJthe123 September 2, 2023}
I have Problems with the "new" loadrt standard.
I attached my hal.
It includes the two "old" lines for litexcnc which work without Problems.

The new single line loading produces read / connection errors.

Now when I try to install driver after pulling the latest "11" I get this...

INFO: Compiling LitexCNC driver...
Compiling realtime litexcnc.c
Linking litexcnc.so
sudo cp litexcnc.so /usr/lib/linuxcnc/modules/
[sudo] Passwort für oj:
Compiling realtime litexcnc_eth.c
Linking litexcnc_eth.so
sudo cp litexcnc_eth.so /usr/lib/linuxcnc/modules/
Compiling realtime litexcnc_stepgen.c
In file included from litexcnc_stepgen.c:44:
/tmp/tmppg5hjrun/litexcnc_stepgen.h:153:5: error: unknown type name ‘litexcnc_stepgen_pin_t’
litexcnc_stepgen_pin_t *instances;
^~~~~~~~~~~~~~~~~~~~~~
litexcnc_stepgen.c: In function ‘litexcnc_stepgen_config’:
litexcnc_stepgen.c:144:80: error: ‘stepgen->hal’ is a pointer; did you mean to use ‘->’?
*(stepgen->data.clock_frequency) / (1 << (shift + 1)) > stepgen->hal.param.max_driver_freq) {
^
->
litexcnc_stepgen.c:170:49: warning: initialization of ‘litexcnc_stepgen_instance_t *’ {aka ‘struct *’} from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
litexcnc_stepgen_instance_t *instance = &(stepgen->instances[i]);
^
litexcnc_stepgen.c: In function ‘litexcnc_stepgen_prepare_write’:
litexcnc_stepgen.c:260:18: warning: assignment to ‘litexcnc_stepgen_instance_t *’ {aka ‘struct *’} from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
instance = &(stepgen->instances[i]);
^
litexcnc_stepgen.c: In function ‘litexcnc_stepgen_process_read’:
litexcnc_stepgen.c:450:18: warning: assignment to ‘litexcnc_stepgen_instance_t *’ {aka ‘struct *’} from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
instance = &(stepgen->instances[i]);
^
litexcnc_stepgen.c: In function ‘litexcnc_stepgen_init’:
litexcnc_stepgen.c:586:17: error: ‘stepgen->hal’ is a pointer; did you mean to use ‘->’?
stepgen->hal.param.max_driver_freq = 400e3;
^
->
litexcnc_stepgen.c:590:24: warning: assignment to ‘int *’ from incompatible pointer type ‘litexcnc_stepgen_instance_t *’ {aka ‘struct *’} [-Wincompatible-pointer-types]
stepgen->instances = (litexcnc_stepgen_instance_t *)hal_malloc(stepgen->num_instances * sizeof(litexcnc_stepgen_instance_t));
^
litexcnc_stepgen.c:599:49: warning: initialization of ‘litexcnc_stepgen_instance_t *’ {aka ‘struct *’} from incompatible pointer type ‘int *’ [-Wincompatible-pointer-types]
litexcnc_stepgen_instance_t *instance = &(stepgen->instances[i]);
^
make: *** [/usr/share/linuxcnc/Makefile.modinc:115: litexcnc_stepgen.o] Fehler 1
Error: Compilation of the driver failed

Maximum frequency 375 kHz.

Dear friend, you have done a great job.
Thank you for that.
I would really like to know why it is possible to generate the maximum 375 kHz?
And this is at a FPga frequency of 50 MHz.
I tried to set the maximum frequency to 55 MHz - 200 kHz.
60 MHz - 200 kHz
70MHz -200KHz
80MHz - 306 kHz
100 MHz - 200 kHz.
I would really like to know what the limitation is?
Thank you.

Install_litex throws errors when switch --user is not used

Is there something special for installing on raspberry pi4 with bookworm?

litexcnc install_litex throws errors.

also when I do "pip3 install litexcnc[cli] it doesn't work

litexcnc install_litex
Traceback (most recent call last):
  File "/home/cnc/.local/bin/litexcnc", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "/home/cnc/.local/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/cnc/.local/lib/python3.11/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/home/cnc/.local/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/cnc/.local/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/cnc/.local/lib/python3.11/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/cnc/.local/lib/python3.11/site-packages/litexcnc/cli/install_litex.py", line 21, in cli
    target = os.path.join(target, 'litex')
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen posixpath>", line 76, in join
TypeError: expected str, bytes or os.PathLike object, not NoneType

EDIT:
solved...forgot to install it with '--user'

Originally posted by @OJthe123 in #36 (comment)

Upgrade toolchain: bring Yosys to version 0.38

As mentioned in #76 , Yosys has improved a lot and is currently on version 0.38.

Background on the current version:

The current version has been chosen as it was stable at that time. By defaulting to the latest version, the firmware could sometimes not be compiled on a RPi4 due to time-outs. The version with the best performance for this project was selected for the default toolchain. The reason is that users should be building their machine, not trying to figure out why it won't build.

Can't get rv901 compiled ...

Release 13.4 ngdbuild O.87xd (lin64)
Copyright (c) 1995-2011 Xilinx, Inc. All rights reserved.

Command Line: /opt/Xilinx/13.4/ISE_DS/ISE/bin/lin64/unwrapped/ngdbuild -uc
rv901t.ucf rv901t.ngc rv901t.ngd

Reading NGO file "/home/durval/devel/LiteX-CNC/rv901t_emco5/gateware/rv901t.ngc"
...
Gathering constraint information from source properties...
Done.

Annotating constraints to design from ucf file "rv901t.ucf" ...
Resolving constraint associations...
Checking Constraint Associations...
ERROR:ConstraintSystem:59 - Constraint <NET "eth_tx_clk" TNM_NET =
"PRDeth_tx_clk";> [rv901t.ucf(42)]: NET "eth_tx_clk" not found. Please
verify that:

The specified design element actually exists in the original design.
The specified object is spelled correctly in the constraint source file.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC "TSeth_tx_clk" = PERIOD
"PRDeth_tx_clk" 8.0 ns HIGH 50%;> [rv901t.ucf(43)]: Unable to find an active
'TNM' or 'TimeGrp' constraint named 'PRDeth_tx_clk'.

ERROR:ConstraintSystem:59 - Constraint <NET "eth_tx_clk" TNM_NET =
"TIGeth_tx_clk";> [rv901t.ucf(54)]: NET "eth_tx_clk" not found. Please
verify that:

The specified design element actually exists in the original design.
The specified object is spelled correctly in the constraint source file.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC "TSsys_clkTOeth_tx_clk" =
FROM "TIGsys_clk" TO "TIGeth_tx_clk" TIG;> [rv901t.ucf(55)]: Unable to find
an active 'TimeGrp' or 'TNM' or 'TPSync' constraint named 'TIGeth_tx_clk'.

ERROR:ConstraintSystem:59 - Constraint <NET "eth_tx_clk" TNM_NET =
"TIGeth_tx_clk";> [rv901t.ucf(66)]: NET "eth_tx_clk" not found. Please
verify that:

The specified design element actually exists in the original design.
The specified object is spelled correctly in the constraint source file.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC "TSeth_rx_clkTOeth_tx_clk" =
FROM "TIGeth_rx_clk" TO "TIGeth_tx_clk" TIG;> [rv901t.ucf(67)]: Unable to
find an active 'TimeGrp' or 'TNM' or 'TPSync' constraint named
'TIGeth_tx_clk'.

ERROR:ConstraintSystem:59 - Constraint <NET "eth_tx_clk" TNM_NET =
"TIGeth_tx_clk";> [rv901t.ucf(71)]: NET "eth_tx_clk" not found. Please
verify that:

The specified design element actually exists in the original design.
The specified object is spelled correctly in the constraint source file.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC "TSeth_tx_clkTOsys_clk" =
FROM "TIGeth_tx_clk" TO "TIGsys_clk" TIG;> [rv901t.ucf(73)]: Unable to find
an active 'TimeGrp' or 'TNM' or 'TPSync' constraint named 'TIGeth_tx_clk'.

ERROR:ConstraintSystem:59 - Constraint <NET "eth_tx_clk" TNM_NET =
"TIGeth_tx_clk";> [rv901t.ucf(77)]: NET "eth_tx_clk" not found. Please
verify that:

The specified design element actually exists in the original design.
The specified object is spelled correctly in the constraint source file.

WARNING:ConstraintSystem:56 - Constraint <TIMESPEC "TSeth_tx_clkTOeth_rx_clk" =
FROM "TIGeth_tx_clk" TO "TIGeth_rx_clk" TIG;> [rv901t.ucf(79)]: Unable to
find an active 'TimeGrp' or 'TNM' or 'TPSync' constraint named
'TIGeth_tx_clk'.

INFO:ConstraintSystem:178 - TNM 'PRDclk25', used in period specification
'TSclk25', was traced into PLL_ADV instance PLL_ADV. The following new TNM
groups and period specifications were generated at the PLL_ADV output(s):
CLKOUT0: <TIMESPEC TS_crg_clkout = PERIOD "crg_clkout" TSclk25 / 2 HIGH 50%>

WARNING:ConstraintSystem:191 - The TNM 'PRDeth_tx_clk', does not directly or
indirectly drive any flip-flops, latches and/or RAMS and cannot be actively
used by the referencing Period constraint 'TSeth_tx_clk'. If clock manager
blocks are directly or indirectly driven, a new TNM constraint will not be
derived even though the referencing constraint is a PERIOD constraint unless
an output of the clock manager drives flip-flops, latches or RAMs. This TNM
is used in the following user PERIOD specification:
<TIMESPEC "TSeth_tx_clk" = PERIOD "PRDeth_tx_clk" 8.0 ns HIGH 50%;>
[rv901t.ucf(43)]

WARNING:ConstraintSystem:197 - The following specification is invalid because
the referenced TNM constraint was removed:
<TIMESPEC "TSeth_tx_clk" = PERIOD "PRDeth_tx_clk" 8.0 ns HIGH 50%;>
[rv901t.ucf(43)]

WARNING:ConstraintSystem:192 - The TNM 'TIGeth_tx_clk', does not directly or
indirectly drive any flip-flops, latches and/or RAMS and cannot be actively
used by the referencing TIg constraint ''. If clock manager blocks are
directly or indirectly driven, a new TNM constraint will not be derived since
the none of the referencing constraints are a PERIOD constraint. This TNM is
used in the following user groups and/or specifications:
<TIMESPEC "TSsys_clkTOeth_tx_clk" = FROM "TIGsys_clk" TO "TIGeth_tx_clk"
TIG;> [rv901t.ucf(55)]
<TIMESPEC "TSeth_rx_clkTOeth_tx_clk" = FROM "TIGeth_rx_clk" TO
"TIGeth_tx_clk" TIG;> [rv901t.ucf(67)]
<TIMESPEC "TSeth_tx_clkTOsys_clk" = FROM "TIGeth_tx_clk" TO "TIGsys_clk"
TIG;> [rv901t.ucf(73)]
<TIMESPEC "TSeth_tx_clkTOeth_rx_clk" = FROM "TIGeth_tx_clk" TO
"TIGeth_rx_clk" TIG;> [rv901t.ucf(79)]

WARNING:ConstraintSystem:197 - The following specification is invalid because
the referenced TNM constraint was removed:
<TIMESPEC "TSsys_clkTOeth_tx_clk" = FROM "TIGsys_clk" TO "TIGeth_tx_clk"
TIG;> [rv901t.ucf(55)]

WARNING:ConstraintSystem:197 - The following specification is invalid because
the referenced TNM constraint was removed:
<TIMESPEC "TSeth_rx_clkTOeth_tx_clk" = FROM "TIGeth_rx_clk" TO
"TIGeth_tx_clk" TIG;> [rv901t.ucf(67)]

WARNING:ConstraintSystem:197 - The following specification is invalid because
the referenced TNM constraint was removed:
<TIMESPEC "TSeth_tx_clkTOsys_clk" = FROM "TIGeth_tx_clk" TO "TIGsys_clk"
TIG;> [rv901t.ucf(73)]

WARNING:ConstraintSystem:197 - The following specification is invalid because
the referenced TNM constraint was removed:
<TIMESPEC "TSeth_tx_clkTOeth_rx_clk" = FROM "TIGeth_tx_clk" TO
"TIGeth_rx_clk" TIG;> [rv901t.ucf(79)]

WARNING:NgdBuild:1345 - The constraint <TIMESPEC "TSeth_rx_clk" = PERIOD
"PRDeth_rx_clk" 8.0 ns HIGH 50%;> [rv901t.ucf(38)] is overridden by the
constraint <TIMESPEC "TSeth_rx_clk" = PERIOD "PRDeth_rx_clk" 8.0 ns HIGH
50%;> [rv901t.ucf(84)]. The overriden constraint usually comes from the input
netlist or ncf files. Please set XIL_NGDBUILD_CONSTR_OVERRIDE_ERROR to
promote this message to an error.
WARNING:NgdBuild:1345 - The constraint <TIMESPEC "TSsys_clkTOeth_rx_clk" = FROM
"TIGsys_clk" TO "TIGeth_rx_clk" TIG;> [rv901t.ucf(49)] is overridden by the
constraint <TIMESPEC "TSsys_clkTOeth_rx_clk" = FROM "TIGsys_clk" TO
"TIGeth_rx_clk" TIG;> [rv901t.ucf(90)]. The overriden constraint usually
comes from the input netlist or ncf files. Please set
XIL_NGDBUILD_CONSTR_OVERRIDE_ERROR to promote this message to an error.
WARNING:NgdBuild:1345 - The constraint <TIMESPEC "TSeth_rx_clkTOsys_clk" = FROM
"TIGeth_rx_clk" TO "TIGsys_clk" TIG;> [rv901t.ucf(61)] is overridden by the
constraint <TIMESPEC "TSeth_rx_clkTOsys_clk" = FROM "TIGeth_rx_clk" TO
"TIGsys_clk" TIG;> [rv901t.ucf(96)]. The overriden constraint usually comes
from the input netlist or ncf files. Please set
XIL_NGDBUILD_CONSTR_OVERRIDE_ERROR to promote this message to an error.
Done...

Checking expanded design ...

Partition Implementation Status

No Partitions were found in this design.

NGDBUILD Design Results Summary:
Number of errors: 5
Number of warnings: 30

Total memory usage is 439320 kilobytes

Total REAL time to NGDBUILD completion: 4 sec
Total CPU time to NGDBUILD completion: 4 sec

One or more errors were found during NGDBUILD. No NGD file will be written.

Writing NGDBUILD log file "rv901t.bld"...

Requirement for encoder.<n>.reset (HAL_BIT)

Is your feature request related to a problem? Please describe.
Limitation rather than a problem. I'm working onto a system that requires resetting the counts of an encoder. Since the count pin isn't writable, there isn't a way to reset or zero the encoder.

Describe the solution you'd like
Addition of < board-name >.encoder.< n >.reset (HAL_BIT). I've seen the pin is already there, however it does not work. Would be nice to eventually have the pin functional.

Describe alternatives you've considered
None at this time. If the encoder is moved, the counts are permanent through the lcnc session. Only way for a reset/zeroing at this moment is to restart Litecnc and Linuxcnc. Not ideal considering, but that obviously works.

Additional context
I'm happy to examine the code base and compile a custom a version with the encoder.reset functional if you could point me in the correct direction and highlight the implication(s) (if any) of doing so.

Linuxcnc installation: Run In Place vs Nn Run In Place: Litex 11-add-external-extensions-to-litexcnc

Debian Bookworm linuxcnc 2.9, installed via package manager.

When loading litexcnc the module is trying to load the extra modules from /usr/rtlib , which is fine I think for a RIP install.

For a version of Linuxcnc installed via packages the extra modules needed to be loaded from /usr/lib/linuxcnc/modules/ (which is where the build process copies them to)

It would appear litexcnc's halcompile.py is defining EMC2_RTLIB_DIR from the first instance of rtlib it finds Makefile.modinc, from what I can gather from reading the code.

I've used this hack (litexcnc.c at top of file) to get the behavior I want for a non RIP install of linuxcnc. Is there a way of checking if the installation is RIP or non RIP ?

//hack for building when not a RIP
#ifdef EMC2_RTLIB_DIR
#undef EMC2_RTLIB_DIR
#endif

#define EMC2_RTLIB_DIR "/usr/lib/linuxcnc/modules"

LinuxCNC crashes on exit when component `litexcnc_eth` is used

Describe the bug
As noted in #28 , LinuxCNC crashes with the following error:

Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
task: 603 cycles, min=0.000041, max=0.012258, avg=0.009716, 0 latency excursions (> 10x expected cycle time of 0.010000s)
mb2hal quit_signal DEBUG: signal [15] received
mb2hal quit_cleanup DEBUG: started
mb2hal quit_cleanup DEBUG: unloading HAL module [16] ret[0]
mb2hal quit_cleanup DEBUG: done OK
mb2hal main OK: going to exit!
litexcnc: LitexCNC etherbone driver unloaded 
rtapi_app: caught signal 11 - dumping core
free(): invalid pointer
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
Waited 3 seconds for master.  giving up.
Note: Using POSIX realtime
motmod: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
Note: Using POSIX realtime
trivkins: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
<commandline>:0: unloadrt failed
Note: Using POSIX realtime

To Reproduce
This error is due to an old loadrt statement in your hal-files. You have now:

loadrt litexcnc
loadrt litexcnc_eth connection_string="192.168.178.15

Above statements have been replaced with:

loadrt litexcnc connection_string="eth:192.168.178.150"

Expected behavior
An error message that the component litexcnc_eth does not exist (as it cannot be used as stand-alone).

Additional context
Why this error emerges at this moment? It is because the FPGA is reset to its safe state when LinuxCNC is unloaded. This means that litexcnc will send a last message to the FPGA. When the FPGA is loaded using two separate statements, the etherbone driver is already unloaded (and memory thus freed up). Thus writing to a closed device, without allocated memory leads to a core dump.

PATH not set on LinuxCNC RPi4 image after installing LitexCNC

Following the documentation for installing LitexCNC / LinuxCNC on a RaspberryPi4 using the image from linuxcnc.org/downloads does not work.

Problems:

LitexCNC is not persisted on PATH
therefore the toolchain is also not on PATH, thus building fails.

Proposed solution
Modify the documentation so the PATH variable is persisted. In later stage modify source code so the relevant files are correctly written.

Caveat
The user uba100 on forum.linuxcnc.org has tried to fix this problem. He changed the PATH variable

export PATH=$PATH:~/.local/bin/:~/toolchain/oss-cad-suite/libexec/

And got the following message:

INFO:SoC:
yosys: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory

This shared file is located within oss-cad-suite, so he changed the LD_LIBRARY_PATH to include this folder:

export LD_LIBRARY_PATH=~/toolchain/oss-cad-suite/lib/:$LD_LIBRARY_PATH

Which now results in receiving the following messages:

/home/cnc/.local/bin/python3: /home/cnc/toolchain/oss-cad-suite/lib/libm.so.6: version `GLIBC_2.35' not found (required by /home/cnc/.local/bin/python3)
/home/cnc/.local/bin/python3: /home/cnc/toolchain/oss-cad-suite/lib/libc.so.6: version `GLIBC_2.33' not found (required by /home/cnc/.local/bin/python3)
/home/cnc/.local/bin/python3: /home/cnc/toolchain/oss-cad-suite/lib/libc.so.6: version `GLIBC_2.32' not found (required by /home/cnc/.local/bin/python3)
/home/cnc/.local/bin/python3: /home/cnc/toolchain/oss-cad-suite/lib/libc.so.6: version `GLIBC_2.34' not found (required by /home/cnc/.local/bin/python3)

This most likely indicates a broken installation. Changing LD_LIBRARY_PATH is most-likely not the correct way to get the installation up-and-running.

pip3 install gives error 404

Describe the bug
the command pip3 install --extra-index-url https://test.pypi.org/simple/ litexcnc[cli] gives the folowing error:

Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple, https://test.pypi.org/simple/
Collecting litexcnc[cli]
Could not install packages due to an EnvironmentError: 404 Client Error: Not Found for url: https://pypi.org/simple/litexcnc/

To Reproduce
pip3 install --extra-index-url https://test.pypi.org/simple/ litexcnc[cli] and enter ;)

Expected behavior
Installation of LitexCNC

LinuxCNC:

OS: on Raspberry Pi4

lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Version 2.8.4

Additional context

install_driver error

I installed litexcnc additional extensions branch with poetry.
when I do 'poetry run litexcnc install_driver' it throws errors when compiling litexcnc.c

$ poetry run litexcnc install_driver
INFO: Retrieving default driver files to compile...
Copying file 'watchdog.c'
Copying file 'wallclock.c'
Copying file 'litexcnc.c'
Copying file 'litexcnc_encoder.c'
Copying file 'litexcnc_stepgen.c'
Copying file 'litexcnc_gpio.c'
Copying file 'litexcnc_pwm.c'
Copying file 'pos2vel.c'
Copying file 'etherbone.c'
Copying file 'litexcnc_eth.c'
Copying file 'litexcnc.h'
Copying file 'wallclock.h'
Copying file 'watchdog.h'
Copying file 'litexcnc_encoder.h'
Copying file 'litexcnc_stepgen.h'
Copying file 'litexcnc_pwm.h'
Copying file 'litexcnc_gpio.h'
Copying file 'pos2vel.h'
Copying file 'etherbone.h'
Copying file 'litexcnc_eth.h'
INFO: Compiling LitexCNC driver...
Compiling realtime litexcnc.c
litexcnc.c: In function ‘litexcnc_register’:
litexcnc.c:512:1: warning: label ‘fail0’ defined but not used [-Wunused-label]
512 | fail0:
| ^~~~~
litexcnc.c: In function ‘register_module’:
litexcnc.c:539:22: error: ‘LINELEN’ undeclared (first use in this function)
539 | char module_path[LINELEN+1];
| ^~~~~~~
litexcnc.c:539:22: note: each undeclared identifier is reported only once for each function it appears in
litexcnc.c:548:10: warning: unused variable ‘register_name’ [-Wunused-variable]
548 | char register_name[LINELEN+1];
| ^~~~~~~~~~~~~
litexcnc.c:539:10: warning: unused variable ‘module_path’ [-Wunused-variable]
539 | char module_path[LINELEN+1];
| ^~~~~~~~~~~
litexcnc.c: In function ‘register_driver’:
litexcnc.c:574:22: error: ‘LINELEN’ undeclared (first use in this function)
574 | char driver_path[LINELEN+1];
| ^~~~~~~
litexcnc.c:583:10: warning: unused variable ‘register_name’ [-Wunused-variable]
583 | char register_name[LINELEN+1];
| ^~~~~~~~~~~~~
litexcnc.c:574:10: warning: unused variable ‘driver_path’ [-Wunused-variable]
574 | char driver_path[LINELEN+1];
| ^~~~~~~~~~~
make: *** [/usr/share/linuxcnc/Makefile.modinc:115: litexcnc.o] Fehler 1
Error: Compilation of the driver failed.

is it the poetry environment that causes this problem? linking problems?
or is there a missing declaration of LINELEN?

I did a new install in a virtual maschine with Debian 12 and Linuxcnc 2.9

EDIT:
I installed it with

$: git clone https://github.com/Peter-van-Tol/LiteX-CNC.git
$: cd LiteX-CNC
$: git checkout 11-add-external-extensions-to-litexcnc
$: pip3 install ./ litexcnc[cli]

but the error is still there

HUB75HAT Pin-out incorrect

Connector numbering was reversed:

J8 <-> J1
J7 <-> J2
J6 <-> J3
J5 <-> J4

Board does work, alias does work. However, when modifying the board, bad solder joints are difficult to trace, as you will be pointed to the wrong connector.

differential step

Peter, please tell me.
About differential step.
Is it just needed to control servomotors?
I understand correctly?
Thank you.

Install toolchain installs wrong binaries on RPi4

Describe the bug
When using the command litexcnc install_toolchain on a RPi4 (are any other architecture different from X86), the command installs the wrong binaries.

Expected behavior
The binaries are x86, but should be arm.

LinuxCNC

OS: Raspbian Buster (10)
Version LinuxCNC 2.8.4

Workaround
As a temporary workaround one can download the correct binaries at https://github.com/YosysHQ/oss-cad-suite-build/releases/2022-12-07

Solution
Quick-fix: let user select their OS (darwin, linux, or windows) and architecture (arm, arm64, 'x64). Sensible defaults are ``linux with x64.

Compiles, but does not work with LinuxCNC version 2.9

When using the driver on LinuxCNC version 2.9, an error is thrown:

halcmd: loadrt litexcnc
Note: Using POSIX realtime
litexcnc: dlopen: /usr/lib/linuxcnc/modules/litexcnc.so: undefined symbol: json_object_array_length
<stdin>:1: waitpid failed /usr/bin/rtapi_app litexcnc
<stdin>:1: /usr/bin/rtapi_app exited without becoming ready
<stdin>:1: insmod for litexcnc failed, returned -1

It seems that the lib-json is not linked correctly.

pip install does not work on debian 10, works on arch linux?

"pip install --extra-index-url https--test.pypi.org/simple/ litexcnc[cli]" does not work on linuxCNC:
cedric@virt-cnc:~$ sudo -i [sudo] password for cedric: root@virt-cnc:~# useradd -m testuser root@virt-cnc:~# su testuser $ bash --login testuser@virt-cnc:/root$ cd testuser@virt-cnc:~$ git clone https://github.com/Peter-van-Tol/LiteX-CNC.git Cloning into 'LiteX-CNC'... remote: Enumerating objects: 1259, done. remote: Counting objects: 100% (421/421), done. remote: Compressing objects: 100% (168/168), done. remote: Total 1259 (delta 293), reused 313 (delta 230), pack-reused 838 Receiving objects: 100% (1259/1259), 4.03 MiB | 3.66 MiB/s, done. Resolving deltas: 100% (795/795), done. testuser@virt-cnc:~$ cd LiteX-CNC/ testuser@virt-cnc:~/LiteX-CNC$ pip install --extra-index-url https://test.pypi.org/simple/ litexcnc[cli] Looking in indexes: https://pypi.org/simple, https://test.pypi.org/simple/ Collecting litexcnc[cli] Could not install packages due to an EnvironmentError: 404 Client Error: Not Found for url: https://pypi.org/simple/litexcnc/
My versions:
testuser@virt-cnc:~/LiteX-CNC$ pip --version pip 18.1 from /usr/lib/python2.7/dist-packages/pip (python 2.7) testuser@virt-cnc:~/LiteX-CNC$ python --version Python 2.7.16 testuser@virt-cnc:~/LiteX-CNC$ linuxcnc -v LINUXCNC - 2.8.4-1-gb7824717b testuser@virt-cnc:~/LiteX-CNC$ uname -a Linux virt-cnc 4.19.0-21-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.249-2 (2022-06-30) x86_64 GNU/Linux testuser@virt-cnc:~/LiteX-CNC$ cat /etc/issue Debian GNU/Linux 10

starting LinuxCNC fails with new driver

Hi.
I did "git pull" to get the updated files from 11-add-external....

then installed the new drivers "litexcnc install_driver"
rebuild the firmware.

Then LinuxCNC won't start anymore.
linuxcnc-report.txt

when I do halrun and load the driver it has no errors
loadrt litexcnc
loadrt litexcnc_eth connection_string="192.168.178.150"

Do I have to change something in the INI for the new driver version?

Litex-cnc on standalone fpga chip?

Would it be possible to use this firmware on a custom board? Basically it would just be an ecp5 fpga and an rmii phy. I know that the colorlight board has SDRAM, is that necessary, or can the litex SOC just use the internal memory of the fpga?

Default state of output pins

Hello.
I have a relais board attached to my Colorlite 5A-75B.
When I turn on the maschine, the outputs from the colorlite are LOW. So, all the relais are turned on.
And therefore my coolant starts running 😄

Is it possible to set the default output to "HIGH"?

I tried to find a line of code in the "/config/modules/gpio.py" and "/firmware/modules/gpio.py" but I am not that familiar with this 😃

When I start LinuxCNC I use the "invert_output" param to turn the relais off. But it would be nice to set the outputs to HIGH when the FPGA is turned on

Stepgen only working up to 4 steppers

I have compiled and flashed the example V8.0 12/14 on my 5A-75B V8.2 FPGA board with my Raspberry pi4 according to the described instructions. I have a small gantry milling machine with 2 Y-axes and an additional rotary axis (XYYZA).
To test my Linuxcnc configuration, I made a small test setup with 5 stepper motors.
The first 4 stepper motor outputs on the FPGA board
stepgen.00.... j7:0 with j7:1
stepgen.01.... j7:2 with j7:4
stepgen.02.... j7:5 with j7:6
stepgen.03.... j8:0 with j8:1
work perfectly. The home movement also works without any problems.

The last two stepper motor outputs:
stepgen.04.... j8:2 with j8:4
stepgen.05.... j8:5 with j8:6

show a strange behavior. As soon as a movement (e.g. home movement) is initiated,
the connected stepper motor starts to turn in a certain direction and can only be stopped,
the FPGA board is disconnected from the power supply.
The stepper motor continues to rotate even when the Raspberry is no longer connected to the board.
It doesn't matter which axis I assign this output to in Linuxcnc.
The stepper motor connected to these outputs shows this behavior.
Has anyone ever tested a 5A-75B V8.x with more than 4 axes?

Reported from: https://forum.linuxcnc.org/27-driver-boards/50383-litexcnc-firmware-and-driver-for-5a-75b-and-5a-75e?start=40#292792

Add (external) extensions to LitexCNC

LitexCNC should be a flexible eco-system where users can create new modules and add them to the board, without the need of re-releasing LitexCNC.

Pin does not exist

I have LinuxCNC version 2.9 on Debian Bookworm, all (including LiteX-CNC) installed or compilled without warnings or errors.
Today I was try the 5a-75e-hello-gpio.json from examples.
I get:

user@debian:~/temp$ halrun -I test_gpio_blink.hal.
Note: Using POSIX realtime
litexcnc: Loading Litex CNC driver version 1.1.0
litexcnc: loading litexCNC etherbone driver version 0.02
litexcnc: Connecting to board at address: 192.168.0.99:1234.
litexcnc: Setting up modules...
litexcnc: - Watchdog
litexcnc: - Wallclock
litexcnc: - GPIO
litexcnc: - PWM
litexcnc: - Stepgen
litexcnc: - Encoder
litexcnc: Creating read and write buffers...
litexcnc: - Write buffer: 8 bytes)
litexcnc: - Read buffer: 16 bytes)
litexcnc: Exporting functions...
test_gpio_blink.hal:14: Pin 'test_PWM_GPIO.gpio.j1:1.out' does not exist
halcmd:.

I have no idea what happened...

Support SPI

Support SPI for RPi4.

This entails:

Update configuration, so people can choose which connection the want to make;
New SPI-driver. Proposed connection string will be spi:<file-descriptor-path>;
New SPI-bridge for the firmware;

Module: STEPGEN. Timing parameters issue.

Describe the bug
The steplen and dir-hold-time timing are mixed up.

To Reproduce
In the hal config, setting setp xxx.stepgen.00.dir-setup-time 7500 will affect the timing of stepgen.00.steplen, rather than setting up a dir-setup-time of 7500 as it should.

Steps to reproduce the behavior when using LinuxCNC:
The behavior can be observed using an oscilloscope by probing the stepgen step pin output.

Expected behavior
Timing to affect the correct parameter.

Screenshots
Potential suspect at line 374 of:
https://github.com/Peter-van-Tol/LiteX-CNC/blob/main/src/litexcnc/firmware/modules/stepgen.py

372 # - source which stores the value of the counters
373 self.steplen = Signal(10)
374 self.dir_hold_time = Signal(10) <--------
375 self.dir_setup_time = Signal(12)
376 # - counters
377 self.steplen_counter = StepgenCounter(10)
378 self.dir_hold_counter = StepgenCounter(11)
379 self.dir_setup_counter = StepgenCounter(13)

LinuxCNC(please complete the following information):

OS: Debian 12 Bookworm
Linuxcnc Version 2.9.1

Additional context
I've yet tested if the timings of stepspace, dir-hold-time and dir-setup-time. Grateful if you could double-check if the parameters are matched correctly in the code while investigating this issue. Happy to support with traces and debug if required.

Thanks.

Velocity is inverted

With the software from "main" branch, the velocity is inverted and direction is decreased instead of increas

Set stepgen scale to 1000 pulses per millimeter and max working speed to 15 m/min. When the speed is over 6 m/min, say, 10 m/min, direction is inverted and actual speed differs from commanded speed by sign

Buffer overflow

Describe the bug
The communication to the card fails with the following message:

Unexpected read length: -1, expected 88
Unexpected read length: -1, expected 88
Unexpected read length: -1, expected 88
Unexpected read length: -1, expected 88
Unexpected read length: -1, expected 88

The card itself is still responsive, as the card is successfully reset at start up and shut down of LinuxCNC.

Cause
The buffer containing the addresses to be read is partly over-written. The magic byte is erased and therefore the FPGA does not recognize the packet as a read command.

Solution
The culprit in this essence is the clearing the read and write buffers:

    // Clear buffer (except for the header)
    memset(
        litexcnc->fpga->read_buffer + litexcnc->fpga->read_header_size, 
        0, 
        litexcnc->fpga->read_buffer_size
    );

This code will cause a write outside of the buffer, because the offset is not applied to the length.

Correct way is:

    // Clear buffer (except for the header)
    memset(
        litexcnc->fpga->read_buffer + litexcnc->fpga->read_header_size, 
        0, 
        litexcnc->fpga->read_buffer_size - litexcnc->fpga->read_header_size
    );

GPIO does not compile when either all pins are input or output

GPIO does not compile when either all pins are input or output. Gives an error that the minimum width of the MMIO register is 1; trying to create a register with a width of 0.