Hallo, ich habe in einer Schaltung einen PIC DSPIC33 auf 10MHz als Herzstück, der bereits einiges an Sensorsignalen verarbeiten und die USB Kommunikation übernehmen muss. Dazu sollen jetzt auch die Signale von 6 Quadraturencodern kommen. Da der PIC aber gut zu tun hat (Performanceanalyse ist noch nicht fertig aber ich denke es wird knapp) - und vorallem diverse Interrupts mit höherer Priorität laufen, mir aber keine Quadratursignale entgehen sollen, suche ich momentan eine lösung der externen Dekodierung (intern über software könnte eben knapp werden), damit der PIC nur noch regelmäßig den aktuellen Zählerstand auslesen muss. Dazu habe ich jetzt die Lösungsansätze 1. kleinerer µC der die Softwareroutine für die 6 Quadratursignale übernimmt und über SPI abgefragt werden kann 2. spezielle Hardwarebausteine zur Quadraturdecodierung Die Fragen an euch wären: zu 1.: Kennt ihr einen AVR/PIC der eventuell bereits 6 (oder mehr) interne Quadraturencoder besitzt? Unabhängig davon sollte der µC möglichst klein sein und bräuchte neben den 12 Pins für die Quadratursignale und der SPI/I²C Schnittstelle keine weiteren Pins zu 2.: Kennt ihr Hardware-Decoder, die (leider) möglichst klein sein müssten - QFM oder vergleichbar - oder zumindest mehrere Quadratursignale in einem Decoder integrieren? Ausgelesen werden soll per SPI. Falls ja: welche? Viele Grüße
@Alex (Gast) >Dazu sollen jetzt auch die Signale von 6 Quadraturencodern kommen. Welche? Normale Drehgeber für eine manuelle Eingabe oder für Maschinen mit hoher Drehzahl? >zu 1.: Kennt ihr einen AVR/PIC der eventuell bereits 6 (oder mehr) >interne Quadraturencoder besitzt? Nein. >zu 2.: Kennt ihr Hardware-Decoder, die (leider) möglichst klein sein >müssten - QFM oder vergleichbar - oder zumindest mehrere >Quadratursignale in einem Decoder integrieren? Ausgelesen werden soll >per SPI. Falls ja: welche? Keine Ahnung, gibt vielleicht ein paar exotische Spezial-ICs. Oder man nimmt einen CPLD. TQFP44 ist nicht super klein, aber vielleicht OK. Wenn es kleiner sein muss, muss man was moderneres nehmen, z.B. Coolrunner-II in QFN32 oder 48. MfG Falk
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
@ MaWin (Gast) >Eine Quadraturdecoderroutine kostet einen DSPIC33 weniger als 1 Promille >Rechenzeit, Wirklich? Wo steht, wie schnell er die Dinger dekodieren muss? 1kHz? Kein Thema 100kHz? Ein Problem bei 10 MHz Takt! MFG Falk
> Bei einer Werkzeugmaschine
Ich ging von handbedienten aus.
Denn natürlich schlreibt ja kein Fragender hier,
was er wirklich har, man muß also raten.
Alex schrieb: > (Performanceanalyse ist noch nicht fertig > aber ich denke es wird knapp) Da kann man sich sehr leicht täuschen. Man sollte sich entsprechende Testroutinen einbauen. Z.B. kann man die Durchlaufzeit der Mainloop messen. Ist diese kurz, d.h. alle Tasks hatten nichts zu tun, dann war dieser Durchlauf überflüssig. Oder man fügt eine Delayloop ein und macht diese so groß, bis irgendwas ins Stocken gerät. Auch kann man in jedem Interrupt zu Beginn einen Pin setzen und am Ende löschen. Ein Widerstand und ein Elko dahinter und man kann mit einem Voltmeter prima die Interruptlast ablesen. Alex schrieb: > und vorallem diverse Interrupts mit > höherer Priorität laufen, mir aber keine Quadratursignale entgehen > sollen Encoder kosten keine nennenswerte Rechenzeit, daher kann man denen ruhig die höchste Priorität geben. 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. Peter
@ Peter Dannegger (peda) >Auch kann man in jedem Interrupt zu Beginn einen Pin setzen und am Ende >löschen. Ein Widerstand und ein Elko dahinter und man kann mit einem >Voltmeter prima die Interruptlast ablesen. Die mittlere. Besser ist hier ein Oszi, noch besser Digitaloszi mit unendlichem Nachleuchten, dann sieht man auch Worst Case Pulse. >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. MFG Falk
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!
Die Hardware-Lösung ist entweder ein FPGA, oder spezielle schnelle Zähler mit ABZ-Schnittstelle, wie z.B. der iC-MD vom iC-Haus. Hier gibt es einige Applikationen zur schnellen Erfassung von Encoder-Signalen: http://ichaus.biz/encoderanschluss.
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
Eh man einen HCTL2032 auftreibt, kann man auch ein kleines PLD programmieren. Die Dekodierung die hier im Drehgeber-Artikel in VHDL steht, klappt einwandfrei auch bei sehr hohen Geschwindigkeiten, je nach Abtastfrequenz natürlich.
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.
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. Da gehen auch nur optische oder induktive Drehgeber. Ein Kontakt wäre viel zu träge. Das einfachste ist dann ein CPLD oder FPGA zum Zählen. Peter
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 (Gast) >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. Mal rechnen. 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 ;-) >Alleine die Counter frassen schon zuviele Ressourcen.... ??? Man muss auch die Frage stellen, wozu 20 Bit? Ein bisschen muss die CPU schon arbeiten für ihr Geld. Der externe Dekoder muss ja nur die Auslesefrequenz effektiv senken. 100 Hz oder sogar 1kHz Ausleserate sind wohl zumutbar, macht bei einem 20 Bit Zähler im CPLD 1 GHz Eingangsfrequenz . . . >Als Idee hätte ich noch die counter als ripple counter zu realisieren, >das dürfte einiges an Logik sparen. Nö, die alten Zeiten der Bastellösungen mit 4000er ICs, RC-Gliedern & Co sind vorbei. > Ob das funktioniert hab ich noch >nicht durchgerechnet... CPLD Takt wären 16 oder 32mhz und die QEP >Signale haben <1mhz) Lächerlich. >Also für Ansätze wäre ich auch dankbar :) Siehe oben. Wahrscheinlich reichen 16 Bit Zähler locker. Aufpassen muss man bei der Synchronisierung des CPLD Taktes und des SPI Taktes. >Die XIlinx CPLDs wären 5V tolerant... Eben. MfG Falk
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
@ Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik) >latchen kann, also absolut synchron auslesen, das kann für eine >Lageregelung hilfreich bis notwendig sein. Ja, das kostet aber halt Makrozellen, und das nicht zu knapp. >CPLDs, und auch FPGAs bleiben im Rennen, wenn man z.B. deine 2 CPLDs >durch 1 FPGA ersetzt, ist das ja durchaus diskutabel. Jo, sowohl preislich als auch vom Platzbedarf. >dieses IC bekommt, ist etwa genauso unsicher, wie ob man das gewählte >CPLD oder FPGA noch beschaffen kann. Aber man kann das VLDL neu compilieren und auf einem neuen FPGA laufen lassen. Und trotz aller Schnellebigkeit der FPGAs sind auch eher alte 95xx von Xilinx noch kaufbar, wenn gleich diese nicht mehr aktiv vermarktet werden. Und diese ICs sind über 15 Jahre alt! MFG Falk
Hi Alex, Ich habe jetzt nicht alles durchgelesen, aber ich würde an deiner Stelle wenn du schon sowieso mit PIC arbeitest, die Ressourcen auf insgesamt 3 PICs (je 2 QEI) verteilen. 1. Master-µC z.B. dsPIC33EP (60/70Mips) mit 2 QEI 2. zwei Slave-µC dsPIC33FJ64MC802 (40Mips) 28Pin, haben auch 2 QEI. Gruß Hermann
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
Hermann U. schrieb: > Ich habe jetzt nicht alles durchgelesen, aber ich würde an deiner > Stelle wenn du schon sowieso mit PIC arbeitest, die Ressourcen auf > insgesamt 3 PICs (je 2 QEI) verteilen. Wieviele denn noch? Ein einzelner dsPic wird woch wohl UART, I2C und 5 ADC Wandelvorgänge schaffen, 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. Denn das ist die Zahl mit der sich entscheidet ob der dsPIC ins Schwitzen kommt oder ob er zwischendurch noch "Zeit für ein paar teuflisch schwierige quadratische Gleichungen zur eigenen Belustigung" hat. Die Dinge werden nicht einfacher, wenn man mehrere µC einsetzt! Anstelle 'produktiver Arbeit' tritt dann das Kommunikationsproblem.
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.
Karl Heinz Buchegger schrieb: > ich noch warte ist, ob die 1000U/s nicht doch eher 1000U/min sind. Und wieviel pro Umdrehung, ist noch nicht bekannt?! ich habe mit YASKAWA Servomotoren rumgespielt das sind 8192Pulse pro Umdrehung, Und die machen 8000U/min. Ich hab dass nur mit eine QEI sauber gelöst bekommen. Gruß Hermann
Hermann U. schrieb: > Karl Heinz Buchegger schrieb: >> ich noch warte ist, ob die 1000U/s nicht doch eher 1000U/min sind. > > Und wieviel pro Umdrehung, ist noch nicht bekannt?! > ich habe mit YASKAWA Servomotoren rumgespielt das sind 8192Pulse pro > Umdrehung, Und die machen 8000U/min. > Ich hab dass nur mit eine QEI sauber gelöst bekommen. Das ist klar, das sind dann schon Zeitbereiche, die nicht mehr so einfach zu beherrschen sind. Nur kann ich der Ursprungsaussage: "Der muss UART und I2C machen, drum hab ich Angst, dass der µC nicht mitkommt" nix abgewinnen. Das sind doch bei einer Interruptsteuerung Peanuts in der Rechenzeit.
Hermann U. schrieb: > ich habe mit YASKAWA Servomotoren rumgespielt das sind 8192Pulse pro > Umdrehung, Und die machen 8000U/min. Ich wusste doch, ich habs irgendwo gelesen. Gestern 21:55 > normale 16-drehgeber Ich interpretiere das mal als: 16 Positionen pro Umdrehung.
Karl Heinz Buchegger schrieb: > Das einzige, worauf ich noch warte ist, > ob die 1000U/s nicht doch eher 1000U/min sind. Oder ob damit die maximale Signalfrequenz gemeint ist... Alex schrieb: > normale 16-drehgeber Was ist "normal"? Falk Brunner schrieb: > Aufpassen muss > man bei der Synchronisierung des CPLD Taktes und des SPI Taktes. Und/Oder im Gray-Code zählen.
Karl Heinz Buchegger schrieb: > Ich interpretiere das mal als: 16 Positionen pro Umdrehung. Okay, habe das nicht gesehen, dann ist da ja sowieso Unfug: > Ich habe jetzt nicht alles durchgelesen, aber ich würde an deiner > Stelle wenn du schon sowieso mit PIC arbeitest, die Ressourcen auf > insgesamt 3 PICs (je 2 QEI) verteilen. Gruß Hermann
@ Ssss (Gast) >Also wahrscheinlich reichen 17-18 Bit für meine Anwendung aus. Aber gut, >um sicher zu sein habe ich mal 20bit angesetzt ;) Rechung? >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. Wieso? Achso, 20 Bit Up/Down im CPLD wird schon SEHR üppig, weil die nur begrenzt Zusatzlogik für sowas haben. >Achso ich hab noch was vergessen: Die zähler haben zusätzlich noch ein >Compare Register. AHA! Das ist schon mal was anderes. Du baust einen halben Servocontroller im CPLD. Klar dass dann irgendwann Sense ist. >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. Kommt drauf an. Wenn man weiß was man tun (tm) geht beides sauber. MfG Falk
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
@ Ssss (Gast) >Siehst du eine Chance das ganze in 3x18Bit+compare in einen 144er CPLD >zu bekommen? No Way. >bei Lösung (a) bereitete mir der übergang zwischen Taktdomäne >Zählerdaten und SPI Register noch ein wenig Kopfzerbrechen, Ein lösbares Problem. > bei b) fand ich das alles klarer. Ja, ist aber bezüglich der SPI-Frequenz eingeschränkt. MFG Falk
Falk Brunner schrieb: >>Siehst du eine Chance das ganze in 3x18Bit+compare in einen 144er CPLD >>zu bekommen? > No Way. Da war doch die Sache mit dem FPGA im Beitrag "Umgang mit CPLD's lernen ( Altera od XILINX) via Dev Kit"
@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
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.