RGB LED Steuerung (AVR)

Vielen Dank.
Habe den Code so erweitert:

1

        char r[3];

2

        char g[3];

3

        char b[3];

4

        r[2]='\0';

5

        b[2]='\0';

6

        g[2]='\0';

Bringt aber leider nichts. Die Led blitzt weiterhin nur kurz auf :(

Gruss,   Tymm

Stackoverflow?

MW

@Michael Wilhelm wo?

Du meinst in den Registern OCR1A, OCR1B und OCR2?
strtol liefert long int zurück.
Ich weiss jetzt nicht ob das ein Problem ist und wenn ja wie man es 
löst.

Gruss,   Tymm

@OP:
Werd' mal das '#include "uart.c"' los, das macht man nicht! (die 
.c-Dateien werden im Makefile/im AVR-Studio-Projekt eingetragen).

Bist du sicher, dass dein string vom PC mit "\n"-endet (Unter Windows 
wäre das eher "\r\n") ? (Als ersten Ansatz, mach mal "char Line[7]" zu 
"char Line[10]").

hth. Jörg
ps. Deine Timereinstellungen hab ich mir noch garnicht angeschaut

@Jörg X. :
Ich benutze ausschließlich Linux. Von daher kein AVR Studio und Strings 
die ganz sicher mit \n enden (echo "FFFFFF" > /dev/ttyUSB0).
Danke für den Tipp mit den Makefiles.

Aber wieso Line[10]? Ich habe doch nur 7 Zeichen: "FFFFFF" (6 Zeichen) 
und ein "\0" (1 Zeichen).

Gruss,   Tymm

>Ich benutze ausschließlich Linux.
hättest du evtl. andeuten können ...

Aber wie schon _Stefan Ernst (sternst)_ schrieb:
>> Überprüfe mal deine Timer-Konfiguration.
Die muss nämlich so (bzw. so ähnlich) aussehen:

1

  // Timer1 init 

2

  TCCR1A = (1<<WGM10)|(1<<COM1A1)|(1<<COM1B1);

3

  TCCR1B = (1<<CS10);

4

5

  // Timer2 init for PWM on Pin PB3 

6

7

  TCCR2 = (1<<WGM20) |(1<< CS20)|(1<<COM21);

Du brauchst zwar für eine LED nicht unbedingt drei Hardware 
PWM-Einheiten, aber das kannst du ja später noch ändern ;)

rtfm, Jörg

>> Überprüfe mal deine Timer-Konfiguration.
Danke, das eine |(1<<CS10) war zuviel.
Allerdings funktioniert PWM auch mit dem |(1<<CS10) zuviel.

Am PWM liegt es leider nicht...

Die serielle Kommunikation funktioniert, allerdings nicht wirklich gut 
wie ich gerade festgestellt habe.

Komischerweise kommen bei einem 'echo -n "Hallo" > /dev/ttyUSB0' die 
"Hallo"s häufiger vollständig zurück als bei einem 'echo "Hallo" > 
/dev/ttyUSB0'.
(echo -n gibt kein \n am Ende aus, echo ohne option schon)
In einem Terminal gibt es auch häufiger Aussetzer.

Am Atmega8 hängt ein 8Mhz Quarz und die Fuse Bits habe ich bei Low auf 
0xEE und bei High auf 0xD9.

Trotzdem glaube ich dass es nicht am UART liegt, weil irgendwann ja 
immer mal was ganz durchkommt.
In einem anderen Programm steuere ich die Led mit einzelnen Buchstaben 
('R' = Rot wird heller, 'r' = Rot wird dunkler usw.) und das 
funktioniert tadellos.

Langsam verzweifel ich...

Es geht!

Es gab zwei Probleme:
1. Das Problem mit dem kurzen Aufleuchten habe ich gelöst indem ich 
bevor ich die empfangenen Daten verarbeite, abfrage ob es sich um 
hexadezimal Ziffern handelt (UART_NO_DATA funktionierte bei mir nicht).

