@oberallgeier
Ich führe mir das nach dem Abendessen nochmal genauer zu gemüte und denk drüber nach, klingt aber nach einen Sinnvollen Ansatz
@Peter
Ich vermute wirklich gleichzeitig, das Analog Oszi sieht nicht das kleinste Zucken.
Aber - Man ohhh Man, wieso bin ich da nicht selber drauf gekommen - 2 Matrixen...
dann wären es wirklich erst mal nur 2 Kanäle zum auswerten, deren Signale sich ja auch NIE "über"schneiden sondern nur aneinander anschließen.
Gruß Basti
EDIT:
@Oberallgeier
Die Idee an sich ist nicht schlecht - Bauchschmerzen macht mir die Tatsache, das mir dann alle 10uS ein Interrupt geworfen wird, wovon so ca 99,9% sinnlos passieren, da sich die Zustände in einem Zyklus ja nur 12 mal ändern.
@Peter
Aber da kommt mir mit der 2 Matrix Methode eine geniale und einfache Idee.
Beide Signale kommen an Interrupt Eingänge.
Ein Timer läuft einfach vor sich hin. Bei Überlauf wird KEIN Interrupt geworfen. Bzw ein Überlauf könnte auf Signalverlust hinweisen (Fail-Safe Funktion)
-INT0 is aktiv und wartet auf High Flanke
-INT1 is deaktiviert
-Kommt nun ein Signal an INT0 wird der Timer auf 0 gesetzt INT0 deaktiviert und INT1 aktiviert
-Bekommt dann INT1 sein Signal wird der Timerwert gespeichert (=Länge Kanal 1), der Timer auf 0 gesetzt, ein Kanal Zähler erhöht und INT1 deaktiviert + INT0 wieder aktiviert.
-Kommt nun wieder auf INT0 ein Signal wieder Wert speichern, Timer Reset, Kanal Zähler erhöhen, INTs tauschen usw...
-Wenn dann der Kanalzähler auf 6 steht, wird der Interrupt nicht getauscht sondern der aktuelle auf Fallende Flanke umkonfiguriert, gibt ja keine weitere High Flanke mehr in diesem Zyklus.
-Wenn diese LOW Flanke dann kommt, wieder Wert speichern, und alles auf Anfang:
INT0 aktiv
INT1 deaktiv
Kanal Zähler 1
Ping Pong Prinzip Quasi...
müsste doch klappen oder nicht?
Vorteil:
Es wird wirklich nur ein Interrupt geschmissen wenn auch wirklich was passiert.
Gruß Basti
Geändert von Bomberpilot (17.12.2014 um 17:35 Uhr)
Hallo,
40ms empfinde ich als zu lang. Das geht auf jedenfall auf die Performance von analogen Servos. Ob digitale so etwas überhaupt mitmachen weiß ich nicht. In ein paar ms Unterschied (vielleicht +-5ms) zu 20ms würd ich kein Problem sehen.Zitat von Bomberpilot
Eine so große Abweichung von +20ms würde ich planmäßig so ziemlich als letztes in Betracht ziehen sondern erstmal schauen, ob man nicht irgendwie den Standard erreichen kann. Gab ja schon interessante Beiträge.
Gruß
Searcher
Hoffentlich liegt das Ziel auch am Weg
..................................................................Der Wegzu einigen meiner Konstruktionen
Hallo.
Ich verfolge das Thema und habe da ein paar Fragen:
Das Servo-Signal ist max. 3ms lang? Was hast du denn da für Servo-Signale anliegen? Die kann kein Servo auswerten. Üblicherweise sind Servo-Signale zwischen 1ms und 2ms lang, Mittelstellung bei 1,5ms. Der Drehbereich kann dabei auch mal auf 0,8ms bis 2,2ms erweitert werden, aber 3ms erzeugt bei mir erst einmal Fragezeichen. Sicher, dass du das Signal korrekt ausgewertet hast?
Eine weitere Frage: Gibt es deiner Meinung nach denn einen Unterschied in der Datenpaket-Übertragung zwischen 40MHz und 2,4GHz? Meiner Meinung nach nicht wirklich. Die Signal-Intervalle liegen weiterhin an jedem Kanal bei ca. 20ms, egal ob 27MHz, 35MHz, 40MHz oder 2,4GHz.
Was das Auswerten der Signale am Eingang und die Ausgabe am Ausgang betrifft: Die Daten werden in fertigen Paketen von der Fernsteuerung an den Empfänger gesendet. Eventuell mal alle Kanäle mit dem Oszi durchmessen, ob die PWM-Signale einzeln abgearbeitet werden oder simultan. Wenn sie nacheinander abgefertigt werden, solltest du eigentlich genügend Zeit für weitere Aufgaben haben.
LG - Maik
Zu dem Thema ist hier eine sehr schöne Applikation für einen Basic Tiger, mit guten Erklärungen die sich auf andere Systeme und Anwendungen übertrage lassen. Das habe ich auch schon mal nachgebaut und es funktioniert Spitze.
https://wilke.de/fileadmin/templates...Technology.pdf
Hat doch niemand behauptet, oder?
Naja bei meinem 2,4GHz Empfänger macht das sehr wohl einen Unterschied, da ich das Summensignal NIE in die Finger bekomme....
Der Empfänger Trennt Summensignal vom Trägersignal ja im Chip, ab da wird es an den Controller der die PWM für die Servos erzeugt digital weiter gereicht, da is nix mit abgreifen.
Ja von den 25 Hz bin ich auch schon wieder weg, war nur so eine Idee, aber eher als letzte Möglichkeit.
Ich werde morgen mal versuchen, das im Edit meines letzten Post's angesprochene Umzusetzen, das könnte super funktionieren, vor allem mit sehr niedriger Prozessor Last.
Gruß Basti
EDIT:
@Slowly
Danke für den Link, aber leider nicht zu gebrauchen, die nutzen dort auch das mir nicht zur Verfügung stehende Summensignal... Mit dem wäre das ein Klacks, aber alle getrennt auszuwerten erfordert schon etwas mehr Aufwand.
Geändert von Bomberpilot (17.12.2014 um 20:08 Uhr)
Hallo Basti,
Welche Bandbreite hat der?
Die Pulse müssten in der Grössenordnung <1µs liegen, das sollte ein 20MHz-Ozi noch anzeigen können.
Wenn du 2 Kanäle hast, kannst du doch mal 2 benachbarte Kanäle anzeigen lassen und die Differenz der Flanken messen.
Möglicherweise war deine Diodenmatrix nur zu langsam.
Noch genauer wird das Ganze, wenn du anstatt des INTx den Capture-Eingang des Timers nimmst.
Der einzige Nachteil ist, dass du dann die Differenz zum letzten Zählerstand berechnen musst und beim Überlauf musst du aufpassen mit der Rechnung.
Der Jitter liegt dann aber bei +/-1 Zählerauflösung, egal wie lange es dauert bis der Interrupt abgearbeitet wird.
Mit 1MHz-Timertakt hast du schon eine Auflösung von +/- 2µs.
Der Capture-Eingang müsste auch mit den µs-Signalen zurecht kommen, dann müsstest du nicht mal die Flanke umschalten.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Jo is ein 20MHz, sogar noch n gutes altes Hameg 203-6 aber wie gesagt, hab schon versucht mit 2 Kanälen zu messen, da sieht man absolut keine Pause zwischen den Pulsen.
Das mit dem Capture Eingang werde ich prüfen. Der AVR hat aber wahrscheinlich nur einen? In meinem Fall Mega32, aber nur zum testen. Wenn der nur einen hat, fällt das fast wieder flach, wenn Ausgabe vom Empfänger so wie im nächsten Absatz beschrieben.
Aber wenn die die Ausgabe ähnlich wie ich machen, gibt es keine Pause.
Ich mache es mit nem Timer im CTC Mode und schiebe einfach ein Bit durch den Port.
Immer wenn die erforderliche Zeit für einen Kanal verstrichen ist, wirds weiter geschoben. Danach wird dann noch so lange "leer" gewartet, bis die 20ms voll sind. Also eigentlich die beste und Ressourcen schonendste Methode, da nur ein Interrupt geworfen wird, wenn auch nötig.
Gruß Basti
Das zusammenschalten in 2 Gruppe ist eine gute Idee. Die meisten der kleineren AVRs haben zwar nur eine Input-capture Einheit (an Timer 1), können aber dafür sowohl den ICP Pin als auch den analogen Komparator als als Eingang nutzen. Die Input Capture Einheit erlaubt eine genaue Zeitmessung ohne von Interrupts gestört zu werden.
Wenn man es geschickt macht, kann man den Timer 1 trotzdem noch für die Erzeugung der Ausgangssignale nutzen - die output Compare Einheiten bleiben erhalten. Man muss nur den Timer durchlaufen lassen und die passenden Zeiten für die Interrupts programmieren.
Um die Ausgabe nicht zu stören wäre ein freigeben von Interrupts angesagt und ggf. auch die Benutzung von etwa ASM, denn Bascom erzeugt recht viel Overhead beim Interrupt.
Wenn sicher ist, dass die Eingangsignal ungestört sind, könnte man die auch per PinChange Interrupt erfassen, und auch da ein Unterbrechen der Interrupts erlauben.
Mehr dazu bitte
Hallo,
Die Zeiterfassung mit Interrupt hat immer das Problem mit Jitter. Kommt natürlich auf die nötige Genauigkeit an, ob das stört.
Die kürzeste Ansprechzeit, hängt schon vom gerade bearbeiten CPU-Befehl ab. Dieser wird bei den meisten CPUs erst mal zu Ende abgearbeitet. Komplexe Befehle wie MUL und DIV können da schon einige Takte benötigen.
Dann kommt der Interrupt-Controller ins Spiel. Der setzt Prioritäten und dann können andere Interrupts zuerst bedient werden.
Normalerweise sind Interrupts während der Ausführung einer ISR gesperrt. Je nach Laufzeit der ISR gibt dies weitere Verzögerungen.
Der Rest ist dann Glückssache, was in der Praxis wie oft zusammenfällt!
Ich hatte da. vor langer Zeit, auch mal ein Interrupt-Problem:
Ein 6502 mit 1MHz Takt.
Für 1µs war da der Interrupt enabled, wo das nicht sein sollte.
Bei manchen Geräten führte dies nur so 1x in der Woche zu einem Absturz, bei anderen schon nach einigen Minuten.
Selbst auf den Zufall ist nicht verlass
Ob da eine Quantenverschränkung mitgespielt hat??
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Berechtigungen
Zitieren
Lesezeichen