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

epineh wrote:

So I can run gw_sh from anywhere, I also edited my .bashrc to make the PATH permanent.
Here is the terminal text, it is still saying it cant see the gowin path, interesting the first line saying XDG_RUNTIME_DIR is not set, I have no idea what that is but it doesn't sound good...

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
loading config: riocore/configs/TangNano9K/config.json
loading board: /home/gus/riocore/./riocore/boards/TangNano9K/board.json
rm -rf rio.fs rio.json rio_pnr.json rio.tcl abc.history impl
gw_sh rio.tcl
make: gw_sh: No such file or directory
make: *** [Makefile:34: impl/pnr/project.fs] Error 127
loading: riocore/configs/TangNano9K/config.json
loading board setup: TangNano9K
loading toolchain gowin
writing gateware to: Output/TangNano9K/Gateware
!!! gateware changed: needs to be build and flash |||
WARNING: can not found toolchain installation in PATH: gowin (gw_sh)
  example: export PATH=$PATH:/opt/gowin/IDE/bin
writing linuxcnc files to: Output/TangNano9K/LinuxCNC
rm -rf rio.fs rio.json rio_pnr.json rio.tcl abc.history impl
gw_sh rio.tcl
make: gw_sh: No such file or directory
make: *** [Makefile:34: impl/pnr/project.fs] Error 127
 

Just checking, I don't mean to offend, but have you tried restarting the computer? Terminals often inherit environment (including path) from processes that spawned them, including login sessions.

You mentioned /home/user/gowin/IDE/bin, does gw_sh actually exist at that exact path? perhaps try  and make sure gw_sh is in there and has the correct permissions for your user to run it. Also, does the user you're running riocore with have access to all directories and files in that path including the parent directories?

I have had issues with gowin running on Ubuntu 24.04, gowin didn't ship the correct versions of one library they compiled against. which OS are you running on?

Ultimately, if you're using a TangNano9k, I recommend the oss-cad-suite instead of gowin. It has been much easier for me to get working reliably across different linux distributions.
 

Could you give me an idea about how spiflash works on the pi4? I see gpio 7 and gpio 25 being used. It seems that gpio 7 is chip select 1 for spi0 (also defined as /dev/spidev0.1).

From what I see, it
- disables gpio7 if it's enabled as a gpio
- unloads and reloads spidev and spi_bcm2835
- enables gpio25, and sets it as an output pin, but does not set the value of it. It seems it needs to be low in order to set chip select 1 active.
- does obvious flashrom work
- unloads the same spi drivers.
- enables gpio7 again
- sets both 7 and 25 to inputs
- sets 7 to a value of 1, but since it's an input, does this also set it as an output again?

Using hardware spi on the pi5, I've found success by allowing the hardware spi to manage the chip select pin automatically.

I am having trouble resetting the iceshield fpga to a running state after flashrom uploads the firmware. Can you describe how the reset works on the iceshield? What pin values I should be seeing with an oscilloscope on gpio25 at each stage of spiflash.sh?

Could you also explain why it unloads and reloads the spi drivers at the start, and unload again at the end? Is the pi4 version of riocore using software spi (bit banging) instead of hardware spi?

puhhh, too many questions
I don't know all that exactly anymore,
can only say that it works like this on the rpi4.

from memory:

* unexport Flash select from gpi, so the SPIdev can use it by it self

* reload SPIDev to get a defined state (i think without that there were errors if linuxcnc was running before)

* then the FPGA must be in RESET mode (25 = 0)

* running flashrom....

* to get a clean state again, the SPIdev is reloaded (I think this also blocks the select lines otherwise)

* Flash select and FPGA reset to input (7 = input / 25 = input), so the FPGA can boot and can operate the flash select itself

* wait a second (FPGA is booting)

* at the end, the flash select is set to 1 again for safety reasons, as the SPI line is to be used for communication with the FPGA (7 = 1)
 

one more thing about the 'pin-modifier', i know it takes some getting used to and the implementation gave me a headache

but it makes the thing enormously flexible and customizable.

list of modifier's: debounce, toggle, invert, onerror, pwm

the modifier's can be set for each input and output pin and also as a pipeline one after the other.

* For example, you can 'dim' an output and either reduce the brightness of an LED or operate a 12V relay with 24V (pwm)

* or set the pwm frequency to 1Hz so that the LED flashes

* suppress interference on inputs with debounce

* or other things that would normally require external hardware components.


i have to admit, i'm a bit proud of the function ;P

meister wrote:

* at the end, the flash select is set to 1 again for safety reasons, as the SPI line is to be used for communication with the FPGA (7 = 1)
 

Thank you, I appreciate your patience with my questions!

This helps a lot for my understanding, and I think it explains the error in my python script. I'll change it to configure chip select at runtime instead of at boot time. My pi5 must be holding the state of 7 at a value I don't want if I want to allow the fpga to be the master for the eeprom spi.

Zayoo wrote:

Only thing hire is missing one good in depth help file!  

Anyone can open a PR with updated documentation!