Advanced Search

Graphics Feature Status
Canvas: Hardware accelerated
Direct Rendering Display Compositor: Disabled
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
OpenGL: Enabled
Rasterization: Hardware accelerated on all pages
Raw Draw: Disabled
Skia Graphite: Disabled
TreesInViz: Disabled
Video Decode: Software only. Hardware acceleration disabled
Video Encode: Software only. Hardware acceleration disabled
Vulkan: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
WebGPU: Disabled
WebNN: Disabled

Problems Detected
WebGPU has been disabled via blocklist or the command line.
Disabled Features: webgpu
Accelerated video encode has been disabled, either via blocklist, about:flags or the command line.
Disabled Features: video_encode
Accelerated video decode has been disabled, either via blocklist, about:flags or the command line.
Disabled Features: video_decode
Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Expose WebGL's disjoint_timer_query extensions on platforms with site isolation: 808744, 870491
Applied Workarounds: enable_webgl_timer_query_extensions
Some drivers can't recover after OUT_OF_MEM and context lost: 893177
Applied Workarounds: exit_on_context_lost
Avoid waiting on a egl fence before swapping buffers and rely on implicit sync on Broadcom GPUs: 938286
Applied Workarounds: rely_on_implicit_sync_for_swap_buffers
Disable GL_MESA_framebuffer_flip_y for desktop GL: 964010
Applied Workarounds: disable(GL_MESA_framebuffer_flip_y)

• 3 × Leadshine EL8 EtherCAT servo drives
• 2 × 400W Leadshine motors with optical encoders and battery backup
• 1 × 400W Leadshine motor with motor brake, also with optical encoder and battery backup
• 1 × Beckhoff EK1100 EtherCAT coupler
• 1 × Raspberry Pi 5 for control

1. Successfully installed LinuxCNC on the Raspberry Pi 5
2. Updated to the latest version
3. Installed CIA402 using Rodw’s guide
4. Configured the Pi as an EtherCAT master

1. .ini

   – Loads the user interface and references the

   .hal

   file

2. .hal

   – The Hardware Abstraction Layer, which defines machine characteristics and connects components

3. .xml

   – Extracts and defines information from the servo drives

•     Raspberry Pi 4
•     LinuxCNC version: 2.9.4 (same behavior also observed in 2.9.3 and 2.8.4)
•     OS: Official LinuxCNC 2.9.4 Raspberry Pi 4 Bookworm image
•     FPGA: ICE40UP5K-SG48I (IceShield)
•     Clock source: Since gpio is not available on Bookworm, I use pigpiod to generate a 5 MHz clock on GPIO 4:
       

  #!/bin/bash sudo pigpiod pigs hc 4 5000000

    I also modified spiflash.sh to work with pigpiod under Bookworm

• The Verilog design (rio.v) is written to return the SPI response header "data" (0x64617461)
• The FPGA’s LED is blinking and SPI data is returned via external tools. This suggests the FPGA is operating correctly with the supplied clock.

import spidev
import time

SPI_BUS = 0
SPI_DEVICE = 0
SPI_SPEED_HZ = 25000  # 25 kHz

spi = spidev.SpiDev()
spi.open(SPI_BUS, SPI_DEVICE)
spi.max_speed_hz = SPI_SPEED_HZ
spi.mode = 0b00

try:
    print("Sending dummy byte 0x00 to read response...")
    result = spi.xfer2([0x00] * 8)
    print("Received:", " ".join(f"0x{b:02X}" for b in result))
finally:
    spi.close()

• In the rio_readwrite() function, logging shows the SPI response always begins with "0:02" (0x30 0x3A 0x30 0x32)
• However, the LinuxCNC log reports "WRONG DATA" with the string "HXHP" (0x48 0x58 0x48 0x50)
• I did not find any logic in the Verilog code that would return "HXHP"
• I suspect that "HXHP" is generated internally by LinuxCNC when an unrecognized or malformed header is received

• SPI communication appears to be working, and the FPGA is returning a response
• However, there may be a mismatch between the header format LinuxCNC expects and what the FPGA sends
• LinuxCNC may be replacing the unrecognized header with "HXHP" as a default or fallback

• Where in the LinuxCNC source is "HXHP" generated or substituted? Is this a fallback response?
• Is the "0:02" sequence a standard header sent by LinuxCNC under the RIO configuration?
• What header or message structure (e.g. MSGID) is LinuxCNC expecting from the FPGA?
• Are there documented or example SPI response formats compatible with riocomp?