Replies: 2 comments 5 replies
-
hello @vortigont One small note to your referencing the PxMatrix library.
But this is true only for panels with a single row mux pattern - i.e., indoor panels where a scan is one half of the height - for example 64x32, scan 1/16.
but this (pattern 2)
if we state the last as the norm and will reconstruct internal program buffer according to it - the geometric transformation for indoor panels will become much easier. |
Beta Was this translation helpful? Give feedback.
-
Hi @vortigont,
It is quote from PxMatrix library, each digit is represents 8 pixels, so four digits 0-1-2-3 are represents single row of leds, because most of outdoor panels has 32x16 dimensions.
Yes, you can see similar classes in my library. If you really interesting, please email me directly to bort707h@gmail.com, because is quite hard to discuss complicated thing out of native lenguage ^) |
Beta Was this translation helpful? Give feedback.
-
Let's make it a new discussion here, @mrfaptastic.
So I've checked the reference - muxpattern is just a way to handle panels with indirect address lines and scan types, right?
for ex:
So how to deal with that? My idea is both options are a question of coordinates transformation like we have in a VirtualDisp class. And it would be best to keep DMA buffers size match to the physical length of resulting shift registers. All overlaying transformations should take place in wrappers, VirtualDisp or something new. We may think of some inherited classes from the base, each one implements some specific mux pattern. The idea is to keep base logic as fast and simple as possible, so as no to mess with Fast functions which are heavily optimized to shift regs length. We may end up in a two layers of transformation - first is a VirtualDisp and second is muxpattern.
Beta Was this translation helpful? Give feedback.
All reactions