search

MarcKarasek / rpi_rgb_ledmatrix-kerneldriver

Controlling one or a chain of 32x32 or 16x32 RGB LED displays using Raspberry Pi GPIO - Kernel Driver and User Applications
GNU General Public License v3.0
1 stars 0 forks source link

Testers needed... #3

Open MarcKarasek opened 7 years ago

MarcKarasek commented 7 years ago

Need some testers to help test the webclient.

New readme.webapp will be avail at the top level with how to compile and run.

MarcKarasek commented 3 years ago

To be honest I have not touched this code in awhile. I was planning on portign this back into the main project sometime this year. Been busy with other things and my display plus pi is in pieces now. Thanks to a fall from the table and a cat...

I will try to get it back up and running in the next week or so.

Will try to answer some of your questions then as well....

Marc

On Sun, Jul 4, 2021 at 6:30 PM David Thacher @.***> wrote:

I may be interesting in trying this out. I have a few questions. The first is my main question.

  1. How does the kernel scheduler play with this? I have noticed stability issues with the kernel on the main, as it works with user space. I have seen this on multicore and single core Pi. apt-get being the most reliable crash test I have so far. I am mostly interested in single core performance.
  2. Do you have FPS counter? I can use this to measure performance and stability.
  3. It looks like you only have support for decoder multiplex panels?
  4. It looks like you assume all pixel and multiplex mappers are applied in user space? It looks like you keep the same DumpToMatrix hook in framebuffer.
  5. How much memory is required for this based on the raw nature of IO transfers? Is there a max size because of this? Is there any performance issues because of this? I can reduce this with imalive?
  6. Why not pass an entire buffer to the kernel module? You have kthread and could do the memory conversion. In theory you could pass the bit array up. The Henner's interface may not work with this. There is a lot of interfaces: memmap, sysfs, ioctrl, syscalls, sockets, file operators, etc.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MarcKarasek/rpi_rgb_ledmatrix-kerneldriver/issues/3#issuecomment-873674823, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD72ZM3GFMK4UAZ4RZ4YYHTTWDOJPANCNFSM4CXTXM5A .

-- /**** Marc Karasek ASM T648 Herder of Cats ****/

daveythacher commented 3 years ago

I did not fully read your logic when I posted this. I also deleted it once I did. I actually experimented with your logic some. From this I wrote a small kernel module of my own, however I never finished it. Mine is a little different. I was not overly sure of ioctl for every IO update. I found another approach which also avoids admin privilege's without copying.

My goal was to see if I could get it to be more stable than user space. I noticed apt-get, cpufreq-info, sync, certain networking, etc. all caused hard dips in refresh. Granted some of these are outside many normal usages. However it can be more stable with the kernel module, but is not completely stable. I know certain configurations and background loads can cause stability issues if you do not account for them. However I did that.

I noticed that user space is actually faster than kernel space, but did not check why exactly. However I was able to get the kernel logic to be as fast as user space. I have a couple theories on it. I also proved that multiple processes driving GPIO is bad. I was able to prove that multicore is somewhat more stable.

I was able to prove an interface between kernel and user space which could be fast. This also enables a memory limit which would open doors that are currently closed off. I eventually realized there would be little kernel logic. It could theoretically support just about anything. Almost everything could be handled in user space.

However I decided to stop as I realized my approach required something that could become unstable within kernel. This would not really work well for library and I was mostly curious about Pi Zero. The Pi Zero in theory could be used as memory mapped controller and this is part of a fixed image.

I figured the only thing really able to potentially create perfect stability was RTLinux patch. This however would cause stability issues with things like audio/TCP potentially. It can reduce performance potentially also. It also requires a kernel build and I was not interested in going that far. I would also have to handle cooperative time sharing, which makes this project a little more annoying.

Given a RT kernel build I would have been able to work around all of that. However those are kind of rare as it turns out. I maybe able to figure it out, but I just decided to stop.

I did not experiment with using PWM hardware, however it should be able to work much of the same. Counters could be installed in kernel for tracking refresh rate and user space for draw rate.

Henner's logic is in need of an overhaul. This could be made to work with it. There is a lot that is possible, but has lot of complexity on configuration. It would be nice if you could create specific OS flavor which is dedicated to LED matrix with pre-built configurations. This would reduce this a lot, but kind of misses the point.

If you consider adding something like memory mapped LED drivers with something like this on Pi Zero the complexity could explode. His CIE1931/BCM implementation is not well understood as is.