Serielle Komunikation mit Mikrocontroller

<div align="left">Hallo,

also LabVIEW ist wohl wirklich unschuldig, ich habe die gleichen Fehler mit diversen anderen Terminal Programmen. Ich hab auch mal das gleiche Zeichen einfach wieder zurück gesendet, kommt nur blödsinn zurück. Es muss wohl wirklich was mit der Baudrate oder dergleichen zu tun haben auch wenn ich das schon zig mal geprüft habe und keinen Fehler finde. Ich möchte euch nicht dazu Auffordern meine Fehler auszubügeln, aber wenn es jemandem Langweilig sein sollte darf er gern mal drüber sehen.Zudem ist das ja eigentlich ein LabVIEW forum. Ich mach für heute aber schluss und such den offensichtlichen Fehler im C-Programm morgen ...oder die tage:blush:Gute Nacht zusammen und Danke für eure Hilfe!

Die Interesannten stellen meines Controller Programms sind die Interruptservice-Routine beim Empfang eines Zeichens und die Initialisireung der USART-Schnittstelle. Es handelt sich um ein ATMega16. :

// USART initialization
// 8 Data, 1 Stop, No Parity
// Mode: Asynchronous
// Baud rate: 9600

UCSRA=0x00;
UCSRB=0x98;
UCSRC=0x86;
UBRRH=0x00;
UBRRL=0x67;


// USART Receiver interrupt service routine
interrupt [USART_RXC] void usart_rx_isr(void)
{
char lcd_buffer_Y[33];
char status,data;
status=UCSRA;
data=UDR;

lcd_gotoxy(0,3);
sprintf(lcd_buffer_Y,"data: %u ",data);
lcd_puts(lcd_buffer_Y);
putchar(data);

}</div>

Anzeige

Vorschlag für Anfänger:

die Zeichen(Zahlen) als ASCII zeilenweise über die Serielle übertragen.
Vorteile:
1. Du kannst mithören und sehen was du überträgst, wenn du statt den Mikrocontroller einen PC mit Hyperterminal anschliesst.
2. Wenn du zeilenweise überträgst, dann brauchst du dir keine Gedanken zu machen, wegen dem Abschlusszeichen.
3. Leicht sich die Verbindung und Übertragung vorzustellen.
4. Kein Protokoll nötig (Checksumme, Counter u.s.w.)

Füe Kenner
Binäre Datenübertragung.

Vorteile:
1. Sichere Übertragung, wenn (Checksumme u.s.w. mitübertragen werden)
2. Schnelle Übertragung, weil kleinere Datenmenge.
3. Modularität, weil die Datenquelle frei wählbar.(z.B. kann man als Datenquelle auch Speicher nehmen)
4. und überhaupt in der Programmierwelt die meist verwendete Übertragungsart.

Also entscheiden: entweder oder, anders geht nicht.

Gruss, Eugen

Wenn du die Zeichen als ASCII überträgst, warum gibst du die im uC als %u aus? Ersetze als erstes dein %u durch %c. Zweitens, wie ist deine Integer Zahl vor der Ümwndlung nach ASCII? Die Integerzahl muss 8 Bit lang und unsigned sein.

Ich gebe Eugen recht.

Wenn Du Data als char deklarierst, kann es auch nur als char sinnvoll ausgegeben werden.

Oder ist dies etwa der Fehler?! Das Display erwartet kein char - deshalb Deine Interpretation als %u?
Noch was zum Verständnis:

Hier setzt Du den Cursor im Diplay:
lcd_gotoxy(0,3);

Hier erstellst Du aus den empfangenen Zeichen (eigentlich) einen String mit abschliessendem :
sprintf(lcd_buffer_Y,"data: %u ",data);

Hier überschreibst Du die mit Newline:
lcd_puts(lcd_buffer_Y);

Hier erfolgt die Ausgabe:
putchar(data);

