Hallo! Es geht im eine kleine LED installation an meinem Haus zu Deko zwecken, der Testaufbau steht und die erste Software Version ist fertig. Das ganze soll Farbverläufe und fertige Programme abspielen die LEDs kommen in kleine 5-10cm Plastikkugeln und werden an die Balkone montiert. Dafür möchte ich kleine AVR basierte Module verwenden die über einen Bus angesteuert werden, UART über RS485. Jedes Modul steuert 8 LEDs über SoftPWM und bekommt die PWM-Daten per UART, das geht auch gerade so, Mega16 mit 24 Kanal Soft-PWM, steht fertig ausgebaut neben mir und blinkt ;-) Nun möchte ich mind. 20 Frames pro Sekunde darstellen, wenn jetzt jede LED 3 Byte an Daten benötigt für die Helligkeit (256 Stufen) sind das 24 Bytes pro Frame je Modul + Protokoll overhead (8 x 3). Das macht dann 480 Bytes pro Sekunde (24 x 20) plus overhead je Modul. Mit jedem Modul das später noch drann kommt steigt dann die benötigte Datenmenge pro Sekunde um diesen Wert. (480 x n) Wenn ich also den Bus mit 56000 Baud laufen lasse und ein Baud ein Bit ist in diesem Fall sind das 7000 Byte pro Sekunde (56000/8). Das heisst ich könnte maximal 14 Module an den Bus hängen (7000/480) ohne mit der Framerate runter zu gehen oder die Farbtiefe zu verringern, den Protokoll overhead jetzt mal ignoriert. Oder habe ich da irgendwo nen Fehler drinn? Mfg, Peter
Hallo, kommt nicht hin. 56000 Baud sind rund 5600 Byte/s. Du hast Start- und Stopbit vergessen, also 56000/10. Zumindest, wenn Du eine übliche asyncrone Übertragung benutzt. Gruß aus Berlin Michael
Michael U. schrieb: > 56000 Baud sind rund 5600 Byte/s. Du hast Start- und Stopbit vergessen, > also 56000/10. Zumindest, wenn Du eine übliche asyncrone Übertragung > benutzt. Danke für das Feedback! Daran hatte ich garnicht gedacht... Mhm. das stellt mich jetzt vor ein Problem, erstmal kommen nur 4-6 an den Bus ich wollte dann aber auch mit der Zeit deutlich mehr drann hängen. Deutlich langsamer als 16Mhz kann ich nich werden, der nächst passende Quarz für eine deutlich größere Baudrate ist zu klein mit ~14,5 der nächst größere ist zu groß mit ~18,5 Mhz... Könnte ich einen ATtiny vor jeden ATMega16 setzen der die Kommunikation und das Protokoll behandelt und am Ende nur die Nutzdaten langsamer per Soft-UART an jeden µC weiterleitet... Oder mehrere Stränge aufbauen, am Rechner kann ich ja mehrere USB-UART-RS485 Wandler anschließen. -_- Mfg, Peter
Hallo Peter, wenn der Bus nur die Atmel verbinden soll zwingt dich keiner, die üblichen Baudraten zu benutzen. Mit guten Treibern und ordentlicher Verkabelung könntest du bei 16 MHz auch eine Baudrate von z.B. 100000 nehmen. Das USART-Modul besteht nicht auf 9600 und co.. Falls ein PC mitmischen soll geht es natürlich nicht direkt (obwohl auch PCs krumme Baudraten können) aber mit einem Umsetzer (z.B. MEGA328 mit 2 RS232) ist das auch kein Problem. gruß avr
Eine Sache nicht vergessen: Wenn Du alle Module nacheinander mit neuen Daten beschickst, dann gib es einen Welleneffekt da die LEDs nacheinander auf neue Helligkeiten wechseln.
müssen denn immer alle moduel mit neuen daten versorgt werden? Wenn sich etwas nicht ändern muss es auch nicht neu übertragen werden.
Stimmt, man könnte eine Adressierung verwenden. 1. Jedes Modul individuell ansprechen. 2. Alle Module gleichzeitig ansprechen (identische Daten) = Broadcast. 3. Modulgruppen werwenden: Alle Module einer Gruppen-ID gleichzeitig ansprechen. 4. Eine Liste an Modul-IDs mitschicken = beliebige Module gleichzeitig ansprechen (also eine Erweiterung von 1.)
Danke für die vielen Anregungen! avr schrieb: > Mit guten Treibern und ordentlicher Verkabelung könntest du > bei 16 MHz auch eine Baudrate von z.B. 100000 nehmen. > Das USART-Modul besteht nicht auf 9600 und co.. Hey, danke für den Tip, daran habe ich ja garnicht gedacht das ich mit einem passendem Adapter ja auch "krumme" braudraten fahren kann. Da ich RS485 über eine geschirmte TP Leitung mit Terminierung nutzen möchte sollte das kein Problem geben, denke ich, mit der Verkabelung. Peter (Gast): > Eine Sache nicht vergessen: Wenn Du alle Module nacheinander mit neuen > Daten beschickst, dann gib es einen Welleneffekt da die LEDs > nacheinander auf neue Helligkeiten wechseln. Oh... daran hatte ich garnicht richtig gedacht, ob das wohl groß ins gewicht fällt? Christian H. (netzwanze): > 1. Jedes Modul individuell ansprechen. > 2. Alle Module gleichzeitig ansprechen (identische Daten) = Broadcast. > 4. Eine Liste an Modul-IDs mitschicken = beliebige Module gleichzeitig > ansprechen (also eine Erweiterung von 1.) Ich hatte bisher in der Theorie eine Lösung aus allen 3 Punkten erstellt, aber damit gibt es auch Probleme. Jedes Modul hat eine eigene und es gibt eine Broadcast ID. Ich wollte dann nacheinander, Adressierte Pakete an jedes Modul schicken, also doch quasi ein Broadcast. Jedes Modul sucht sich aus diesem Broadcast dann den Datenblock das ihm gehört und stellt diesen dar. Dabei währe es jetzt möglich auch nur einzelene Module anzusprechen und nur die Daten zu senden die sich geändert haben. STARTSEQUENZ 01_LED1_LED2_LED3_LED4_LED5_LED6_LED7_LED8_NULL 02_LED1_LED2_LED3_LED4_LED5_LED6_LED7_LED8_NULL 04_LED1_LED2_LED3_LED4_LED5_LED6_LED7_LED8_NULL ENDSEQUENZ Gibt es vielleicht fertige Projekte die ähnlich aufgebaut sind wo ich mir mal anschaun kann wie andere das gelöst haben? Mfg, Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.