Forum: Mikrocontroller und Digitale Elektronik ATMEGA 32 und RXD (BASCOM)


von Peter (Gast)


Lesenswert?

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

von Wolfgang (Gast)


Lesenswert?

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

von Peter (Gast)


Lesenswert?

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

von Klugscheisser (Gast)


Lesenswert?

... kann es sein, dass config serialin stört?
Du willst ja eben keinen Buffer haben, sondern direkt reagieren.
Nur mal so als Idee...

von Peter (Gast)


Lesenswert?

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

von BASCOM-User (Gast)


Lesenswert?

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.

von Peter (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.