ZitierenBesteht nicht die Möglichkeit Interrupts zu benutzen? Dann würde der MC auf keinen Fall ein Signal verpassen.
Ist das Signal getriggert?
MFG Moritz
Vielleicht doch nicht ganz so dumm.
Bisher haben wir die Wegbestimmung über Reflexkoppler (CNY70,...) und Gabellichtschranke mehr schlecht als recht verwirklichen können. Es entstand die Idee einen externen Zähler zu konstruieren.
Hat hier irgendjemand damit schon praktische Erfahrungen?
Auf die Idee kamen wir weil der Prozessor offenbar so ab und an vergisst einen Tick mitzuzählen; ein Schieberegister/Multiplexer nähme dem uC ein wenig die Arbeit ab.
REB
Besteht nicht die Möglichkeit Interrupts zu benutzen? Dann würde der MC auf keinen Fall ein Signal verpassen.
Ist das Signal getriggert?
MFG Moritz
Es lief bisher über externe Interrupts, die bei ansteigender Flanke getriggert wurden. Nur produzieren zwei solche Taktscheiben bergeweise Interrupts, und unser Controller hatte dann nicht mehr genügend Zeit für andere Aufgaben. Es wurden z.B. Zeichen am USART verschluckt...
So kamen wir halt auf die Idee, einen Hardwarezähler zu nehmen und ihn per SPI regelmäßig abzufragen.
Kann jemand Erfahrungen dazu posten? (wie baue ich die Schaltung so, dass beim Abfragen keine Impulse "verschluckt" werden? Hat jemand sowas schonmal gebaut und kann nen Schaltlan posten?)
mfG
cht
Schaltplan brauchst du eigentlich nicht. Nimm einen 8-bit-up-down-counter, dessen Ausgänge auf ein 8-bit-Schieberegister gehen. Der Takt, der Strobe und der Datenausgang des Registers gehen auf 3 µC-Ports. Zuerst gibst du den Strobe aus zum laden des Registers. Danach taktest du 8x das Register und liest VOR dem Takten das Output-Bit des Registers ein. Wenn du möchtest kannst du den Zähler nach einem Lesevorgang löschen, kannst aber auch die Differenz zum vorigen Zählerstand bilden um die zurückgelegte Teilstrecke zu messen (bei Kurvenfahrt z.B.)
Up-down-counter nur, wenn der Inkrementalgeber des Rades auch einen entsprechenden Ausgang hat. Sonst Vorwärts- oder Rückwärtsfahrt durchführen -> Impulse zählen und als positive oder negative Strecke in die Berechnung des Weges einsetzen. Dann reicht ein einfacher Zähler.
Es gibt auch Counter-shift-register als ein Schaltkreis, mußt mal googlen. Phillips hat die sicher auch
Hat hier irgendjemand damit schon praktische Erfahrungen?Ich nehme an bei der Frage nach der Erfahrung und nach einem Schaltplan geht es um solche Details wie:Schaltplan brauchst du eigentlich nicht.
Soll der Zählereingang gesperrt werden, während das Schieberegister ausgelesen wird? Besser mit Latch? Synchronisation von Latch und Zählimpuls?
Soll/muß der Motor zum Auslesen des Zählers stehenbleiben?
Soll durch die Fahrt (während der Fahrt) ein bestimmter Zählerstand angesteuert werden?
Soll auch die Geschwindigkeit der Motoren verglichen werden können?
Manfred
ja richtig, Manfred, ich hatte aber sowieso mit weiteren fragen gerechnet. Da kann man dann auch Details besser klären. aber REB fragte so sachkundig, daß ich von mehr als Grundkenntnissen ausging.
Übrigens hab ich die gleichen Überlegungen angestellt, wie er/sie.
Wenn man den Prozessor von Zählvorgängen entlasten will oder mehrere Zähler abfragen muß, dann ist so eine Lösung mit einer Art Sensorbus gekoppelt garnicht schlecht.
Übrigens ein Latch braucht man bei meinem Vorschlag nicht. Gelatched wird eh im Schieberegister. Während des Strobes kann der Zähler locker weiterzählen. Dann wird der Impuls eben mit erfaßt. Einen digitalen Fehler von einem Digit hat man sowieso immer (auch bei ADUs usw.)
Statt Schieberegister ist natürlich auch ein PCF8574 I2C-Portexpander einsetzbar.
Nicht wirklich. Ich wollte eigentlich zunächst ein Mal wissen ob es schon Erfahrungen mit dem externen Auslesen von Encodern gibt (das Rad muss man nicht jedes Mal neu erfinden).Zitat von Manf
Ob der Motor stehenbleiben soll (wenn man mal die Taktfrequenz und Befehlszyklen eines Mega 32 oder 128 betrachtet und grob die Aufeinanderfolge von Impulsen abschätzt erübrigt sich eigentlich solch eine Frage) spielt keine Rolle.
Noch mal: Es geht um Odometrie, also um Korrektur von Fehlern, die durch unterschiedliche Motorengeschwindigkeit / Getriebespiele / ... entstehen. Ein angenehmer Nebeneffekt könnte sein, dass dann auch die Orientierung im Gelände leicht zu programmieren ist.
Wie man Takte synchronisiert - das interessiert mich nicht (weil bekannt).
Die Idee mit dem PCF8754 ist übrigens gut; danke dafür.
REB
Meinst du damit, wie man es macht, dass die Motoren gleich schnell laufen?Wie man Takte synchronisiert - das interessiert mich nicht (weil bekannt).
Wie machst du das denn? Würde mich interessieren, weil ich bald vor dem selben Problem sthen werde.
MFG Moritz
Nein, Taktsynchronisationen sind mir bislang nur bei bei Übertragungsprotokollen über den Weg gelaufen.
Um es vorweg zu sagen: Motoren laufen nie gleich schnell. Deshalb muss man ja den zurückgelegten Weg messen und je nach Messergebnis die Motoren unterschiedlich ansteuern. Und genau damit schlagen CHT und ich uns rum...
Für Odometrie ohne externe Counter: siehe seattle robotics org...
REB
Das wollte ich damit sagen, dachte du/ihr hättet einen schönen Lösungsansatz.Motoren laufen nie gleich schnell. Deshalb muss man ja den zurückgelegten Weg messen und je nach Messergebnis die Motoren unterschiedlich ansteuern.
MFG Moritz
Berechtigungen
Lesezeichen