Decoderschaltung für Drehimpulsgeber

Hmm...ich denke, das der genannte wert die register sprengt. Jedes byte max 255
Addi
 
Ich bekomme da eine ganz andere Zeit raus..
@dino03 : Sind die Routinen gestestet? Meiner Meinung nach sind bei der Berechnung der Schleifen(takten) bei den bei den BRNEs je die Takte für true und false vertauscht, man müßte auf 256*((256*3-1)+3)-1+17 kommen...
Das paßt dann auch eher zu Jans 197K-Takten.

Bei Controllern mit sehr viel Flash (22bit-PC) kostet RCALL einen Takt mehr, ruft man die Routine mit CALL statt RCALL auf, kostet das auch einen Takt mehr. Beides zusammen wären dann sogar zwei Takte mehr.
Beim RETI ebenso.
Beim reduced Tiny Core kosten die RCALLs auch 4 Takte.
Aber das sollte ja nicht so ins Gewicht fallen...
 
Hi,

@dino03 : Sind die Routinen gestestet?
die Assemblerroutinen hab ich eigentlich vor meiner Bascom-Zeit immer so verwendet. Die Programme liefen.
Ob die Zeiten nun wirklich genau waren müßte ich jetzt nachrechnen. Ich hab die Angaben für die Befehlslaufzeiten
aus den Daten von Atmel geholt. Kann schon sein das da in den Anfangszeiten kleine Böcke reingekommen sind.
Mit den Routinen habe ich auch das Timing von 1Wire-Bus, LCD-Ansteuerung und anderen Dingen erledigt.
Spätestens beim 1Wire-Bus wäre falsches Timing aufgefallen.

Gruß
Dino
 


CodeBox Assembler
;                    2__________131841_                      
;                    |    1__513__     |                      
;                    |    |       |    |                      
;         12 Cycle = 256*((256*2+1)+2)+1+17
loop8m: dec r20        ; (1)     || niedrigstes Byte -1
        brne loop8m     ; (1f,2t)_/| 0 erreicht? nein -> Schleife
        dec r21        ; (1)      | mittleres Byte -1
        brne loop8m     ; (1f,2t)__/ 0 erreicht? nein -> Schleife
Mal nur die innere Schleife betrachtet: Dec kostet einen Takt, Brne kostet wenn die Bedingung wahr ist, und der Sprung (zurück) erfolgt zwei Takte. so hast Du es auch kommentiert. Also hast Du 256mal Dec und 255mal Brne(true) und einmal Brne(false).
256*1+255*2+1 oder eben (256*3)-1

Dasselbe dann nochmal bei der äußeren Schleife.
 
Die Abfrage des Drehimpulsgebers durch den "Hauptprozessor" (ATMega8) wollte allem sportlichen Ehrgeiz zum Trotz einfach nicht zuverlässig klappen und so habe ich das "Problem" irgendwann einfach ausgelagert.

Der war allerdings schon mit anderen Aufgaben gut beschäftigt und auch etliche Prozessorbaugruppen waren schon anderweitig in Benutzung.
Im wesentlichen braucht man da ja eigentlich einen Timer. Wenn kein vorhandener nativer Timer nutzbar ist (aus welchen Gründen auch immer), hier noch ein paar "alternative", unkonventionelle Ansätze:
  • Der U(S)ART-Transmitter läßt sich quasi als Timer mißbrauchen, je nach gewählter Baudrate und Bit-Anzahl läßt sich die Zeit bis der IRQ zuschlägt vorgeben. Belegt (neben dem Transmitter) den TxD-Pin.
  • Ebenso beim SPI, hier werden MISO, MOSI und SCK belegt. Außerdem ist der CS-Pin zu beachten (zwingt den AVR ggf in den Slave-Mode).
  • Der ADC kann einen "hab fertig IRQ" triggern,
  • Bei einigen Controllern kann der Watchdog alternativ zum Reset auch einen IRQ triggern.
So, jetzt mal eine andere Frage:
@Pirx urspünglicher Ansatz bezieht sich ja auf die Gatter-Verschaltung mit den Flip-Flops und ein paar XORs.
Müßte sich das nicht auch irgendwie mit der Configurable Custom Logic (und ggf des Eventsystems) der XMegas/XTinies machen lassen?
Wenn ja, ich komm nicht drauf... Es stehen quasi zwei Logik-Kanäle zur Verfügung, die je drei Eingänge mit einem Ausgang verknüpfen.
Als Eingang kann ein Pegelwechsel eines Pins genutzt werden (Event).
Interessant wäre 'ne Lösung, die "Schritt-Links" oder "Schritt-Rechts" liefert.

