Decodierung von 6 Quadratur(Drehgerber)Signalen - extern zur Entlastung des PIC

Eine Quadraturdecoderroutine kostet einen DSPIC33 weniger als 1 Promille 
Rechenzeit, wenn man 12 I/O Pins hat kann dieses Promille nicht den 
Unterschied machen zwischen einem ausreichenden Prozessor und einem 
überlasteten Prozessor. Es gibt kein Argument für eine externen Chip, 
zumal die Kommunikation mit ihm eher mehr Rechenzeit kostet.

MaWin schrieb:
> Eine Quadraturdecoderroutine kostet einen DSPIC33 weniger als 1 Promille
> Rechenzeit

Bei einer Werkzeugmaschine mit mehr als 10m/s Verfahrgeschwindigkeit und 
Auflösung im µ-Bereich ist das verantwortungsloser Quatsch.

Gruss Reinhard

> Bei einer Werkzeugmaschine

Ich ging von handbedienten aus.

Denn natürlich schlreibt ja kein Fragender hier,
was er wirklich har, man muß also raten.

Wenn die Signale von Weg- oder Drehgebern erzeugt werden, funktioniert 
ein AVR/Kanal bis ca. 100kHz. Beispiel: 
http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm
Wenn es schneller sein muß, braucht man PGAs oder µCs mit internen 
Dekodern.

Für manuelle Drehgeber reicht ein einziger ATmega48, der die 
betreffenden Eingänge bequem mit 10kHz pollen kann. Klein wird es im 
TQFP32-Gehäuse und internem Taktgenerator.
Die Datenabfrage über IIC ist vorzuziehen, da die Taktfrequenz nicht 
stabil sein muß. Die IIC-Routinen benötigen keinen Interrupt.

Mit einem separatem µC ist man für € 1,50 auf der sicheren Seite!

Falk Brunner schrieb:
> Welche? Normale Drehgeber für eine manuelle Eingabe oder für
> Maschinen mit hoher Drehzahl?

normale 16-drehgeber, allerdings ist die eingabe nicht manuell sondern 
geschieht über die welle eines motors an einem getriebe. der dreht 
ungefähr mit 1000/s je nachdem, was man als hohe drehzahl betrachtet...


Falk Brunner schrieb:
>>Für Handbetätigung sollte aber eine mittlere Priorität ausreichen.
>>Und da Menschen mit 6 Händen selten sind, werden die eh nie gleichzeitig
>>betätigt.
>
> Eben DAS wissen wir noch nicht.

es geht letztendlich um eine interpolation auf winkel in gelenken die 
durch motoren bewegt werden. die 6 motoren müssen gleichzeitig bewegt 
werden können.

das problem ist, dass der PIC auch schon UART und I²C kommunikation mit 
diverser peripherie sowie 5 AD-Wandlungen macht, insgesamt sammelt er 
sensordaten und gibt sie über UART zusammen aus.
was fehlt sind eben noch die decodierten quadratursignale

Alex schrieb:
> was fehlt sind eben noch die decodierten quadratursignale

Ich habe bei Mess- und Werkzeugmaschinen Encoder/Zähler-ICs wie den 
THCT12024 verwendet, das ist in Prinzip die perfekte Lösung und erlaubt 
zuverlässige Zählraten bis einige MHz, man muss bloss bei Bedarf den 
24bit-Zähler auslesen.

Das ist aber keine Empfehlung mit so ganz gutem Gewissen, solche ICs 
sind schwer beschaffbar. Es gibt zwar auch andere Typen und andere 
Hersteller, aber Exoten sind das allesamt. Der Vollständigkeit halber 
solltest du die Möglichkeiten solcher ICs aber prüfen, z.B. mit Avago 
HCTL2032. Und lass dich von Mawin nicht drausbringen, der kennt sowas 
nur von alten Hifi-Verstärkern, da kann man noch selber die Schritte 
mitzählen. Ist eine ganz andere Welt.

Gruss Reinhard

Christian R. schrieb:
> Eh man einen HCTL2032 auftreibt, kann man auch ein kleines PLD
> programmieren.

Wenn ich in meine Bleikiste greife finde ich THCT12024, THCT2000 oder 
auch 74LS2000.

Alex schrieb:
> normale 16-drehgeber, allerdings ist die eingabe nicht manuell sondern
> geschieht über die welle eines motors an einem getriebe. der dreht
> ungefähr mit 1000/s je nachdem, was man als hohe drehzahl betrachtet...

Ich vermute optische Drehgeber mit 16 Imp./U. Bei 4-fach Auswertung 
wären ca. 1000 (16*4*1000 / 60) prellfreie Flankenwechsel/s zu 
verarbeiten.
Da es nicht um manuelle Drehgeber geht, würde ich konservativ pro Kanal 
einen ATmega48 einsetzen. Die Lösung ist auch noch mit höher aufgelösten 
Drehgebern funktionssicher und skalierbar.

