GRBL port

[Anathae]

If I had time, I would love to port GRBL to this hardware.
Use the RP2040 for the ui and motion planning, and the FPGA for the motion control. There might even be enough bandwidth/pins to add DVI output and kb/mouse.

[josuah]

This is a very good idea!
There is also a Discord server where live chat can happen if you like. But this is a very good place to talk about it here already...

In which language are you interested in?
The pico-sdk permits to program in C/C++.
MicroPython (upstream project) / CircuitPython (Adafruit extensions) allow to write firmware in Python.

Finally, the pico-ice-sdk (doc) is an extra library for the picco-sdk with coverage for most hardware, like the SRAM chipo, FPGA programming, and USB configuration via TinyUSB.

[josuah]

I also happen to have all parts for building a RepRapPro Huxley, waiting that I am getting some time to look into it...

[Anathae]

GRBL is already written in a C++ variant, so it would be easiest to port the GRBL code to the RP2040 in that manner. As there is already a HAL for LinuxCNC for the Mesa 7I96 that uses the Xilinx Spartan6 FPGA, and the newer 7I96S uses a different but equally capable FPGA from Trion, it may be possible to generate a VHDL for the motion control based on one of those two firm wares.

As for language I am interested in, I consider myself fluent in functional programming languages, and I have been known to code in machine/assembler for fun. For timing dependent applications I have an old programmer style preference for a compiled over an interpreted language. I can see an argument that the motion planner side of the CNC control problem not being timing dependent, but you may be able to implement more advanced motion planning in C++ with out starving the motion control side of the problem.

The RP2040 is an advance and fast processor, compared to the 8bit ST-Micro chip that was first used in the Arduino, but it is still slow compared to even a 10 year old lenovo running a 2.8 GHz Pentium chip.

[josuah]

even a 10 year old lenovo running a 2.8 GHz Pentium chip
Definitely not the same kind of performance than a high-frequency (but also high-power usage) 2.8GHz CPU (as opposed to MCU).

I am often fooled in thinking that some code running very fast on a laptop is taking minutes on an MCU (like JPEG encoding).

preference for a compiled

I am taking note that it is useful to keep the pico-ice-sdk libraries up to date in addition to the upcoming MicroPython port.
This was planned already...

for the Mesa 7I96 that uses the Xilinx Spartan6 FPGA, and the newer 7I96S uses a different but equally capable FPGA from Trion

Interesting, I did not know these chips, and there might be motion control cores that can be reused indeed!

[Anathae]

even a 10 year old lenovo running a 2.8 GHz Pentium chip

Definitely not the same kind of performance than a high-frequency (but also high-power usage) 2.8GHz CPU (as opposed to MCU).

I am often fooled in thinking that some code running very fast on a laptop is taking minutes on an MCU (like JPEG encoding).

There pretty much has to be on an order of magnitude difference between the RP2040 ARM M0+ running at 125 MHz and the Intel Pentium G3220T running at 2.6 GHz (I must have miss remembered the processor). Having said that, an order of magnitude difference between running a routine that takes a second to complete, is the same routine completing in 10 seconds. These differences are useful to us because they are intended to serve two completely different markets.

preference for a compiled

I am taking note that it is useful to keep the pico-ice-sdk libraries up to date in addition to the upcoming MicroPython port. This was planned already...

for the Mesa 7I96 that uses the Xilinx Spartan6 FPGA, and the newer 7I96S uses a different but equally capable FPGA from Trion

Interesting, I did not know these chips, and there might be motion control cores that can be reused indeed!

Hopefully I become employed soon and can spend some hobby time with your very interesting board, both from the hardware and software side.

[josuah]

These differences are useful to us because they are intended to serve two completely different markets.

I am impressed by the diversity in all the different microcontrollers, maybe because there is as much diversity of situations.

your very interesting board, both from the hardware and software side

I am standing on the shoulders of giants...

[josuah]

It looks like there is a successor planned for GRBL, a rewrite of the project:
https://github.com/gnea/gnea

It does not appear to be taking-off, and grblHAL seems like some larger effort for it:
gnea/gnea#4

And here we go with an existing RP2040 driver to get started from!
https://github.com/grblHAL/RP2040

[Anathae]

Excellent.