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.
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.
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.
