Forum: Mikrocontroller und Digitale Elektronik Bytes empfangen über FT232RL - Bascom


von Lazlo Panaflex (Gast)


Lesenswert?

Guten Abend,

ich versuche vergeblich, mit einem Atmega88 + FT232RL Bytes zu 
empfangen, die von einem PC gesendet werden. Zu Testzwecken habe ich 
folgenden Code geschrieben und lasse den PC alle 33ms ein "S" (ASCII 
115) senden. Demnach sollte die Steuerungssoftware des PCs alle 33ms 
"01110011" ausgeben.

Sobald der uC irgendetwas empfängt, sollte die LED an Pinb.1 an  bzw 
ausgehen. Im Hyperterminal tut sie das. Nicht aber, wenn ich sie an die 
Steuerungssoftware anschließe.

Wäre klasse, wenn mir jemand einen Tipp geben könnte, wo es klemmt.

--

$regfile = "m88def.dat"
$crystal = 8000000
$baud = 19200

Config Serialin = Buffered , Size = 20
Config Pinb.1 = Output
Led Alias Portb.1

Dim A As Byte

Enable Interrupts

Do
A = Inkey()
If A <> 0 Then
Toggle Led
End If
Loop
End

--

von Justus S. (jussa)


Lesenswert?

Lazlo Panaflex schrieb:
> Im Hyperterminal tut sie das. Nicht aber, wenn ich sie an die
> Steuerungssoftware anschließe.

dann dürfte der Fehler aber doch eher in deiner Steuerungssoftware 
liegen und nicht im µC-Code...

von Lazlo Panaflex (Gast)


Lesenswert?

An der Software liegt es nicht, die tut es seit Jahren. 
http://www.x-simulator.de/wiki/Read_more_about_the_Universal_Serial_Output_%28USO%29

von Spezi (Gast)


Lesenswert?

Hallo,

hast Du geprüft, ob die Steuer-Software tatsächlich Daten auf der 
seriellen PC-Schnittstelle ausgibt (Schnittstellen-Tester, Scope)? Und 
wenn ja, was kommt am RX-Pin des Controllers an? (am besten mit Scope 
prüfen)

BTW: Die Taktfrequenz von 8MHz deutet ein wenig auf die Benutzung des 
internen RC-Oszillators vom AVR hin. Dieser hat allgemein aber eine zu 
hohe Toleranz für serielle Übertragungen; hier wäre ein externer 
(Baudraten-) Quarz deutlich besser, insbesondere bei längeren 
Telegrammen.

von Lazlo Panaflex (Gast)


Lesenswert?

Der uC läuft tatsächlich mit dem internen RC. Ich wusste nicht, dass das 
bei serieller Übertragung eine Rolle spielt. Werde ihn "fusen" und einen 
Quarz anstecken.

Ein Scope müsste ich mir von der Arbeit mitnehmen, was aber kein Problem 
darstellt.

Aber am Code liegts nicht? Keine groben Schnitzer drin? Oder gibt es 
noch eine elegantere Methode, als Inkey (welche ich aus der BASCOM Hilfe 
habe).

von Spezi (Gast)


Lesenswert?

Um festzustellen, ob ein Zeichen empfangen wurde, ist "Inkey" geeignet; 
nur wenn das empfangene Zeichen eine binäre Null ist, kann "Inkey" 
dieses Zeichen nicht erkennen. Dann geht man anders vor; dies ist in der 
BASCOM-Hilfe bei "Inkey" unter dem Verweis "Ischarwaiting" zu finden. 
Damit liegt man dann auf der sicheren Seite.

Für Deine Tests (Senden des ASCII-Zeichens "S") reicht das Programm 
allemal (zumal der serielle Buffer von BASCOM, also interrupt- 
gesteuerter Empfang, aktiviert ist).

von Lazlo Panaflex (Gast)


Lesenswert?

Danke. Ich kanns leider gerade nicht testen. Melde mich morgen, obs 
geklappt hat.

von Spezi (Gast)


Lesenswert?

Bitte noch mal folgendes prüfen:

Da Deine Tests mit Hyperterminal funktioniert haben, mit der 
Steuersoftware aber nicht, probiere mal dort eine kleinere Wiederholrate 
des Telegramms (z.B. 200ms). Wird dann etwas vom Controller erkannt?
Ich schätze mal, dass mit dem HyperTerminal von Hand keine 33ms 
Wiederholrate hinzubekommen ist ...

Wenn da auch nichts erkannt wird, kommen wir ums Scope nicht herum ...

von Bernd T. (bastelmensch)


Lesenswert?

Hi,

also ich würde das ja so lösen, das ich den Empfang per Interrupt 
auswerte.

Warten und nachschauen ob was per RS232 reinkommt ist 
Resourcenverschwendung.

Gruß

von Lazlo Panaflex (Gast)


Lesenswert?

Hast du ein Beispiel für mich? Bin nicht sonderlich fit in Bascom - 
arbeite mich noch ein.

@Spezi: Danke, werd ich checken.

von Spezi (Gast)


Lesenswert?

Hallo,

> also ich würde das ja so lösen, das ich den Empfang per Interrupt
> auswerte.

Genau das macht BASCOM ja mit dem Befehl "Config Serialin = Buffered, 
Size = ... ".
Normalerweise muss man selbst (per Polling) die Schnittstelle nach Bytes 
abfragen. Durch diesen Befehl wird die BASCOM-Empfangs-Routine auf eine 
ISR umgeschaltet, die im Hintergrund serielle Daten empfängt und sie im 
definierten Buffer ablegt.
Im Hauptprogramm (das ja in der Regel zyklisch abläuft) wird mittels 
einer Funktion geprüft, ob Daten im Buffer sind. Wenn ja, kann man sie 
einlesen und bei Bedarf auswerten.

> Warten und nachschauen ob was per RS232 reinkommt ist
> Resourcenverschwendung.

Gewartet wird hier bei der Funktion überhaupt nicht; sie prüft ein Flag, 
das die ISR setzt, wenn Daten im Buffer sind.
BASCOM bildet hier einen seriellen FIFO nach, in dem die per Interrupt 
eingelesenen Daten gesammelt werden. Die Grösse des FIFO wird beim 
Config-Kommando übergeben.

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.