Auswertung mehrerer Drehencoder

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

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.

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.

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.

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!