SBC mode on non-pi's

dc42

NeoPixel control and on_the_fly post-processing are two good arguments for SBC use.

All Duet 3 main boards can control Neopixels.

o_lampe

@dc42
RRF can do basic stuff with NeoPixels, but i've seen 'animations' with colour fading and other beautiful stuff. (campfire or ocean waves)
That's beyond RRFs capability AFAIK. It's overkill for simple 3D printers, but nice to have for sandtables and such.

Mentaluproar

How do I determine the transferreadypin on a lepotato?

chrishamm

@Mentaluproar According to https://docs.google.com/spreadsheets/d/1U3z0Gb8HUEfCIMkvqzmhMpJfzRqjPXq7mFLC-hvbKlE/edit#gid=0 it should be gpiochip1, number 79.

deckingman

@Mentaluproar said in SBC mode on non-pi's:

@achrn You're the guy behind Sisyphus? ...............

Sisyphus was so cool.

For info, the original Sisyphus machine was invented by a guy called Bruce Shapiro. I've seen one of his machines at Questacon in Canberra, Australia which was installed in 2013 but there are others around the world.

Also for info, Sisyphus (or Sisyphos) was a king of Corinth in Greek mythology, who was condemned by Zeus to spend all eternity rolling a boulder up a hill in Hades. Hence the name given to the machines.

Mentaluproar

@chrishamm I'm getting an operation failed error. Failed to open IO device. Error 19. Cannot put line into event mode. I applied the settings you gave me. Seems there's something still amiss here.

chrishamm

@Mentaluproar You probably need to remove the pin from the sysfs interface first by running echo 480 > /sys/class/gpio/unexport as root.

Mentaluproar

@chrishamm said in SBC mode on non-pi's:

echo 480 > /sys/class/gpio/unexport

bash: echo: write error: Invalid argument

My understanding is this has been depreciated so it might not work properly.

Mentaluproar

@chrishamm on the bottom it says the first 10 pins are on gpiochip0. I switched it in DWC config but it just gave an error 22 this time, so I guess this isn't helping either.

Falcounet

@Mentaluproar What does gpioinfo returns ? If you are lucky enough, the device tree is correctly documented and the pin number will be displayed

Nurgelrot

Working with anything other than a PI make sure you install the gpiod package. This gives you the gpioinfo utility that will list out all the pins whatever chipset you using has access to. And if you are super lucky the maker of your SBC will have them documented mapping to the the PI's heaader. Hardkernel is pretty good about this with the Odroid line of SBC but others vary.

As for the usefulness with current RRF. I'm on the fence. Some things about the way the pi works I like and others just make it more wiring... The one biggest feature I've stumbled onto is leaving the pi on leaves DWC up. This lets me power the main board on and off from a tasmota and the btncmd plugin. Also software updates are easier esp if you want to bounce between stable and unstable... That's about it so far.

Nurgelrot

I just spent 2 day trying to get Le Potato working with RRF - with both the standard Duet3 boards as well as some STM32F4's.

No Dice. The issue isn't the TranferReadyPin thats pretty easy to find and use. Line 79 on /dev/gpiochip1. The real issues is the lack of OS images with working SPI overlays. I was able to get it loaded into the kernel with the Raspian image off the Libre Computers site and their wiringTools package. But was unable to get DuetControlServer to talk over it.

So I give up if anyone else gets it working drop me a note I'd love to know what I was doing wrong.

Falcounet

@Nurgelrot WiringPi uses the sysfs interface. You want to use spidev.

Nurgelrot

@Falcounet yep I got /dev/spidev0.0 /dev/spidev0.1 to show up an got them merged into the current kernel passed in the bufsiz on the grub line options to the kernel cuz the modprobe.d method doesn't work. Just would not talk. Error 19. Maybe I'll get curious in few days and go for another round with it.