0

Adafruit RGB Matrix + Real Time Clock HAT for Raspberry Pi
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

Adafruit RGB Matrix + Real Time Clock HAT for Raspberry Pi

by clubcard on Mon Dec 18, 2017 7:52 am

I have found this nice page with details on LED arrays - http://bikerglen.com/projects/lighting/led-panel-1up/

My question is simple. Is the Pi or Adafruit board acting as a frame buffer so that the LCDs are, in effect, just being sent voltage for a very short period and, like the old phosphor screens, it is persistence that keeps them illuminated (or appear illuminated)? The C++ code has some in-line assembly language and it looks like bit-planes. Is this like VGA so each plane sets a voltage level?

I'm sorry to bother you but I have been looking through this large amount of information looking where the CPUs bandwidth is going. I note that even on a Pi, the OS can get in the way so I'm looking closely at the large number cheap IoT options. I note the new Raspberry Pi 0 has space for a 40-pin connector but isn't populated. If such a cheap system can be nudged into doing a better job (I mean I'm going to strip out the OS so it is me hitting the metal).

Clearly the refresh rate needs to be higher the more colour-depth and it needs to refresh at a multiple of the frame-rate. Considering that Europe, Africa, India, Asia and Australasia use 50Hz DC power while North and South America use 60Hz. Is it possible or likely that having the option to support multiples of the two different frequencies will be beneficial? I do know that certain types of lighting as well as some other audio-visual hardware can cause 'judder' to be perceived. I can remember having to write code on consoles like the NES,SNES,Master System and Megadrive so that whichever the refresh-rate was, the games ran at the same speed.

I do apologize if I have asked damned stupid questions but I'm just someone who wants to be certain that they WILL be able to run eventually even before they have walked. I haven't been slow to reverse-engineer the BBC Micro:Bit so that the 48MHz CPU is available to the user. Each CPU supports DMA so I was considering leaving the 48MHz core as the video-processor, DMAing a double-buffered 'draw list' to the I/O port while the 16MHz CPU creates successive draw-lists. If you recall, on the Atari 2600, the programmer had to write line-data for each row of the screen by writing to a 20-bit register. Am I in the right area i.e. the hardware is very low-level?

With tnanks
clubcard
 
Posts: 31
Joined: Sun Dec 29, 2013 10:28 am

Please be positive and constructive with your questions and comments.