How to make parallel ?

[K0rkunc]

i want to make parallel how to make that ?

and can i work compute module ?

[daveythacher]

I was curious so I looked, but this is a total guess.

Client configuration:

network-rgb-matrix-display/client/examples/direct-draw-on-buffer.ini

Lines 41 to 43 in 007c79f

	number_segments = 1 ; How many segments is the screen broken into? (this is ignored)
	segment_width = 256 ; Width of each segment
	segment_height = 64 ; Height of each segment

Server configuration:

network-rgb-matrix-display/server/rgb-server.ini

Line 34 in 007c79f

parallel = 1

Compute module is supported by the underlying Pi RGB matrix. However this requires a newer version (change) than what is used here. You would need to compile with this uncommented:
https://github.com/hzeller/rpi-rgb-led-matrix/blob/63e3e7ffdbe88223cc80e1faa508bc4f3cf2bea4/lib/Makefile#L138

Note it recommended to use large number of parallel chain but not long chains unless impossible. Increasing the number of pixels per Pi will require faster Pi. Too much CPU and memory bandwidth required. See this.

However increasing the number of chains will increase quality and/or refresh against for the same number of pixels. Processing power and memory bandwidth is mostly due to pixel count. While IO bandwidth is mostly per pixel in chain, which divides size, color depth and refresh. At least for standard shift register LED drivers without PWM or MM.

These LED drivers roughly cap the number of pixels against IO. Which sets a cap on memory and processing needs against IO. The Pi is only capable of certain accelerations and there are complications which further increase this depending on application. However custom logic is possible at fairly low cost for this. Its a trade off.

In theory the servers could be replaced by receiver cards for low cost and better quality. However these require more effort in setup and configuration. Its not too bad if you know a little bit about the panels and there is a helpful application for most of them. Even still some of the setting's meaning is not fully known, but can be experimented with. (A logic analyzer would probably be helpful if you cared enough.)

The Pi library only supports certain panel types. Mostly low density modules, which means you would likely be forced into receiver card for higher density panels using PWM and MM LED drivers. ColorLight 5A-75B has decent support for this and can be integrated with Linux. (I have done this personally.)

[K0rkunc]

Merak edip baktım ama bu tamamen bir tahmin.

İstemci yapılandırması:

network-rgb-matrix-display/client/examples/direct-draw-on-buffer.ini

Lines 41 to 43 in 007c79f

	number_segments = 1 ; How many segments is the screen broken into? (this is ignored)
	segment_width = 256 ; Width of each segment
	segment_height = 64 ; Height of each segment

Sunucu yapılandırması:

network-rgb-matrix-display/server/rgb-server.ini

Line 34 in 007c79f

parallel = 1

Hesaplama modülü, temel alınan Pi RGB matrisi tarafından desteklenir. Ancak bu, burada kullanılandan daha yeni bir sürüm ( değişim ) gerektirir . Bu yorumsuz olarak derlemeniz gerekir:
https://github.com/hzeller/rpi-rgb-led-matrix/blob/63e3e7ffdbe88223cc80e1faa508bc4f3cf2bea4/lib/Makefile#L138

Çok sayıda paralel zincir kullanılması tavsiye edilir, ancak imkansız olmadıkça uzun zincirler kullanılmaz. Pi başına piksel sayısını artırmak, daha hızlı Pi gerektirecektir. Çok fazla CPU ve bellek bant genişliği gerekli. Bunu gör .

Bununla birlikte, zincir sayısını artırmak, aynı sayıda piksel için kaliteyi ve/veya yenilemeyi artıracaktır. İşlem gücü ve bellek bant genişliği çoğunlukla piksel sayısından kaynaklanır. IO bant genişliği çoğunlukla boyut, renk derinliği ve yenilemeyi ayıran zincirdeki piksel başınadır. En azından PWM veya MM'siz standart shift register LED sürücüleri için.

Bu LED sürücüleri, IO'ya karşı kabaca piksel sayısını sınırlar. Bu, IO'ya karşı bellek ve işleme gereksinimlerine bir sınır koyar. Pi sadece belirli hızlanmalar yapabilir ve uygulamaya bağlı olarak bunu daha da artıran komplikasyonlar vardır. Ancak bunun için oldukça düşük bir maliyetle özel mantık mümkündür. Onun bir takası.

Teorik olarak sunucular, düşük maliyet ve daha iyi kalite için alıcı kartları ile değiştirilebilir. Ancak bunlar kurulum ve konfigürasyonda daha fazla çaba gerektirir. Paneller hakkında biraz bilginiz varsa ve çoğu için faydalı bir uygulama varsa, bu çok da kötü değil. Hatta ayarın bazı anlamı hala tam olarak bilinmemekle birlikte denenebilir. (Yeterince önemsiyorsanız, bir mantık analizörü muhtemelen yardımcı olacaktır.)

Pi kitaplığı yalnızca belirli panel türlerini destekler. Çoğunlukla düşük yoğunluklu modüller, yani PWM ve MM LED sürücülerini kullanan daha yüksek yoğunluklu paneller için muhtemelen alıcı kartına zorlanacaksınız. ColorLight 5A-75B bunun için yeterli desteğe sahiptir ve Linux ile entegre edilebilir. (Bunu kişisel olarak yaptım.)

Colorlight solution can u share me ?

[daveythacher]

Check my public repos.

[daveythacher]

I have no clue if this works or not yet. I am still trying to figure out how to start the client. However I was able to the server to fire up with logic that should talk to my daemon. Note this works off C++ logic that I have not yet tested.

The daemon is believed to be in working order. However the C++ wrapper interface for talking to the daemon is untested. This wrapper was used in the port.

Note the port is not very high quality. I did not create pull request for this reason. If there is interest in it, I can create a pull request. This should enable communication to the ColorLight modules. Note you will need to customize the configurations. I modified the server configuration to match the repos Colorlight configurations.

Currently there is a decent amount of configuration points, which is less than ideal.

[jaygarcia]

Hi @daveythacher !! Nice to see you here dude!!

@K0rkunc ,

To achieve what you're looking to do, you will likely need to think about how you logically want to lay out the buffer on the server node, and then for account for that in modifying how it slices up that buffer and sends it over to the child/slave nodes.

The logic for both server and client only account for the current configuration. You can see it in action here: https://www.youtube.com/watch?v=tZuQKhhq8zI