Da die XTinies für konventionelle AVR-Mega/Tiny-Assembler-Programmierer wie mich eh sehr ... gewöhnungsbedürftig sind (Register/Bitnamen), denke ich weiterhin über einen seperaten Encoder-Auswerte-Tiny nach.
Neben der Entlastung des Hauptcontrollers gehts mir auch um das Einsparen von Controllerpins - der Encoder-Tiny sendet die Information asynchron seriell (UART).
Mein Ansatz läuft auf den Tiny4/5/9/10 hinaus (SOT23-6), Es stehen vier Beine zur Verfügung, wenn der Reset als I/O genutzt wird. Eins als Datenausgang, zwei für den Drehgeber - bleibe eins für den eventuellen Taster. Da der Tiny über kein HW-Interface verfügt, müßte ein UART-Transmitter in Software gestrickt werden (mit einem Timer für Transmitter und Encoder-Sampling).
Halbwegs elegant scheint das ganze sich mit sechs zu übertragenden Bits handhaben zu lassen, da man Start- und Stopbit dann mit den sechs Bits in ein Register packen kann. Wegen dem Stopbit wäre ein zu sendendes Paket nie null, man könnte also im Interrup des Baudratentimers dieses Register einmal schieben. Meldet sich dabei des Z-Flag, ist nichts weiter zu tun - sonst wird das Carry "quasi auf den Sendepin gelegt".

Von den sechs Bits könnte je eins für "Links-Schritt" und eins für "Rechts-Schritt" verwendet werden, blieben vier Bits für den Taster (z.B. unterschiedliche Betätigungszeiten) - hmm... wäre die Erkennung von Schritten bei gedrücktem Taster interessant?

Interesse, daß ich diesen Ansatz weiterverfolge, und ein Resultat hier ggf mitanhänge (als Alternative)?
 
So, jetzt mal eine andere Frage:
@Pirx urspünglicher Ansatz bezieht sich ja auf die Gatter-Verschaltung mit den Flip-Flops und ein paar XORs.

Diese Gatterschaltung lieferte mir seinerzeit ein Verfahren für die Drehencoderabfrage. Allerdings entprellt diese Schaltung nicht und macht keine Auswertung, sondern liefert einen Impuls bei jeder Schaltflanke inklusive sämtlicher Preller. Die Routine hat deshalb eine gewisse Fehlerrate und wird von mir nicht mehr verwendet.

Müßte sich das nicht auch irgendwie mit der Configurable Custom Logic (und ggf des Eventsystems) der XMegas/XTinies machen lassen?

Gute Frage. Mit den Xern habe ich mich noch nicht beschäftigt. Wegen der zuvor genannten Nachteile lohnt es sich m.E. nicht, dem nachzugehen.

Gruß
Pirx
 
Die Xmega A-Serie kann von Haus aus 3 Drehencoder auswerten, die D- und E-Serie jeweils einen.
Bei den Xtinies ist es anscheinend nicht vorgesehen (habe ich mir aber noch nicht so genau angesehen).
 
Ja, bei den XMegas gibts Hardware-Quadraturencoder. Beim XTiny nicht. Ich hatte schon irgendwo 'ne Appnote(*) gesehen, die das Eventsys und die CCL nutzt - galt für XMegas und XTinies - allerdings wurden da zwei (!!) Instanzen des TimerB verwendet (und beide CCL-Channels, eine Instanz von TimerA und vier Kanäle des Eventnetzwerkes, mit mindestens sechs verwendeten Beinen) - zumindest die kleinen (8-Bein) XTinies besitzen aber nur einen TimerB, und auch nur sechs I/Os...

Ich wollte mich jetzt mal mit der Prellerei meiner PEC11S-929K-S0015-ND beschäftigen. Dabei ist mir aufgefallen, daß A und B bei jedem(!) Rastpunkt denselben Pegel aufweisen. Mein bisheriger Lösungsweg würde bei jedem Dreh-Schritt zwei Schritte melden.
Oder anders gesagt: Der kann viel leichter ausgewertet werden, indem man nur einen Kanal überwacht (nein, ich nehm keinen Flanken-IRQ), und die Pegel beider Pins vergleicht. Hat der andere Pin noch den alten (anderen) Pegel, folgt er - hat er bereits (denselben) neuen, führt er.

(*) P.S.: AN2434
 
Das gilt wohl für die Xtinies. Die Xmegas brauchen nur zwei Pins pro Encoder (ggf. einen 3. für Index), zwei Event-Channels und einen Timer/Counter.
XCL brauchen sie nicht, hätte eh nur die E-Serie. Als die Anderen entwickelt wurden, gab es das noch nicht ;)
 
Das gilt wohl für die Xtinies. Die Xmegas brauchen nur...
Nein, das gilt auch für die XMegas. Falls man (warum auch immer) den anderen Weg nicht gehen will...
Some AVR® microcontrollers, like the AVR XMEGA®-E5, include dedicated quadrature decoding functionality, but the decoding can also be accomplished by utilizing some of the core independent peripherals available on smaller, less feature rich controllers. This application note describes how to decode and keep track of quadrature encoded signals from an incremental position sensor using an AVR by combining Configurable Custom Logic (CCL), Event System (EVSYS), 16-bit Timer/Counter Type A (TCA), and 16-bit Timer/Counter Type B (TCB).
Allerdings ist dieser Hardware-Aufwand bei 'nem sehr kleinen Controller nicht unerheblich...
 
