Das liegt an deinem Algorithmus, wie du die Module ansteuerst.
So wie ich das sehe, wird das alles nacheinander ausgegeben. Bedingt durch die Code-Laufzeit dauert das eben.

Um das zu verbessern kannst du die Codelaufzeit verbessern, indem du z.B. den Code effektiver schreibst, sofern möglich, oder zeitkritisches in Assember schreiben.


Deine gesamte Ausgabe ist in der Timer-ISR untergebracht. Diese braucht vermutlich viel Code-Laufzeit.
Die Timer-Wiederholrate zu erhöhen ergibt nur eine höhere Refresh-Frequenz. Beschleunigt aber nicht die Ausgabe.

Zwei Dinge können helfen.
Darüber nachdenken, wie man die Ausgabe, also den Ausgabe-Algorithmus, effektiver machen kann, auch in Punkto gleichzeitige Ausgabe.
Der 2. Punkt ist die Laufzeit zu reduzieren, z.B. mit Assembler.

Beides ist natürlich auch davon abhängig, was du schlussendlich darstellen willst.
Für eine Bilder-Sequenz alá Trickfilm wirst du um Assembler nicht herum kommen.

Da dies hier ein deutsches Forum ist, habe ich hier auch auf deutsch geantwortet. Du kannst ja auch den Übersetzer nutzen.
Ein englisches Forum findest du z.B. unter mcselec.com

Möglicherweise!

Was man dafür wissen muss, wie diese Module angesteuert werden und wie du diese miteinander verschaltet hast.
Datenblatt und Schaltplan wäre nützlich.

Und was du genau ausgeben möchtest und wie oft.
Nur Textausgabe?
Was genau willst du erreichen?

Das Funktionsprinzip von deinem Code ist auch nicht so wirklich erkennbar.
Vielleicht findest du hier auch ein paar erklärende Worte.

Ich sehe hier jetzt nur, dass du die Module kaskadiert hast.
Aber wie sie angesteuert werden ist mir unklar. Hast du da ein Datenblatt?

Zudem hatte ich gefragt, in welche Richtung das optimiert werden soll.
Wird nur Text ausgegeben oder Bilder?
Und die Frage der gleichzeitigen Ausgabe steht noch im Raum.

Wenn du Fragen nur unzureichend beantwortest, kann ich nicht weiter helfen.

Ich weiß im Moment nicht mal welche Pins an dem Modul wie anzusteuern sind.

Ich weiß nur, dass dies seriell passiert über den Clock.

Mir ist auch unklar, was es mit den Pins Line A bis Lines E auf sich hat.

Bei den Pins R1 und R2 kann ich mir vorstellen, dass die für Rot stehen mit den Bitwertigkeiten. Also 2 Bit je Farbe.

Beim verzweifelten Versuch, deinen Kommentarlosen Code zu verstehen, sehe ich aber, dass du umständlich Bitbänging in dem Shift-Out machst.
Ich vermute, du drehst dir den Font da irgend wie so zurecht, dass das auf die Matrix passt.

Da geht natürlich viel Zeit verloren.

Besser wäre, den Font gleich so zu machen, dass er für die Matrix direkt zu verwenden ist.

Ein Layout nützt mir da nichts, um den Code zu optimieren. Ich brauche etwas um die Funktion der RGB-Matrix zu verstehen.

