SoftwareFehler bei BASCOM AVR Basic, Befehl: Shiftin ????

[magluh]

SoftwareFehler bei BASCOM AVR Basic, Befehl: Shiftin ????

BASCOM AVR Compiler : Version 1.11.7.4 , DEMO

Ich möchte Daten von einem externen Gerät mit TTL Interface
in den ATmega8 einlesen.
Das TTL Interface liefert 2 Signale, das DatenSignal (DP) und den Takt (CP).

Es sollen die Daten (DatenBit) mit fallender Flanke (H/L) des TaktSignals eingelesen
werden. Allerdings scheint hier etwas nicht zu stimmen (???).
Werden die Daten (DatenBit) mit steigender Flanke (L/H) eingelesen, so ist alles OK.

Fallende Flanke: nicht OK
Steigende Flank: OK


Das DatenBit wird nicht richtig eingelesen, wenn das TaktSignal
von H/L geht (Optionen 4, 6).

Bei den Optionen 5 und 7 ist alles OK. Hier geht das TaktSignal
von L /H.

Der Fehler tritt nur bei der Datenübernahme auf, wenn das TaktSignal
von H/L geht.

.................................................. .................................................. ......
Da etwas nicht stimmt, habe ich mir eine kleine TestSchaltung aufgebaut.

Das DatenSignal wird einfach durch Anlegen der entsprechenden Spannungen
5 V (H) oder GND (L) erzeugt.

Das TaktSignal wird durch eine einfache Lichtschranke erzeugt, die einfach mittels
Finger unterbrochen wird, um ein prellfreies Signal zu erhalten.

( Siehe Code ganz unten )

Verbindung zum ATmega8:

DP ( DATA pulse) an Pind.5
CP ( CLOCK pulse) an Pind.6

Test 1 :
Option : 4
RESET
Pind.5 ( DP , DATA ) auf HIGH (5 Vcc)
CP (CLOCK) 5 Takte eingegeben
Ich erwarte 00011111 , Ich erhalte 00011111 (das ist OK)
dann sofort anschließend
Pind.5 ( DP , DATA ) auf LOW ( 0 Vcc) setzen
CP (CLOCK) abermals 5 Takte
Ich erwarte 00000000 , Ich bekomme aber 00010000 (nicht OK , warum 1 und nicht 0).
Der DatenPin (Pind.5) war die ganze Zeit auf Low. Folglich dürfte keine 1 auftauchen.


Test 2 :
Option : 6
RESET
Pind.5 ( DP , DATA ) auf LOW (0 Vcc)
CP (CLOCK) 5 Clock-Impulse
Ich erwarte 00000000 , Ich bekomme 00000000 (das ist OK)
dann sofort anschließend
Pind.5 ( DP , DATA ) auf HIGH ( 5 Vcc) setzen.
CP (CLOCK) 5 Clock-Impulse.
Ich erwart 11111000 , Ich erhalte 11110000 (nicht OK , eine 1 fehlt, warum 0 statt 1 )
Der DatenPin (Pind.5) war die ganze Zeit auf High. Es dürfte keine 0 auftauchen.
CP (CLOCK) erneut 5 Clock-Impulse
Ich erwarte 11111000 , Ich erhalte 11111000 ( das ist OK , keine 1 fehlt )

Test 3 oder 4
Option : 5 oder 7
Ich bekomme, was ich erwartet habe. Option 5 und 7 sind OK.
Es gibt hier keinen Fehler.


Schlussfolgerung
Der Befehl arbeitet immer dann fehlerhaft, wenn das TaktSignal von H nach L geht (Option 4, 6).
Der Befeh arbeitet immer dann fehlerfrei, wenn das TaktSignal von L auf H geht (Option 5, 7).

Frage: Ist der Compiler fehlerhaft oder mache ich einen Fehler ?
Kann mir jemand helfen ?

Luhmer
luhmerm@t-online.de


.................................................. ..............
'Test: SHIFTIN
'
$regfile = "m8def.dat"
$crystal = 3686400
$baud = 9600
Config Serialout = Buffered , Size = 255

Dim A As Byte

Config Pind.5 = Input ' DP (DATA Pulse)
Config Pind.6 = Input ' CP (CLOCK Pulse)

Portd = &B11111111

Do

A = 0
Shiftin Pind.5 , Pind.6 , A , 6 , 5 ' Option: 5 oder 7 OK , 4 oder 6 nicht OK
Print Bin(a)

Loop

End
.................................................. ............

[Michael]

Hallo magluh,


Shiftin Pind.5 , Pind.6 , A , 6 , 5 ' Option: 5 oder 7 OK , 4 oder 6 nicht OK

heißt es nicht:
SHIFTIN pin , pclock , var , option [, bits , delay ] ?
nur 5 Bits? kein Delay?
ist deine Clockleitung (bei Option 4+6) vorher High?
Gruß, Michael

