www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USART stört Software PWM


Autor: Aike T. (biertrinker)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Henning (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Kölling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias Kölling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Aike T. (biertrinker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.