This is not just DMA fire and forget, the trick here as I understand it is he's interleaving (dummy?) transfers using the hardware PWM. This has the effect of pacing the individual DMA transfers from the buffer out to the pins at a reliable rate. So, the queue has a reliable timebase, which is independent of the CPU, with future timestamps for banging the pins at that future time.
Doing this he was able to get the following performance numbers, with each frame being a pin flip (I think), while doing a 1mb/sec network transfer to add some contention/load using the same buss. 250k frames per second with max 3us of jitter 500k frames per second with -3us to +30us of jitter. 800k frames per second max, with lots of jitter. Beyond my ability to properly implement this, but probably well within most of yours. He documented it exceptionally well. Please take a look. On Sunday, August 12, 2018 at 10:49:55 PM UTC-4, Daren Schwenke wrote: > > Following the other thread on GPIO made me wonder how stable that approach > was going to be, so I went looking around and came across this: > > https://github.com/Wallacoloo/Raspberry-Pi-DMA-Example/blob/master/dma-gpio.c > > Having DMA handle the GPIO writes removes the CPU from the equation, and > his approach of interleaving writes to PWM to provide control of the data > transfer rate looks promising, to my under-informed self anyway. > I think I recall this being discussed before.. Did anyone ever go further > with this? > > Would it be feasible to feed that from Machinekit? Reliable high data > rate GPIO on the PI could result. > > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
