Hi, ich frage einfach mal ins blaue hinein, da ich dafür noch keine vernünftige Lösung habe: gibt es einen IC, der zwei um 90 Grad phasenverschobene Impulse richtungsabhängig zählt und mir das Zählergebnis dann auf irgend einer schnellen Schnittstelle zur Verfügung stellt (z.B. I2C) und sich auch per Kommando zurücksetzen lässt? Hintergrund: ich möchte sowas mit dem BeagleBone Black machen. Der AM3358 hat zwar einen entsprechenden Decoder an Bord, nur ist der Zugriff auf das Zählregister grausam langsam und bremst die gesamte CPU mit sämtlichen Interrupts aus, weswegen ich nach einer vernünftigen, externen Alternative suche. Danke schon mal!
Bronnoysund schrieb: > gibt es einen IC, der zwei um 90 Grad > phasenverschobene Impulse richtungsabhängig zählt und mir das > Zählergebnis dann auf irgend einer schnellen Schnittstelle zur Verfügung > stellt LS7166, LS7266 (LSI Logic), HCTL2022/2032 (HP), DDM01 (amira.de) Bronnoysund schrieb: > weswegen ich nach einer vernünftigen, externen Alternative suche. Un das alles bloss weil dir die Doku zu den bereits eingebauten viel besseren fehlt ? https://github.com/Teknoman117/beaglebot/tree/master/encoders
MaWin schrieb: > Un das alles bloss weil dir die Doku zu den bereits eingebauten viel > besseren fehlt ? Siehe oben, der Decoder, der im AM3358 daher kommt ist beim Lesen des Zählerregisters grottenlangsam und bremst sätmliche (Timer)Interrupts aus. Ich benötige also was, was sich schnell auslesen lässt (und z.B. seine Werte per DMA) liefert.
@ Bronnoysund (Gast) >Ich benötige also was, was sich schnell auslesen lässt (und z.B. seine >Werte per DMA) liefert. Bescheibe zahlenmässiß, in welchem Bereich du landen willst, siehe Netiquette. Mit welcher Frequenz willst du die Werte auslesen?
Bronnoysund schrieb: > Ich benötige also was, was sich schnell auslesen lässt (und z.B. seine > Werte per DMA) liefert. Moment. Du behandelst doch nicht etwa jeden Tick des Zählers mit einem Interrupt und verwendest mit diesem dann den Wert im Zähler weiter? Sinn der ganzen HW ist es den Zugriff auf das Register nur dann zu machen, wenn es benötigt wird. Daher hat es recht wenig Chance dein System wirklich auszubremsen. Ich glaub da liegt weniger das Register als Problem vor als das Konzept.
Maxx schrieb: > Moment. Du behandelst doch nicht etwa jeden Tick des Zählers mit einem > Interrupt und verwendest mit diesem dann den Wert im Zähler weiter? Nein. Ohne zu viele uninteressante Details auszubreiten: es gibt ein externes Event, bei dem ich weiß, dass ich jetzt einen neuen Zählerstand benötige, um interne Zahlenwerte (=Positionswerte) zu aktualisieren. Dieses Event kommt maximal alle 10 usec (=100 kHz), was an sich kein Problem ist. Das Problem: es sollte stabil bei diesen 100 kHz bleiben, leider bremst der Zugriff auf das QPOSCNT-Register (welches den aktuellen Zählerstand enthält) die CPU ziemlich heftig - und auch der Timer-Interrupt, der für die 100 kHz sorgt, wird dadurch beeinflusst. Zitat TI: "The eQEP is on the L4PER interconnect, which has clock speed of 100MHz. To read from an eQEP register the MPU must go through the L3F interconnect (200MHz), then through L3S (100MHz), through L4PER (100MHz) to the eQEP. Each of these transitions requires several clocks for synchronization." Diese "several clocks" pro Transition sind laut meinen Messungen schon wirklich sehr viele Taktzyklen, sprich das System wird spürbar beeinflusst.
Bronnoysund schrieb: > Diese "several clocks" pro Transition sind laut meinen Messungen schon > wirklich sehr viele Taktzyklen, sprich das System wird spürbar > beeinflusst. Und das wird bei Verwendung eines externen Bausteins mit typ. 0,1 MHz natürlich viel besser Bronnoysund schrieb: > schnellen Schnittstelle zur Verfügung stellt (z.B. I2C) MfG Klaus
Bronnoysund schrieb: > und auch der Timer-Interrupt, der für > die 100 kHz sorgt, wird dadurch beeinflusst. Dann hast Du was grundlegend falsch gemacht. Der Sinn eines Timers ist nämlich, daß er von Software unbeeinflußt weiter läuft. Es kann zu einem Jitter kommen durch verzögerten Eintritt in den Interrupt, aber dieser Jitter akkumuliert nicht. Bronnoysund schrieb: > The eQEP is on the L4PER interconnect, which has clock speed > of 100MHz. Und Du meinst, ein Zugriff auf einen externen IC ginge schneller? 100MHz kannste voll vergessen.
@Bronnoysund (Gast) >externes Event, bei dem ich weiß, dass ich jetzt einen neuen Zählerstand >benötige, um interne Zahlenwerte (=Positionswerte) zu aktualisieren. >Dieses Event kommt maximal alle 10 usec (=100 kHz), was an sich kein >Problem ist. Schon recht flink. >Zitat TI: "The eQEP is on the L4PER interconnect, which has clock speed >of 100MHz. To read from an eQEP register the MPU must go through the L3F >interconnect (200MHz), then through L3S (100MHz), through L4PER (100MHz) >to the eQEP. Each of these transitions requires several clocks for >synchronization." Naja, das ist halt der Nachteil dieser aufgeblähten Monster-CPUs, die Verkettung diverser Busse bringt halt haufenweise Latenz. ABER! >Diese "several clocks" pro Transition sind laut meinen Messungen schon >wirklich sehr viele Taktzyklen, Wieviel denn? Deine 200/100MHz Busse machen pro 10us 2000/1000 Takte. Ich vermute mal, dass da um die 10 100MHz Takte hängen bleiben, um das zu synchronisieren, macht halt 0,1us Zugriffszeit. Ist jetzt nicht sooo langsam, ist schließlich gerade mal 1% deiner 10us Periodendauer. Schneller wird es nur, wenn man einen weniger aufgeblasenen Controller nimmt, der NICHT mehrere Peripheribusse kaskadiert. Irgend was schickes, kompaktes mit 32 Bit mit integriertem Quadraturdekoder, z.B. PICCOLO.
iC-Haus könnte eine interessante Adresse sein. Das Produktportfolio ist allerdings etwas unübersichtlich geworden, so dass ich ad hoc nicht überblicke, ob die etwas passendes haben. Ich denke aber auch, dass eine externe Lösung immer langsamer sein wird als die interne. Wenn die interne Logik so langsam ist, ist es vielleicht effizienter, in einem normalen Timer die Eingänge zyklisch auszuwerten und den aktuellen Zählerstand im Ram vor zu halten. Mit freundlichen Grüßen Thorsten Ostermann
Klaus schrieb: > Und das wird bei Verwendung eines externen Bausteins mit typ. 0,1 MHz > natürlich viel besser Ja, weil ich mir da die Daten per DMA irgend wo hin schreiben lassen kann und der Zugriff besteht dann nur noch aus dem Lesen einer Speicheradresse. Das ist GARANTIERT schneller als auf diese Buslatenzen zu warten.
Peter Dannegger schrieb: > Dann hast Du was grundlegend falsch gemacht. Der Sinn eines Timers ist > nämlich, daß er von Software unbeeinflußt weiter läuft. Erkläre das mal TI. Während ich mich in meinem Timerinterrupt aufhalte (und dort muss auch das Positionsregister gelesen werden), läuft der Timer NICHT weiter. D.h. die Interrupt-Ausführzeit addiert sich immer zum Timer hinzu, der erst nach verlassen der ISR wieder anfängt loszulaufen (und ja, der Timer wird bereits wieder automatisch angestoßen, es gibt ein Reload-Register, welches den Timer nach Ablauf automatisch wieder mit einer neuen Zeit füttert und startet).
Bronnoysund schrieb: > Während ich mich in meinem Timerinterrupt aufhalte > (und dort muss auch das Positionsregister gelesen werden), läuft der > Timer NICHT weiter. Hast Du mal nen Link, wo das steht? Ich konnte im AM335x ARM Cortex-A8 Microprocessors (MPUs) Technical Reference Manual (Rev. J) nichts derartiges entdecken. Das wäre auch der absolute Schwachsinn und würde ja die Timer generell unbrauchbar machen.
>und würde ja die Timer generell unbrauchbar machen.
Der Fachausdruck ist: ad adsurdum führen
;-)
Matthias Lipinsky schrieb: >>und würde ja die Timer generell unbrauchbar machen. > > Der Fachausdruck ist: ad adsurdum führen Si tacuisses ...
Da sowohl das Memory-Interface als auch die Parallel-IO genauso wie die restliche interne Peripherie über den L3- und L4-Interconnect läuft, wirst du auch mit einem externen Zählerbaustein die gleichen (wenn nicht sogar noch größere) Delays bekommen.
Die Sache ist aber dass er bei einem externen Baustein der diesen Wert vorhält diesen auslesen kann wenn es ihm und seiner Software in den Kram passt.
>Die Sache ist aber dass er bei einem externen Baustein der diesen Wert >vorhält diesen auslesen kann wenn es ihm und seiner Software in den Kram >passt. Aber ein internes CPU-eigenes Register zu lesen ist doch immer schneller als ein wie auch immer von extern zu holen...
Bronnoysund schrieb: > Ja, weil ich mir da die Daten per DMA irgend wo hin schreiben lassen > kann und der Zugriff besteht dann nur noch aus dem Lesen einer > Speicheradresse. Wenn Du per DMA von extern lesen kannst, warum dann nicht von intern? Ob das aber auch merkbar schneller sein wird, kann ich nicht so richtig glauben.
Peter Dannegger schrieb: > Bronnoysund schrieb: >> Ja, weil ich mir da die Daten per DMA irgend wo hin schreiben lassen >> kann und der Zugriff besteht dann nur noch aus dem Lesen einer >> Speicheradresse. > > Wenn Du per DMA von extern lesen kannst, warum dann nicht von intern? Weil ich keinen Weg kenne (und der TI-Support auch nicht), das QPOSCNT-Register per DMA irgendwo hin zu mappen. Bei UART/SPI/etc. geht das aber.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.