Syntax
SHIFTIN pin , pclock , var , option [, bits , delay ]
Shiftin Pind.5 , Pind.6 , A , 4 , 5

In diesem Fall werden nur 5 Bits (5 Bit Code) eingelesen.
Kein DELAY .

Test 1: Erst High (5 Bit lang auf 5 Volt), Print Bin(a) gibt nach dem 5. Takt
(Clock-Signal) das Ergebnis über RS232 automatisch an den PC aus.
Anschließend sofort Pind.5 auf Low (GND, 0 Volt) setzen und erneut 5 Takte (Clock-Signale) eingeben. Es kommt ein falsches Ergebnis.
Irgendwo / irgendwie übernimmt er beim Wechsel von HIGH nach LOW
noch ein H-Bit, obwohl zum Zeitpunkt des Taktsignales bereeits ein LOW anliegt.

[Michael]

Hallo Gast (magluh?)

Kein DELAY .

warum nicht? Ein paar µS machen im Handbetrieb das Kraut nicht fett. Würden aber eventuelle Prellpegel bzw. zu langsame Pegeländerungen besser wegstecken.


Anschließend sofort Pind.5 auf Low (GND, 0 Volt) setzen und erneut 5 Takte (Clock-Signale) eingeben. Es kommt ein falsches Ergebnis.

Wie schaffst du das so schnell Pind.5 auf low zu setzen? Vor allem im richtigen Moment?
Vorschlag:
Nimm einen unbenutzten Port und und verbinde ihn mit dem (Daten-) Eingangsport (PinD.5)
vor dem "LOOP" schreibst du also:
Toggle Portx.y
so kannst du falsche (Handeingabe-) Pegel ausschließen.
Gruß, Michael

Hallo und Dank für die bisherigen Antworten.

Eigentlich möchte ich die Daten eines externen Gerätes in den ATmega8 einlesen. Dies gelingt mir aber nicht. Deshalb habe ich eine Ersatzschaltung aufgebaut, um den Fehler zu finden. Die Schaltung ist auf das Wesentlichste konzentriert. Dies ist das Signal für die Daten und das externe Taktsignal.

Wenn ich den Befehl SHIFTIN richtig verstehe, so kann ich auf eine negative Flanke des Taktsignales (H/L, Option 4 oder 6 ) als auch auf eine positive Flanke (L/H, Option 5 oder 7 ) das DatenBit übernehmen. Es funktioniert ja auch bei der positiven Flanke (L/H) mit meiner Testschaltung. Ich verstehe den Befehl SHIFTIN und seine Optionen so, daß in dem Bruchteil der MilliSekunde, indem der Pegel des Taktsignales von H nach L geht, das anliegende DatenBit auf H oder L abgetastet wird und übernommen wird.

Prellen oder ähnliche ungereimtheiten kann ich ausschließen, da nach 5
Taktsignalen (durch Hand) der Befehl SHIFTIN ausgeführt wird. Ich habe einen 5-Bit-Code eingestellt und nach 5 Taktsignalen (von Hand durch Unterbrechung einer Lichtschranke) erhalte ich das Resultat über RS232 auf dem PC. Prellen absolut nein !

Es dürfte bei dem Befehl SHIFTIN keine Rolle spielen, ob die Daten von einem Menschen manuell eingegeben werden oder von einem externen Bauteil kommen. Wichtig ist das Anliegen des DatenBits zum Zeitpunkt des Taktsignales.

MagLuh

[Michael]

Hallo Gast-MagLuh,

Prellen oder ähnliche ungereimtheiten kann ich ausschließen
woher nimmst du diese Sicherheit? Dein Datensignal mag zwar stabil auf High/Low liegen, spätestens beim nächstem Umschalten prellt es vielleicht doch, und das Umschalten schaffst du nicht so schnell.(siehe unten)
Obendrein könnte (theoretisch) dein Clockpegel so langsam kommen, so daß dein Clockpegel beim Umschalten eine kleine "Delle" oder "Überschwinger" kriegt und als weiterer Clock interpretiert wird. (Daher auch mein Vorschlag mit dem Delay)Gerade bei schnellen Signalen sollte man immer die analogen Aspekte im Auge behalten.


Wichtig ist das Anliegen des DatenBits zum Zeitpunkt des Taktsignales.

