Aktueller Inhalt von sHINE

Ja, das hab ich schon begriffen, aber trotzdem ne super Erklärung, hehe... Ich meinte damit, dass ich die Daten des RS232-AVR im selben Moment einlesen muss, also wie Du schon sagtest, mit dem selben Taktsignal...Die Daten, die ich ans Display rausrotze brauche ich ja am Ende nicht mehr, die...

Heißt also, dass ich die Daten in der Mux-Routine auch wieder empfangen muss. Und mein RS232-AVR dabei als SPI-Slave fungiert. Den Code hat Sebastian schon optimiert, mehr ist da wohl ohne Assembler nicht drin. Leider kann ich das nicht. Hat nur für Basic gereicht, hehe... Der Atmel läuft...

Moin! Nachdem ich jetzt noch mehr Displays (192x96) dran hab, kann ich das über RS232 eh vergessen. Meine Idee ist jetzt, einen weiteren AVR einzusetzen, der die Daten per RS232 empfängt und dann per SPI an meinen "Display"-AVR schiebt, der den Inhalt wiederum direkt in die LEDBuffer schreibt...

Dein Code mit dem UART-Interrupt funzt überhaupt nicht :)

Also kann 115.200 eigentlich auch schon nicht funzen?!

Habe ja schon mit verschiedenen Blockgrößen experimentiert, siehe #35 und #39. Wenn ich mehrere Blöcke schicke, muss ich natürlich auch die entsprechende Array-Position vorher ausrechnen. Alles in allem bringt es nix, daher habe ich die Blöcke so gross wie möglich gemacht, um so wenig wie...

Moin! Werd' ich mal ausprobieren. btw. Habe mal die Anzahl der Displays erhöht, fahre jetzt 8 anstatt 4, also DisplayWidth ist 1.024 statt 512. Er muss jetzt also statt 64 Bytes 128 Bytes per SPI raushauen. Läuft ebenfalls sauber mit 57.600. Denke, an den SPIOut's kanns irgendwie auch nicht...

Wenn ich die Mux-Routine splitte, schaffe ich wieder 115.200 bps... Mux: TIMER1 = 52267 If ISR_Helper = 0 Then Spiout ledBufferGreen(startIndex + 1) , numberOfModulesPerRow Incr ISR_Helper Else Spiout ledBufferRed(startIndex + 1) , numberOfModulesPerRow...

Moin! Hab jetzt mal alles so umgebaut und auch die Mux-Routine optimiert. Hat allerdings nix gebracht, bei 57.600 ist Schluss. Egal, ob ich den UART mit Interrupt fahre oder nicht (Config SerialIn = Buffered). Es liegt daran, dass die Mux-Routine einfach zuviel Zeit braucht, die Grütze...

Moin Sebastian, ich kann Deinen Einwand nachvollziehen, aber ich möchte einzelne Pixel explizit ansteuern können, z.B. für mein VU-Meter oder auch für's Game-of-Life. Dort wäre der Overhead mit Deiner Variante wieder zu hoch. Ich stimme Dir zu, dass die Anzahl der zu übertragenen Bytes...

Moin Leute, ich fürchte, ich habt's noch nicht verstanden :) Hab jetzt wenig Zeit, aber versuche es mal an einem ganz einfachen Beispiel. Stellt Euch vor, Ihr habt eine 8x8 Matrix, einfarbig, ums einfach zu halten. Die hat 8x8 = 64 LED's. Wenn man den Zustand jeder einzelnen LED speichern bzw...

Ich wieder, ich werd' mich - wohl oder übel - noch mal an die Mux-Routine ranmachen. Da die Displays etwas eigenwillig angesteuert werden wollen, benutze ich im Moment vier SPIOUT's und rechne den entsprechenden ArrayIndex im Timer-Interrupt aus. Das kostet natürlich. Wenn ich die Routine jetzt...

Moin und sorry für den späten Reply, kommt immer wieder was dazwischen :) @HinterBlauenAugen: Mein Code ist jetzt wie in #39 gepostet, der Code in #35 läuft nur bis 57.600 sauber, der in #39 auch mit 115.200. Ich muss gestehen, dass ich mich noch nie mit dem BasCom-Simulator beschäftigt habe...

Hey Werner, den hab ich schon entfernt, vorher kompilierte er ja gar nicht....aber wie schon geschrieben, habe ich bereits bei 57.600 erhebliche Pixelfehler, sodass diese Variante so nicht brauchbar ist. Das beste Ergebnis erziele ich immernoch mit dem "Config SerialIn = Buffered, Size = 255"...

Hi Werner, erster Test leider negativ, selbst mit 57.600 gibt's schon 'Pixelfehler'...werd mal weiter sehen...kann meine Routine zur Auswertung nicht noch optimiert werden? Das Geshifte dauert wohl ziemlich lange. Gruß Jan