Barcodescanner mit UART auf LCD (C)

Dein Buffer ist nicht terminiert (letztes Zeichen muss ein 0x00 sein).

Patrick Fuchs schrieb:
> if (NODATA && !is_reading)

Du meinst doch sicherlich "stat == NODATA", da NODATA mit 0x01 immer 
wahr ist.

Patrick Fuchs schrieb:
> for (int i = 0; i<33; i++)
>       {
>         buffer[i] = "";
>       }

buffer[i] ist ein char. "" ist ein char*. Das geht so nicht.
Du willst wohl folgendes haben:
buffer[i] = 0x00;

Du machst auch keine Prüfung auf einen Bufferüberlauf.
Was passiert wohl, wenn index plötzlich über die 33 rausläuft?

Wo und wie hast Du den Scanner angeschlossen?
Laut Datenblatt gibt es zwei Modi: Keyboard und Serial.

Das mal so auf die Schnelle.

Wo hast du denn das Scanner-Modul her?

Der Scanner ist laut Datenblatt Serial angeschlossen.

Ich würde mir erst mal das Modul mit einem RS232/USB Umsetzer (oder 
einem MAX232, wenn ich noch eine echte serielle Schnittstelle am PC 
habe) erst mal an den PC hängen und dort in einem Terminalprogramm 
nachsehen ob und was das Scanner-Modul so von sich gibt.

So wie das momentan ist, ist das ein Stochern im Nebel. Du weißt nicht, 
ob das Modul was vernünftiges von sich gibt bzw. du weißt nicht, ob in 
deinem µC alles korrekt gemacht ist. die 1Mhz für F_CPU lassen in mir 
den Verdacht aufkommen, dass der auf internem Oszillator läuft, was ein 
Problem mit der Baudrate bedeuten kann. D.h. auch das würde ich mal 
testen, indem ich den µC etwas ausgeben lasse, was ich mir am PC im 
Terminalprogramm ansehe.

Die x bzw x-quer bzw. Leerezeichen lassen eigentlich nicht auf 'bekannt 
oder nicht bekannt' schliessen (nichts dergleichen steht im Datenblatt 
vom Scanner), sondern die würde ich erst mal als Indiz werten, dass da 
mit der Baudrate was nicht stimmt. Höchst wahrscheinlich ist das Problem 
im µC zu lokalisieren. Gerade deshalb ist es so wichtig, dass man erst 
mal eine Komponente (den Scanner), durch etwas ersetzt, dessen 
funktionieren ausser Zweifel steht (ein PC mit Terminalprogramm) und 
dort mal die UART Verbindung durchtestet.
Es hat sich auf lange Sicht bewährt, wenn man in einem System immer nur 
eine Komponente hat, von der man nicht weiß, ob sie sauber funktioniert. 
Je mehr ungetestete und unbekannte Komponenten man hat, desto 
schwieriger wird die Fehlersuche. Daher führt der schnellste Weg, auch 
wenn es zunächst nicht so aussieht, meistens darüber erst mal alles bis 
auf 1 einzige unbekannte und ungetestete Komponente durch etwas ausser 
Frage stehendes zu ersetzen. Und in den meisten Fällen muss dann eben 
ein PC als 'Lückenbüsser' herhalten. Was in diesem Fall besonders 
einfach geht, da die Kommunikation über UART abläuft und ein PC das aus 
dem Stand kann. Damit kann man Scanner und µC erst mal unabhängig 
voneinander auf korrekte Funktion testen UND hat auch noch den Vorteil, 
dass man im Terminalprogramm sogar sieht, was sich auf der Schnittstelle 
abspielt.

Scanner gekauft bei http://www.szhcct.com/en/gyhz.asp

Wäre ein externer Oszillator für den IC eine Möglichkeit?
In PuTTy bekam ich bereits eine ca. 12 Byte lange (Ergebnisse liegen 
zuhause) Hex-Schlange.
Es muss also entweder an der falschen Konversion --> Display liegen oder 
an - wie von kbuchegg bereits erwähnt - der falschen Baudrate. Wie 
kann ich die Baudrate überprüfen bzw. richtig stellen? Oder ist der 
interne Oszillator einfach zu ungenau?

Danke vielmals für die hilfreichen Antworten!

Liebe Grüße,
Patrick

Patrick Fuchs schrieb:


> In PuTTy bekam ich bereits eine ca. 12 Byte lange (Ergebnisse liegen
> zuhause) Hex-Schlange.

Das ergibt keinen Sinn.
Das Gescannte vom Barcode kommt ziemlich sicher im ASCII-Klartext raus. 
Höchst wahrscheinlich auch noch mit einem abschliessenden \n, so dass 
man ihn einfach und problemlos in bestehende Programme integrieren kann.

Wenn also auf deinem Etikett steht
"Klo-Beleg"
und im Terminal taucht dieser Text nicht auf, dann ist was oberfaul(*)

Alles andere wäre nämlich ziemlicher Schwachsinn, ohne das dieser 
irgendetwas bringen würde.


(*) dir ist schon klar, dass es verschiedene Barcode-Systeme gibt?
http://de.wikipedia.org/wiki/Strichcode

> #define UART_BAUD_RATE      9600            // SCANNER Baud Rate

da stellst du deine baudrate ein. Ansonsten such im Forum nach Baudrate 
einstellen. Da gibs n kleinen Schnippsel Code wo du dein Taktrate und 
deine Baudrate eingibst, doch ich denke #define UART_BAUD_RATE genau das 
macht, nur schon weiß welchen Prozesseortakt du fährst.
Das Codeschnippselchen gibs definitiv in ASM doch ich glaub da gibs auch 
ne Variante für C für. In C arbeite ich mich übrigens auch gerade erst 
ein, daher kann ich da nicht wirklich viel zu sagen. Ich weiß nicht, wie 
deine UART_INIT aussieht.

Hallo Freunde!

Dem Vorschlag mit PuTTY bin ich gefolgt --> nach einer 
Baudratenanpassung durch den Vergrößerungsfaktor 4 stimmten die Zeichen.

Ich vermute, dass das an der fehlerhaften Delay.h Header liegt, die in 
der meinen Version delays 4 mal so schnell wie normal ausführt.

Die Arbeiten gehen weiter, danke für alle Antworten!

Lg,
Paz

Patrick Fuchs schrieb:
> Ich vermute, dass das an der fehlerhaften Delay.h Header liegt, die in
> der meinen Version delays 4 mal so schnell wie normal ausführt.

Muss mich korrigieren:
    Was ich nicht wusste: dass das myavr Board den mega8 mit einem 
externen Oszillator
    (3686400 Hz) auf Trab hält.
    Mein Lehrer meinte immer dass die Delay.h in dieser Version 
inkompatibel zum Board
    wäre.

Lösung: einfach die richtige Frequenz einstellen --> 3686400 und schon 
kann mit allem normal und wie geplant gearbeitet werden.

Nochmals vielen Dank für die Ideen und Anregungen,
Lg, Paz