Hallo liebe µC-Programmierer, die von mir anvisierte Anwendung ist denkbar einfach. Der serielle Ausgang eines GPS-Moduls wird auf RXD (Pin14 / Port D.0) eines ATMEGA32 übergeben. Die Abfrage soll mit waitchar() geschehen - hier wird aber nichts erkannt. Um zu überprüfen, ob denn überhaupt irgendwelche Zeichen ankommen, habe ich mit ischarwaiting() mal auf den Port gehört und erhalte immer nur 0 zurück. Die elektronische Überprüfung (Oszi) des Ports ergibt, dass im Sekundentakt saubere Bursts gesendet werden. Wenn ich nun den Port mit dem Befehl "Serin" abfrage, kann ich einwandfrei Daten auslesen. Ich vermute, dass der serielle Port für die Anwendung mit waitchar() falsch konfiguriert ist. Auf einem ATMEGA8 hingegen läuft die Sache wie im Listing dargestellt. Was könnte hier falsch sein? Die wichtigsten Teile des Listings siehe hier: $regfile = "m32def.dat" $crystal = 8000000 $baud = 9600 $hwstack = 32 $swstack = 10 $framesize = 40 Dim S As String * 100 Dim H As Byte Config Serialin = Buffered , Size = 100 Cls Cursor Off Noblink Clear Serialin S = "" Serin S , 0 , D , 0 , 9600 , 0 , 8 , 1 H = Ischarwaiting(3) Cls Lcd H Waitms 500 Cls Upperline Lcd Left(s , 16) End Schöne Grüße & danke im Voraus Peter
Hallo, Peter! Scheinst ja viele Fragen zu haben. Nur zum Verständnis, weil ich nicht weiß, ob Du die µC z.B. in einem STK500 ausprobierst: PD0 ist bei beiden µC RxD, liegen aber auf verschiedenen Anschlüssen. Beim 32er ist es Anschluß 14, bei 8er Anschluß 2 (immer PDIP vorausgesetzt). Prüf das doch mal. Gruß - Wolfgang
Hallo Wolfgang, herzlichen Dank für die Antwort. Es handelt sich genau um die eine Frage, warum der eine Befehl (serin) funktioniert un der andere (waitchar) nicht. Die Pins sind richtig gelegt, denn sonst könnte ich mit dem serin-Befehl keine Daten auslesen. Der Mega8 ist in einem völlig anderen Board verbaut, funktioniert aber mit dem Befehl waitchr() und dem selben Schmitt-Trigger. Schöne Grüße Peter
... kann es sein, dass config serialin stört? Du willst ja eben keinen Buffer haben, sondern direkt reagieren. Nur mal so als Idee...
Hallo und danke für die Idee, hab´ ich gerade ausprobiert - kein Unterschied. Hätte mich auch gewundert: Beim ATMEGA8 habe ich diesen Befehl eingebaut, da sonst beim Abarbeiten der Unterroutinen Zeichen verlorengingen. Aber trotzdem danke für die Idee- jeder Beitrag ist kostbar. Schöne Grüße Peter
Hallo, > Die Abfrage soll mit waitchar() geschehen Es gibt in BASCOM keinen Befehl namens "Waitchar()". Meinst du vielleicht "Waitkey()"? Der blockiert so lange, bis EIN Zeichen über die serielle Schnittstelle kommt. Erst dann läuft das Programm weiter. "Waitkey" kann kein Null-Byte einlesen, da diese Null auch ein String-Ende ist. Dafür ist "Inkey()" mit "Ischarwaiting()" sinnvoller. > Wenn ich nun den Port mit dem Befehl "Serin" abfrage "Serin" erzeugt einen Software-UART an einem beliebigen Pin. Das könnte mit dem Hardware-Uart kollidieren. Warum dieser Befehl funktioniert und der HW-UART nicht, ist allerdings merkwürdig ... > H = Ischarwaiting(3) Dieses Kommando nimmt keinen Wert in den Klammern (es ignoriert ihn). Die Anzahl steht in der Variablen H. Meine Standard-Konfiguration für Hardware-UART-Kommunikation: - mit $baud=xxxx die Baudrate der UART einstellen - mit Config Serialin=xxxx kann der interruptgesteuerte Datenempfang aktiviert werden. ("Enable Interrupts" dabei nicht vergessen!) - zyklisch mit "Ischarwaiting()" den Buffer der UART prüfen; wenn Anzahl grösser Null, dann mit xxx = Inkey() ein Zeichen einlesen und fortlaufend in einem String oder Byte-Array speichern (je nach Typ der Variable "xxx"). Oder man wartet so lange, bis eine bestimmte Anzahl Bytes im Buffer sind und evtl. ein Timeout abläuft; dann kann man in einem Rutsch alle Bytes (einzeln) aus dem Buffer lesen. Diese Vorgehensweise habe ich schon häufig verwendet; bisher hatte ich keine Probleme mit dem Hardware-UART / den UARTS (wenn mehrere vorhanden). Im Übrigen gibt es in der BASCOM-Hilfe reichlich Beispiele für die UART-Kommunikation; irgendwas Passendes (und Lauffähiges) wird dort sicher dabei sein. P.S.: Die angegebene Taktfrequenz von 8MHz: wird sie mit einem Quarz erzeugt? Der interne RC-Generator könnte zu ungenau sein für den Hardware-UART.
Hallo Bascom-USer, natürlich hast Du Recht: Ich meine natürlich waitkey(). Das rührt daher, dass ich für den Atmega8, wo ja alles einwandfrei läuft, eine Subroutine mit dem Namen eingerichtet hatte. Ischarwaiting(3) stand nur deshalb im Listing, weil ich experimentiert hatte- ursprünglich war () angegeben. Die 3 wäre dann hilfreich, wenn es entsprechend viele Uarts geben würde. DIe Interrupts können nicht verantwortlich sein: Die habe ich im ursprünglichen ATMEGA8-Listing hinterlegt. Jetzt habe ich nochmals eine Gegenprobe gestartet: mit dem Tiny2313 klappt mein (natürlich dafür auf Minimalstversion gekürztes und modifiziertes) ATMEGA8-Listing auch einwandfrei. Bevor ich jetzt lange herumforsche, lese ich einfach einen kompletten Burst (dessen Länge in etwa immer gleich ist) mit serin aus und werde das Listing für den 32er entsprechend anpassen. Allerdings ist es sehr komisch, dass gerade der ATMEGA16 (habe ich auch gerade getestet) und 32 solche Mätzchen macht. Die Bascom-Hilfe ist in diesem Fall recht wenig hilfreich. Hier habe ich schon ein paar Listings "abgekupfert" umd ewr Sache auf die Spur zu kommen... Herzlichen Dank für Eure Unterstützung & "bis neulich" Peter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.