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