UNSOLVED Installing DSF on a Banana-Pi-M3 with Raspbian OS

[JayJay]

@bearer

So i got raspbian to actaully install the DSF package but i now have an error which is evidently linked to the SPI connection not being activated.

As i get the following error

[Fatal] could not connecto to Duet (error 2 cannot open GPIO device file  '/dev/gpiochip0/

I am not a linux user and I am not that good with coding so i really need a idiots step by step guide on what i need to do to enable the SPI

on the banana-pi (even with raspbian) there is NO section in raspi-config to enable the SPI

so im at a loss as to how i go about enabling it and i looked at some of the online guides on how to do this and i became very very lost as it is all greek to me.

i installed RPI.GPIO but how to actually use it and configure things again all greek to me.

is anyone able to advise ?

[JayJay]

Thank you to those that tried to assist.

I am somewhat dissapointed that no-one from the duet team offered any assistance whatsoever.

The only option left is to run the board in standalone mode, i dont want to go with a raspberry pi.

[gloomyandy]

@JayJay said in UNSOLVED Installing DSF on a Banana-Pi-M3 with Raspbian OS:

The only option left is to run the board in standalone mode, i dont want to go with a raspberry pi.

Out of interest why don't you want to use a raspberry pi?

[JayJay]

@gloomyandy said in UNSOLVED Installing DSF on a Banana-Pi-M3 with Raspbian OS:

@JayJay said in UNSOLVED Installing DSF on a Banana-Pi-M3 with Raspbian OS:

The only option left is to run the board in standalone mode, i dont want to go with a raspberry pi.

Out of interest why don't you want to use a raspberry pi?

I feel it's a even worse a proposition than the bannana pi, I have used the raspberry pi for a lot of home automation projects that used raspbain and with that the GPIO thing was never an issue but hardware wise I found the raspberry pi's burned out very quickly, making them less cost effective.

So I was looking for an alternative to the raspberry pi I had high hopes for the bannana pi.

This being my first one it now seems I should just bite the bullet and pay once for the software/hardware to run all my home automation from a central win pc over a network.

From reading the forum many people are having connection issues with the Duet 3 to raspberry pi so I am getting the feeling the whole single board computer interface idea is more than a little half baked.

The lack of support from duet for anything other than a raspberry pi is as i said is dissapointing, and I know the reply to that will be "if you cant work it out on your own you should not be near it" and that too shows the attitude towards its users.

[A Former User]

I'd be hesitant to say the Raspberries burn out quickly as a general statement, certainly doesn't match my experience.

But yes, single board computer interface is half baked and intended for OEMs and enthusiasts to build on. What is your end goal with the Pi, be it raspberry, banana, orange or whatnot?

[A Former User]

This post is deleted!

[chrishamm]

@JayJay Your last attempt looked good but I suspect you have to change the GPIO number for the transfer ready pin in /opt/dsf/conf/config.json (key TransferReadyPin). But because I currently don't have access to my BananaPi I can't tell you to which value.

DSF uses the same GPIO driver like gpiod (i.e. /dev/gpiochip*), so I suggest you run gpioinfo after installing gpiod on your system. That should help you identify which GPIO# has to be set.

You must have a /dev/gpiochip node on your system and adjust the DCS config, else DSF will not be able to communicate with the Duet.

[Falcounet]

I'm trying to do the same thing but using an OrangePi4B SBC (RK3399 SoC)

On this SBC, the pin 22 of the GPIO header is mapped to GPIO0_B5.
This SoC has 5 GPIO controllers.
Each controller controls 32 lines and each line is 32 bits.
So, in order to find the GPIO number of port GPIO0_B5, I have to use this formula : 0 * 32 + 1 * 8 + 5 = 56 (A=0, B=1, C=2, D=3, E=4).
Pin 22 (GPIO0_B5) is GPIO number 56.
GPIO number 56 is also the line 26 of the 2nd GPIO controller /dev/gpiochip1.

I tried to connect a wire from pin 1 (3.3V) to pin 22 and use gpioget gpiochip1 26. I got 0 while not connected and 1 while connected so that's ok.

I also had to change the SPI device because SPI bus 1 is exposed on pins 19, 21, 23 and 24.
Also needed to decrease SpiBufferSize.

I modified /opt/dsf/conf/config.jsonas follows:

"SpiDevice": "/dev/spidev1.0",
"SpiBufferSize": 4096,
"SpiTransferMode": 0,
"SpiFrequency": 8000000,
"SpiConnectTimeout": 500,
"SpiTransferTimeout": 500,
"SpiConnectionTimeout": 4000,
"MaxSpiRetries": 3,
"SpiPollDelay": 25,
"GpioChipDevice": "/dev/gpiochip1",
"TransferReadyPin": 26,

But I still have no luck with communication.
After systemctl restart duetcontrolserver.service, I get the following error in journalctl -xe:

Jan 28 21:45:23 orangepi4 DuetControlServer[2311]: [fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin)
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]: [debug] System.OperationCanceledException: Timeout while waiting for transfer ready pin
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.WaitForTransfer(Boolean inTransfer) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetCo
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/Dat
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/christian/Duet3D/DuetSoftwareFramework/src/Du
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.SPI.DataTransfer.Init() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.
Jan 28 21:45:23 orangepi4 DuetControlServer[2311]:    at DuetControlServer.Program.Main(String[] args) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Program.cs:li
Jan 28 21:45:23 orangepi4 systemd[1]: duetcontrolserver.service: Failed with result 'protocol'.
Jan 28 21:45:23 orangepi4 systemd[1]: Failed to start Duet Control Server.

