LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)

then I am at a loss,
if the file 'gw_sh' is callable, a 'make' should work

you can try to remove the first line from the Makefile (if on dev branch):
and try again

@ meister

Understood, but it is not the FPGA itself as it keeps the pins in high Z mode during power up and flashing until the programmed logic takes over.

Another way than just having on all pins the resistors could be just one pull-down resistor on the OE pin of the voltage translaters. It is set high / enabled by one FPGA output pin after the logic has taken over.

that's exactly the problem, the 'high Z mode',
this is not a defined state and is susceptible to malfunctions of all kinds.

at best, you can listen to the radio on the stepper

epineh wrote:

I get the command line console and it quits out with ctrl+d as you say, but I'm still getting the same issue, I had changed the filename to something other than config.json to suit the machine, so I changed it back to config.json but no dice.
 

It might be easier to use the docker container, see the documentation in the git repo. github.com/multigcs/riocore/blob/main/DOCKER.md

Otherwise, gw_sh must be callable in the same terminal session you start the riocore tooling in.

It may be simpler to add the gowin bin path to your system path.
Start a new terminal, and 
if you don't see your gowin bin dir listed somewhere in there, how you're setting the path is not working.

Zayoo wrote:

I'm trying to get the gowin toolchain up and running on rpi5. It gives me an error when execute making all.

Code:

cnc@raspberrypi:~/riocore/Output/TangNano9K_spi_rpi5/Gateware$ make clean rm -rf rio.fs rio.json rio_pnr.json rio.tcl abc.history impl cnc@raspberrypi:~/riocore/Output/TangNano9K_spi_rpi5/Gateware$ make all gw_sh rio.tcl /opt/gowin/IDE/bin/gw_sh: 2: Syntax error: Unterminated quoted string make: *** [Makefile:34: impl/pnr/project.fs] Error 2 cnc@raspberrypi:~/riocore/Output/TangNano9K_spi_rpi5/Gateware$  I see you've already mentioned this error. I downloaded and cloned the dev version and it still doesn't work. Any tips... I see there is another option 'generic_spi'. I will test that on rpi5 too just to get that toolchain working. I don't want to take the TN9 out of the device and program on windows anymore.

 

I found the gowin toolchain a major problem to get running on a few systems like a current LTS release of Ubuntu, so I built a docker container for the oss-cad-suite. Meister added one for the gowin toolchain, and one for oss-cad-suite on the pi. I think the pi one should work fine on the pi5 too.

I was able to flash directly using the oss-cad-suite one with a T9 on a pi4, but it's been a while. At the very least, the Dockerfiles have the details on getting the toolchain working.

Give this a try, it's the oss-cad-suite instead of gowin but it supports the T9 IIRC.
github.com/multigcs/riocore/blob/main/do...ile.debian12-run-rpi
github.com/multigcs/riocore/blob/main/DOCKER.md

Thanks Chris, I will try with oss-cad-suite later, i have other issues that bothering me now .

I can't enable that onerror modifier.
It currently looks like this:
And this give me pin 68 on as soon as the power arrives to TN9. I can off/on this pin later through halshow rio.estop.bit. Togle ESTOP or ENABLE or exit LinuxCNC don't change state of this bit!

I noticed that if we close LinuxCNC while the spindle, flood or any other output is enabled, they stay on even LinuxCNC is off. I would like to implement some safety to machine. Easiest way is just to put relay which is on pin 69 in series with machine estop. When I exit linuxcnc or togle estop on LinuxCNC machine will off. How to implement that?

meister wrote:

Many thanks Zayoo !

i have add the code to the dev branch for testing.

if you want to use it, you can add

Code:

"rpi5": true, to your json config like this: [code]{ "name": "IceShield", "description": "RIO-IceShield on Raspberry PI5", "boardcfg": "IceShield", "protocol": "SPI", "rpi5": true, ....

[/code]

I have tested it on dev. It works good with 2 changes:
I needed to set my spi speed at 1mhz due to my clock speed (I think), instead of 1.5mhz. I think we may need a way to configure this, as well as which spi dev to use. If we can configure which spi dev to use, it would be easier to use this on other systems as well. But for the main branch, I think we just need to support setting the spi speed.

Also, in toolchain.py, {cmd_cp} and {cmd_rm} were not evaluating correctly: I was able to make it work by changing the make by hand to cp -v. Probably not related to the rpi5 changes.

spiflash.sh doesn't work for an iceshield board, but that's to be expected I think. I'll look into that a little later. It's about not being able to set the board into reset mode via gpio25 I think, so flashrom can't read the rom size. I think there's an rpi4/5 compatible python gpio library out there, I'll see about writing a simple python helper for that instead of hitting the dev tree directly.

@meister Here is a python version of spiflash.sh that works on either the rpi4 or rpi5, except the resetting the target afterwards isn't quite working.

github.com/digiexchris/6x11-sg-grinder-l...reconfig/spiflash.py

Unloading and reloading the spi modules on the pi5 image doesn't bring /dev/spidev0,0 device back again on the pi5, so I removed that, and am just power cycling the board to reset the fpga after flashing (sudo halt, wait for it to stop, power cycle). Also it's not possible to manually toggle the state of gpio 7, becaues it's controlled by the spidev0,1 automatically. Is that why you unload and load the spi modules again on the 4, to allow you to manually control the flash chip select pin? It seems that the only thing needed for flashrom to work is just pulling the reset pin low. Not sure how to reset afterwards though. I wonder if I need to set active-low instead, and set it high to reset?

I think on a new version of the board I'm going to put a reset button to interrupt the power to the board in order to manually reset it, and perhaps put a dip switch to set it into flash mode.

And this give me pin 68 on as soon as the power arrives to TN9. I can off/on this pin later through halshow rio.estop.bit. Togle ESTOP or ENABLE or exit LinuxCNC don't change state of this bit!

on_error causes the pin to remain at 0 as long as there is an error
the pin only goes to one if there is no error and the pin in the hal has also been set to one.

subsequent 'invert-modifiers' invert the signal subsequently

ok it's a bit confusing, i'll think about building special plugins for frequently used functions



 

Also, in toolchain.py, {cmd_cp} and {cmd_rm} were not evaluating correctly:

fixed in dev branch, thanks