Erste Erfahrungen mit der seriellen Datenübertragung

Hallo,
heute erste Erfahrungen mit der seriellen Datenübertragung beim STK500-Board
mit dem ATMega8515 gesammelt und in Screenshots dargestellt.
Hatte schon größere Befürchtungen, doch es klappte bis auf ein paar Kleinigkeiten, die ich (-wie meistens-) übersehen hatte, eigentlich auf Anhieb.

Punkt 1)
Die Errechnung der exakten Baudratenteilerwerte soll laut verschiedenen Testprogrammen im Net durch den Assembler selbst erfolgen und auch optimiert werden können. Das habe ich mir geschenkt und den heimischen Taschenrechner zu Hilfe genommen. Es wird die im Programmiertool unter Menü "Board" angezeigte Taktfrequenz des STK500-Boards eingesetzt. Es kommen "krumme" Werte heraus, wurde gerundet.

Punkt 2)
Die Übertragung funktioniert bis 4800 Baud auch bei höherer Anschlagsrate an der Tastatur ohne Probleme, bei 9600 Baud kommt es schon mal zur Anzeige von fehlerhaften Zeichen. Das steht aber sicher in Zusammenhang mit den in Punkt 1 genannten Quarzfrequenz-/Baudratenteiler-Werten. Bei weiteren Experimenten könnte man da sicher noch etwas besser "runden".

Punkt 3)
Verbindung wurde gesteckt von Port D Pin D0 und D1 an den zweipoligen RXD/TXD-Board-Jumper.
Natürlich kam es anfänglich zu keiner Verbindung, da ich ja die PC-Connection erst auf zweite DB-9-Verbindung am Board umstecken muß. Ist vielleicht IMHO etwas lästig, da man beim Programmieren das jedesmal wieder umstöpseln muß, Meldungen dazu in Screenshots Bild 8 und Bild 9. Auch Hyperterminal blockiert mir ja die Programmierschnittstelle, muß natürlich vor dem neuerlichen Flashen erst beendet werden, da ja die Maus auf COM1 läuft und ich somit keine seriellen Schnittstellen am PC mehr frei habe für das Terminalprogramm selbst.

Punkt 4)
Die anfänglichen Hurrah-Rufe über den (fast) auf Anhieb geklappt habenden Versuch, mit dem ATMega8515 über die serielle Schnittstelle eine Kommunikation mit der Außenwelt hergestellt zu haben, verstummten aber bald, als ich merkte, daß die Umlaute der deutschen Sprache nicht richtig wiedergegeben werden.
Habe per Experimenterfreude herausgefunden, daß dies mit der Terminalemulation in direktem Zusammenhang steht. Man muß zweimal hintereinander über Menü Eigenschaften das Hyperterminal entsprechend vorher konfigurieren (Bilder 10 bis 12 in den Screenshots).
Das Ergebnis präsentiert sich voller Stolz in Bild 13.

Fazit:
Hat super geklappt.

Gruß von Oskar01

Hallo Markus,

ok. Danke für den Tip!

Meinst Du den Baustein AVRISP mkII ?


Da muß ich mich mal so langsam ranpirschen.....

Da stand auch was von Vista-Kompatibilität drin. Aber wie ich sehe, ist Dein Prob ja mittlerweile gelöst.

Mein Mutter-Bord am PC unterstützt nicht USB, fahre aber auf einem freien PCI- Slot (ISA-Slots hat das auch noch, ja, ja...) mit einem Lucent-USB-Host-Adapter.



So long....
Gruß von Oskar01

LCD eibinden und include-file falsch

