OK so yes, seeing your code would help us understand what you're bottleneck but I've a pretty good idea why you're LCD matrix refresh is so slow. It has to do with userspace communicating with kernel space, and you're either invoking some system API calls ( which are notoriously slow ), or you're copying data from userspace to kernel space, which again is slow.
The reason I said to show us some code above however is that I think it *should* be possible to use /dev/mem/ + mmap() to access whatever you're controlling. Using mmap() in this manner gives you no userspace to kernel overheard . . . but again I need to see some relevant code to give you a better idea how that might work. On Sun, Mar 20, 2016 at 8:58 PM, William Hermans <[email protected]> wrote: > Show us some code. > > On Sun, Mar 20, 2016 at 6:28 PM, David Good <[email protected]> wrote: > >> Hi All, >> >> I've been experimenting with embedded linux and matrixed LED displays. I >> started on a Raspberry pi user space program, but could see visual >> artifacts on the display due to inconsistent timing of my sleep command. >> So, I figured that moving the basic row scanning into the kernel would help >> out. After failing to get the right kernel headers for the pi, I switched >> to a BeagleBone White. I've now got a working character device LKM which >> takes new images by writing ASCII formatted hex strings to the device in >> /dev. The performance is pretty good, but not great. I still see visible >> artifacts, but am playing with things. >> >> My basic question is this: I know that Linux is not a RTOS, so timing >> will never be guaranteed, yet linux does a lot of things very quickly >> (video, audio, i2c, etc). My driver is bit-banging a spi like stream over >> 8 rows at a rate of ~3ms per row (333Hz row scanning or ~41Hz per complete >> frame) and is really struggling. How does linux usually get large smooth >> video at over 60FPS while doing other things??? Is it simply taking >> advantage of special hardware resources? >> >> The obvious solution for this display is to use a little 8051 or M0 >> microcontroller (or PRU!) and let the Bone feed it over uart or something, >> but I really thought I could do better with the LKM. >> >> Am I just doing something totally wrong? Any other ideas? >> >> Thanks! >> >> --David >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