Jung-dynamisch angegangen würde ich 2 x ATmega48 für je drei Kanäle 
programmieren und sehen, wie weit man damit kommt. Wenn es zu eng werden 
sollte, werden 3 Stück mit je zwei Kanälen eingesetzt.

Peter Dannegger schrieb:
> Alex schrieb:
>> der dreht
>> ungefähr mit 1000/s je nachdem, was man als hohe drehzahl betrachtet...
>
> 60.000U/min ist recht sportlich für einen E-Motor. Macht bestimmt ne
> Menge Krach.

Ich hatte nur 1000 gesehen und angenommen, dass es 1000 U/min seien. 
1000/s sagt mir genau genommen garnichts. Da besteht wohl noch 
Klärungsbedarf!

Aus Spaß habe ich mal die max. Geschwindigkeit simuliert, die ein ATmega 
für 4 Kanäle brauchen würde, womit ein 8-bit Port belegt würde.

unsigned long z1, z2, z3, z4; // globale Zählerstände

// 4-fach Auswertung aller 4 Kanäle
void dekoder(unsigned char neuer_wert){}

// Aufruf mit gleichzeitiger Änderung aller Kanäle
  while(1) {
    dekoder(0x00);
    dekoder(0x55);
    dekoder(0xff);
    dekoder(0xaa);
  }

Bei 16MHz Taktfrequenz wird dekoder() mit über 90kHz aufgerufen. Man 
könnte dekoder(PINx) aus einem Timer-Interrupt mit gut 30-50kHz aufrufen 
und hätte noch genug Luft für die Datenausgabe.

m.n. schrieb:
> Ich hatte nur 1000 gesehen und angenommen, dass es 1000 U/min seien.
> 1000/s sagt mir genau genommen garnichts. Da besteht wohl noch
> Klärungsbedarf!

das ist wahr, habe ich auch gerade gemerkt. ich bekomme lediglich die 
drehgebersignale von einem anderen modul und DACHTE mir da sicher zu 
sein aber da kann was nicht stimmen.. ich gehe dem mal nach

m.n. schrieb:
> Aus Spaß habe ich mal die max. Geschwindigkeit simuliert, die ein ATmega
> für 4 Kanäle brauchen würde, womit ein 8-bit Port belegt würde.

interessant! danke dir!
Das ganze wird bei meinen 10MHz und 6 Kanälen dann aber schon etwas 
schwieriger, ich glaube ich komme ohne externe lösung nicht aus...

ah ich bin heute schräg drauf.
das war ja von dir genau so (externer Atmega) gemeint. danke!

Peter Dannegger schrieb:
> Das einfachste ist dann ein CPLD oder FPGA zum Zählen.

ja darüber habe ich auch schon nachgedacht, nur dass die idR nicht 
gerade klein sind und nicht mehr auf meine platine passen dürften... :/

Alex schrieb:
> ja darüber habe ich auch schon nachgedacht, nur dass die idR nicht
> gerade klein sind und nicht mehr auf meine platine passen dürften...

Die Rechnung wird nur aufgehen, wenn du ein einziges FPGA für alle 6 
Zähler nimmst (und vielleicht noch ein paar andere Sachen, "Glue Logic", 
mit rein packst). Du brauchst ja nur ein Prozessorinterface und 3x6 
Eingänge (mit Index), also ziemlich wenige I/O-Pins.

Gruss Reinhard

Reinhard Kern schrieb:
> Die Rechnung wird nur aufgehen, wenn du ein einziges FPGA

an was für ein FPGA hast du gedacht? die dinger die ich kenne (von 
xilinx oder altera) sind alle etwas groß...

Alex schrieb:
> an was für ein FPGA hast du gedacht? die dinger die ich kenne (von
> xilinx oder altera) sind alle etwas groß...

Hallo,

um es vorauszuschicken, das ist nicht so ganz mein Fachgebiet, aber wenn 
ich was Falsches sage, wird sich eh gleich jemand draufstürzen (wenn ich 
was Richtiges sage auch), also mach ich mal eine Abschätzung:

Für einen 8Bit-Bus, RD, WR, Reset, CLK etc. veranschlage ich mal 16 
I/Os, ein Quadratureingang hat SIN und COS-Eingang sowie ein Indexsignal 
zur Nullstellung, also 18 I/Os für die 6 Encoder. Dafür reicht ein PLC44 
oder TQFP44, kleinere Gehäuse gibts sowieso nicht.