Hallo,
ungeachtet der geplanten Anwendung des neuen Proggers, möchte ich noch etwas berichten zu den Versuchen mit dem U ( S ) ART.
Also, beim Studio4 hatte ich ein neues Projekt eröffnet und auch den Radiobutton auf ATmega8515 gesetzt. Offensichtlich ist aber das Include-File "8515...." nicht das richtige,
denn es muß "m8515..." heißen. Die Fehlermeldung "unknown statement" bei den UART-Registern allesamt. Der Assembler stoppt da.
Klaro, die Auswahl des MC im Studio4-Menü hat nichts mit dem im Editor manuell gesetzten Include-File zu tun, das reagiert ja erst, wenn ich assembliere mit "Built".
Dann meckert er, wenn es irgendwelche Unstimmigkeiten gibt ... und derer gibt es viele bei mir. -)
Im vorigen Prog-File hatte ich die "einfachen" 8-Bit-Register benutzt, jetzt aber UBRRH, UBRRL, UCSRB und so weiter.
Dabei ist mir noch aufgefallen, daß man diesen String für die Initialisierung nochmal senden muß, hat man das UCSRC mal nach unten angegebener Manier beschreiben.

Man kann nämlich UCSRC laut Datenblatt nicht "direkt" beschreiben, weil derselbe I/O-Bereich für UBRRH- und UCSRC-Register verwendet wird. Dazu muß erst der Wert 0x80 Hex in das UBRRH geladen werden (also Bit URSEL im UBRRH-Register auf high), damit das Ding auf das UCSRC Register springt.
Eigentlich sollte jetzt das UBRRH-Register unangetastet bleiben. Könnte aber sein, daß es anschließend, nachdem UCSRC (auch mit Bit für URSEL) beschrieben wurde, nochmals so geladen werden muß, daß Bit für URSEL (Bit7) wieder auf Low steht, womit dann UBRRH wieder aktiv ist.
Am besten aber zu Sicherheit den gesamte String mit UBRRH und UBRRL nochmal dahinter reinsetzen, wie ich es im unten angegebenen Proggi auch ausprobiert habe. Anders als von der Stackpointerinitialisierung her bekannt. (Dort erst Low, dann High, hier, beim USART erst High, dann Low.OK.)
(Jedenfalls verstehe ich die Dokumentation so, obwohl das auf Seite 153 angegebene Codebeispiel IMHO etwas irreführend ist. Auf Seite 8 und den auf die Seite 153 folgenden Seiten der Doku ist's aber korrekt dargestellt.
Übrigens:
Es muß nicht 3 sondern 6 heißen, wie ich anderswo gelesen habe.
Zitat:
ldi temp, (1<<URSEL)!(3<<UCSZ0)

für den hier verwendeten "Frame" 8N1 also korrigiert:

ldi temp, (1<<URSEL)!(6<<UCSZ0) (statt Ausrufezeichen den "komischen" Strich)

irgendwie richtiger wäre wohl diese Darstellung dafür:

ldi temp, (1<<URSEL)!(1<<UCSZ1)!(1<<UCSZ0)

wobei man natürlich "im Regen" steht, auf welcher Position im Byte-Rahmen genau die "Platzhalterbits" tatsächlich sitzen. Der Assembler scheint hier ja echt alles umsetzen zu können, vorausgesetzt, die Zuordnung ist mit dem "richtigen" Include-File vorher definiert.
Man kann natürlich auch das betreffende Include-File mit dem Editor öffnen und mal rumstöbern, ob man was findet dazu, vielleicht gibt es ja dann nochmals einen Aha-Effekt.

....Oder sehe ich das falsch, denn mit dieser Art der "bitweisen" Schreibweise habe ich so meine ganz spezifischen Probs.)

Das ist nun im Proggi konkret mit Hex-Werten ohne "Brimborium" drin.
.....Und es läuft wunschgemäß.

Hier der Programmschnipsel dafür:



Unten noch die Response des LC-Displays, das ja die bekannte "Macke" hat, etwas zu verschlucken.

So long.....
Es grüßt,
Oskar01

Registerinhalte in Hex-Format seriell auslesen

Hallo,
ok.
Erstens: Es geht jetzt auch mit 9600 Baud. (Teilerwert nochmals optimiert.)
Zweitens: Programm ergänzt um Konversion in Dezimalschreibweise und
Hexadezimalschreibweise.
Das Programm für die Dezimalzahlumwandlung eines 8-Bit-Register-Wertes vom allseits bekannten "Tutorial" klappte eigentlich auf Anhieb, so daß ich es mir hier schenke.
Nur, die Routine für die Hex-Darstellung zeigt mir nur Nullen.

OK.
Hab mich drangesetzt und mal selber was ausgedacht.

