mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART & Interrupt für Taschenrechnerkommunikation


Autor: Michael Frangenberg (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich hab vor etwa einer Woche mal mit Assembler angefangen, da ich einen
µC programmieren wollte, der die Kommunikation zwischen zwei
Taschenrechnern ermöglicht. Datenblatt und so weiter hab ich (und sogar
gelesen & größtenteils verstanden!).
Material:
- ATmega162 (wegen 2USARTs)
- 7,3728Mhz Quarzoszillator
- AVRStudio4, yaap
- Casio CFX-9850GB+
- Übertragungsprotokolle für GTR unter:
   http://users.pandora.be/gp/casio/index.html -> Information
-> Communication Protocol Between Casio and PC (CFX9x50 & Graph 25-65)
und -> Send( and Receive( commands + protocol


Das Prinzip: (GTR = grafikfähiger Taschenrechner)
Hinweis zum Programmtext: es geht vorläufig nur um einen GTR und damit
um USART 1 (nicht 0, den hab ich hier entfernt)!!!

Sobald der GTR zu Beginn 0x15 sendet, soll der µC mit 0x13 antworten.
Dazu habe ich einen Interrupt eingefügt (TXC), der den empfangenen Wert
mit 0x15 vergleicht. Wenn temp3=0x15 ist, dann sendet der µC 0x13 zurück
und setzt noch zwei Variablen auf 0. time2 zählt dann die Anzahl der
empfangenen bytes und darüber werden auch später die
Speicher-Subroutinen aufgerufen usw. Die Variable byte4 beinhaltet
später den in byte Nr4 empfangenen ASCII-Code (teil eines Headers), um
zu erkennen, ob der GTR Daten senden will oder Daten anfordert.
Die vier LEDs an PORTD hab ich nur zur Fehlersuche dran.

Nun das Problem: der GTR sendet 0x15, der µC erkennt das und sendet
irgendwas zurück, der GTR meldet sofort einen Fehler. WARUM???
Zum Test hab ich die LEDs an PORTD so konfiguriert, dass ich erkennen
kann, was der µC grade macht. Er geht offensichtlich in die
send_x13_2-Subroutine und sendet was, aber anscheinend irgendwas, was
dem GTR nicht gefällt.
Die Überprüfungsroutinen für UDRE hab ich rausgenommen, weil der µC da
irgendwie festhing und gar nix gesendet hat.

Könnte sich bitte mal jemand den Programmtext anschauen und Ideen
posten? Schon mal danke im Vorraus!
Ich meine, ich habe die Fusebits richtig gesetzt, aber zur Sicherheit
könnte mir ev. ein Profi noch mal sagen, wo die Häkchen hin müssen.

Autor: AndreasH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Programm ist zu komplex damit man Dir auf die Schnelle einen Hiweis
geben kann.

Du versuchst schon die fertige Lösung zu programmieren obwohl der
Anfang noch nicht geht.
Reduzier das erstmal auf die wesentlichen Routinen die am Anfang
notwendig sind. 0x15 empfangen 0x13 senden. Erst wenn das einwandfrei
geht, dann der nächste Schritt. Immer ein Stein auf dem anderen.

Ansonsten probier das ganze mal statt mit dem Casio mit einem PC und
Hyperterminal. Schick dem Controller ein 0x15 und sieh Dir an ob das
richtige passiert bzw. was zurückgeschickt wird.

Grüße
Andreas

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

du bist nich der StarTrekMichi oder?

das Programm ist ganz nett, hat aber ein paar kleine Haken. Wenn du so
weitermachst, reicht dein Programmspeicher nicht. Außerdem solltest du
den Header nicht im EEPROM ablegen, da er dynamisch ist und das EEPROm
nicht so oft beschreibbar ist. Am einfachsten du hängst den
Mikrocontroller mal an den PC und sendest per Terminal mal die 0x15 und
siehst ja dann was als Antwort kommt.
Wenn ich mein Programm finde schicke ich es dir mal.

Seb

Autor: Michael Frangenberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, das mit dem PC werde ich mal ausprobieren (muss mal so ne
9Pol-Buchse suchen).
Wo sollte ich den Header sonst hinspeichern?
Die beiden Header werden nicht verändert, die "DATEN" aber schon.
Sprich ich sollte um die Kommunikation nicht zu behindern das alles in
einen leicht erreichbaren Speicher schreiben. => welchen?

PS: der ATmega162 hat 16kb Flash, da geht schon was rein..
PPS: ich bin StarTrekMichi

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja aber die 16kb sind schnell voll. Naja egal.
Wenn du das Teil an den Pc schließt,vergiss den Pegelwandler nicht!

Ich hab die Daten in der Interruptroutine an ne Stelle im SRAM
geschrieben. In der Main hab ich die dann ausgelesen. Wenn 0x15 oder
0x16 kam, in ne routine Empfang gesprungen und 0x13 gesprungen. Die hat
nachgeschaut ob eine Zählervariable <=48 war. Wenn ja dann hab ich
nachgesehen was geschickt werden soll. Und so weiter. Leider verlies
mich dann die Zeit und dann der Taschenrechner. :-(
Das er dir sofort nen Fehler meldet, kann vieles sein. Die Übertragung
ner Variablen dauert nur Sekundenbruchteile. Hast du ähnliche Festures
geplannt wie ich oder nur ne reine Umsetzung des 0x15/0x16 Fehlers?

Seb

Autor: StatTrekMichi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Inzwischen liefert er keinen Fehler mehr, sondern arbeitet nur ewig (mit
dem Rechteck rechts oben in der Ecke). Er scheint auf was zu warten,
liefert aber erst einen Fehler, wenn ich die Versorgungsspannung am µC
entferne.
Hab grad leider keinen Pegelkonverter zur Hand und überleg mir grad
noch schnell einen zu kaufen.
Noch ne Frage: wie hast du die Daten in den SRAM geschreiben, ich
dachte nur der Stackpointer und die Register (r0-r31) sind da drin???
Wär natürlich deutlich eleganter.

Erst mal will ich nur eine direkte Datenübertragung einer Variablen
hinkriegen (klein anfangen) und dann schau mer weiter, weil wenn die
Kommunikation einmal funzt ist es bestimmt relativ "einfach" den
Programmtext zu erweitern.

Autor: Sebastian (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal einen meiner ersten Quelltexte angehangen. An meinem 162
hängt noch ein 512k SRAM dran, aber das weist du ja eh. Das Programm
macht nach dem einschalten erstmal nen Ramtest. Schreibt also in alle
externen Ramzellen ne Zahl und liest die wieder aus. Da kannst du sehen
wie man in den Ram schreibt. Im Tutorial auf der Seite hier ist das auch
erklärt. Wie der Ram aufgeteilt ist, sieht man gut im Datenblatt. Ich
such mal meine Sachen und dann schreib ich das mal rein. Hab ja schon
einiges gemacht und auch viele Fehler, die brauchst du ja nicht nochmal
machen.

seb

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast doch so ein PC-GTR Kabel, das kannst du auch ranhängen anstelle
des GTR um mit dem Computer zu testen.

Autor: StatTrekMichi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was für einen SRAM hast du da noch extern drangehangen (wenn ich so was
ausprobieren will, sollte ich den auch dran machen und vielleicht auch
jetzt gleich mitkaufen) oder reicht da vorlääufig der interne
1kb-SRAM?

schon mal danke für deine Hilfe!

Autor: StarTrekMichi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich werd mir jetzt das Tutorial, das Datenblatt und deinen
Programmtext noch mal genau durchlesen. Dann schau mer mal weiter. Ich
geh später noch mal online (ISDN-Zeittarif :-( ).
Du kannst mir ja auch alles mal gesammelt per email schicken.
Danke und bis später
 michi

Autor: StarTrekMichi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich hab das Programm jetzt umgeschrieben, dass ich am PC per
Hyperterminal sehen kann, was der µC macht. Alles läuft planmäßig bis
zu einem bestimmten Punkt:
     µC                GTR
                     0x15
 0x13
                 50 bytes header
 0x6
                 16 bytes daten
der µC speichert jetzt nur 6 bytes in den EEPROM und macht dann nix
mehr. Theoretisch müsste er nach den 16 bytes mit 0x6 bestätigen, mal
abgesehen davon, dass er alle 16 bytes abspeichern sollte und nicht nur
6.
Hat jemand eine Ahnung warum er das so macht???

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab nen einfachen von Reichelt genommen mit 512kb. Wenn ich
jetz wieder die Wahl hätte, würde ich wohl einen mit integrierter
Spannungsversorgung wählen. Maxim hat da tolle im Programm. So kann man
ein Programm auslagern und es bleibt erhalten. Geht zwar auch jetz aber
ist etwas umständlicher. Außer dem Ram hab ich auch noch nen Latch aber
das steht im Datenblatt was das für einer ist.
Seb

Autor: StarTrekMichi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab es gestern abend zum ersten Mal geschafft, eine Variable auf den
Chip zu senden!!! Dann hab ich das Programm um die Senderoutinen
erweiter und es funzte nicht mehr?!? Obwohl ich am Empfang nichts
verändert hatte. Laut PC-Diagnose (über den anderen UART) sendet der µC
die geforderten 0x13 zurück. Der GTR mag die aber wohl nicht mehr und
meldet einen Fehler. Weiß der Geier warum.
Übrigens danke für den SRAM-Tip, ich hab das schon gleich mal ins
Programm eingebaut. ich werd jetzt, um den Fehler einzugrenzen, mal ein
paar neue Programme schreiben, die dann Stück für Stück erweitert
werden...

Autor: StarTrekMichi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für die Tips es funktioniert jetzt

Autor: Gast1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was war falsch. nur weil ich neugierig bin und es andere auch
interessiert!!!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.