gut erkannt.
Wie kannst du also während der Zeit, also dem Ende des Befehls schiftin und dem Beginn des neuen schiftin, so schnell per Hand den Pegel wechseln???
Hast du meinen Tip aus dem letztem Post gelesen? :(
Gruß, Michael

Hallo Michael

..Wie kannst du also während der Zeit, also dem Ende des Befehls schiftin und dem Beginn des neuen schiftin, so schnell per Hand den Pegel wechseln....

Der Wechsel dauert mehrere Sekunden, da ich ein kleines Kabel am ATmega8 von H auf L oder von L auf H umstecke. Anschließend gebe ich dann wieder 5 TaktSignale ein.

Die Zeit dürfte aber keine Rolle spielen. Es gilt der Daten- Spannungspegel zum Zeitpunkt des Clock-Signales. Es funktioniert ja auch, wenn das ClockSignal von L nach H geht. Nur umgekehrt ist dieses Problem zu beobachten. Schließlich weiß der ATmega8 in einer Schaltung auch nicht, wann die Daten-Signal-Pegel wechseln. Er macht erst dann für eine kurze Millisekunde die Augen auf, wenn er den ClockImpuls erhält. Außerhalb dieser kurzen Millisekunde ist dem Prozessor alles egal.
Oder ? Oder ich habe alles falsch verstanden.


MagLuh

Hallo Michael

Nachtrag: Natürlich habe ich mit DELAY experimentiert. Leider ohne Erfolg.

MagLuh

[Michael]

Hallo Gast-MagLuh,
ich habe jetzt extra eine Schaltung mit einem Mega8 aufgebaut und kann bestätigen, daß es funktioniert. Sowohl mit Option 4, als auch mit 6.


Der Wechsel dauert mehrere Sekunden, da ich ein kleines Kabel am ATmega8 von H auf L oder von L auf H umstecke. Anschließend gebe ich dann wieder 5 TaktSignale ein.

Soso, hast du auch schon daran gedacht, daß der neuer Befehl schon abgearbeitet wird , während du noch den Pegel wechselst? Das versuchte ich dir aber schon in den letzten beiden Beiträgen zu sagen. :(
Zitat von gestern:
Wie kannst du also während der Zeit, also dem Ende des Befehls schiftin und dem Beginn des neuen schiftin, so schnell per Hand den Pegel wechseln???
Zitat Ende.
Zitat Nr.2:
Wie schaffst du das so schnell Pind.5 auf low zu setzen? Vor allem im richtigen Moment?
Zitat Ende.

Gruß, Michael

Hallo Michael

Das ist schon alles ein wenig sonderbar.
Das der Befehl schon teilweise abgearbeitet wird, da ich den Pegel wechsel, ist wohl ersichtlich. Aber genau das dürfte er nicht.

Der Pegelwechsel in einer elektronischen Schaltung kommt auch irgendwann und der Wechsel wartet auch nicht auf irgendwelchen Quellcode. Deshalb gibt es ja auch den externen Takt, der den Zeitpunk der Übernahme festlegt.

Ich habe das ganze noch einmal mit der positiven Logik (L/H) probiert.
Alles wunderbar, ich kann zu jedem Zeitpunkt den Pegel wechseln. Es kommt genau raus, wass ich auch als DatenBit eingegeben habe.
Die Schaltung ist die gleiche, lediglich die Optionseinstellung hat sich geändert.

Da Deine Schaltung arbeitet und meine nicht. komme ich an dieser Stelle wohl nicht weiter.

Wenn Du möchtest, dann könntest Du mir Deine TelefonNummer mailen.
Ich würde dann anrufen. Möglicherweise läßt sich mein Problem so lösen.

Bascom in Holland habe ich auch angeschrieben, aber die antworten nicht.
Es ist auch unwahrscheinlich, daß ich als Laie einen Bug entdecke.
Der Fehler wird wohl bei mir liegen.

Meine Email: luhmerm@t-online.de

MagLuh

[Michael]

Hallo MagLuh,

Das der Befehl schon teilweise abgearbeitet wird, da ich den Pegel wechsel, ist wohl ersichtlich. Aber genau das dürfte er nicht.

was ich dir schon seit einigen Postings sagen will:
Überleg doch mal, was passiert, wenn der letzte Takt (pclock=Pind.6) abgearbeitet ist!
Dein Programm sendet seine Daten (Byte A) seriell ab.
Danach springt das Programm mithilfe von LOOP sofort nach DO.
Dann findet es den Befehl Shiftin...
Das ganze passiert so schnell, daß du keine Chance hast, dazwischen den Pegel per Hand zu wechseln, glaub es mir einfach.
Gestern (10.11.04 20:16)schrieb ich dir, wie du dieses Problem deiner Testschaltung lösen könntest.Und was machst du?
Ohne das irgendwie zu testen schreibst du Bascom an, weil du glaubst, das Problem liegt bei denen.
Du solltest dein Problem mit deinen seriellen TTL-Daten nochmal überdenken und schreiben, was du wirklich willst :(
Oder hast du Angst, es klaut dir einer deine Ideen, wenn du es etwas ausführlicher beschreibst?
Gruß, Michael