Hallo zusammen, ich müsste sowohl ein PWM Signal auswerten (feste Frequenz, variable Weite) als auch ein daraus resultierendes generieren (andere feste Frequenz, variable Weite). Ich benutze zwei Mega8. Der eine wertet das PWM Signal aus (ICP Pin ) der andere generiert das PWM Signal OC1A Pin). Das ganze habe ich mit einem selbst erstellten 8bit Datenbus miteinander verbunden. Soweit klappt die Sache auch recht gut. Nun möchte man natürlich seine Schaltungen auch immer weiter verbessern und auch was dazu lernen. Ich habs leider nicht hinbekommen ein PWM Signal mit dem 16bit Timer auszuwerten und gleichzeitig ein anderes mit dem 16bit Counter zu generieren. Geht das irgendwie anders aus noch? Und falls nicht wie kann man 2 AVR's zuverlässig verbinden (TWI, UART oder SPI)? Grüße Tom
Welche Frequenz haben denn Deine PWM-Signale? wenn diese im unteren kHz bereich sind, sehe ich keine Probleme dies mit einem einzigen AVR hinzubekommen. Wenn man noch betonen dürfte, das die Generierung eines PWM Signales eigentlich nur aus der Initialisierung und dem schreiben des PWM Regs (bei einer änderung) besteht. Die Generierung benötigt also fast keine Rechenleistung. Bitte etwas mehr infos... Programmiersprache, Taktfequenz der PWM Signale, Prozzi Takt,... gruß, Tubie
Hallo, also die PWM Signale haben eine Frequenz < 1kHz. Ich betreibe den 16bit Counter des Mega8 in Mode 14. Damit ist doch für den Betrieb dieser Counter belegt, sprich ich kann ihn nicht mehr für das auswerten des angelegten Signals benutzen(Input Capture Einheit benutzt ebenfalls den 16bit Counter). Betrieben wird der Mega8 mit internem 1MHz Takt und ich programmiere in C. Richtig zum generieren wird nur der INIT und das updaten benötigt. @xXx blöd ist, wenn man sich noch nicht mal traut seinen Namen zu schreiben (aber vielleicht schreibt man den auch falsch -> es heisst Kommunikation und nicht Kommunitation !) >> "Und was hat das ganze jetzt mit Kommunitation zu tun?" Ich will einfach nur wissen, welche Kommunikationsmethode zuverlässig ist. Hardware TWI habe ich in diversen Beiträgen gelesen macht immer wieder Probleme wenn Signale nicht korrekt empfangen werden, UART habe ich bisher nur mit dem PC betrieben, aber nicht wenn ich 2 AVR's jeweils mit internem Oszillator betrieben habe(Synchronisation?) und bei TWI habe ich keine Erfahrung. Grüße Tom
Also lieber 2x Mega8 als als 1x einen passenderen Controller (z.B. Mega162)?
Also habe ich das richtig verstanden, dass man die ICP Unit und die PWM Generierung im Mode 14 nur mit 2 ATMEGA8 realisieren kann? Kann mir dann vielleicht jemand einen Tipp geben wie ich die beiden Megas am einfachsten sichersten miteinander kommunizieren lassen kann? Vielen Dank schonmal Tom
Stimmen dürfte, dass sich Mode14 und Input Capture ausschliessen. Frag ich mich aber, warum du partout auf den Mode14 rauswillst? Es gibt ja noch ein paar andere Modi, die nicht ausgerechnet das ICR blockieren. Anonsten schliessen sich Input Capture und PWM Output mit dem gleichen 16bit-Timer nur dann aus, wenn die Frequenzen schweinemässig weit auseinanderliegen.
Hallo A.K, was meinst du denn mit schweinemässig weit auseinanderliegen. Die Frequenzen liegen beide unterhalb 1kHz. Ich habe den Mode14 genommen, denn da kann man die Ausgangsfrequenz genau einstellen. Andernfalls muss man ja eine fixe PWM-Frequenz nehmen. Hintergrund ist, dass dahinter eine Elektronik sitzt die 400Hz +- 3Hz braucht. Ich hab das ganze auch schon mit einem Interrupt versucht die eingehende Frequenz zu capturen(jeweils geschaut welcher Zustand im Durchlauf davor angestanden hat, und die Zeit mit dem 8bit Timer gemessen) allerdings kam es dabei immer wieder zu Fehlern die ich mir nicht erklären konnte. Ich lass mich aber gerne überzeugen, dass ich nur einen Mega8 brauche der dann auch zuverlässig läuft ;-) Grüße Tom
"Ich habe den Mode14 genommen, denn da kann man die Ausgangsfrequenz genau einstellen." Mode15 unterscheidet sich doch nur dadurch, dass ICR1 für Input Capture frei bleibt, dafür OC1A draufgeht. Bleibt aber immer noch OC1B für den PWM-Ausgang übrig. "schweinemässig weit auseinanderliegen" Wenn beispielsweise der PWM-Output so langsam takten muss, dass die Auflösung des Timers für den Input nicht reicht.
Hallo A.K., was ich nicht verstehe ist, dass selbst wenn ich Mode 15 benutze ich immer noch nicht mehr 16 bit Timer zur Verfügung habe. Wenn ein Ereignis am ICP1 Pin ansteht dann wird doch der 16 bit Timer Wert in das Input Capture Register geschrieben. Im Counter steht aber doch schon der laufende Wert vom Fast PWM Mode drinne. Kannst du mir bitte erklären wie du das meinst oder verstehe ich da was falsch? Grüße Tom
Ich weiß jetzt nicht genau in welchem Modus (Nummer) ich mein Servo-Umsetzer betreibe, aber bei dem Ding benutze ich ein und den gleichen Timer für ICP und OC. Allerdings arbeitet der Timer bei mir im Overflow-Modus und ICP und OC werden per Interrupt angesprungen (OC kann man auch komplett per Hardware arbeiten lassen...). ICP reagiert (löst ein Interrupt aus) nur auf die eingestellte Flanke und OC halt beim eingestellten Vergleichswert. Da ich im Überlauf-Modus arbeite, kann ich auch beide OCs benutzen... Eigentlich sollte das kein Problem für einen einzelnen Controller sein. Sonst muß man die beiden per SPI verbinden, wobei der eine nur Master (ICP) und der andere nur Slave (OC) sein müsste...
Wozu braucht du partout mehrere Counter/Timer? Der Timer zählt fortlaufend von 0..OCR1A. Beim Input Capture wird der laufende Wert ins ICR1 geschrieben und ein Interrupt erzeugt - darauf leitet sich die Messung vom Input ab. Und OCR1B definiert den PWM-Ausgang.
Im Prinzip geht das. Mathematisch gesehen ist es egal, ob nun der Timer bis 65535 zählt oder nur bis 2449 (400Hz bei 1Mhz = 2500). Ist der 2. Capturewert kleiner, als der erste, gab es einen 2449->0 Überlauf, also einfach zur Differenz noch 2500 addieren. Kann die Pulsbreite aber länger als 2500 sein, muß man noch die Clear on Compare Interrupts mitzählen und drauf achten, daß der Capture-Interrupt kurz davor oder danach auftreten könnte, ist also etwas tricky, dann alle Fälle zu berücksichtigen. Peter
Wem das bei >2500 in Software zu heikel ist, der kann natürlich auch OC1B mit T0 verbinden und den Timer1 die Überläufe mitzählen lassen. Dann verlagert sich das "tricky" auf das Problem, den so entstandenen 24-Bit-Wert konsistent auszulesen ;-).
Alles klar ich hab verstanden wie ihr das gemeint habt. Ich denke der Aufwand ist nicht viel mehr ( jetzt wo ich es verstanden habe) und ich kann mir dem zweiten Mega8 sparen. Vielen Dank für die Antworten. Grüße Tom
@A.K. es ist egal, ob man die Überläufe im Interrupt oder mit T0 zählt. Entscheidend ist, daß die Überläufe nicht gleichzeitig mit dem Capture gelesen werden, sondern später. Somit braucht man beidesmal die Entscheidung, ob ein zeitnaher Überlauf vor oder nach dem Capture erfolgte. Peter
@Peter: Das war nicht so ganz ernst gemeint. Klar - man hat genau das gleiche Problem, nur etwas anders getarnt.
Hallo, ich habe versucht die ganze Sache wie von A.K. und Peter beschrieben zu implementieren. Leider habe ich immer noch einen kleinen Fehler im Code (ist angehängt). Im Moment betreibe ich den Mega8 mit einem externen 16MHz Quarz und ich möchte ein 140Hz Signal am Eingang auf ein 250Hz Signal am Ausgang wandeln. Ich lasse mir die Daten immer wieder über UART zum debuggen an den Rechner schicken. Wie im File zu sehen ist kommt die Auswertung immer mal wieder, allerdings fast periodisch, durcheinander(wie kann der Wert negativ werden). Kann mir einer erklären wie dies passieren kann? Was mir noch aufgefallen ist, ich kann die Werte nicht in der ISR über UART verschicken. Dann wäre ich mir auch sicher dass immer die richtigen Werte ankommen. Probleme macht auch die konvertierung in eine 8bit (dtc) variable. Diese bleibt immer auf null. Kann mir jemand helfen? Vielen Dank schonmal, Ihr seid klasse. Grüße Tom
Wie schon oben skizziert, ist es einfacher, wenn die Input-Frequenz grösser ist als die Output-Frequenz. Sonst entsteht das Problem, dass Capture- und Overflow-Interrupts, die dicht beieinander liegen, nicht zwingend in der erwarteten Reihenfolge ausgeführt werden. Meistens schon aber eben nicht immer. Das war's was Peter als "tricky" bezeichnete. Musst da etwas Heuristik einbauen, die anhand der gelesenen Werte potentiell kritische Fälle entweder korrigiert (more tricky) oder schlicht ignoriert (less tricky - geht aber nur wenn die Output-Frequenz nie ein exaktes Vielfaches der Input-Frequenz betragen kann).
Zu "dtc". hightime/(hightime+lowtime) ist nun einmal bestenfalls 1 (bei lowtime=0), sonst kleiner. Und die einzige vorzeichenlose Zahl <1 ist 0.
Hallo A.K., vielen Dank für die Antworten (Bist du um die Uhrzeit noch aufnahmefähig ;-)). Die Sache mit dtc leuchtet ein. Man sollte halt immer wissen was man macht. Das Problem, dass die Eingangsfrequenz kleiner als die Ausgangsfrequenz ist hab ich leider. Das kann man nicht ändern. Tricky war mir klar, aber sonst machts ja keiner Spass. Wie meinst du denn ich könnte potentielle Fälle ignorieren? Die beiden Frequenzen stehen soweit fest, also ein Vielfaches kommt nicht vor. Grüße Tom
Was passieren kann, in dieser Reihenfolge:
Capture Event
Time
Timer Overflow
Capture Interrupt
Verd... Tab-Taste, nochmal:
Was passieren kann, in dieser Reihenfolge:
Capture Event
=> Timerwert nahe oberem Limit landet im ICR
Timer Overflow
Timer Overflow Interrupt
=> ueberlauf += 1
Capture Interrupt
=> ICR und "ueberlauf" passen nicht zusammen.
Den Fall gilt es zu identifizieren. Einfachster Weg: Wenn ICR dicht am
oberen Limit ist, diese Messung ignorieren.
Apropos: Den umgekehrten Fall kann es auch geben, also ICR captured nach Overflow, aber "ueberlauf" hat's noch nicht mitgekriegt.
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.