RS232 - Kommunikation zwischen PC und dem AVR

[robo_wolf]

mare_crisium,
bekomme es nicht simmuliert.
Habe den Breakpoint bei SER_TX_INT(SERIAL_V02.asm) gesetzt und das Programm durchlaufen lassen.
Mit "out UDR,r16" wird die Servieroutine gestartet, naja erst wenn das SREG zurueck gesichert wird und Global Interupt Enable setzt.
....oder?
Aber ich komme dann zum Label SER_TX_DONE und haenge dort fest...?

Das Programm als solches funktioniert aber, sonst wuerde ich den String nicht im Terminal sehen....
Irgendwas uebersehe ich.

[mare_crisium]

robo_wolf,

den gleichzeitigen Ablauf von Versand über die USART und Assemblerprogramms musst Du Dir vorstellen, als wären es zwei Threads unter Windows: Es sind zwei voneinander unabhängige, gleichzeitig ablaufende Vorgänge.

Wenn (in SER_TX_START) bei aktivierter USART (TXEN = 1) ein Byte ins UDR geschrieben ist, beginnt der MC, unabhängig vom Ablauf des Assemblerprogramms, das Byte über die USART hinauszutakten. Das ist wie ein eigener USART-"Thread".

Derweil läuft das Assemblerprogramm weiter, quasi im Assembler-"Thread": Es aktiviert den Interrupt (TXIE) und das globale Interrupt-Flag und kehrt ins Hauptprogramm zurück. Dort läuft es in die HS_01-Schleife.

Währenddessen hat der USRAT-"Thread" den Inhalt von UDR vollständig versandt und löst dann den "Tx_complete"-Interrupt aus. Jetzt wird der Ablauf des Assembler-"Threads" ge-interrupted und das Programm springt in das Dienstprogramm "SER_TX_INT". Wenn er sich da durchgewurschtelt hat, kehrt er wieder in die HS_01-Schleife zurück.

Wenn er innerhalb des Dienstprogramms noch ein Byte ins UDR geschrieben hat, dann läuft der USART-"Thread" munter weiter, während der Assembler-"Thread" weiter durch "SER_TX_DONE" hechelt.

War die Botschaft beendet, dann schaltet das Dienstprogramm den "Tx_complete"-Interrupt ab (TXIE=0) und setzt das "SER_TX_AKTIV"-Flag in SERCTL. Weil das UDR leer bleibt, endet hier der USART-"Thread" und der "Tx_complete"-Interrupt bleibt aus - man brauchte ihn noch nicht einmal auszuschalten.

Wenn das Assemblerprogramm nun aus dem Dienstprogramm zurückkehrt, merkt es beim nächsten Aufruf von "SER_TX_DONE", das die Botschaft vollständig verschickt wurde und läuft in die "HAUPTSCHLEIFE" weiter.

Das wichtige Konzept ist hier die "Nebenläufigkeit" von USART-Verarbeitung und Assemblerprogramm. Dieselbe Nebenläufigkeit gibt es auch z.B. bei der TWI-, der SPI-Schnittstelle, den diversen Timer/Countern, beim Lesen und Schreiben des EEPROMS und der ADC-Wandlung.

Piu ciaro?

Ciao,

mare_crisium

P.S. OT: Nach dem Spiel traut man sich kaum noch Italienisch zu schreiben !

[mare_crisium]

robo_wolf,

beim Nachlesen Deiner Fragen ist mir diese Bemerkung von Dir aufgefallen:

... "protKopf" auf UDR geschrieben und mit dem naechsten Takt verschickt wurden...

Das Verschicken aus dem UDR dauert mehr als einen Prozessortakt. Die Bits müssen ja mit der eingestellten Baudrate versandt werden . Also wird der MC-Takt erst einmal bis auf die Baudrate heruntergeteilt. Dann braucht es einen Baudraten-Takt pro Bit; Start-, Stop- und Paritätsbit (je nach Einstellung) kommen auch noch dazu. In unserem Programm, z.B., (16MHz MC-Takt, 8 Bits, ein Stopbit, keine Parität, 9600 Bd) braucht der Vorgang 10/9600=1ms oder rund 16667 MC-Takte, bis das UDR leer ist. In der Zeit kann der MC 'ne Menge anderer nützlicher Sachen anstellen !

Ciao,

mare_crisium

[robo_wolf]

mare_crisium,
also es laufen der "normale ProgrammCode und die USART parallel?
Wie kann das sein? Muss nicht alles durch den Prozessor gekaut werden..?
Setzt das nicht einen Co-Prozessor voraus?
Demnach gibt es auch keine Programmunterbrechung wie bei Interrupts oder Timer.
Noch einmal fuer die "Langsamen", wie mich:
In SER_TX_START wird " out UDR,r16 "das "CR" - SER_MSG_KOPF an die USART uebergeben.
- damit geht es los
- so weit ueberschaue ich es noch im Simulator.
Nun kommem auf UDR noch
16MHz MC-Takt, (wird in "SER_CREATE" festgelegt und gespeichert)
8 Bits, (das Datenbyte) (wird in "SER_TX_INT" aus Datenspeicher gelesen umgewandelt und auf UDR gelegt)
ein Stopbit, (wird in "SER_CREATE" festgelegt und gespeichert)
keine Parität, (wird in "SER_CREATE" festgelegt und gespeichert)
9600 Bd (wird in "SER_CREATE" festgelegt und gespeichert)
LF - "SER_MSG_END" - in "SER_TX_ZST_11"(SER_TX_INT)

