24 Bit über Pin auslesen Takt/Daten ohne Interrupt

[Gerry (Gast)]

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

[Flo (Gast)]

Wie sieht das Signal genau aus?

[Gerry L. (Gast)]

Hoffe das Bild sagt was aus.

Edit
upps 2 mal angehangen
Edit

[Bernd R. (Firma: Promaxx.net) (bigwumpus)]

Evtl. hilft es etwas, wenn Du nach der fallenden Flanke auch wieder eine 
steigende Flanke abwartest, sonst ist beim ersten LOW schon alles 
durch...

[Gerry L. (Gast)]

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

[Walter (Gast)]

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 B. (falk)]

Meßschieber auslesen

[Gerry L. (Gast)]

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]

[Gerry L. (Gast)]

> 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

[Einhart P. (einhart)]

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

[Einhart P. (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.

[Peter D. (peda)]

Laut Diagramm sind das 15 Bit je 100µs. Das sind bei 8MHz 53 Zyklen je 
Bit, das ist in C zu schaffen.


Peter

[Einhart P. (einhart)]

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 ;-)

[Peter D. (peda)]

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

[Einhart P. (einhart)]

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.

[Gerry L. (Gast)]

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

[Gerry L. (Gast)]

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

[Peter D. (peda)]

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

[Peter D. (peda)]

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

[Einhart P. (einhart)]

So sieht das bei meinen Messschiebern aus. Das deckt sich auch mit den 
Informationen aus dem Web.

[Gerry L. (Gast)]

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

[Karl H. (kbuchegg)]

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

[Gerry L. (Gast)]

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

[Karl H. (kbuchegg)]

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

[Gerry L. (Gast)]

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.

[Karl H. (kbuchegg)]

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.

[Einhart P. (einhart)]

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.

[Gerry L. (Gast)]

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 :)

[Karl H. (kbuchegg)]

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)

[Einhart P. (einhart)]

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.

[Gerry L. (Gast)]

Auf der Anzeige steht nun 0.01

[Einhart P. (einhart)]

könnte eher -0.01 sein. Sag 'mal: verucht dein Analyzer irgendein 
Protokoll zu dekodieren? Der Datenkanal passt so nicht.

[Gerry L. (Gast)]

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

[Einhart P. (einhart)]

1,5 V ist bei einer Versorgungsspannung von 1,5V zu sehr auf Kante 
genäht. Stell 'mal 0,8 V ein.

[Gerry L. (Gast)]

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

[Einhart P. (einhart)]

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.

[Gerry L. (Gast)]

So einfach ist das garnicht. Alles schon verlötet.
Kann allerdings die Kabel mal abklemmen.

Erstmal noch nen Graph. Abgegriffen direkt vorm LM393

[Gerry L. (Gast)]

Diese Messung ist ohne LM393 Stromversorgung direkt vom STK500.
Messschieber zeigt 0.00 an.

Ich hoffe ich kriege keinen Ärger wegen der vielen Bilder.

[Gerry L. (Gast)]

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.

[Einhart P. (einhart)]

So sieht's gut aus - dann viel Erfolg mit dem Rest!

[Peter D. (peda)]

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

[Gerry L. (Gast)]

Vielen Dank an euch alle.

Schaun wa mal obs klappt.

gerry

[Peter D. (peda)]

#include <avr/io.h>
#include <util/atomic.h>

#define F_CPU   8e6

#include <util/delay.h>

#include "sbit.h"

#define CLK_PIN         SBIT( PINB, 0 )
#define DATA_PIN        SBIT( PINB, 1 )


uint32_t read_caliper( void )
{
  uint32_t val = 0;

  ATOMIC_BLOCK(ATOMIC_FORCEON){
    for( uint8_t i = 20; i; i-- ){
      _delay_us( 4 );
      if( CLK_PIN == 0 )                        // if CLK = 1 for >80us
        i = 20;
    }
    for( uint8_t i = 24; i; i-- ){
      while( CLK_PIN == 0 );                    // wait until CLK = 1
      val <<= 1;
      while( CLK_PIN == 1 );                    // wait until CLK = 0
      if( DATA_PIN )                            // read data
        val |= 1;                               // lsb first
    }
  }
  return val;
}

Peter

[Gerry L. (Gast)]

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

[Einhart P. (einhart)]

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