Jetzt die Frage: Nachdem Du den String so gewandelt hast, warum schreibst Du dann den ungewandelten String ausf Display? Oder habe ich die Funktionsaufrufe fehlinterpretiert?

Gruß

Ich tippe mal schon wieder.

' schrieb:

Code:

UBRRH=0x00;
UBRRL=0x67;

Gemäß der Formel UBBR = (Fosc / (16*Baud) - 1) kommt bei Fosc=10MHz und Baud=9600 ca. 64 bzw. 0x40 raus. Aber nicht 0x67. Wie bist deu denn auf den Wert 67 gekommen?

So, nach langem Arbeitstag wieder Zuhause.
Wie ich sehe befasst ihr euch noch immer mit meinem Thema, schön!

@eugen graf: Das %u hab ich bewusst gewählt. Wenn ich das ankommende Zeichen in ein char "wandle" giebt mir das Display ein Zeichen aus. Das find ich unpraktisch da es 1. die Sonderzeichen nicht alle korrekt darstellen kann und ich 2. Jedes zeichen dan anhand einer ASCII-tabelle wieder zurück rechnen muss um es mit dem Wert den ich in LabVIEW eingegeben habe vergleichen zu können. Wenn ich es als Zahl ausgebe seh ich gleich ob es stimmt oder nicht, da es mir hauptsächlich um den Zahlenwert geht. Das ausgeben auf dem Display mache ich nur aus Debug-Gründen, das wird später nicht mehr gebraucht. Ich sehe auch eigetlich nicht das Problem wo hier noch ein Fehler passieren sollte, die ASCII to Unsigned Integer Funktion hab ich schon öfter Erfolgreich verwendet.

@Mr.T: Du hast meinen Quellcode fast richtig interpretiert.

sprintf(lcd_buffer_Y,"data: %u ",data);
Hier wird die Variable "data" in eine Unsigned Integer Zahl gewandelt und daraus dan ein String gemacht. Dieser wird in das Array "lcd_buffer_Y" geschrieben.

cd_puts(lcd_buffer_Y);
Hier erfolgt die Ausgabe auf das Display

putchar(data);
Und hier sende ich das gesendete Zeichen postwendend wieder an den Absender (an das Terminal-Programm) zur Kontrolle zurück. Wie schon erwähnt kommt leider nicht das zurück was ich sende.

@IchSelbst: Sorry, ich hätte zum Controller noch die Takfrequenz nennen müssen. Es hängt ein Quarz mit 16Mhz dran. Ich denke dan müsste 0x67 stimmen.

So und jetzt such ein bissel weiter nach meinem Bockmist. Drückt mir die Daumen!

Anzeige

Also ich hab mir nochmal die Tabelle vorgenommen und meine jetzt: falsche Baudrate ist auszuschließen. Aber das mit den vielen Einser wo eine Null hingehört ist schon merkwürdig. Kannst du verifizieren, dass der Pegelwandler auf dem Controller/board in Ordnung ist?

Kannst du nachkucken, ob es zu Overrun-, Framing- oder Parityerror kommt?

Wenn ich HEX übertragen will, dann muss ich doch 41 HEX nicht wandeln, weil es schon HEX ist und nicht ASCII. Oder etwa doch?

' schrieb:Das ist richtig.

Wenn ich ASCII übertragen will, brauche ich nicht wandeln.

Muss ich aber HEX übertragen, weil die Gegenseite quasi lesbare Zeichen verlangt - nämlich HEX-Darstellung - muss ich die beiden ASCII-Zeichen der Hex-Darstellung übertragen.

Im übrigen bin ich der Meinung, dass Mark_LabVIEW möglicherweise eine Hex-Übertragung meint, auch wenn er ASCII schreibt.

' schrieb:Wenn ich HEX übertragen will, dann muss ich doch 41 HEX nicht wandeln, weil es schon HEX ist und nicht ASCII. Oder etwa doch?

Eine Zahl habe den Wert 65. (Alleine das Hinschreiben dieses Satzes birkt das Problem, dass eine Darstellungsform für die Zahl benutzt werden muss).

