Hallo, Weiß einer von euch welchen pin ich beim atmega 8515 als pwm pin benutzen kann. Danke Mfg niclas
Wie wärs mit einem Blick ins Datenblatt? Hardware PWM hat immer etwas mit einem Timer zu tun. Welche Timer können beim M8515 PWM? Wenn ein Timer PWM beherrscht, dann hängt das damit zusammen, dass er mit der Compare Match Unit arbeitet. Das zugehörige Register heisst immer irgendwie OCRn, wobei n für die Nummer des Timers steht. Angehängt wird noch ein A oder ein B, wenn es mehrere COmpare Match Units bei diesem Timer gibt. Und herausgeführt ist die PWM dann immer auf einem Pin, der OCn heisst, wobei n wieder die Nummer des Timers ist und gegebenenfalls ein A oder ein B anheghängt wird. Der M8515 besitzt 2 Timer, den 0-er und den 1-er, wobei der 1-er über 2 Compare Match Einheiten verfügt. Auf welchen Pins liegt also die Zusatzfunktion OC0, bzw. OC1A bzw. OC1B? Und ja: du brauchst das Datenblatt. Ohne kommst du nicht weit. Also gewöhn dich daran selbst mit dem Datenblatt zu arbeiten, sodass dir andere nicht jede Kleinigkeit, die ganz leicht im Datenblatt zu finden ist, vorkauen müssen. Sonst sehe ich nämlich in der Programmierung dann schwarz für dich.
Das Datenblatt ist oft ein Buch, in dem ich manchmal lange such' bis die Lösung wird gefunden: Soll statt ver-odern ich ver-unden? Ist der Timer lang und breit, erzeugt er auch 'ne lange Zeit. Ist er klein und nur 8 Bit, dann geht das ohne Weit'res nit! Schön ist auch die PE-WE-EM, als ob ich mir die Haare kämm, sieht das auf dem Oszi aus nur hier doch immer ohne Laus... Wenn mich dann der Teufel packt, dann stell ich auf externen Takt. Bloß: Das dann plötzlich Nichts mehr geht weil das Ding ganz stille steht. Das Biest macht nunmehr keinen Hieb und ruhet sanft im vollen Sleep. Da erzeug ich einen Inter-rUpt, daß er aus der Fassung huppt! In diesem Sinne Paul
Karl Heinz schrieb: > Wie wärs mit einem Blick ins Datenblatt? Das kann ganz sicher niemals schaden. > Und herausgeführt ist die PWM dann immer auf einem > Pin, der OCn heisst Vorsicht, bei Atmels neuesten Kreationen ist das nicht mehr unbedingt der Fall. Tiny441/841 z.B. fällt mir da ein, wohl weil ich aktuell gerade an einem Projekt mit einem solchen Tiny arbeite und in diesem Projekt tatsächlich PWM eine zentrale Rolle spielt. Tja, so nützlich routebare Ausgänge oft sind, das Datenblattlesen erschweren sie natürlich leider etwas. Ich habe deshalb extra für die Projektdoku für die Hardwareleute ein klassisches Pinout mit "OCxy" für das gewählte Routing erzeugt, damit die nicht bei jedem Nachschlagen bezüglich der Hardware wieder erst die den Scheiß aufwendig aus dem Datenblatt und meinem Programmcode zusammenbasteln zu müssen. Übrigens, in diesem Zusammenhang fällt mir noch was ein: Diese neue Routingeinheit hat offensichtlich auch noch einen Bug. Für die Dauer von genau einem Takt liegen beim "Freischalten" eines bereits vollständig initialisierten und laufenden Timers über das TOCPMCOE-Register nach außen teilweise falsche Pegel an, die weder dem aktuellen Zustand des Timers in diesem Moment entsprechen noch dem Zustand der entsprechenden IO-Pins, die bis dahin ein für den konkreten Hardwareaufbau sicheres Signal liefern sollten. Besonders "lustig": Ob und welche der Ausgänge von diesem illegalen Pegelwechsel betroffen sind, ist (zumindest scheinbar) zufällig. Jedenfalls ergab ein statistischer Test eine Gleichverteilung mit 50% Wahrscheinlichkeit für das Auftreten an jedem einzelnen getesteten Pin. Bei vier Pins (H-Brücke) ist also theoretisch bei jedem vierten Startup potentiell das Ableben einer Hälfte der Brücke zu erwarten. Gar nicht gut... Nur der relativ hohe verwendete Takt und die Gatekapazitäten der FETs haben bisher bei dem Projekt heftige blaue Wölkchen mit "Pfuff" aus eben diesen FETs verhindert. Ich bin deshalb überhaupt erst beim Oszillografieren eines ganz anderen Problems in der Regelung auf diesen Bug gestoßen. Bei deutlich geringerem Takt könnte es aber deshalb tatsächlich ernsthaft knallen. Da muß Atmel wohl noch nachbessern. Und wir verwenden bis dahin statt der passend konfigurierten IO-Pins einfach Pullups/Pulldowns, um die "unsichere" Zeit bis zur vollständigen Timerinitialisierung zu überbrücken. Denn (und das ist der wesentliche Punkt): Bei auf Eingang konfigurierten IOs passiert der illegale Pegelwechsel nicht. Die starten dann beim Freischalten via TOCPMCOE wirklich exakt mit dem Zustand, der dem aktuellen Zustand des Timers entspricht. Muß man das verstehen? Wohl nicht. Vermutlich wird sich aber der zuständige Entwickler bei Atmel die Haare raufen, denn der wird es verstehen... Aber beim 8515-Methusalem des TO sollte ja noch alles wie gewohnt sein...
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.