mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kommunikation mit 2 Megas


Autor: Tom Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: xXx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was hat das ganze jetzt mit Kommunitation zu tun?

Autor: Tom Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also lieber 2x Mega8 als als 1x einen passenderen Controller (z.B.
Mega162)?

Autor: Tom Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tom Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Tom Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... und den Timer0 die Überläufe von Timer1 mitzählen lassen...

Autor: Tom Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter: Das war nicht so ganz ernst gemeint. Klar - man hat genau das
gleiche Problem, nur etwas anders getarnt.

Autor: Tom Bayer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom Bayer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist noch das Logfile der UART Kommunikation

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu "dtc". hightime/(hightime+lowtime) ist nun einmal bestenfalls 1
(bei lowtime=0), sonst kleiner. Und die einzige vorzeichenlose Zahl <1
ist 0.

Autor: Tom Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was passieren kann, in dieser Reihenfolge:
    Capture Event
Time
    Timer Overflow
    Capture Interrupt

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos: Den umgekehrten Fall kann es auch geben, also ICR captured nach
Overflow, aber "ueberlauf" hat's noch nicht mitgekriegt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.