Für diese Zahl gibt es mehrere Darstellungsformen: HEX = 41 (Beachte: zwei Zeichen); DEC = 65 (Beachte: zwei Zeichen, beachte weiterhin, dass z.B. 129 aus drei Zeichen steht); ASCII = 'A' (Ein Zeichen); Binär = 0100.0001 (8 bzw. 9 Zeichen, der . ist Ansichtssache).

Dieser Wert kann nun wie folgt übertragen werden:
Binär: Bei dieser Übertragungsart wird ein einzelnen bzw. ein einziges Byte übertragen. Beachte dass hier nicht die Binärdarstellung des Wertes übertragen wird - die hätte nämlich 8 Zeichen = 8 Byte.
ASCII: Auch bei dieser Übertragung wird ein einzelnen bzw. ein einziges Byte übertragen. Für die Übertragung besteht also kein Unterschied zwischen ASCII und Binär. Jemand der auf der Strecke mithört kann nicht feststellen, ob die Übertragung Binär oder ASCII ist. Der Unterschied liegt im Protokoll. Ein ASCII-Protokoll kann z.B. das Zeichen LF (oder CRLF oder ETX oder EOT etc.) als spezielles Steuerzeichen auffassen.

Wenn nun einer verlangt (warum auch immer), dass die Zahl in Hexformat (oder Dezimalformat) übertragen werden soll, dann will er, dass "41" übertragen wird - d.h. es sollen zwei Zeichen übertragen werden. Um aber über die Strecke "41" zu übertragen (jemand der mithört würde die beiden Zeichen "4" und "1" erkennen), müssen die ASCII- bzw. Binärwerte von "4" und "1" übertragen werden. Diese selbst sind 0x34 und 0x31.

Mark_LabVIEW hat deswegen gesagt, er will ASCII übertragen, weil sein Display nur ASCII-Zeichen darstellen kann. Das sind die Zeichen von 0x20 bis 0x7E. Der Bereich unter 0x20 ist nicht darstellbar, weil es sich in der "ASCII-Darstellung" bei diesen Zeichen um Steuerzeichen handelt. Es wird also kein Zeichen dargestellt, sondern eine Funktion ausgeführt. Um in einem Binärkanal (also einer per se protokollfreien Übertragung, wie sie Mark_LabVIEW benutzt hat, davon gehe ich aus) ASCII-Werte zu übertragen, muss man aber keine Anpassung machen - der Übertragungsstrecke ist es egal, ob das Zeichen darstellbar ist oder nicht. Ob das Zeichen nun als ASCII-Zeichen oder als Binär-Zeichen aufgefasst werden soll, liegt im Ermessen des Empfängers. Wenn der Empfänger weis bzw. verlangt hat, dass eine HEX-Übertragung stattzufinden hat, dann wird er immer zwei Bytes zusammenfassen und aus den zwei Zeichen "4" und "1" wieder 0x41 machen. Weiterhin gehe ich davon aus, dass Mark_LabVIEW mit "Konvertierung nach ASCII" den Befehl "Bytearray nach String" gemeint hat: Er kann dann im String die Darstellungsform "A" sehen. (Bei "Zahl nach String" hätte er "65" gesehen). Würde das VISA-Schreiben-VI auch mit einer Zahl bzw. einem Zahlarray als Eingangsparameter funktionieren, würde man nicht die "Konvertierung" nach String brauchen, die eine ASCII-"Wandlung" vortäuscht. Strings pflegen von sich aus eine ASCII-Darstellung zu machen - auch wenn der Inhalt binär ist.

Ich habe bald die Aufgabe mit einer seriellen Schnittstelle Daten zu übertragen, die im Hex-Format vorliegen. Reicht es da nicht, wenn ich in LabVIEW die Hex-Darstellung bei meinem "String Control" einstelle und das dann über "VISA Write" an den Controller rüberschicke? Wenn ich da jede einzelne Hex-Ziffer in Ascii umwandeln muss, dann werde ich ja wahnsinnig. Oder geht das einfacher?

Gruß Markus

' schrieb:Eine Zahl habe den Wert 65. (Alleine das Hinschreiben dieses Satzes birkt das Problem, dass eine Darstellungsform für die Zahl benutzt werden muss).

Für diese Zahl gibt es mehrere Darstellungsformen: HEX = 41 (Beachte: zwei Zeichen); DEC = 65 (Beachte: zwei Zeichen, beachte weiterhin, dass z.B. 129 aus drei Zeichen steht); ASCII = 'A' (Ein Zeichen); Binär = 0100.0001 (8 bzw. 9 Zeichen, der . ist Ansichtssache).

Dieser Wert kann nun wie folgt übertragen werden:
Binär: Bei dieser Übertragungsart wird ein einzelnen bzw. ein einziges Byte übertragen. Beachte dass hier nicht die Binärdarstellung des Wertes übertragen wird - die hätte nämlich 8 Zeichen = 8 Byte.
ASCII: Auch bei dieser Übertragung wird ein einzelnen bzw. ein einziges Byte übertragen. Für die Übertragung besteht also kein Unterschied zwischen ASCII und Binär. Jemand der auf der Strecke mithört kann nicht feststellen, ob die Übertragung Binär oder ASCII ist. Der Unterschied liegt im Protokoll. Ein ASCII-Protokoll kann z.B. das Zeichen LF (oder CRLF oder ETX oder EOT etc.) als spezielles Steuerzeichen auffassen.

Wenn nun einer verlangt (warum auch immer), dass die Zahl in Hexformat (oder Dezimalformat) übertragen werden soll, dann will er, dass "41" übertragen wird - d.h. es sollen zwei Zeichen übertragen werden. Um aber über die Strecke "41" zu übertragen (jemand der mithört würde die beiden Zeichen "4" und "1" erkennen), müssen die ASCII- bzw. Binärwerte von "4" und "1" übertragen werden. Diese selbst sind 0x34 und 0x31.

Mark_LabVIEW hat deswegen gesagt, er will ASCII übertragen, weil sein Display nur ASCII-Zeichen darstellen kann. Das sind die Zeichen von 0x20 bis 0x7E. Der Bereich unter 0x20 ist nicht darstellbar, weil es sich in der "ASCII-Darstellung" bei diesen Zeichen um Steuerzeichen handelt. Es wird also kein Zeichen dargestellt, sondern eine Funktion ausgeführt. Um in einem Binärkanal (also einer per se protokollfreien Übertragung, wie sie Mark_LabVIEW benutzt hat, davon gehe ich aus) ASCII-Werte zu übertragen, muss man aber keine Anpassung machen - der Übertragungsstrecke ist es egal, ob das Zeichen darstellbar ist oder nicht. Ob das Zeichen nun als ASCII-Zeichen oder als Binär-Zeichen aufgefasst werden soll, liegt im Ermessen des Empfängers. Wenn der Empfänger weis bzw. verlangt hat, dass eine HEX-Übertragung stattzufinden hat, dann wird er immer zwei Bytes zusammenfassen und aus den zwei Zeichen "4" und "1" wieder 0x41 machen. Weiterhin gehe ich davon aus, dass Mark_LabVIEW mit "Konvertierung nach ASCII" den Befehl "Bytearray nach String" gemeint hat: Er kann dann im String die Darstellungsform "A" sehen. (Bei "Zahl nach String" hätte er "65" gesehen). Würde das VISA-Schreiben-VI auch mit einer Zahl bzw. einem Zahlarray als Eingangsparameter funktionieren, würde man nicht die "Konvertierung" nach String brauchen, die eine ASCII-"Wandlung" vortäuscht. Strings pflegen von sich aus eine ASCII-Darstellung zu machen - auch wenn der Inhalt binär ist.