nrzled on rapsberry pi

[nkovacs]

I'm trying to use the experimental nrzled package on a raspberry pi.
The first problem was that this failed because the returned pin is a pinAlias, so you need to get the real pin. I fixed that.
Then it fails with this error:
nrzled: nrzled: bcm283x-gpio (GPIO18): frequency is too high(800kHz).

Apparently the maximum frequency is 200kHz (https://github.com/google/periph/blob/v3.1.0/host/bcm283x/dma.go#L1163). Why? 800kHz is the default in nrzled and is what the led ring needs.

[maruel]

Can you send a CL to fix the first problem? It needs to be fixed anyhow.

The second is a problem with the BCM DMA driver, which is a separate problem. I plan to create the initial support likely on the PCM driver and on the FT232H, because arbitrary DMA on the BCM is tricky. :/

[nkovacs]

I've submitted a pull request for the first issue: #287

I've also tried using 200kHz and changing the hardcoded 200kHz to 800kHz, but in both cases I got an index out of range runtime error.

[nkovacs]

This line is overflowing on 32 bit: https://github.com/google/periph/blob/v3.1.0/host/bcm283x/dma.go#L879
The result is 1152,000,000,000, but the bits slice is just 1152 / 8 bytes long. I think the calculation of l should be d * w.Frequency() / physic.Hertz / time.Second, that yields the correct result of 1152.

[maruel]

Thanks! You're right that the calculation is wrong, albeit it's not about an overflow.

The equation is samples := duration * frequency

Both duration and frequency are fixed points, so it's the fixed point part that needs to be fixed. So yes it should be divided by time.Second.

That said, we don't want to round down, we must round up. That's an important additional bug.

[nkovacs]

So after fixing that (I guess the rounding isn't needed for the test app), the dma transfer hangs and it seems to break something, since if I kill the go app, the python example from https://github.com/jgarff/rpi_ws281x can no longer correctly control the led, and after a while I run out of available dma channels.

I wasn't able to figure out how to reset the channels (except by rebooting the device), and I can't even see which ones are reserved since /sys/module/dma doesn't exist on my version of raspbian.

[maruel]

Let's still fix this calculation to make iterative progress there. Clearly, there's need for more tests and code cleanup.

[nkovacs]

The hang happens in runIO. I commented out ch.startIO and ch.wait so the example app exits, but it still breaks things (the python example doesn't work any more and after a few tries I run out of available channels).

[maruel]

On what distro are you? I normally test on raspbian stretch lite.

[maruel]

(not that I tested the DMA support)

[maruel]

I suspect this was the same issue as #363. We're designing a new API that makes it harder to forget to clean up.