Was das gleichzeitige Anzeigen angeht, würde ich so vorgehen (wenn du das nicht schon machst:
Die ausgabedaten, so wie sie in die Matrix zu schieben ist, im RAM 1:1 vorzubereiten.
Dann das ganze RAM in die Matrix takten und mit Latch 1x übernehmen. Damit sollte die Änderung auf einen schlag sichtbar werden.

Das Bild kommt sofort, wenn du es vorher aufbauen lässt:
Zeile 19 Stop Timer0 (gestartet wurde er schon bei der Config timer0....)
Zeile 79 Gosub Clear_Memory (ist unnötig, da der beim Neustart immer leer ist.)
Zeile 91 Start timer0 (denn hier ist das Bild fertig)

Die Bildausgabe benötigt 93% Cpu, da bleibt nicht viel Zeit Text in den Speicher zu schreiben. Wie groß darf die Timer0reload werden ohne das das Bild flackert. (Kinder fragen)

Doch, weil er die Bildberechung stark ausbremst. Es an zu zeigen benötigt ca 20 ms. Wird es vorher aufgebaut (ohne Timer)braucht das auch nur 250ms und keine 5 Sekunden (Video)
Sollen später schnelle Bildwechsel erforderlich sein wird ein zweite Bildspeicher gebraucht. Er zeigt solange das alte bis das neue fertig ist, dann sieht niemand den Aufbau
Das sind die kleinsten Timer0reload? Was sind die größten? Je größer desto mehr Zeit hat die Cpu ein Bild auf zu bauen/ ums schneller ist das neue fertig.

Wie werden sie eingesetzt? Laufschrift? Wiederholend oder endlos? Verschiedene Zusammenstellungen?

Mit 2 "spielt " er aber bei 12 ist seine "Lastgrenze" fast erreicht. Der Ausgabecode ist schon ziemlich schnell. Der lässt sich nur noch wenig (ca 10%) beschleunigen. Da bringt ein größerer Timer0reload mehr.
Das Video war mit 48(?) und brauchte 5 Sekunden. Mit Timer0reload 56 braucht es 2 Sekunden?

Statische Bilder oder Text könnten vorher berechnet werden und könnten dann schnell in den Bildspeicher geschrieben werden. Leider hat er nicht genug ram für einen zweiten Bildspeicher. Wie kommen die da rein (Usart?, Spi?) Oder werden sie mit gebrannt? Dann könnten fertig bearbeitet in den Flash. Superschnell, aber für jede Konstellation müssen sie extra vorbereitet werden. Wenn er sie selber umrechnen muß braucht er mehr Speicher. Spi Ram?

Wie schnell muß es werden?
Hier eine gepimte Display_refresh:
Die sollte auch mit Timer0reload 48 ca 2Sekunden brauchen. Im besten Fall bekomme ich noch eine Verdopplung hin, aber dann wäre es immer noch eine Sekunde.
Ps Das 'Brightness = 255' habe ich raus genommen, das steht besser vor/in der Main oder im Clear_memory. Dieses ließ sich besser beschleunigen ( ca 6x)


An der 'Txt_6_8' habe ich noch nichts geändert, da ich keine Chance habe das zu testen, zumal die ja auch für alle Konstellationen arbeiten muß.
Wird für den Ticker auch Font_6x8 genutzt? Geht der immer nur bis "F" ? Werden Font genutzt die weiter gehen als bis 127?

Wenn man die Methodik ändert, kann man noch was rausholen.
Wenn man, um ein flackerfreies Bild zu erhalten, 50 Hz für ein Vollbild ansetzt, und bei jedem Interrupt immer nur eine ScannLine der 16 ausgibt, benötigt man eine Interrupt-Frequenz von 16*15Hz = 800 Hz.

Wenn man nun den Bildspeicher so verwendet, dass die Ausgaberoutine (Interrupt) nur noch die Daten vom SRAM 1:1 in die Schieberegister schieben muss. geht es deutlich schneller.

In einem Byte (Buffer für Matrix) sind dann 2 Pixel gespeichert, nämlich die RGB1 und RGB2 Werte für Matrix-Zeile z.b. 0 und 16, oder Zeile 1 und 17 usw.
Die Pixel z.B. von einem Font-Zeichen müssen hier dann nicht während der Ausgabe jedesmal gedreht werden. Das spart Zeit.

Um ein Panel von 64x32 Pixel anzusteuern, benötigt man einen Buffer von 64x32 / 2 = 1024 Byte. Dividiert durch 2 weil man in einem Byte ja 2 Pixel speichert. 2 Bit werden verschenkt.

Will man ein Zeichen auf der Matrix darstellen, muss man das Zeichen nur einmal umrechnen und in den Bildspeicher (Buffer für Matrix) schreiben.

Ich habe die Ausgabe-Routinen mal gecodet und im Simulator den Durchlauf einer Scannline mit 64 Pixel ermittelt, also für ein 64x32 Panel. Es waren ca. 900 Takte je Scanline. Da der Interrupt 800x je Sekunde aufgerufen wird, sind das 900x800 = 720000 Takte je Sekunde. Bei 16MHz Takt also 720000 / 16000000 = 0,045 = 4,5 % CPU-Auslastung. Wenn man die 12 Panels kaskadiert, ergibt das eine Auslastung von weniger als 12x 4,5% = 54% CPU-Auslastung. Das liegt am Overhead durch den ISR-Aufruf.

Es bleiben also mindestens ca. 46% CPU-Leistung für den Rest übrig, also um den Speicher zu beschreiben. Da die Datenbytes im Buffer quasi Pixel-Orientiert sind, lassen sich auch pixelweise Bildverschiebungen realisieren. Der Controller könnte hier aber noch übertaktet werden, was dann auch noch etwas bringen würde.

Zwei Nachteile hat diese Methode allerdings auch.
Es ist komplizierter, ein Ascii-Zeichen so im Buffer abzulegen, welches dann auch korrekt auf der Matrix angezeigt wird, und man verschenkt 1 Bit Speicher je Pixel.
Allerdings muss man nur einmal den Buchstabe richtig in den SRAM schreiben, im Gegensatz zur bisherigen Lösung, wo er bei jeder Ausgabe umgerechnet wird.

Die Speicher-Verschwendung kann man auch eliminieren, indem man 4 Module Parallel ansteuert. So würden dann anstelle von 6 Bit je 2 Matrix-Pixel, x4 = 24 Bit für 8 Pixel parallel ergeben, was schön in drei Byte passt. Speicher wäre ausgenutzt. Das ganze müsste folglich aus einer Anzahl von Einzel-Panelen bestehen, die ein Vielfaches von 4 sind.

Wie man es dreht und wendet, bleibt immer die Berechnung der zu setzenden Pixel im Buffer, je nachdem, wie die Module verschaltet sind.
Aber das ist auch nur Mathematik, wenn die Panel-Verschaltung klar definiert ist.

Noch ein paar Tips zur Verbesserung der Performance.

• Die Werte für RGB1 und RGB2 1:1 an einem Port ausgeben, ohne vorheriges Bitbanging, weil die Pins anders beschaltet sind.
  
• Die Werte für Scanline (Pins A, B, C, D) auch in eine sinnvolle Reihenfolge bringen und auf einen Port legen, damit auch hier ein Bitbangig entfallen kann.
  
• Zugriffe auf Ports wie PortH, die außerhalb des IO-Bereichs von 0-63 bzw. hex bis $3F sind (siehe Register), benötigen mehr Takte, weil sie nicht mit IN oder OUT angesprochen werden können.
  

Ich habe in meinem Code diese Dinge berücksichtigt.
Allerdings fehlen da noch Routinen, zur Ausgabe von Punken oder Zeichen. Da ich kein Matrix-Modul zur Hand habe und die Buffer-Beschreibung von der Kaskadierung und Anordnung der Panels abhängt, habe ich darauf verzichtet.

Für eine Ausgabe also erst mal statisch in den Buffer was reinschreiben.

Der Code ist ungetestet, da kein Panel verfügbar.

Ach und es ist ein Projekt aus 3 Dateien.
Also in Bascom im Menü Datei > Project > Open auswählen und die Datei "Matrix_64x32.prj" auswählen.
Es wird dann alles geladen.

Die Pinbelegung ist anders als bei Raimond!

Dank daran, dass im Code eine andere Pinbelegung vorliegt!