RS232 - Kommunikation zwischen PC und dem AVR

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

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 :oops: ) 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.

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"?

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

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.

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

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.

robo_wolf,

Zitat:

---

Zitat von robo_wolf

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

---

Prima! :-)

Zitat:

---

Zitat von robo_wolf

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

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?

robo_wolf,

Zitat:

---

Zitat von 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

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.

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 :oops: !

robo_wolf,

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

Zitat:

---

Zitat von robo_wolf

... "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

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.... :-(

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

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...

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

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?

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

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"....

robo_wolf,

welches Terminalprogramm verwendest Du? Es ist besser, wenn ich's mit demselben Programm versuchen kann. Es könnte sein, dass die Zeichen erst übertragen werden, wenn Du ENTER drückst. Könntest Du sicherheitshalber anhand der Anwesenheitsmeldung noch einmal die Versionsnummer prüfen?

Ciao,

mare_crisium

mein Dummheit....
Es hat von Anfang an funtkioniert.
Das lokale Echo war ausgeschaltet.
So bin ich davon ausgegangen, das das angezeigte Zeichen vom lokalen Echo erzeugt wird. Nun habe ich das mal eingeschaltet und siehe da jede Eingabe kommt 2mal .... einmal vom lokalen Echo und einmal vom MC.
sorry

robo_wolf,

kommt in den besten Familien vor :-) !

So, als Nächstes gibt's die Version mit dem Zustandsautomaten für den Empfang - braucht aber noch ein bisschen...

Ciao,

mare_crisium

robo_wolf,

Doppelpost - gelöscht - hatte übersehen, dass es schon eine zweite Seite gab :oops:

Ciao,

mare_crisium

mare_crisium,
bin leider noch immer nicht 100%ig mit dem Durchrarbeiten des Codes durch.
Manche Programmteile gehe ich schon zum x-ten mal durch, springe dann wieder zu deiner gut beschriebenen Doku und dann wieder zurueck usw. :-)
Moechte eben alles nachvollziehen, was du geschrieben hast. (hast ja wieder mal sehr viel Zeit und Muehe investiert)
Das mit den Einbinden eines Zustandsautomaten, fand ich anfangs etwas schwieriger, mittler Weile aber vereinfacht es mir sorgar das Nachvollziehen des Codes.
Wo wir schon mal bei dem Zustandsautomaten sind:
??? Es gibt ja auch fehlerhafte Zustaende, welche abgefangen werden.
Macht es nicht Sinn, Fehler zur Anzeige im Terminal-Programm zu bringen?
??? In einem abgeschlossenen Projekt, wo der Code auf dem MC werkelt, wuerde man doch sonst Probleme bei der Uebertragung(z.B.wenn Zeichen mehrfach uebertragen werden muessen)
nicht oder nur sehr schwer merken, um den Code eventuell zu korrigieren.

PS.
Bitte noch etwas Geduld mit mir, brauche leider noch ein paar ruhige Stunden fuer die Aufarbeitung des Codes.

mare_crisium,
kann ich das Echo im Studio simmulieren?
Wenn ja wie?
eventuell auf UDR CR legen und dann ein Zeichen...und dann LF fuer das Ruecksetzen des COM-Ports..?

robo_wolf,

ich bastele schon an SERIAL_V04; deshalb dauert's ein bisschen mit den Antworten auf Deine Fragen ;-) :
1. Abfangen fehlerhafter Zustandsnummern: Ja, das habe ich vergessen. Wird in Version _V04 eingebaut. Die Prozedur SER_TX_DONE wird dann den Abschluss der Sendung (im T-Flag) und die Fehlernummer (in r16; 0x00 bedeutet "kein Fehler") zurückgeben.
2. Im Studio kannst Du das Echo nur bis zu der Stelle verfolgen, wo das Zeichen ins UDR geschrieben wird. Es wäre schön, wenn die virtuelle USART des Simulators mit einem virtuellen ComPort des PC verbunden wäre. Dann könnte man auch die Zusammenarbeit von PC und MC simulieren - ist aber leider nicht vorgesehen (meines Wissens).

Ciao,

mare_crisium

Zu 2., ich stand bei meinem Projekt vor dem selben Problem und habe dafür com0com ( http://com0com.sourceforge.net/ ) verwendet. Zwar mit dem Bascom-Simulator, aber das dürfte ja keinen Unterschied machen.

mfg

robo_wolf,

hier ist endlich - muss ja zwischendrin auch noch Fussballspielen :-) - die (teilweise) getestete Version mit Empfangsautomat. Nach dem Einschalten wird wieder die Anwesenheitsbotschaft an den PC gesendet. Danach können Botschaften vom PC empfangen werden. Es gibt kein Timeout - also kann man sich beim Tippen der Botschaft Zeit lassen.

Die „Auswertung“ der empfangenen Botschaften ist noch sehr rudimentär: Bei jeder empfangenen Botschaft wird ein Botschaftszähler hochgezählt. Der Zählerstand (0 bis 15) wird auf LED0 bis LED3 angezeigt.

Beim Empfangsautomaten zeigt sich eine Schwäche der Konstruktion ohne Sprungtabelle: Die Reichweite der „rjmp“-Sprünge ist zu kurz, um das Programm mit einem Satz zur Zieladresse zu befördern. Deshalb sind einige „Aufsetzer“ nötig, um bis ans Ziel zu kommen. Weil mir das nicht gefällt, wird die nächste Version wieder mit Tabellen hantieren.

