Hallo,
leider bekomme ich es nicht alleine hin das ich die Daten die von einem
Messschieber gesendet werden in einen Atmega32 eingelesen werden.
Die verschiedenen Threads hab ich mir bereits durchgelesen. Auch das
2x24 Bit Protokoll hab ich mir angesehen.
Per Logicport kann ich sehen das die Daten am Pin ankommen. Aber ich hab
keine Idee mehr wie ich diese vernünftig einlesen kann ohne das ich
Extern Int benutze was auch nicht möglich ist da diese Pins belegt sind.
Takt liegt an PA0 und Daten an PA1 an.
Mein bisheriger Versuch:
Warte auf Takt High - warte auf Takt Low - lese 48 Bits
void readBit(void)
{
static uint8_t counter=0;
counter++;
while(PINA & (1<<PA0)); //Warten auf fallende Flanke
if(counter==49) counter=0;
if(counter>=25){
buf[counter-25]=(PINA & (1<<PA1)); // Bit lesen
}
}
in main wird das so aufgerufen
if(PINA & (1<<PA0)) readBit(); // Falende Flanke ?
Ich hab nun keine Ahnung mehr wie ich weiter vorgehen soll bzw. fehlts
mir hier an Wissen.
Vieleicht hat ja jemand so etwas schon getan und würde mir helfen.
Gerry
Bernd Rüter schrieb:> Evtl. hilft es etwas, wenn Du nach der fallenden Flanke auch wieder eine> steigende Flanke abwartest, sonst ist beim ersten LOW schon alles> durch...
Ich weiss nicht ganz wie Du das meinst. Er wartet in main auf eine
steigende Takt Flanke. Da ist der Source falsch, muss heissen
if( ! (PINA & (1<<PA0))) readBit(); // Steigende Flanke
Jetzt ist klar das Bits kommen nun soll er alle 48 Bits lesen.
Und genau hier komm ich nicht weiter...
Gerry
Gerry L. schrieb:> Bernd Rüter schrieb:>> Evtl. hilft es etwas, wenn Du nach der fallenden Flanke auch wieder eine>> steigende Flanke abwartest, sonst ist beim ersten LOW schon alles>> durch...>> Ich weiss nicht ganz wie Du das meinst. Er wartet in main auf eine> steigende Takt Flanke. Da ist der Source falsch, muss heissen
er meint wohl dass du auch im UP den Takt abfragen musst ...
Falk Brunner schrieb:> Meßschieber auslesen
Mensch Falk, Du warst doch auch schon gesprächiger. Die Links hab ich
durch auch die Beispiele dazu nur helfen diese mir nicht weiter. Meine
Hardware Vorraussetzungen sind leider andere. Schön wäre ein Shiftin wie
bei Basic aber wer will schon Basic.
Meine Gedanken mal.
Testen ob Takt High - wenn ja Bits lesen gehen.
(Die Bits werden immer bei Falender Flanke gelesen.)
Also warte bis Takt wieder Low
Wenn Takt Low dann counter++ dann kucken was Datenpin sagt und diesen
einlesen.
Nach counter 49 sollten alle Bits gelesen sein.
So hatte ich mir das eigentlich gedacht nur so bekomm ich es nicht
gebacken.... :(
Gerry
[Edit]
Beim oberen Bild müsste eigentlich für die erste Sequenz folgendes
rauskommen
1 0 0 1 0 1 1 0 1 1 0 1 0 1 1 1 1 1 1 1 1 1 1 1
[Edit]
> er meint wohl dass du auch im UP den Takt abfragen musst ...
Vieleicht mit einer Schleife
Z.Bsp.
void readBit(void)
{
static uint8_t i;
for(i=0;i<49;i++){
while(PINA & (1<<PA0)); //Warten auf fallende Flanke
buf[i]=(PINA & (1<<PA1)); // Bit lesen
}
}
Gerry
Hallo Gerry,
das Übernehmen der Daten ist recht zeitkritisch. Bei einem Prozessortakt
von 8 MHz habe ich das in AVRco Pascal nicht hinbekommen. Da brauche ich
Assembler um die Schiebeoperationen in Arbeitsregistern ablaufen zu
lassen. Interrupts habe ich während der Übernahme der 24 Bit gesperrt.
Ich weiß nicht, ob das baim C-Compiler wesentlich besser aussieht.
Gruß
Einhart
... noch etwas:
Du musst natürlich erst den Start der Übertragung detektieren. Z.B. 70
µs logisch 1 auf der Taktleitung. Das wäre dann der Start der zweiten 24
Bit, die den auf dem Display gezeigten Wert darstellen.
Sagen wir 'mal 45 Takte. Die billigen Messschieber streuen bestimmt beim
Timing. Eine Lösung in C wäre interessant. Vielleicht werde ich ja doch
noch zum C-Anhänger ;-)
So, wie das Diagramm aussieht, werden die Daten an beiden Flanken
übertragen.
Stimmt das?
Kannst Du mal mit höherer Auflösung darstellen, damit man den
Zeitabstand zwischen Daten und Takt sieht.
Peter
Peter Dannegger schrieb:> Laut Diagramm sind das 15 Bit je 100µs. Das sind bei 8MHz 53 Zyklen je> Bit, das ist in C zu schaffen.>>> Peter
Nein, sind schon 24 Takte pro Sequenz. Das Bild ist sehr Breit
vielleicht musst du das Bild nur vergrössert darstellen lassen. Beim IE
mit den Pfeil Symbol rechts unten im Bild.
Ich kann aber gerne eine vergrösserte/Zoom Darstellung posten wenn du
möchtest.
Gerry
Einhart Pape schrieb:> Nein, Daten werden mit der negativen Flanke übernommen. Das LSB kommt> zuerst. Das Format ist 24 Bit binär. Das Erste 24 Bit Paket kann man> ignorieren.
Ja richtig ist auch gut zu erkennen das Pro Low Takt ein Bit entweder
High oder Low ist.
Der Atmega32 werkelt mit 16 MHz also sollte es kein Problem in c sein.
Gerry
Gerry L. schrieb:> Nein, sind schon 24 Takte pro Sequenz.
Ja, aber das Signal ändert sich an beiden Flanken.
Einige High-Signale sind auch nur kurz um die steigende Flanke an.
> Ich kann aber gerne eine vergrösserte/Zoom Darstellung posten wenn du> möchtest.
Wo man auch den zeitlichen Abstand zwischen Daten- und Takt-Flanke sehen
kann.
Peter
Einhart Pape schrieb:> Nein, Daten werden mit der negativen Flanke übernommen.
Da sich das Signal aber auch an der fallenden Flanke ändert, muß man
dann aber vor der Flanke einlesen.
> Das Erste 24 Bit Paket kann man> ignorieren.
Und wie erkennt man das erste Paket?
Peter
Ich hab mal einen Auschnitt vergrössert darstellen lassen.
Man sieht schön das ein Bit immer nach der Fallenden Flanke kommt.
In dem Fall wäre es Binär 111010.
Meine Graphik deckt sich mit denen von Einhart Pape.
Nun die erste Steigende Flanke ist ca. 51 us sekunden Lang dan kommen
die Takte in Abständen von genau 24 x 17 us dann kommt eine High Flanke
von
110 us nun folgen die letzten 24 Bit.
Gerry
Gerry L. schrieb:> Ich hab mal einen Auschnitt vergrössert darstellen lassen.> Man sieht schön das ein Bit immer nach der Fallenden Flanke kommt.
Ich weiß nicht woran du das siehst. Ich seh da ganz was anderes.
Ich frage mich zb, warum es auf der Datenleitung 3 verschiedene
Pulsformen gibt:
ein breiter Puls
ein schmaler Puls
gar kein Puls
> In dem Fall wäre es Binär 111010.
und wie du da drauf kommst, ist mir völlig rätselhaft. Wenn ich mir in
der oberen Leiste die fallenden Flanken raushole, dann ist dort jeweils
in der untersten Leiste das Datensignal eine 0.
Wenn da überhaupt irgendetwas anders als Dauer-0 kodiert ist, dann ist
für mich die steigende Flanke diejenigte welche und die
unterschiedlichen Pulsbreiten sind Zufall oder Messfehler vom
Logikanalysator und haben nichts weiter zu bedeuten. Aber das ist IMHO
Karl heinz Buchegger schrieb:> Gerry L. schrieb:>> Ich hab mal einen Auschnitt vergrössert darstellen lassen.>> Man sieht schön das ein Bit immer nach der Fallenden Flanke kommt.>> Ich weiß nicht woran du das siehst. Ich seh da ganz was anderes.> Ich frage mich zb, warum es auf der Datenleitung 3 verschiedene> Pulsformen gibt:
Soweit ich das Protokoll des Messschiebers verstanden habe spielt die
Dauer der Pulse auf der Datenleitung keine Rolle. Natürlich dauert der
Puls nur ein Takt lang und das tut er ja auch. Spätestens vor dem
nächsten Takt ist der Puls wieder Low. Es kommt also nicht auf die Dauer
des Puls an sondern ob Innerhalb eines Taktes der Puls High oder Low
ist.
> ein breiter Puls> ein schmaler Puls> gar kein Puls
Wäre also
1
1
0
Gerry
Gerry L. schrieb:> Soweit ich das Protokoll des Messschiebers verstanden habe spielt die> Dauer der Pulse auf der Datenleitung keine Rolle.
OK.
Bleibt immer noch die Frage, wie du an den fallenden Flanken etwas
anderes als 0 erkennen kannst. Ich hab mal in dein Diagramm die
Positionen eingezeichnet. Sorry: Aber in jedem einzelnen Fall ist zu
diesem Zeitpunkt das Datensignal eindeutig auf 0. Die Pulse spielen sich
alle rund um die steigenden Flanken ab.
Edit: Sorry für das JPG
Ich hab mal meine Interpretation des Signals gezeichnet.
Vieleicht bin ich ja auch auf dem völlig falschem Weg.
Wichtig ist halt das immer nach der Fallenden Flanke die Datenleitung
gelesen wird undzwar bis zur nächsten Steigenden Flanke. Ist nun in
diesem Zeitraum Signal auf Low ist es eine 0 ist das Signal High ist es
eine 1.
Gerry L. schrieb:> Ich hab mal meine Interpretation des Signals gezeichnet.> Vieleicht bin ich ja auch auf dem völlig falschem Weg.
Du hast da einen Denkfehler:
Entscheidend ist normalerweise nicht, was das Signal von einer Flanke
zur nächsten macht, sondern welchen Zustand die Datenleitung genau zum
Zeitpunkt der Flanke hat!
Die Flanke definiert einen Zeitpunkt, an dem die Datenleitung per
Defintion einen gültigen Zustand angenommen hat. Was sie dazwischen
macht interessiert nicht.
So ist das meistens. Der Fairness halber muss man aber auch sagen, dass
es auch andere Protokolle gibt. Das sieht aber dann das 0-Byte anders
aus.
Gerry, ich glaube du bist nicht auf dem richtigen Weg. Was du da als
Datensignal zeigst, das deckt sich nicht mit dem 2*24 Bit
Chinesenprotokoll - auch nicht mit meinem Grafen.
Du hast irgendein Problem mit dem Datensignal. Ich habe schon die Daten
von einigen verschiedenen Messchiebern gesehen. Keiner hatte das von dir
gezeigte Signal.
Och nö oder?
Ich hab jetzt mal an den Einstellungen der Software gespielt.
Im Bild sind die 2ten 24 Bits dargestellt. Auf dem Messchieber steht
0.00
Aus meiner Sicht stimmt alles bis auf das ich scheinbar nicht an der
Fallenden sondern an der Steigenden Flanke die Datenleitung lesen muss.
Vielen Dank das ihr euch meiner annehmt :)
Gegentest:
Versuch den Messchieber minimalst zu verfahren. Ideal wäre 1
Hundertstel, aber ich schätze mal, das wird nicht gehen.
Ansonsten irgendein anderes Mass (nicht zu groß). Mass + Logikprotokoll
wären interessant.
Wenn geht eine 2te derartige Vergleichsmessung vornehmen (damit man die
Hypothese aus der ersten Messung kontrollieren kann)
Gut, fangen wir'Äs anders an: Hast du die ´Triggerschwelle richtig
gesetzt?
Auch bei Display 0.00 schwanken die unteren Bits in der Schnittstelle.
Die 24 Bit Auflösung ist größer als die der Anzeige.
Pulse auf der Datenleitung, die kürzer sind als die auf der Taktleitung,
sind Störungen und kein Nutzsignal.
Einhart Pape schrieb:> Gut, fangen wir'Äs anders an: Hast du die ´Triggerschwelle richtig> gesetzt?
1,5 V Abtastrate 50 MHz
Das einzige was Zappelt sind die Bits in den ersten 4 Takten die letzten
20 bleiben konstant. Und das bei beiden 24er Sequenzen. Da ja das LSB
zuerst kommt nehme ich mal an das es normal ist da die Auflösung zu groß
ist.
Mist ich sehe gerade das auf dem Messschieber Profitexx steht und ich
glaube da mal gelesen zu haben das die ein extra Protokoll haben.
Edit
wusst ich doch
laut
Beitrag "Re: Interface für 10€- Messschieber"
2x24 Bit also ganz normal oder ?
Edit
Hallo Einhart,
ich hoffe du haust mich jetzt nicht. Alle Bilder oben sind am Port des
Atmega nach dem LM393 aufgezeichnet.
Das Bild ist nun direkt am Messschieber vor dem LM393 abgegriffen.
Schwellwert ist 0,7 und das Bild sieht komplett anders aus.
Da zappelt auch nix mehr.
Anzeige auf dem Messschieber immer noch 0.01 mm
Nun weiss ich echt nicht mehr weiter.
Edit
Sorry
Gott sei dank Zappelt immer noch
Edit
jau, sieht vorn schon ganz richtig aus. Allerdings gefallen mir die dann
fogenden kurzen Einbrüche auf Null nicht so ganz. Das Auswerten mit der
fallenden Flanke würde aber schon klappen.
Ich habe übrigens keinen Komparator in der Schaltung. Die
Messschiebersignale liegen direkt am Controllereingang (Mega88,Vcc 3,3
V). Die Versorgung des Messchiebers ist per Diode hochgelegt auf 0,7V.
Das läuft bisher mit 4 verschiedenen China-Modellen.
Klemm doch 'mal den Komparator ab und guck das Signal nocheinmal an.
So nun noch den Graph am Atmegaport.
Nachdem ich den Schwellwert am LM393 neu eingestellt habe (0,65V) bekomm
ich nun endlich identische Graphen.
Ich hoffe der Rest ist einfacher.
Na die letzten Bider sehen vernünftig aus, die Signale sind bei low
stabil. Also erst etwa 80µs high abwarten und dann 24 mal nach der
fallenden Flanke einlesen.
Peter
Hallo Peter,
vielen Dank für den Codeschnippsel.
Leider kann ich diesen nicht wirklich testen da mir der LM393 Sorgen
bereitet. Ich bekomme einfach kein ordentliches Signal hinten raus.
Ständig pfuschen irgendwelche Spitzen/Spikes dazwischen.
Gerry
Moin Peter,
dein Code funktioniert und ist schnell. Man muss am Ende nur noch das
Vorzeichen anpassen. Wenn Bit 23 = 1 ist, dann muss das ganze MS-Byte
(Bits 24..31) invertiert werden.
Vielen Dank
Einhart