2. Nachdem ich hinter das uart_gets per Zufall ein paar Befehle 
geschrieben hatte, wurde das UART aufeinmal stabiler.
Ich habe jetzt ein paar delays hinter dem uart_gets und vor der 
Verarbeitung der ankommenden Daten und es geht.

Ein Problem bleibt aber:
Wenn ich sehr schnell viele Farbcodes an den Atmega schicke, wird das 
UART anscheinend wieder instabiler und falsche Farben werden erzeugt.

Im Anhang befindet sich der funktionierende Code + Python Programm zur 
Ansteuerung.

Gruss,   Tymm

>Du bremmst deinen AVR TIERISCH aus, der muss nach jedem empfangenen
>String 5s! warten, ehe er wieder was machen darf. Da läuft garantiert
>ein Empfangsbuffer über. Solche delays sind totaler Mist.

Ein _delay_ms(1000) sind bei mir lange keine Sekunde, was wohl an 
falschen Einstellungen meinerseits liegt.
Kann auch sein das delays totaler Mist sind.
Ich bin Anfänger, ich habe keine Ahnung.
Ich weiss nur, dass ohne delays oder irgendetwas anderes was Zeit in 
Anspruch nimmt garnichts geht.

>Und das wundert dich?
Trotz der Gefahr noch ein "AUA!" zu kassieren und der Tatsache dass mein 
AVR keine 5s wartet: Mich wundert es schon ein bisschen.
Ich dachte Peter Fleury's UART Lib arbeitet mit Interrupts.
Und wenn ich das richtig verstanden habe, unterbrechen Interrupts das 
Hauptprogramm?

Gruss,   Tymm

>Ein _delay_ms(1000) sind bei mir lange keine Sekunde
Ja, dann ist was mit der Taktfrequenz-Angabe faul.


Aus dem Programm:

1

/* define CPU frequency in Mhz here if not defined in Makefile */

2

#ifndef F_CPU

3

#define F_CPU 8000000L

4

#endif

trifft die erste Zeile zu?

1

if( (Line[0] == '0') | (Line[0] == '1') | (Line[0] == '2') | (Line[0] == '3') | (Line[0] == '4') | (Line[0] == '5') | (Line[0] == '6') | (Line[0] == '7') | (Line[0] == '8') | (Line[0] == '9') | (Line[0] == 'A') | (Line[0] == 'B') | (Line[0] == 'C') | (Line[0] == 'D') | (Line[0] == 'E') | (Line[0] == 'F'))

2

    {...

könnte auch so beschrieben werden:

1

if( (Line[0] >= '0' && Line[0] <= '9') || (Line[0] >= 'A' && (Line[0] <= 'F') )

2

    {...

Dir ist schon klar, dass du mit

1

uart_gets(Line, sizeof(Line));

auch nur mal halbe Zeilen abholen könntest?

Die Funktion holt ab, was gerade im Puffer ist. Da wird nicht bis zum 
CR/LF gewartet. Und du machst keinerlei Plausibilitätsprüfungen, ob 
überhaupt ein ganzer String für deine Line[] gekommen ist.

Kein Wunder, dass längeres Warten dir da etwas hilft.

Ja, da scheint mir die Implementierung von uart_gets() die möglichen 
Rückgabewerte von uart_getc() noch nicht richtig abzufangen:

Returns:
    lower byte: received byte from ringbuffer
    higher byte: last receive status
    * 0 successfully received data from UART
    * UART_NO_DATA
      no receive data available
    * UART_BUFFER_OVERFLOW
      Receive ringbuffer overflow. We are not reading the receive buffer
      fast enough, one or more received character have been dropped
    * UART_OVERRUN_ERROR
      Overrun condition by UART. A character already present in the
      UART UDR register was not read by the interrupt handler before
      the next character arrived, one or more received characters have
      been dropped.
    * UART_FRAME_ERROR
      Framing Error by UART

Aus:
http://homepage.hispeed.ch/peterfleury/group__pfleury__uart.html