P.Fleury USART-Lib/getc() liefert immer 256

Gast #1728726
Lesenswert?

Hallo,

ich verzweifle langsam daran, ein paar Bytes mit dem USART zu Empfangen.

Ein Atmega32 ist an ein eDIP240-7 angeschlossen, auf dem Display ist ein 
Bargraph, der nach jedem Bewegen seinen neuen Wert in 5 Bytes sendet.
Das erste soll auf 0x1B geprüft werden, dann werden drei verworfen und 
das fünfte ist ein Wert von 0-100. Eine völlig unelegante Lösung, aber 
zurzeit gibt es auf dem Display nur den Bargraph.

Dazu habe ich folgende Sourcecode(auch völlig ineffizient):
1
     
2
for(;;)
3
{
4
        
5
    c = uart_getc();
6
    if ( c & UART_NO_DATA )
7
    {
8
        
9
    }
10
    else
11
    {
12
       if (c==0x1B)
13
       {
14
       c=uart_getc();
15
       c=uart_getc();
16
       c=uart_getc();
17
       c=uart_getc();        
18
            
19
       uart_puts("#YH");
20
       itoa(c,buffer,10);
21
       uart_puts(buffer);            
22
       uart_putc(',');        
23
      }
24
  }
25
}

Das Problem ist, das immer "#YH256," gesendet wird. Eigentlich soll 
statt 256 aber der Wert c vom letzen getc() gesendet werden.
Im übrigen sind alle getc() bis auf das allererste 256, das erste 
funktioniert hingegen und erkennt ggf. das 0x1B.

Danke im Vorraus,
Alex
#1728857
Lesenswert?

Alexander W. schrieb:
> Danke, das war tatsächlich das Problem. Ich glaube ich hätte ewig
> gesucht, obwohl ich eigentlich weiss das das eDIP ziemlich langsam ist.
> Mit einer ms delay läuft es. :-)

AUTSCH!

Die Library ist so ausgelegt, dass uart_getc nicht auf ein Zeichen 
wartet, sondern sofort zurück kommt, wenn kein Zeichen vorhanden ist.
Das macht man doch nicht mit delays!

Wenn du auf ein Zeichen warten willst, dann schreib dir eine Routine, 
basierend auf uart_getc, die genau das macht: Auf ein Zeichen warten
1
char uart_getc_wait()
2
{
3
  unsigned int c;
4

5
  do {
6
    c = uart_getc();
7
  } while( c & UART_NO_DATA );
8

9
  return c;
10
}

und diese Funktion verwendest du jetzt anstelle von uart_getc().
Gast #1729094
Lesenswert?

Moin,

deshalb hab ich ja geschrieben, das der Code "auch völlig ineffizient" 
ist. ;-)

Es ging mir nur darum die Kommunikation mit dem Display hinzukriegen, 
wenn ich das richtige Programm schreibe mach ich das schon noch 
ordentlich.

Gruß,
Alex

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren