RS232 - Kommunikation zwischen PC und dem AVR

[robo_wolf]

R S 2 3 2 - U E B E R T R A G U N G
--- Kommunikation zwischen PC und dem AVR ---

Vorwort:
Dieser Thread soll sich mit der Kommunikation zwischen dem AVR und einen PC ueber die RS232(serielle) Schnittstelle beschaeftigen.
In meinen letzten Thread wurde zum Schluss die FIFO-Funktion mit sehr, sehr viel Unterstuetzung von mare_crisium erarbeitet.
https://www.roboternetz.de/phpBB2/viewtopic.php?t=51693
Diese soll mit als Grundlage dienen.
Auch hier soll verstaendlich erklaert und beschrieben werden, wie der AVR mit dem PC kommuniziert.
Habe einige Daten zusammen getragen... aber lanengst nicht alles.

Auch in diesem Thread hoffe ich wieder auf die tatkraeftige Unterstuetzung von mare_crisium.
Aber auch andere User koeennen bzw. sollen sich an daran beteiligen.


Hardwarevoraussetzung:
AVR arbeitet mit 5V Signalen
RS232 benutzt 12V Signale
Aus diesem Grund muss ein Pegelwandler eingesetzt werden.
Der Pegelwandler macht die 5V Signale des AVR RS232 konform(12V-Signale) und wandelt umgekehrt die Signale die ueber die RS232 kommen,
in fuer AVR verstaendliche 5V Signale um.

Pegelwandler 5V / 12V MAX232(oder Derivat)

Beim STK500 ist so ein Baustein auf der Entwicklerplatine vorhanden und nach aussen durch eine 9polige Buchse gefuehrt.
Bei anderen Platinen muss also auch ein Pegelwandler vorhanden sein, wenn man die RS232 Kommunikation nutzen moechte.
Oder man realisiert es extern ueber zusaetzliche Schaltung, der man die Signalleitungen des AVR zur Verfuegung stellt.

Nullmodemkabel oder serielles Kabel???
Nullmodem wird zwischen 2 PC(Master) verwendet.
Serielles Kabel verwendet man zwischen eine PC(Master) und einem Peripheriegeraet(Slave).
In unseren Fall also ein PC und ein Peripheriegeraet - > serielles Kabel.


Signalleitungen:
RXD und TXD - also Empfang und Senden reichen aus.
Aber eine Massleitung wird trotzdem benoetigt.( - der Pegel braucht ja ein Bezug)

PinEinstellung:
RXD (Empfang)
ist bei den vielen AtMega's PortD0
TXD (Senden)
ist bei den vielen AtMega's PortD1

Steht in der Spec des verwendeten Exemblars.

Anschlusseinstellungen:
hmmm ??? keine Ahnung
-------------
- Baudrate
- Datenbits
- Paritaet
- Stoppbits
- Protokoll
-------------
Handshake
Empfang
Senden

[mare_crisium]

robo_wolf,

so, endlich: In den angehängten Dateien finden sich die Bestandteile des Testprogramms "SerialTest01_V01.asm" für den ATmega8515; wie alles zusammengehört sieht man an den includes am Ende.

Die Zerlegung in ein Hauptprogramm und drei Module folgt dem Konzept wiederverwendbarer Komponenten, das wir im Thread "Anfänger mit STK500 und Assembler" besprochen haben.

Das Testprogramm dient dazu die Programmkomponenten auszutesten, aus denen sich eine sehr einfache aber flexible Kommunikation über die USART-Schnittstelle des ATmega zusammenstellen lässt. Es geht erst einmal um das Grundgerüst; XON/XOFF usw. ist erst einmal nicht vorgesehen, lässt sich aber jederzeit nachrüsten. In den Beschreibungen zu den Modulen SERIAL_V01.asm und SERIALIF01_V01.asm habe ich das Konzept des Botschaftsaustausch ziemlich ausführlich (hoffentlich nicht zu kompliziert ) dargestellt.

Damit auch gleich ein Erfolgserlebnis winkt, habe ich die Sendefunktion soweit zusammengesteckt, dass beim Einschalten des STK500 der Programmname, in 46 HexChars codiert, an den PC gesendet wird. Hab's mit dem Simulator getestet und hoffe es klappt auch im echten Leben.

Die Empfangsfunktion habe ich nicht ausgearbeitet; etwas muss ja zu tun bleiben, denn: Selber programmieren macht schlau !

Ciao,

mare_crisium

EDIT: Das Hauptprogramm "SerialTest_V01.asm" und die Module "SERIAL_V01.asm" und "SERIALIF01_V01.asm" gelöscht, weil sie Fehler enthielten. Die korrigierten Dateien sind an meinen Post vom 13.06.2010, ca. 17:00 angefügt.

[robo_wolf]

mare_crisium,
sorry dass ich mich erst jetzt wieder melde.
Zur Zeit ist die Zeit rar.

Erst einmal moechte ich mich fuer Deine Muehen bedanken.
Habe heute vergeblich auf meinen Win7-Notebook das gewohnte Hyperterm zu finden.
Habe dann im Net eine Shareware gefunden und mit der dann getestet.
Edit:
nach dem Programmieren des Atmels habe ich das serielle Kabel in die "Spare"-Buchse gesteckt und ein Verbindung zwischen PD0 und RX sowie zwischen PD1 und TX hergestellt.(mitgeliefertes zweiadriges Kabel)
Eine weitere Veraenderung ist der Quarz. Der 8MHz wurde durch einen 16 MHz ersetzt.
Leider kommt nach dem Einschalten des STK500 nur ein "b" im Terminalfenster an.

Also scheint zumindestens die RS232 Kommunikation zu klappen.
Aber woher nimmt er das "b"?

[mare_crisium]

robo_wolf,

Du weisst, dass Du das Kabel vom PC an die randnähere SUB-D-Buchse ("RS232 SPARE") anschliessen, und das zweiadrige Verbindungskabel vom zweipoligen "RS232 SPARE"-Anschluss (Nähe LED 4) zu den Pins PD0 und PD1 an "PORT D" stecken musst (siehe Handbuch S. 3-5) ?

Ciao,

mare_crisium

[robo_wolf]

mare_crisium,
das ich das im Vorfeld gemacht habe, haette ich im Posting erwaehnen sollen. sorry
Werde es noch ergaenzen. Trotzdem kommt nur ein "b" an.
edit:
Im Simulator bleibt der Code in der Prozedure "SER_TX_DONE:" und wartet auf das Senden des Ident-Strings aus dem FIFO-Pfuffer.
Das passiert aber nicht. zumindest nicht im Simulator.

Es wird "protKopf an UDR" geschickt, mit dem naechsten Takt verschickt und dann wird auf das Ende der Sendung gewartet. Es muessten doch nun auch die anderen Zeichen aus dem Puffer geladen und an UDR geschrieben werden.

[mare_crisium]

robo_wolf,

ich habe doch noch einen ATmega8515 in meiner Kruschtelkiste gefunden und kann das Programm jetzt auch "in echt" testen. Der Fehler war schnell gefunden: In meinen eigenen Programmen verwende ich immer das Carry- und nicht das T-Flag, um Zustände zurückzumelden. Na ja, die Macht der Gewohnheit führt dann rasch zu Verwechselungsfehlern .

Die korrigierten Versionen hänge ich hier an. Das FIFO-Modul "FIFO8_V07.asm" bleibt unverändert.

Dann drücken wir uns mal die Daumen für heute abend !

Ciao,

mare_crisium

[robo_wolf]

mare_crisium,
nun kommt der ASCII-String im Terminalfenster an.
Klappt also wunderbar. Besten Dank.
Nur versteh ich nicht ganz warum...
Im Simmulator sehe ich nur das "protKopf" auf UDR geschoben wird.
Wie kommen die anderen Zeichen dahin...???
Ausserdem bleibt das Programm auch nach dem X'ten Durchlauf in SER_TX_DONE stecken. Muesste es nicht nach dem Stoppbit rauskommen?

Habe jetzt auch ne bessere Loesung zu meinen unter Win7 fehlenden Hyperterm gefunden.
Da die Shareware ja in 28 Tage ablaeuft, habe ich die Dateien von meinen alten XP-Rechner genommen.

[mare_crisium]

robo_wolf,

mare_crisium,
nun kommt der ASCII-String im Terminalfenster an.
Klappt also wunderbar.