Not sure what I miss here.

EDIT:
I also tried "TransferReadyPin": 56, just in case ...
But I get the following error :

Jan 28 22:07:48 orangepi4 DuetControlServer[2403]: [fatal] Could not connect to Duet (Error 22. Cannot put line into event mode.)

So I think the TransferReadyPin configuration is correct.

[chrishamm]

Please check out my last post, you must use the gpioinfo utility to find the right GPIO device + number. Decreasing the SPI buffer size is a really bad idea because that requires a custom RRF build, without that the communication may fail unexpectedly whenever large chunks of data are transferred. See here for the right way to configure the SPI buffer size under Linux.

PS: If the line cannot be put into event mode, it's probably already allocated by something else (e.g. the sysfs driver) and gpioinfo will report it as [used]. In that case you must free it before DCS can use it.

[Falcounet]

@chrishamm I don't understand how gpioinfo could help me.
I decreased the SPI buffer size because I had a warning about it but I will check later how to increase that.

Also, I think the line cannot be put in event mode because 56 is an invalid number for gpiochip1. It's only 0 to 31 because it only have 32 lines.

[chrishamm]

@Falcounet gpioinfo lists the available pins for each gpiochip device and the corresponding pin indices as required by DCS and it reports if the corresponding pins are available or blocked (i.e. used). The warning about the SPI buffer size in DCS is there for the same reason I already explained - leaving the default value can lead to unstable SPI connections. The buffer size property in the DCS config is only intended for third-party firmware forks and it should not be modified by Duet users.

[Falcounet]

@chrishamm Well, I'm unable to post the gpioinfo output here (content flagged as spam) but you can see it here

and as I said in my previous post, I saw pin 22 is mapped to gpiochip1 , line 26

[chrishamm]

@Falcounet That looks fine, then I recommend changing the bufsiz module parameter of the spidev module to 8192 as described before and to reset the buffer size in config.json to 8192. Do you get the same error about the transfer ready pin when you start DCS as root (via /opt/dsf/bin/DuetControlServer)? If not, check the permission for gpiochip1. You may have to add the dsf user to the group that owns that node.

[Falcounet]

@chrishamm Same error when starting as root :

root@orangepi4:~# /opt/dsf/bin/DuetControlServer
Duet Control Server v3.2.0
Written by Christian Hammacher for Duet3D
Licensed under the terms of the GNU Public License Version 3

[info] Settings loaded
[info] Environment initialized
[fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin)

But anyway, I already checked the permissions should be ok for user dsf.
I also increased the SPI buffer, thanks for the modprobe hint !

NB: It works when using a raspberry pi (so its ok on the board and cable side).

I think I will use a logic analyzer to check if SPI works well.

[chrishamm]

@Falcounet DCS expects the transfer ready pin to be high when it is started and it's toggled before every following SPI transfer. Perhaps it's worth to check that particular pin first via gpioget once the Duet is powered up and connected. And make sure there is no SD card in the Duet when you start DCS.

[Falcounet]

@chrishamm I'm using the LPC/STM32 fork of RRF on a SKR Pro board.
gpioget gpiochip1 26 returns 0 when I power up the board.

As you said, it should be 1. I will have a closer look again at the wiring.

[Falcounet]

Well, I was mixing pins and GPIO numbers ...

PIN 22 on the GPIO header is related to gpiochip1 line 24 and not 26 !

gpioget gpiochip1 24 returns 1 with the board connected

Now I have another error:
Jan 29 14:22:01 orangepi4 DuetControlServer[2188]: [fatal] Could not connect to Duet (Board is not available (no header))

[Falcounet]

Update : it works with the SPI buffer sets to 4096 but I'm getting no header errors with the buffer set to 8192.
(Nothing changed on this side on the LPC/STM32 port)

There is probably some problem with the SPI driver. I'm going to check this.

[Falcounet]

Well, I don't know what happened with the SPI buffer, maybe some problem with the driver but it worked after resetting it to 8192.

I did all the steps again from scratch to be sure and it works now.

By the way, a documentation is written and may help anyone who want to use DSF on another SBC than a RaspberryPi : https://teamgloomy.github.io/dsf_on_armbian.html

Feel free to share the settings which work on your board to complete the "Known boards settings" section.