Nein, das gilt auch für die XMegas. Falls man (warum auch immer) den anderen Weg nicht gehen will...

Some AVR® microcontrollers, like the AVR XMEGA®-E5, include dedicated quadrature decoding functionality, but the decoding can also be accomplished by utilizing some of the core independent peripherals available on smaller, less feature rich controllers. This application note describes how to decode and keep track of quadrature encoded signals from an incremental position sensor using an AVR by combining Configurable Custom Logic (CCL), Event System (EVSYS), 16-bit Timer/Counter Type A (TCA), and 16-bit Timer/Counter Type B (TCB).
Warum sollte man etwas umständlich machen, wenn man es auch einfach haben kann?

Das Zitat (aus der AN, nehme ich an (habe sie nicht gelesen)) verstehe ich aber ganz anders.
Einige AVRs, wie der Xmega E5 (und alle anderen Xmegas) können Hardware-Quadraturdecodierung.
Die Decodierung kann auch anders gemacht werden (muß aber nicht).
Für diesen anderen Weg braucht man Custom-Logik (hat nur der E5 (und die neuen Xtinies), kein anderer Xmega), Event-System und zwei Timer/Counter.

Das heißt doch, der andere Weg wäre von den Xmegas nur auf dem E5 überhaupt möglich ohne zusätzliche externe Hardware.

Der E5 war der letzte Xmega, der entwickelt wurde und der erste und einzige mit Custom-Logik, die damals noch XCL genannt wurde. Bei den Xtinies heißt es jetzt CCL.

Und von allen anderen AVRs kommen auch nur die Xtinies in Frage, da sie, soweit ich weiß, bisher die einzigen mit Custom-Logik sind.

Um auf anderen Xmegas (und auf anderen AVRs überhaupt) den Weg aus der AN anwenden zu können, müßte man die Custom-Logik mit externen Bauteilen nachbauen und über zusätzliche Pins anschließen. Wer würde diesen Aufwand überhaupt nur in Erwägung ziehen, wenn er einen Hardware-Decoder benutzen kann?
 
Warum sollte man etwas umständlich machen, wenn man es auch einfach haben kann?
Falls man (warum auch immer) den anderen Weg nicht gehen will...
Das Zitat [...] verstehe ich aber ganz anders. [...]Einige AVRs, wie der Xmega E5 (und alle anderen Xmegas) können Hardware-Quadraturdecodierung.
Ja, bei den XMegas gibts Hardware-Quadraturencoder.
Die Decodierung kann auch anders gemacht werden (muß aber nicht).
Eben, genau deswegen hab ich ja die apnote erwähnt. Ich hätte statt des "auch" das "kann" betont. das "auch" enfällt beim XTiny.
Bei den XMega (außer dem E5) entfällt dafür das "kann":
braucht man Custom-Logik (hat nur der E5 (und die neuen Xtinies), kein anderer Xmega)
Ich hätte also nicht allgemein XMegas sagen dürfen, sondern präziser den E5 nennen müssen.

Um auf anderen Xmegas (und auf anderen AVRs überhaupt) den Weg aus der AN anwenden zu können, müßte man die Custom-Logik mit externen Bauteilen nachbauen und über zusätzliche Pins anschließen. Wer würde diesen Aufwand überhaupt nur in Erwägung ziehen, wenn er einen Hardware-Decoder benutzen kann?
Genau das umgekehrte war ja eigentlich meine Frage. Ausgangspunkt war die Externe Logikschaltung aus Beitrag #1 (bzw eine ähnliche), die Pirx damals sinngemäß in Software nachimplementiert hatte. Meine Frage war, ob man sowas ähnliches in einem XTiny mit CCL und ohne HW-Quadraturencoder (weitgehend ohne Softwareeingriffe) nachbilden kann.
Mit vertretbarem Aufwand, die restliche periphäre Hardware betreffend.
Die erwähnte Appnote gilt beim Tiny nur für die ATtiny16xx (da zwei Instanzen des TimerB verwendet werden (genauer: die beiden Input-Capture). Die 8-Pin-XTinies (derzeit ATtiny212/412) besitzen nur eine)
 
Zuletzt bearbeitet:
Meine Frage war, ob man sowas ähnliches in einem XTiny mit CCL und ohne HW-Quadraturencoder (weitgehend ohne Softwareeingriffe) nachbilden kann.
Mit vertretbarem Aufwand, die restliche periphäre Hardware betreffend.
Wenn keine dafür vorgesehene Hardware vorhanden ist, wäre mir der Aufwand gegenüber einer reinen Softwarelösung zu groß.
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)