Hallo, um einen inkrementalen Drehgeber auszuwerten, suche ich einen IC. Verwendet wird der Tricore TC1797. Da der Drehgeber zur Motordrehzahlmessung gedacht ist und 1024 Striche hat, ist der Prozessor bei einer hohen Motordrehzahl alleine etwas zu langsam dafür. Das Signal des ICs wollte ich dann über die SSC-Schnittstelle einlesen. Welchen IC empfehlt ihr? Was muss ich beachten? Es ist mir wichtiger, dass ich das schnell hinkrieg als dass es eine super tolle Lösung ist.
was genau ist "bei einer hohen Motordrehzahl" ?
Der Antrieb ist im Labor auf 1800 U/Min limitiert aus Sicherheitsgründen. Die Drehgeber haben 1024 bzw. 1250 Markierungen. Sie liefern TTL-Signale, Signal A und B sind um 90° verschoben. Dazu werden noch jeweils die invertierten Signale geliefert. Quasi so: http://www.mikrocontroller.net/articles/Drehgeber
Minty Mint schrieb: > ist der Prozessor > bei einer hohen Motordrehzahl alleine etwas zu langsam dafür. Du hast einen Porsche der dir immer noch zu langsam ist????? wenn es dir nur um die Drehzahl und nicht die Position geht: warum nimmst du dann keine Prescaler-zelle um die Drehzahl zu bestimmen? Ansonsten 1800U/min = 30U/sek * 1024 = 30kHz. Da lacht das mit 20 Mhz getaktete Timer-Array nur. Gruß Anja
Hat dein Encoder keinen Index-Puls ? Also einen Puls pro Umdrehung, der die Nullmarkierung angibt? Ansonsten: siehe Kommentar von Anja
Danke für die Antwort. Da hast du Recht. Aber ich müsste wegen Niquist dann mit mehr als 60 kHz abtasten. Ich weiß nicht, ob das dann viel ausmacht und die CPU überlastet, wenn ich noch 3 andere Sensoren(keine TTL-Signale, sondern analoge Spannungswerte) langsamer abtasten will. Beispielsweise liefert ein Drehgeber eine lineare Ausgangsspannung, die in Verhältnis zur Drehzahl steht. Das mache ich per FADC und dessen Channel-Timern. Zudem werden noch Signale per CAN-Bus empfangen und die Sensorwerte werden auch per CAN gesendet. Die Prescaler-Zelle und das GPTA hab ich noch angeschaut. Hab mich bisher davor gedrückt, da mich die Komplexität und die über 300 Seiten im Manual einschüchtern ^^ :/ Führt wohl doch kein Weg daran vorbei... Das ist für meine Bachelorarbeit und ich hatte davor sehr wenig mit Microcontrollern zu tun. @Daniel V: Doch, hat er. Was nutzt mir das? Deswegen muss ich doch auch so schnell abtasten, um den Puls zu erwischen, oder?
Minty Mint schrieb: > Da hast du Recht. Aber ich müsste wegen Niquist dann mit mehr als 60 kHz > abtasten. ?????? Die Timer-Unit tastet mindestens mit 20 MHz ab. Minty Mint schrieb: > Führt wohl doch kein Weg daran vorbei... Mit einer der beiden PDL-Units kannst Du sogar die Position und nicht nur die Drehzahl erfassen. Ansonsten: für schnelle Ergebnisse ist "DAVE" dein Freund. Gruß Anja
Minty Mint schrieb: > @Daniel V: Doch, hat er. Was nutzt mir das? Deswegen muss ich doch auch > so schnell abtasten, um den Puls zu erwischen, oder? Ich dachte eher an einen TimerInterrupt, aber nachdem ich das Datenblatt vom TC1797 kurz überflogen habe, denke ich, ist Anja eher dein Ansprechpartner. Dass dein Controller zu langsam ist, dazu brauchst du dir keine Sorgen zu machen.
Ok. Dave verwende ich schon, aber da muss man trotzdem Ergänzungen machen. Zudem ist es gerade bei dem GPTA nicht alles selbsterklärend, sondern für mich verdammt komplex. Als ich mittels FADC und dessen Channel Timern 4 Sensoren mit eigenen Interrupts abgetastet und das Ergebnis sofort per CAN weitergeschickt habe, gab es Probleme wenn ich das mit über 25kHz gemacht habe. Dann ist der Interrupt für den Sensor mit der niedrigsten Priorität z.B. nur noch halb so oft aufgerufen worden. Weiß nicht, woran das lag. Die Baudrate beim CAN war 500kBaud.
Minty Mint schrieb: > Weiß nicht, woran das lag. Die Baudrate beim CAN war 500kBaud. Dann rechne doch mal nach wie viele CAN-Botschaften a 100 Bit kannst du denn innerhalb 40us bei 500k-Baud verschicken wenn eine Botschaft 200us dauert? Gruß Anja
Dauert es echt 200µs, eine CAN-Botschaft zu senden? Oder hast du irgendwas in deinem Post verdreht, Anja? Wenn das so ist, dann mach ich das ja schon die ganze Zeit falsch. Aber es werden alle Prioritäten von Interrupts gleich oft ausgeführt. Außer wenn ich die Grenze überschreite, die bei 20 bis 25 kBaud liegt. Außerdem zeigt mir das Programm zum Empfangen der CAN-Nachrichten grob die richtige Zykluszeit an.
Minty Mint schrieb: > Dauert es echt 200µs, eine CAN-Botschaft zu senden? Wenn alle 8 Bytes im Puffer belegt sind dann ja. Wenn nicht dann etwas kürzer. Allerdings ist der Overhead durch Bus Idle, Botschafts-ID und Checksumme relativ hoch. Unter 100us wirds wohl auch bei 2 Bytes Nutzdaten und 500kBit/s nicht gehen. Gruß Anja
1800 upm und 1024 Striche benötigen 16us Reaktionszeit. Das schafft dein 150MHz Infineon Luxus Prozessor nicht ? Erbärmlich. Aber so schlimm ist er nicht, nutzt man seine I/O-Module sinnvoll und schreibt effektive (tabellengesteuerte) Programme, kann der TC1797 sogar Inkrementalgeber bis zu 45 MHz auswerten statt deiner schlaffen 61kHz, bei moderater CPU Belastung. Dennoch gibt es natürlich extern Chips, falls einem die pogrammierung zu viel Arbeit ist: http://www.lsicsi.com/ (LS7083/7084/7166/7266) http://www.avagotech.com/docs/5988-5895EN (HCTL2000/2016/2020/2022/2032) http://lost-contact.mit.edu/afs/eos.ncsu.edu/dist/xact_step/online/onlindb/xapp012.pdf oder sonstige Arten es in Hardware zu machen http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
Der TC1797 hat einen sog. "PCP", das ist einer der drei Cores, die dem TriCore seinen Namen geben. Der PCP ist so eine Art Microcontroller im Microcontroller und für ganz genau solche Sachen angedacht. Für den PCP sollte ein Drehgeber kein Problem sein.
Jungs, er kennt sich doch mit dem Prozessor nicht so gut aus (ich auch nicht), aber: Minty Mint schrieb: > Ok. > Als ich mittels FADC und dessen Channel Timern 4 Sensoren mit eigenen > Interrupts abgetastet und das Ergebnis sofort per CAN weitergeschickt > habe, gab es Probleme wenn ich das mit über 25kHz gemacht habe. Dann ist > der Interrupt für den Sensor mit der niedrigsten Priorität z.B. nur noch > halb so oft aufgerufen worden. > Weiß nicht, woran das lag. Die Baudrate beim CAN war 500kBaud. Das liegt mit 100% an der Programmierung, wenn ein Interrupt nicht mehr funktioniert. Wahrscheinlich schickst du in der ADC-Interruptroutine deine AD-Daten an den CAN-Bus.
Dosmo schrieb: > Für den PCP > sollte ein Drehgeber kein Problem sein. Wie kannst Du jemandem der sich nicht traut sich mit dem Kapitel GPTA zu beschäftigen den PCP (mit notwendiger Assembler Programmierung) empfehlen? Für ein bischen Frequenzauswertung reichen 2 GTC oder 3 LTC-Zellen und eventuell eine FPC-Zelle zur Erhöhung der Genauigkeit (Mittelwertbildung über mehrere Perioden) vollkommen aus. Bei Verwendung LTC braucht noch nicht mal einen Interrupt hierfür. Falls doch eine Positionsbestimmung erforderlich sein sollte nimmt man halt eine PDL-Zelle. Den PCP braucht man ausschließlich nur wenn der Hauptprozessor dermaßen stark ausgelastet ist daß Laufzeitprobleme auftreten. Das kann ich mir bei 4 analogen Sensoren einer Drehzahlspur und ein bischen CAN bei 180 Mips nicht vorstellen. Gruß Anja
Fertige Auswerteschaltung für sehr schnelle und einfache Drehgeberabtastung sind in dieser Applikation beschrieben: http://www.ichaus.biz/upload/pdf/EncoderAnschluss%20-WP22102011de.pdf
Anja schrieb: >Wie kannst Du jemandem der sich nicht traut sich mit dem Kapitel GPTA zu >beschäftigen den PCP (mit notwendiger Assembler Programmierung) >empfehlen? Naja, ich dachte, wenn er schon so verzweifelt ist, daß er nach einem externen IC fragt, sollte man ihm wenigstens sagen, daß er bereits einen geeigneten "internen IC" hat. Aber Du hast schon Recht, der PCP ist etwas anspruchsvoll.
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.