Der Empfangsautomat selbst ist die 1:1 Umsetzung dessen, was in der Beschreibung steht. Er ist etwas lang, weil ich versucht habe, alle Situationen, die mir einfielen, zu berücksichtigen. Ich hoffe jedenfalls, ich habe ihm den Fluchtweg ins Nirwana gründlich versperrt ;-).

@netzman:

Danke für den Hinweis - ich werde das Teil demnächst ausprobieren. Es wäre eine echte Erleichterung, wenn man testen könnte, ohne das Programm jedesmal erst in den Ziel-MC brennen zu müssen.

Ciao,

mare_crisium

mare crisium,
vielen Dank.
Da habe ich wieder einiges zum Aufarbeiten :-)

"muss ja zwischendrin auch noch Fussballspielen"
Spielen oder Schauen? ;-)

robo_wolf,

das Modul SERIAL_V04 mit seinen unbeholfenen "rjmp"-Zweisprüngen gefällt mir wirklich nicht :-( .

Deshalb ist hier die Version SERIAL_V05, bei der der Empfangsautomat wieder tabellengesteuert werkelt - viel eleganter :-) .

Im Quelltext der anderen Module ändert sich nichts. Nur im Hauptprogramm muss die Zeile

Code:

---

.include "SERIAL_V04.asm"

---

in

Code:

---

.include "SERIAL_V05.asm"

---

geändert werden. An diesem Beispiel zeigt sich übrigens wieder die Flexibilität der modularen Struktur ;-) .

Ciao,

mare_crisium

OT: Wer richtig Fussball guckt, der spielt auch immer mit :-) !

mare_crisium,
probiere schon ein Weile das Programm zusammen mit dem STK500 zum Laufen zu bekommen.
Aber weder V4 noch V5 bringen die LEDs zum Leuchten.
Auch die Echo-Funktion funktioniert nicht mehr.
Die LEDs sind aber noch vom alten Projekt her mit PortB verkabelt.
Da Du das Programm sicher am Board getestet und probiert hast muss es doch ein meiner Verkablung liegen..? :-(
Hast Du noch einen Tipp?

robo_wolf,

das Echo habe ich in der neuen Version erstmal wieder ausgeschaltet, weil ich befürchtete, es könnte beim Eintippen der Botschaft stören. Die LEDs sind nach wie vor mit PortB verbunden.

Nach dem Flashen bzw. dem RESET müssen alle 8 LEDs kurz aufblitzen. Danach wird's erstmal zappenduster :-) . Ab jetzt arbeitet das Programm als Botschaftszähler. Die Anzahl der Botschaften (0 - 15) wird von LED0 bis LED3 angezeigt. Wenn Du also mehrere Botschaften an den STK500 schickst, sagen wir mal

Code:

---

0D 00 0A

---

dann zeigen die LED0 bis LED3 den steigenden Zählerstand an. Die LEDs leuchten also nur, wenn Du Botschaften schickst. Es werden aber nur vollständige und fehlerfreie Botschaften gezählt ;-) !

Ciao,

mare_crisium

mare_crisium,
beim Einschalten oder Reset druecken kommt der bekannte String und die 8 LEDs blinken kurz auf.
Auf spaetere Eingaben am Terminal wird weder mit einem kurzen, noch mit laengeren oder dauerenden Leuchten einer LED am STK500 geantwortet.
Da das kurze Blinken beim Reset kommt, gehe ich davon aus, dass die Verkabelung stimmt. Die Einstellungen der COM-Schnittstelle sind 9600/8/keine/1/keine - sollte doch auch passen, oder?

robo_wolf,

habe mir die Dateien noch einmal heruntergeladen und werd's ausprobieren - melde mich, wenn ich den Fehler finde.

Ciao,

mare_crisium

robo_wolf,

ich habe mir die Dateien heruntergeladen, das Programm (mit SERIAL_V05) assembliert und es läuft :-(. Keine Ahnung, was bei Dir schiefgeht.

Ich hänge hier eine geänderte Version SERIAL_V05 an, in der das Echo wieder aktivitert ist; in der Hoffnung, dass Dir das bei der Fehlersuche hilft.

Wenn das auch zu nix führt, könnte ich Dir mein Terminalprogramm schicken. Ist aber eine .exe-Datei, die kann man hier im Forum nicht posten.

Ciao,

mare_crisium

mare_crisium,
vielen Dank fuer die schnelle Antwort.
Das Echo geht wieder, aber die Anzeige nicht.
Habe nun mal auf PortC gewechselt... auch hier das Gleiche.
Kannst Du mal mit dem Hyperterm von Windows testen?

robo_wolf,

nee, die LEDs werden von PortB angesteuert, die Verbindung musst Du so lassen (LED-Header <-> PortB-Header).

Hyperterm.exe finde ich unter Windows Vista nicht. Hast Du einen Tip, in welchem Verzeichnis das stehen könnte?

Ciao,

mare_crisium

mare_crisuium,
PortC hatte vorher natuerlich auch im Programm eingetragen.
Hyperterm habe ich vom XP-Rechner kopiert, da es unter Win7 auch nicht da ist.

robo_wolf,

ich glaube ich hatte "pomodori su i occhi":oops: In meinem Posting von 29.06.2010 (23:13) muss es natürlich

Code:

---

0D 30 30 0A

---

heissen. In meiner Beschreibung habe ich doch lang und breit erklärt, dass die beiden Nibbles als HexChars verschickt werden müssen: Also 0x00 -> 0x30 0x30 !

Bin mal gespannt, ob es damit klappt.

Ciao,

mare_crisium