Du brauchst 6 Zähler, dabei reichen 32 Bit für so gut wie jede Aufgabe 
(bei einer Werkzeugmaschine mit 1µ Auflösung sind das 4 km Fahrweg), 
dazu ein Latch zum Einfrieren des Zählerstands, und ein paar wenige 
Flipflops und Gatter für die Umsetzung der Eingangssignale, so rund 70 
Flipflops pro Zähler, sind also 420 Macrozellen. Das muss noch kein FPGA 
sein, sowas gibt es schon als CPLD, allerdings musst du mit TQFP100 als 
Gehäuse rechnen, weil es so wenige I/Os mit mehr als 400 Macrozellen 
nicht gibt. Aber ein TQFP100 ist ja noch recht niedlich. Es gibt von 
Altera MAX II mit 440 Zellen, von Lattice welche mit 600.

Bei FPGAs ist die überwiegende Anzahl sowieso grösser, du hast also 
grosse Auswahl. Sie sind aber nicht nur viel grösser, sondern brauchen 
auch noch einen Speicher.

Gruss Reinhard

Wäre es da nicht sinnvoller - wenn der PIC tatsächlich nicht mehr 
ausreicht, was ich kaum glaube - nen kleinen Slave-Pic zu verbauen, der 
nur die Encoder einliest und die Zählerstände über SPI ausgeben kann?

Das dürfte etwas weniger Platz wegnehmen als ein TQFP... Oder man nimmt 
insgesamt statt des PIC gleich einen richtigen Controller.

ja, slave pic oder avr habe ich ja als eine lösung in betracht gezogen.. 
so wie es aussieht wird das wohl die einfachste lösung sein..

Alex schrieb:
> ich bekomme lediglich die
> drehgebersignale von einem anderen modul und DACHTE mir da sicher zu
> sein aber da kann was nicht stimmen.. ich gehe dem mal nach

Weißt Du schon Genaueres?
Vielleicht schreibe ich dazu etwas in die Codesammlung, dann könntest Du 
"abkupfern".

Alex schrieb:
> n was für ein FPGA hast du gedacht? die dinger die ich kenne (von
> xilinx oder altera) sind alle etwas groß...

Actel Ignoo Nano

http://www.eevblog.com/2011/08/07/eevblog-193-fpga-implementation-tutorial/

Gruss

@Reinhard:
Wie willst du das denn alles in einen CPLD bekommen?
Ich hab letztens was ähnliches probiert: 3 QEP inputs mit je n>=20bit 
auflösung + SPI controller in einen kleinen Xilinx CPLD (144pin) - keine 
Chance.
Alleine die Counter frassen schon zuviele Ressourcen....
Als Idee hätte ich noch die counter als ripple counter zu realisieren, 
das dürfte einiges an Logik sparen. Ob das funktioniert hab ich noch 
nicht durchgerechnet... CPLD Takt wären 16 oder 32mhz und die QEP 
Signale haben <1mhz)

Also für Ansätze wäre ich auch dankbar :)
Momentan siehts so aus als ob ich einfach 3x die 32bit spi qep decoder 
von LSI nehme. Das gefällt mir aber nicht ganz so gut wegen dem 
Platzbedarf und der nötigen zusätzlichen 5v->3.3v Wandlung.
Die XIlinx CPLDs wären 5V tolerant...

Danke & Gruss,
Simon

Ssss schrieb:
> Ich hab letztens was ähnliches probiert: 3 QEP inputs mit je n>=20bit
> auflösung + SPI controller in einen kleinen Xilinx CPLD (144pin) - keine
> Chance.
>
> Also für Ansätze wäre ich auch dankbar :)

Die neueren Renesas µCs haben bis zu 4 Zähler, die im phase-counting 
Modus arbeiten. Die 16 bit Zähler lassen sich intern auf 32 bit 
kaskadieren.
Suche im Datenblatt z. B. des H8SX1668R nach TPU. Der RX62N hat wohl 
auch vier Kanäle (Stichwort MTU).
Letzterer ist so schnell, dass er 1MHz auch noch in Software (per 
Interrupt) zählen kann.

Falk Brunner schrieb:
> 3x20 Bit Zähler + 3x 4 Bit "State Machine" für Dekodierung der
> Drehgeber + 24 Bit SPI Schieberegister

Du bringst mich da auf was - ich habe für jeden Zähler ein paralleles 
Latch gerechnet zum Auslesen, während der Zähler unabhängig davon 
weiterzählt. Man kann natürlich wie du auch mit nur einem Leselatch für 
alle Zähler auskommen, und auch mit weniger Bit im Zähler, wenn man sich 
genaue Gedanken macht, wie die Überläufe zu verarbeiten sind. Der 
Vorteil bei meiner Auslegung ist nur, dass man alle 6 Zähler zugleich 
latchen kann, also absolut synchron auslesen, das kann für eine 
Lageregelung hilfreich bis notwendig sein.