Ein Registerwert kann zwar auch unmittelbar ohne vorherige Umwandlung als ASCII-Character auf dem Terminal des PCs dargestellt werden, nur sieht das dann wie in Bild 1 "Direktausgabe" aus und erinnerte einen eher an ein abstraktes Teppichknüpfmuster.-)
Es ist dann auch noch von der Terminalemulation stark abhängig.
Möchte man nun einen Code möglichst unverändert darstellen, muß man einen anderen Weg beschreiten.

Die Voraussetzung:

Die Hex-Darstellung erfolgt bekannterweise bei acht Bit in zwei Zeichen.
Also brauche ich schon mal zwei Schreibvorgänge pro Wert.

Dann ist die Darstellung für Zahlen von 0 bis 9 eigentlich eine nicht sonderlich schwierige Umsetzung in den ASCII-Code: Man braucht nur die entsprechende Konstante addieren.

Für die Zahlendarstellung von 10 ab aufwärts bis 15 kann man nicht einfach jetzt eine Fortsetzung des bekannten ASCII-Codes nehmen, da durch die Sonderzeichen dazwischen eine Lücke entsteht, so daß eine zweite Kodierung notwendig ist.

Fazit: Eine Unterscheidung zwischen Ziffern von 0 bis 9 und 10 bis 15 bzw. A bis F wird notwendig.

Und dann das Ganze zweimal. Da in der Terminaldarstellung von links nach rechts gelesen wird,
muß nun die höherwertige Vierergruppe, sprich Nibble (... da war doch noch was mit LCD-Vierbitmodus oder so.....?) zuerst als Symbol geschrieben werden, dann das niederwertigere Nibble.
Der dazu angebotene Code hier läuft bei mir nicht:


Habe nun das Ganze so realisiert:


So long,

Gruß von Oskar01

Watchdog und Quarzwechsel im Betrieb

Hallo,
nachdem ich bemerkte, daß sich das Programm immer nach etwa einer Stunde
"aufhängt", hatte ich die Idee, es mal mit dem "Bello", seines Zeichens Wachhund, zu versuchen. Ebenso wollte ich mal testen, ob es an der Taktfrequenzgenerierung liegt, denn die geht beim "Absturz" auf Kilohertzwerte.
So habe ich im laufenden Betrieb den 4 MHz Quarz reingesteckt und den Jumper OSCSEL mal umgesteckt.
(Übrigens läuft der Programmer immer noch mit der 3,868 MHz Frequenz trotz Quarzwechsel.)
Daß sich tatsächlich die Taktfrequenz ändert, kann man schon daran erkennen, daß nach anderer Rechnung des Baudratenteilers der UART wieder auf "Normal"-Anzeige anstelle von "Hieroglyphen"-Darstellung umschaltet. Ebenso vollführt der "Bello" sofort einen Reset.
Also, ich verstehe das so, daß er auf die WDR-Anweisungen wartet, die ihm sozusagen als Leckerli immer wieder in regelmäßigen Abständen vorgelegt werden müssen, sonst reagierte er sauer und bellt los. Habe mal die WDRs mal testweise so gesetzt, daß ich sehen kann, wann das Programm wieder von vorne losläuft, das ist tatsächlich hier im 2-Sekundenrhythmus. Was zu beweisen war.

Wichtig ist noch, daß die Interruptfreigabe erst hinter der Wachhund-Initialisierung erfolgt, dann - entgegen einiger Darstellungen im Net- das WDCE-Bit bei Vorteilersetzen auf "low" stehen muß.
Hier der entsprechende Code-Abschnitt. Die WDRs sind dann testweise immer vor den Ausgaben und den Zeitschleifen gesetzt. Bis jetzt blinkert das Programm noch vor sich hin, hat noch keinen "Absturz" gegeben.


Im Bild noch der "aktive" Quarzwechsel im Hyperterminal, man erkennt deutlich, die Baudrate und korrekte Zeichendarstellung ist taktfrequenzabhängig.

Es grüßt,
Oskar, jetzt auch stolzer Wachhundbesitzer, gut gemacht "Bello". Platz und Sitz!