Prima!

Wie kommen die anderen Zeichen dahin...???

Das macht der "Tx_complete"-Interrupt in Zusammenarbeit mit einem Zustandsautomaten (Sendeautomat), der im Dienstrprogramm "SER_TX_INT" eingebaut ist ! Jedesmal, wenn das Datenbyte aus dem UDR vollständig (inkl. Stopbit) verschickt ist, löst die USART diesen Interrupt aus, und der ruft das Interrupt-Dienstprogramm "SER_TX_INT" auf. Was dann passiert, wird vom Zustand "SERCTL_TX_ZST" des Sendeautomaten gesteuert:

SER_TX_ZST = 0 : Neues Datenbyte aus FIFO einlesen.
Wenn dabei T-Flag = 0 (FIFO ist leer), dann wird das eingelesenen Byte nicht verwendet, sondern stattdessen "SER_MSG_END" gesendet und der Folgezustand ist 2.
Wenn das T-Flag = 1 ist (FIFO noch nicht leer), dann wird das eingelesene Byte in "SERCTL_TX_NIBBLE" gespeichert. Das obere Nibble des Bytes wird in einen HexChar umgerechnet und gesendet. Der Folgezustand ist 1.

SER_TX_ZST = 1 : Altes Datenbyte aus "SERCTL_TX_NIBBLE" einlesen, das untere Nibble in einen HexChar umgerechnen und versenden. Der Folgezustand ist 0.

SER_TX_ZST = 2 : Dieser Zustand wird nur erreicht, nachdem "SER_MSG_END" versandt wurde; d.h. wenn die Botschaft vollständig gesendet worden ist. Deshalb wird jetzt der "Tx_complete"-Interrupt abgeschaltet (TXIE = 0). Der Folgezustand ist 2.

Die Prozedur "SER_TX_START" befördert den Sendeautomaten aus Zustand "SER_TX_ZST" = 2 nach "SER_TX_ZST" = 0, wenn eine neue Botschaft gesendet werden soll.

Das Tolle daran ist, dass das alles völlig im Hintergrund abläuft. Das Hauptprogramm kann nach dem Aufruf von "SER_TX_START" machen, was Du willst - na ja, fast - die Sendung läuft völlig selbstständig und ohne jede Unterstützung vonseiten des Hauptprogramms weiter, bis das letzte Zeichen im PC ist.

Das mit dem Hängenbleiben in "SER_TX_DONE" kommt davon, dass das Ergebnis mal im Carry- und mal im T-Flag übergeben wird. Deshalb habe ich jetzt alles so geändert, dass ausschliesslich das T-Flag als Informationüberbringer verwendet wird. Ich werde in meinem alten Post die alten Versionen einfach durch die neuen ersetzen. Musst sie Dir nochmal runterladen.

Ciao,

mare_crisium

[robo_wolf]

mare_crisium,
es wird also alles ueber die Serviceroutine der usart(SER_TX_INT) abgewickelt. Was ich beim Durchtickern des Codes im Simmulator gesehen habe... ist "protKopf" auf UDR geschrieben und mit dem naechsten Takt verschickt wurden. - Das ist Ausloeser der Serviceroutine?

[mare_crisium]

robo_wolf,

es wird also alles ueber die Serviceroutine der usart (SER_TX_INT) abgewickelt

ja, so isses . Eingeleitet wird die Abwicklung durch den Aufruf von "SER_TX_START" im Hauptprogramm; erst dadurch wird der "Tx_complete"-Interrupt eingeschaltet.

Im Simulator kann man die schrittweise Interrupt-Abwicklung sehr gut verfolgen, weil er den "Tx_complete"-Interrupt sogar mit der richtigen Baudrate (relativ zum Prozessortakt) simuliert. Wenn Du einen Breakpoint an den Anfang von SER_TX_INT setzt, kannst Du zusehen, wie ein Zeichen nach dem anderen verwurstet wird.

An der USART hängen insgesamt drei Interrupts: "Tx_complete", "Rx_complete" und "USART_Data_Register_Empty". Noch nutzen wir nur einen davon - beim Aufbau des Empfängerteils werden wir dann auch den "Rx_complete" einspannen.

Ciao,

mare_crisium