Hallo, ich bastel momentan an einer LED Steuerung für RGB Leds. Dabei sollen insg. ca. 35 µC in einem Ring zusammengeschaltet. Ich will das eigendlich per UART machen, weil ich dachte das das die Systemleistung am wenigsten beeinflusst. Ich habe das progamm was ich dafür verwende mal angehängt. Nun also zum Problem. Sobald ich ein Signal losschicke, flackern die LEDs an den angeschlossenen µCs. Das ist leider nicht so, wie ich mir das gedacht habe. Was kann ich denn dagegen unternehmen? Würde das mit Hardware-PWM besser werden? Ich wollte eigendlich auf Hardware PWM verzichten, damit ich einen möglichst kleinen µC verwenden kann. Ich will pro µC 2 RGB Led's steuern können, also brauche ich 6 PWM Kanäle. viele Grüße Biertrinker
Wenn du so Sachen wie itoa in den Interrupt packst, dann brauchst du dich nicht zu wundern... Die Interruptroutinen so kurz wie möglich halten !
Ich habe das selbe Problem mit einer Software-PWM auf einem Attiny26. Die Routine ist auf einem Atmega8 lauffähig, jedoch beim Tiny glimmen nur die LEDs in einer "sichtbaren" Frequenz. Bin daran echt schon verzweifelt.
Also ich würde einfach die USART in der while loop pollen, dann kann der timer interrupt, für PWM, schön gleichmäßig arbeiten und die auswertung der seriellen daten unterbrechen. Damit läuift dann die PWM emulation flüßig und die USART daten sollten auch kein problem darstellen, den die hat ja eh zwei byte puffer. Mfg. Olaf
Alle, was im receeive interrupt ist in die main loop und im receive interrupt nur einen Puffer füllen und einen Indikator setzen, wenn der Puffer voll ist. Gruß Matthias
arg, da hätte ich ja auch selber drauf kommen können. Naja, Microcontroller sind halt doch ne andere Welt ;-) Gut dann änder ich das mal. vielen dank! werde bescheid sagen obs hilft!
Hm, jetzt habe ich doch wieder probleme. Ich habe die gesamte Funktionallität in die Main-Schleife gelegt und schreiben nurnoch das empfangene Byte in einen Puffer. Der ist allerdings nur ein Byte groß. Dann setze ich einen Indikator, der mitteilt, das ein neues Zeichen empfangen wurde. In der Schleife wird dann gelesen. Ergebnis ist dann, das mir wohl teilweise Bytes verloren gehen. Das Zeigt sich daran, das teilweise die falschen farben ankommen. Nun, dann bleibt mir wohl nur über den Puffer zu vergrößern, aber wie groß sollte der sein, und wie kann ich das koordinieren? viele Grüße Biertrinker
Na ja aus Deinem Code ging nicht eindeutig hervor, wie lang der Datenstrom ist und mit welcher Baudrate Du fährst. Ich habe nur gesehen, dass Du irgendwie prüfst, ob 4 Zeichen oder 8 Zeichen da sind. Kommen wirklich nur diese Zeichen am Stück und dann kommt eine größere Lücke, dann braucht Dein Puffer nur so groß zu sein und dann klappt das auch mit der main loop. Wenn die ununterbrochen mit 115kBaud gesendet werden, dann wirds schon langsam eng. Ich habe Dich aber so verstanden, dass Du Dir das Protokoll für Deine Anwendung selber ausgedacht hast. Dann hast Du in der Gestaltung entsprechende Freiräume. Du könntest die Datenpakete z.B. nur alle 100ms verschicken. Dann kommst Du mit der main loop mehr als locker hin. Du schreibst auch, dass alle Controller per UART verbunden sind. Aber irgendjemand muß die Daten ja einmal vorgeben. Wenn in den Daten nur neue PWM-Werte drin stehen, sind die 100ms zwischen den Paketen mehr als akzeptabel. Ja Microcontroller sind etwas anderes als PCs. Dafür erschließt sich mir nicht, warum objektorientierte Programmierung ala Bjarne Stroustrup die Erstellung eines Programms vehement vereinfacht. Gruß Matthias
Naja, mal sehen, im Moment teste ich noch, ob das alles so passen kann, daher habe ich das Protokoll noch nicht fertig implementiert. Es werden immer 4 byte übertragen, immer ein Steuerbyte und 3 Datenbytes mit den Farbwerten. Jeder µC nimmt sich die ersten 4 Byte weg, den rest schickt er an den nächsten weiter. Bei den 19200 Baud die ich aktuell verwende könnte ich also Theoretisch 16 mal in der Sekunde meine 37 Microcontroller ansteuern. Wobei es ja eigentlich sinnfrei ist vor jedem Datenblock ein Steuerbyte einzubauen. Da ich kaum 148 Byte Puffer einbauen will, könnte ich ja auch z.B. alle 5 Datenblöcke eine kleine Pause machen zum verarbeiten. Egal, wird schon gehen. Habe jetzt auf jeden fall eine Quick&Dirty anpassung gemacht, jetzt klappt das erstmal, sieht aber scheiße aus. Für Heute soll das aber reichen, ich mache das Morgen mal etwas sauber und dann kann ich das nochmal hochladen. Objektorientierung ist eigentlich eine feine Sache, aber es kommt dann doch immer auf den Anwendungszweck an. Programme für Microcontroller können ja schon durch den geringen Speicher kaum so komplex werden. Allerdings ist C++ nicht unbedingt das, was ich unter Arbeitserleichterrung verstehe. ;-) Für reine Anwendungsentwicklung finde ich Java da deutlich schicker. vielen Dank und viele Grüße Biertrinker
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.