>>> CR >> Datenbyte bzw. 8Bit >> LF
- und das dann 46 mal fuer die 46 Zeichen(unteres und oberes Nibble?

und warum das Aufteilen in unteres und oberes Nibble.
Kann man den das Byte nicht komplett versenden?

Wahrscheinlich viele seltsame Fragen... aber ich habs noch nicht ueberrissen....

[mare_crisium]

robo_wolf,

ja, man kann sagen, da ist ein Coprozessor am Werk - wenn auch ein ziemlich einfacher . Wenn Du Dir das Diagramm auf Seite 136 des 8515-Datenblattes ansiehst, bekommst Du einen Eindruck davon, welche Hardware speziell für die USART eingebaut ist. Bei der USART ist das noch überschaubar, bei der TWI-Schnittstelle kommt es einem richtigen Coprozessor schon ziemlich nahe.

Der Grund für das Zerlegen in Nibbles ist, dass sich dadurch sehr einfach zwischen Nutz- und Steuerzeichen unterscheiden lässt und dass sich die Botschaften direkt angezeigen lassen. Ausserdem kann man fehlerhaft empfangene Zeichen sehr leicht erkennen. Mehr dazu findest Du am Anfang der Beschreibung im Modul "SERIAL_V02.asm".

Tja, da ist schon allerhand Erstaunliches drin, in diesen unscheinbaren Käferchen !

Ciao,

mare_crisium

[robo_wolf]

mare_crisium,
besten Dank fuer die schnelle Antwort.
Dann stimmt das was ich im letzten Posting geschrieben habe nicht.
Es muss so heissen:
Eingeleitet wird das Senden durch das Senden von
protKopf(SER_MSG_KOPF) - also CR, dann kommen die
||
Datenbytes und wenn der Datenspeicher geleert ist, kommt
||
protEnd(SER_MSG_END) - also LF

Das Protokoll(Konfiguration) wird beim Aufruf von "SER_CREATE" in der USART gespeichert.
Fuer das senden der 23 Byte benoetigt der MC ca. 806.000 Zyklen = 50ms.

Empfangsrichtung
Hast Du ja auch schon ein wenig erklaert.
Letzten Endes werden am PC Zeichen eingeben(im einfachsten Fall durch die Tastatur) und wandern im Empfang-FIFO.
Im Simulator laesst sich das dann aehnlich gut anschauen, wie dem Sendefall.
Aber in der harten Realitaet sieht man nichts davon.
Also muss man den Empfangs-FIFO auch zur Anzeige bringen. Am STK500 sind nur 8 LEDs zur Anzeige.
Beim Empfang von den Daten und direkter Ausgabe wird man nicht einmal ein leichtes Blinken sehen koennen.
- gut man koennte die Ausgabe eventuell bremsen -
Eine Moeglichkeit waere die Datenbytes einzeln durch Tastendruck aus dem Empfang-FIFO zu laden und diese bis zum naechsten Tastendruck anzeigen zu lassen.
Eine weiteres Moeglichkeit, waere das Ruecksenden der Daten an den PC- ein ECHO...

[mare_crisium]

robo_wolf,

jau, jetzt hast Du's !

Der nächste Schritt ist erstmal nur ganz klein: SERIAL_V03 hat jetzt eine Methode zum Einschalten des USART-Empfängers und ein ganz einfaches Interrupt-Dienstprogramm (SER_RX_INT), das jedes empfangene Zeichen unverändert an den PC zurückschickt.

Das dient erstmal nur zum Überprüfen, ob nach der Verbindung MC->PC auch die interruptgesteuerte PC->MC-Verbindung klappt.

Ciao,

mare_crisium

[robo_wolf]

mare_crisium,
vielen Dank.
Komme erst heute Abend zum ausgiebigen Testen.
Noch eine Frage:
Die Erweiterung beinhaltet ein MC-Echo.
Wenn im Terminal zum Beispiel eine "8" eingeben wird, kommt sie vom MC also Echo "8" zurueck und steht dann zweimal im Terminalfenster?

[mare_crisium]

robo_wolf,

zuerst kommt die Anwesenheitsmeldung vom MC, wie gehabt, als Zeichen, dass er empfangsbereit ist. Danach schickt er jedes Zeichen, das Du ihm sendest, unverändert an den PC zurück. Es erscheint dann zweimal in der Eingabezeile Deines Hyperterminals, dass hast Du richtig verstanden .

Ciao,

mare_crisium

[robo_wolf]

mare_crisium,
die Anwesenheitsmedlung des MC kommt.
Aber ein Echo auf meine Eingabe kommt leider nicht.
Habe das Programm ordnungsgemaess uebertragen, und als es nicht funktionierte, sicherheitshalber noch einmal uebertragen.
Aber kein Echo auf meine Eingabe. Ich habe mehrer Ziffern, aber auch Buchstaben probiert. Kann ich bei der Schnittstelleneinstellung des Hyperterms etwas falsch gemacht haben? "9600,8,keine,1,keine"....