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
Hoffe das Bild sagt was aus. Edit upps 2 mal angehangen Edit
Evtl. hilft es etwas, wenn Du nach der fallenden Flanke auch wieder eine steigende Flanke abwartest, sonst ist beim ersten LOW schon alles durch...
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.
Laut Diagramm sind das 15 Bit je 100µs. Das sind bei 8MHz 53 Zyklen je Bit, das ist in C zu schaffen. Peter
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
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.
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
So sieht das bei meinen Messschiebern aus. Das deckt sich auch mit den Informationen aus dem Web.
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.
könnte eher -0.01 sein. Sag 'mal: verucht dein Analyzer irgendein Protokoll zu dekodieren? Der Datenkanal passt so nicht.
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
1,5 V ist bei einer Versorgungsspannung von 1,5V zu sehr auf Kante genäht. Stell 'mal 0,8 V ein.
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 einfach ist das garnicht. Alles schon verlötet. Kann allerdings die Kabel mal abklemmen. Erstmal noch nen Graph. Abgegriffen direkt vorm LM393
Diese Messung ist ohne LM393 Stromversorgung direkt vom STK500. Messschieber zeigt 0.00 an. Ich hoffe ich kriege keinen Ärger wegen der vielen Bilder.
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.
So sieht's gut aus - dann viel Erfolg mit dem Rest!
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
Vielen Dank an euch alle. Schaun wa mal obs klappt. gerry
1 | #include <avr/io.h> |
2 | #include <util/atomic.h> |
3 | |
4 | #define F_CPU 8e6
|
5 | |
6 | #include <util/delay.h> |
7 | |
8 | #include "sbit.h" |
9 | |
10 | #define CLK_PIN SBIT( PINB, 0 )
|
11 | #define DATA_PIN SBIT( PINB, 1 )
|
12 | |
13 | |
14 | uint32_t read_caliper( void ) |
15 | {
|
16 | uint32_t val = 0; |
17 | |
18 | ATOMIC_BLOCK(ATOMIC_FORCEON){ |
19 | for( uint8_t i = 20; i; i-- ){ |
20 | _delay_us( 4 ); |
21 | if( CLK_PIN == 0 ) // if CLK = 1 for >80us |
22 | i = 20; |
23 | }
|
24 | for( uint8_t i = 24; i; i-- ){ |
25 | while( CLK_PIN == 0 ); // wait until CLK = 1 |
26 | val <<= 1; |
27 | while( CLK_PIN == 1 ); // wait until CLK = 0 |
28 | if( DATA_PIN ) // read data |
29 | val |= 1; // lsb first |
30 | }
|
31 | }
|
32 | return val; |
33 | }
|
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.