Man kann also meine Maximum-Abschätzung von 400 Macrozellen für alle 6 
Zähler nach Bedarf noch erheblich downgraden, aber es gibt ja so grosse 
CPLDs, und auch FPGAs bleiben im Rennen, wenn man z.B. deine 2 CPLDs 
durch 1 FPGA ersetzt, ist das ja durchaus diskutabel.

Es gibt also viele Möglichkeiten, aber wir sind uns absolut einig, dass 
das vernünftig zu realisieren ist.

Noch zu meinem Vorschlag mit HCTL2032 (braucht natürlich mehr Platz, 
dafür muss man nix mehr tun ausser auslesen): ob man in 5 Jahren noch 
dieses IC bekommt, ist etwa genauso unsicher, wie ob man das gewählte 
CPLD oder FPGA noch beschaffen kann.

Gruss Reinhard

Hi!

Sorry fürs hijacken dieses Threads ;)

Also wahrscheinlich reichen 17-18 Bit für meine Anwendung aus. Aber gut, 
um sicher zu sein habe ich mal 20bit angesetzt ;)
16 sind definitiv zu wenig und die jetzige Lösung mit einem Xmega und 
softwaremässiger Erweiterung auf 17 Bit ist unter hoher Last nicht 
verlässlich genug.

>3x20 Bit Zähler + 3x 4 Bit "State Machine" für Dekodierung der
>Drehgeber + 24 Bit SPI Schieberegister + ein Dutzend Bit für SPI
>State machine. Macht in Summe 108 Makrozellen. Das sollte mit einem 144
>oder sogar 128 Makrozellen CPLD machbar sein. Irrtum vorbehalten ;-)
Also irgendwas mache ich falsch. Die Counter werden einfach riesige 
Gattergräber im ISE.
Ich habe ganz einfach per vhdl up/down counter mit einem enable bit 
geschrieben (synchron). Wenn man sich das ansieht im RTL viewer sind
das riesige Gebilde.
Achso ich hab noch was vergessen: Die zähler haben zusätzlich noch ein 
Compare Register.

Das ist auch der Grund das ganze extern zu machen: Beim Compare match 
soll der uC per ISR bescheid bekommen dass das Ziel erreicht wurde.
Evtl frisst das auch die ganzen Ressourcen wobei ich mir das nicht 
vorstellen kann...

>Siehe oben. Wahrscheinlich reichen 16 Bit Zähler locker. Aufpassen muss
>man bei der Synchronisierung des CPLD Taktes und des SPI Taktes.
Da hatte ich bis jetzt beides ausprobiert:
a) SPI_SCK geht direkt als "clock signal" rein (rising edge etc)
b) SPI_SCK wird mit clk gesampled und dann per hand eine steigende 
Flanke erkannt
In der Literatur bzw Web hab ich beides gefunden. VOm bauchgefühl her 
finde ich (b) sauberer bzw erwarte weniger Probleme.



Gruss,
Simon

Karl Heinz Buchegger schrieb:
> während er regelmässig 18 Pins überwacht. Das einzige, worauf
> ich noch warte ist, ob die 1000U/s nicht doch eher 1000U/min sind.

Und ob er überhaupt Indeximpulse auswerten muß. Dann sind es nämlich nur 
12 Pins.

Hi!

@falk:
Ursprünglich hatte ich gedacht ich bau einfach die 24Bit dinger von LSI 
im CPLD nach. Daher ursprünglich 24Bit, das hab ich dann aber schnell 
runtergeschraubt ;)
Selbst mit 18Bit bekomme ich das nicht in einen CPLD gefittet.

Das mit up/down hatte ich nicht erwähnt da ich QEP immer im Zusammenhang 
mit Positionsreglung sehe/nutze.

Siehst du eine Chance das ganze in 3x18Bit+compare in  einen 144er CPLD 
zu bekommen?
Ich bin da nicht wirklich auf einen grünen Zweig gekommen...

Zum takten:
bei Lösung (a) bereitete mir der übergang zwischen Taktdomäne 
Zählerdaten und SPI Register noch ein wenig Kopfzerbrechen, bei b) fand 
ich das alles klarer.

Gruss,
Simon

@falk: Danke für die Einschätzung!

Ich hätt auch nen FPGA genommen. Aber das wird mir wieder zu groß vom 
package her und dem levelshifter (dann kann ich auch gleich 3x das LSI 
IC nehmen).
Ich hatte nur bei Xilinx geguckt da ich deren Toolchain und die FPGAs 
kenne.
Wobei die oben verlinkten Actel dinger echt nett aussehen...


Gruss,
Simon