Hallo, ich würde gerne 16 Drehencoder mit einem STM32 auswerten. Diese dienen der Benutzereingabe, sollen also nicht für irgendwelche Positionierungsbestimmungen verwendet werden. Nach Möglichkeit soll die Auswertung in Hardware erfolgen, allerdings haben alle STMs die mit ihren PWM Einheiten Encoder auswerten können, maximal 7 von diesen integriert. Hat jemand von euch eine Idee, wie sich das ganze effizient lösen lässt? Liebe Grüße und vielen Dank schonmal für eure Ideen
Drehwurm schrieb: > Nach Möglichkeit soll die Auswertung in Hardware erfolgen, Warum? Sowas erledigt der mit links in Software, siehe Drehgeber. > Hat jemand von euch eine Idee, wie sich das ganze effizient lösen lässt? Beitrag "Re: Mehrere Drehencoder gleichzeitig abfragen"
Drehwurm schrieb: > maximal 7 von diesen integriert. > > Hat jemand von euch eine Idee, wie sich das ganze effizient lösen lässt? Man muss ja nicht die internen Encoder/Decoder verwenden. Eine Software-Lösung tut es auch und macht wenig bis keinen Mehraufwand. Zudem ist man sehr frei in der Wahl der Port Pins.
Du könntest in einem zyklischen Timer Interrupt die Zustände aller Spuren über normale GPIOs pollen wenn die Drehgeschwindigkeiten nicht zu hoch werden. Alternativ ICs verwenden der die Quadraturencoder Funktion übernimmt und die Daten über eine Schnittstelle zur Verfügung stellt (z.B. SPI/I2C). Einen Typ habe ich gerade nicht im Kopf. Kleines FPGA verwenden. 7 Quadraturencoder instanzieren und über eine Schnittstelle deiner Wahl auslesen. Und wenn es morgen 10 sein sollen ist das auch kein Problem solange noch ein paar Zellen übrig sind.
Du kannst die auch alle über Multiplexer an den Controller aschliessen. Dann benötigst Du erheblich weniger Ports am µC und mit schnell-genugem TimerInt ist die Auswertug überhaupt kein Problem.
Drehwurm schrieb: > Nach Möglichkeit soll die Auswertung in Hardware erfolgen Warum? > Hat jemand von euch eine Idee, wie sich das ganze effizient lösen lässt? Wenn es Hardware sein muss, dann würde ich einen kleinen MachXO(2/3) neben den uC setzen und dort die Auswertung machen. Den jeweils aktuellen Zählerstand kann ich dann z.B. mit SPI kurz mal einlesen.
:
Bearbeitet durch Moderator
Drehwurm schrieb: > ich würde gerne 16 Drehencoder mit einem STM32 auswerten. Diese dienen > der Benutzereingabe, aus Neugier: Welche Anwendung verwendet 16 Dreh-Encoder? Wird das ein Studio-Mischpult??
Falk B. schrieb: > Warum? Sowas erledigt der mit links in Software, siehe Drehgeber. Weil ich gerne noch anderen Code ausführen möchte, unteranderem Ethernet und ein Display. Meine Befürchtung ist, dass es eventuell nicht schnell genug seien könnte und ich entweder Impulse schlabbere oder der Rest von meinem Code hängt. N. M. schrieb: > Alternativ ICs verwenden der die Quadraturencoder Funktion übernimmt und > die Daten über eine Schnittstelle zur Verfügung stellt (z.B. SPI/I2C). > Einen Typ habe ich gerade nicht im Kopf. An sowas hatte ich auch schon gedacht, allerdings noch keine konkreten Typen gesucht, da ich es wenn möglich halt gerne ohne Zusatzbausteine lösen möchte. N. M. schrieb: > Kleines FPGA verwenden. 7 Quadraturencoder instanzieren und über eine > Schnittstelle deiner Wahl auslesen. Und wenn es morgen 10 sein sollen > ist das auch kein Problem solange noch ein paar Zellen übrig sind. Schöne Idee, leider habe ich keine Ahnung von FPGAs, deshalb scheidet das für mich aus. Wegstaben V. schrieb: > aus Neugier: Welche Anwendung verwendet 16 Dreh-Encoder? Wird das ein > Studio-Mischpult?? Fast richtig, es geht um ein Zusatzmodul für ein Live Mischpult bei dem ich mir bestimmte Parameter auf Schnellwahl Knöpfe legen möchte (ja es ist dokumentiert, wie die Daten in das Pult reinkommen, dass ist also nicht die Baustelle)
> Falk B. schrieb: >> Warum? Sowas erledigt der mit links in Software, siehe Drehgeber. > > Weil ich gerne noch anderen Code ausführen möchte, unteranderem Ethernet > und ein Display. Meine Befürchtung ist, dass es eventuell nicht schnell > genug seien könnte und ich entweder Impulse schlabbere oder der Rest von > meinem Code hängt. Bei deinen Kenntnissen, dem Nachschieben relevanter Infos, der äußerst mangelhaften Planung und der schnodderigen Sprache, gehe ich davon aus, dass du mit dem Projekt überfordert bist.
Drehwurm schrieb: > Meine Befürchtung ist Unbegründet, wenn man es richtig macht. Und nicht gerade die lausigsten Drehgeber verwendet. > dass es eventuell nicht schnell genug seien könnte Worauf begründest du diese Befürchtung? Auf Messungen und Tests? Oder auf einem diffusem "Gefühl"? > Schöne Idee, leider habe ich keine Ahnung von FPGAs, deshalb scheidet > das für mich aus. Im Ernst: wenn ich von vorn herein alles ausschließe, was ich nicht kann, dann lerne ich nichts dazu... Die Lösung wäre auf jeden Fall nahe an "ideal". Mit dem SLG46140 gibt es sogar ein mickriges kleines SPLD, das per Appnote zu einem solchen Wandler umgebaut werden könnte: https://www.allaboutcircuits.com/industry-articles/designing-quadrature-encoder-counter-with-spi-bus/ In Stückzahlen kostet das dann gerade mal 25 Cent und ist dank "1 pro Encoder" beliebig granular skalierbar: https://www.dialog-semiconductor.com/products/slg46140 Das wäre für mich bei der Aufgabe hier schon ein Grund, mal das EVAL-Kit zu kaufen... Und sonst, wie gesagt: ein MachXO2 für 3,79 in Einzelstücken kann das auch https://www.mouser.de/ProductDetail/Lattice/LCMXO2-640HC-4SG48C/?qs=Slt%252B5btlScQmmER%252BK4i8aQ%3D%3D
:
Bearbeitet durch Moderator
N. M. schrieb: > Alternativ ICs verwenden der die Quadraturencoder Funktion übernimmt und > die Daten über eine Schnittstelle zur Verfügung stellt (z.B. SPI/I2C). > Einen Typ habe ich gerade nicht im Kopf. Wegen der Geschwindigkeit des STM32 hätte ich keine Bedenken. Es ist eine Fleißarbeit beim Layout und beim Programmieren. Mein Vorschlag wäre pro Kanal einen ATtiny zu verwenden: http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm#qcnt_tiny202 Wenn man damit die einzelnen Drehgeber ausstattet, braucht man lediglich vier Leitungen zu verbinden: GND, VCC, SDA, SCL.
Lothar M. schrieb: > Worauf begründest du diese Befürchtung? > Auf Messungen und Tests? Oder auf einem diffusem "Gefühl"? Ja es ist eher dieses diffuse Gefühl, aber wenn ihr soweit sagt, dass es kein Problem darstellen sollte, dann werde ich es erstmal so probieren.
Drehwurm schrieb: > Weil ich gerne noch anderen Code ausführen möchte, unteranderem Ethernet > und ein Display. Meine Befürchtung ist, dass es eventuell nicht schnell > genug seien könnte und ich entweder Impulse schlabbere oder der Rest von > meinem Code hängt. Irrtum. Ich wiederhole mich, das macht ein 32Bitter mit links, wenn man weiß was man tut. Man braucht nur einen 1ms Timer-Interrrupt. > Schöne Idee, leider habe ich keine Ahnung von FPGAs, deshalb scheidet > das für mich aus. Es gibt eine Lösung mit ATtiny2313, der liest 4 Drehgeber ein und schickt sie per UART weiter. Ist aber auch Overkill, denn du brauchst keine 800kHz Abtastrate. Man könnte es auch in einen AVR mit ausreichend Pins auslagern, z.B, ATmega64. Aber auch das ist eine Beleidigung eines 32 Bit Prozessors. ;-) 16 Drehgeber sind 3x16=48 Pins (incl. Taster). Die kann man per Schieberegister ala 74HC165 einlesen und gut.
m.n. schrieb: > Wegen der Geschwindigkeit des STM32 hätte ich keine Bedenken. Es ist > eine Fleißarbeit beim Layout und beim Programmieren. > Mein Vorschlag wäre pro Kanal einen ATtiny zu verwenden: OMG!!! So ein Käse!
Nö, Herr Falk, so blöde ist das nicht! Es gibt entliche Beispiele für I2C-Lösungen, wo unter jedem Encoder ein Tiny sitzt für ein paar Cent, eine wurde ja bereits genannt. Dann müssen nämlich nur 4 Leitungen durch alle Encoder geschleift werden, es werden am Host nur 2 Ports verwendet und der Host ist komplett entlastet, weil die Encoder die komplette Auswertung selbst machen und zudem per I2C noch prima konfiguriert werden können, z.B. Min-Max-Korrektur, Tastenauswertung, etc.
Hermann Kokoschka schrieb: > Es gibt entliche Beispiele für I2C-Lösungen, wo unter jedem Encoder ein > Tiny sitzt für ein paar Cent, eine wurde ja bereits genannt. > Dann müssen nämlich nur 4 Leitungen durch alle Encoder geschleift werden Die Lösung mit den HC165 kann das auch. Und der muss nicht noch programmiert werden. > und zudem per I2C noch prima konfiguriert werden können, z.B. > Min-Max-Korrektur, Tastenauswertung, etc. Das Problem ist eher, dass man das, was man "kann" meist auch "muss". Und dass solche "Coprozessoren" eben nicht einfach updatebar sind. Die müssen also sicher gut und zuverlässig funktionieren. Drehwurm schrieb: > Weil ich gerne noch anderen Code ausführen möchte, unteranderem Ethernet > und ein Display. Also kein zetikritischer Code im Sinne von "der muss genau in dieser einen ms fertig werden". Denn ein Display braucht nicht schneller als 20x pro Sekunde aktualisiert werden und wenn es zwischendurch mal für 100ms steht, dann schaut man sich noch nicht gleich schräg an. Und bei Ethernet ist "Echtzeit" sowieso kein Thema, "schnell genug" reicht da aus.
Falk B. schrieb: > Drehwurm schrieb: >> Weil ich gerne noch anderen Code ausführen möchte, unteranderem Ethernet >> und ein Display. Meine Befürchtung ist, dass es eventuell nicht schnell >> genug seien könnte und ich entweder Impulse schlabbere oder der Rest von >> meinem Code hängt. > > Irrtum. Ich wiederhole mich, das macht ein 32Bitter mit links, wenn man > weiß was man tut. Man braucht nur einen 1ms Timer-Interrrupt. Blödsinn! >> Schöne Idee, leider habe ich keine Ahnung von FPGAs, deshalb scheidet >> das für mich aus. > > Es gibt eine Lösung mit ATtiny2313, der liest 4 Drehgeber ein und > schickt sie per UART weiter. Ist aber auch Overkill, denn du brauchst > keine 800kHz Abtastrate. Man könnte es auch in einen AVR mit ausreichend > Pins auslagern, z.B, ATmega64. Aber auch das ist eine Beleidigung eines > 32 Bit Prozessors. ;-) Völliger Quatsch! > 16 Drehgeber sind 3x16=48 Pins (incl. Taster). Die kann man per > Schieberegister ala 74HC165 einlesen und gut. OMG!!! So ein Käse!
Drehwurm schrieb: > Meine Befürchtung ist, dass es eventuell nicht schnell > genug seien könnte und ich entweder Impulse schlabbere Das wäre schlimm für eine Positionserfassung, aber für eine manuelle Eingabe ist das egal: es gibt ja keinen Absolutwert, den der Drehgeber liefert, sondern man dreht solange bis der zugehörige Wert dem gewünschten entspricht. Ob da Schritte verlorengehen ist egal, meistens sieht man ja sogar noch eine Beschleunigungsfunktion vor wie bei Mäusen. Wenn du aber meinst, du könntest der Stellung eines Drehgeberknopfes einen festen Wert zuordnen, dann beschreibe doch wie. Eingaben über Drehgeber funktionieren NICHT wie bei einem Potentiometer. Georg
Hermann Kokoschka schrieb: > Nö, Herr Falk, so blöde ist das nicht! > > Es gibt entliche Beispiele für I2C-Lösungen, wo unter jedem Encoder ein > Tiny sitzt für ein paar Cent, eine wurde ja bereits genannt. Die I2C-Kommunikation mit den ganzen Slave-µCs ist mehr Aufwand, als die direkte parallele Auswertung auf einem einzigen µC, Abtastung der Geber z.B. über Porterweiterung mit Parallel-Seriell-Schieberegister via SPI.
Drehwurm schrieb: > ich würde gerne 16 Drehencoder mit einem STM32 auswerten. Ah, es MUSS ein STM32 sein, einen anderen Cortex würdst du nicht in Betracht ziehen. Soso. Also, mir kommt da so ein Gedanke: Sowas wäre doch eine prima Anwendung für diese kleinen µC von Padauk, die es für wenige Pfennige so gibt. Also DG an den Padauk, irgend ein sinnvolles Interface dann vom Padauk zum eigentlichen µC, evtl. ein abgemagertes SPI? SSEL CLK MISO, braucht 16x SSEL und je 1x CLK und MISO. Ein 8 Pin Padauk würde dafür ausreichen W.S.
Georg schrieb: > Ob da Schritte verlorengehen ist egal Finde ich nur unangenehm. Ich hatte schon viele Geräte in der Hand, wo Encoder eben nicht präzise reagieren und einzelne Werte zu treffen recht schwierig ist. Lothar M. schrieb: > Also kein zetikritischer Code im Sinne von "der muss genau in dieser > einen ms fertig werden". Korrekt. Georg schrieb: > Eingaben über > Drehgeber funktionieren NICHT wie bei einem Potentiometer. Ist mir bewusst. Lothar M. schrieb: > Und dass solche "Coprozessoren" eben nicht einfach updatebar sind. Eben dies würde ich gerne umgehen und entweder alles im STM32 machen oder über nicht intelligente Bausteine lösen. W.S. schrieb: > Ah, es MUSS ein STM32 sein, einen anderen Cortex würdst du nicht in > Betracht ziehen. Ja, da ich mich in dem Ökosystem auskenne und bisher gut damit gefahren bin
Ich würd ja alle (wenn der weg denn nich zu weit is) an einen Port hängen und per Dioden entkoppeln.... Dann über alle 16, mit ~6-8kHz Pollen. Macht 16+3 Ports, die sind doch über oder? :)
Drehwurm schrieb: > Ist mir bewusst. Also mal als Einwurf: Ich habe auch schon Quasi-Drehgeber verbaut, die nicht auf Schaltkontakten beruhen, sondern zwei um 90 Grad versetzte Potis enthalten. Sowas kann man getrost in festen Zeitabständen pollen, weil dort die Information über Richtung und Betrag für nicht allzu große Zeitabstände eben erhalten bleibt. Und sowas wie Coprozessoren solltest du nicht von vornherein ausschließen. Siehe die Idee mit den Padauk-Chips. Immerhin kann man damit die Ebenen der Aufgaben trennen, was sich IMMER als hilfreich erwiesen hat. Man muß es bloß vorher gründlich überdenken und sich eine saubere Schnittstelle mit sauberem Protokoll ausdenken. Wenn dann beide Seiten diese Schnittstelle einhalten, dann ist die Sache erledigt. Dann kannst du dir auch eine ganze Schachtel von solchen DG-Chips brennen und weißt auf alle Zeit, daß die eben funktionieren, solange man sie korrekt vom µC aus bedient. Und was das Ökosystem der STM32 betrifft: Ja, man kann sich dort hineinstürzen und sich mit der Nase an die Firma ST annageln lassen. Das geht - und so manche sind sogar glücklich dabei. Aber mein Fall ist das nicht, ich bleibe lieber unabhängig und kann es mir deshalb leisten, auch andere Chips anzuschauen. Die haben nämlich manchmal Features, die man gut gebrauchen kann und die es bei ST eben nicht oder nicht SO gibt. W.S.
Wolfgang schrieb: > Die I2C-Kommunikation mit den ganzen Slave-µCs ist mehr Aufwand, als die > direkte parallele Auswertung auf einem einzigen µC, Abtastung der Geber > z.B. über Porterweiterung mit Parallel-Seriell-Schieberegister via SPI. Das stimmt doch garnicht! Gerade bei räumlicher Ausdehnung ist eine dezentrale Auswertung von Vorteil. Ein IIC-Knecht kann sogar ganz simpel von einem Arduino ausgelesen werden. Parte et divide: von Cäsar lernen heißt Siegen zu lernen.
Teo schrieb: > Ich würd ja alle (wenn der weg denn nich zu weit is) an einen Port > hängen und per Dioden entkoppeln.... Dann über alle 16, mit ~6-8kHz > Pollen. Macht 16+3 Ports, die sind doch über oder? :) Freie Pins habe ich genug, daher brauch ich eigentlich keine Sparvarianten sondern könnte jeden Encoder mit zwei Pins anschließen. Das Hauptproblem ist die Auswertung, aber da viele bestätigt haben, das es eigentlich kein Problem seien sollte diese auch per Software auszulesen, werde ich diesen Weg einschlagen. W.S. schrieb: > Und sowas wie Coprozessoren solltest du nicht von vornherein > ausschließen. Ja kann ich nachvollziehen und die Paudak Dinger sehen auch recht schick aus, für ein Einzelstück ist mir der Aufwand an der Stelle allerdings zu groß W.S. schrieb: > und so manche sind sogar glücklich dabei Da ich hier keinen Glaubenskrieg entfesseln möchte, lasse ich das einfach mal so stehen. Ich bin es bisher jedenfalls. Vielen Dank schonmal für alle konstruktiven Antworten, ihr habt mir wirklich weitergeholfen!
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.