Hallo zusammen, ich versuche mich derzeit am Timer1 des Atmega 8. Das Ziel ist, eine 16bit phasenkorrekte PWM am Ausgangspin OC1A zu nutzen. Beim Debugging in Atmel Studio ist mir aufgefallen, dass bei OCR1A == TCNT1 nicht PORTB, sondern PINB an der Stelle PB1 auf true gesetzt wird, obwohl DDRB =(1<<PB1) eingestellt ist (auch im Debugger sichtbar). Entsprechendes Messen der Spannungen am uC-Pin lässt verständlicherweise keine Wirkung erkennen. Ich verwende Mode 10 (phase correct, ICR1 als Source für TOP und nicht-invertierdene PWM (COM1A1 = 1, COM1A0 = 1)). Laut Debugging macht die Implementierung bis auf die Sache mit PINB das, was sie soll. Habt ihr eine Idee, was hier schiefläuft?
Phil schrieb: > Beim Debugging in Atmel Studio ist mir aufgefallen, dass bei OCR1A == > TCNT1 nicht PORTB, sondern PINB an der Stelle PB1 auf true gesetzt wird, > obwohl DDRB =(1<<PB1) eingestellt ist Das ist wirklich sehr verwirrend ....
Ver Wirrter schrieb: > Phil schrieb: > Beim Debugging in Atmel Studio ist mir aufgefallen, dass bei OCR1A == > TCNT1 nicht PORTB, sondern PINB an der Stelle PB1 auf true gesetzt wird, > obwohl DDRB =(1<<PB1) eingestellt ist > > Das ist wirklich sehr verwirrend .... Das ist nicht sehr hilfreich. Sonst hat niemand eine Idee?
Phil schrieb: > PINB an der Stelle PB1 auf true Ein Schreiben auf PINx sollte den Pin toggeln, wenn dein AVR nicht antik ist. Genaueres steht im Datenblatt. leo
Der "Betreff" ist auch
> nicht sehr hilfreich
Es soll ja Menschen geben, die etwas anderes benutzen.
Mein Erwartung ist, dass bei Output Compare der Pin toggelt. Wenn dieser als Ausgang definiert ist geschieht das über Port und zwar ohne zusätzlich einzugreifen. Der uC ist tatsächlich etwas älter aber als antik würde ich ihn noch nicht bezeichnen.
S. Landolt schrieb: > Wie sieht das Programm aus, auf zehn Zeilen reduziert? Hier mal ein stark reduziertes Beispiel (Fehler tritt immer noch auf)
1 | int main(void) |
2 | {
|
3 | |
4 | DDRB = (1<<PB1); |
5 | PORTB = 0x0; |
6 | |
7 | unsigned char configurationA = (1<<WGM11)|(1<<COM1A1)|(1<<COM1A0); |
8 | unsigned char configurationB = (1<<WGM13); |
9 | unsigned char OnCondition = (1<<CS11); |
10 | unsigned int TOP = (1 * 1000000UL)/(2*8*100); |
11 | ICR1 = TOP; |
12 | unsigned int compareValue = (TOP/100) * (100-50); |
13 | OCR1A = compareValue; |
14 | TCCR1A |= configurationA; |
15 | TCCR1B |= (configurationB |OnCondition); |
16 | volatile unsigned int cnt = 0; |
17 | while (1) |
18 | {
|
19 | cnt++; |
20 | |
21 | }
|
22 | }
|
Phil schrieb: > Der uC ist tatsächlich etwas älter aber als > antik würde ich ihn noch nicht bezeichnen. In meinem Manual fuer Atmega328 steht: "18.2.2. Toggling the Pin Writing a '1' to PINxn toggles the value of PORTxn,..." In Atmega8-L konnte ich das nicht finden. Wahrscheinlich hast du Code fuer einen neueren uC. leo
Phil schrieb: > Beim Debugging in Atmel Studio ist mir aufgefallen, dass bei OCR1A == > TCNT1 nicht PORTB, sondern PINB an der Stelle PB1 auf true gesetzt wird, > obwohl DDRB =(1<<PB1) eingestellt ist (auch im Debugger sichtbar). Das ist vollkommen korrekt so. Der Timer übernimmt zwar die Kontrolle über den Pin, aber NICHT über das entsprechende Bit im PORT-Register. Das eigentliche Pin-Signal kannst du im Debugger nicht sehen, nur dessen (um einen Takt verzögerte) Wirkung auf das entsprehende Bit im PIN-Register. Dasselbe Verhalten hast du auch bei allen andere Peripherie-Teilen mit Port-OVERRIDE. Das heißt übrigens absichtlich overRIDE und nicht overWRITE, weil das nämlich exakt das tatsächliche Verhalten beschreibt. > Entsprechendes Messen der Spannungen am uC-Pin lässt verständlicherweise > keine Wirkung erkennen. Das ist nun wieder nicht korrekt. Am Pin messen kann man natürlich den korrekten Pegel, aber nur dann, wenn das entsprechende Bit im PORT-Register zuvor auf 1 gesetzt wurde und damit der Pin auf Ausgang. Nur dann kann das vom Timer generierte Signal bis an den Pin gelangen. Dieses Verhalten ist allerdings weit weniger einheitlich. Es gibt etliche Peripherie, die selbstständig den Pin als Ausgang setzt oder auch als OpenDrain-Ausgang, bei dieser Peripherie spielt der Zustand des Portbits dann keine Rolle. Steht übrigens wirklich alles erschöpfend im Datenblatt beschrieben, sogar mit Blockschaltbild der Pin-Mimik. Darin findest du sogar die Signale, die im Debugger unsichtbar bleiben, weil sie halt nicht in irgendeinem IO-Register sichtbar sind. Man muss dieses verdammte Datenblatt halt einfach nur mal LESEN...
c-hater schrieb: > Das ist nun wieder nicht korrekt. Am Pin messen kann man natürlich den > korrekten Pegel, aber nur dann, wenn das entsprechende Bit im > PORT-Register zuvor auf 1 gesetzt wurde und damit der Pin auf Ausgang. Das muss natürlich DDR-Register heißen...
an Phil: Bei mir läuft das; mangels eines ATmega8 auf einem ATmega16A (mutatis mutandis).
c-hater schrieb: > c-hater schrieb: > >> Das ist nun wieder nicht korrekt. Am Pin messen kann man natürlich den >> korrekten Pegel, aber nur dann, wenn das entsprechende Bit im >> PORT-Register zuvor auf 1 gesetzt wurde und damit der Pin auf Ausgang. > > Das muss natürlich DDR-Register heißen... Das passende Bit im DDR-Register setzt er ja im obigen Code. Ich sehe an dem Programm auch keinen Fehler. Eigentlich müsste am Ausgang PB1 das PWM-Signal ankommen.
Um die Sprachlosigkeit zu beenden: > (Fehler tritt immer noch auf) Wie sieht dieser Fehler denn aus, LED leuchtet falsch, Oszillogramm falsch, oder nur ein Artefakt im Debugger?
Beim debuggen in Atmel Studio wird bei Output Compare PINB bei PB1 true gesetzt (erwartet PORTB). Am uC lässt sich am uC eine konstante Spannung (etwa 200mV messen). Ich habe den Code um eine ISR erweitert, die Bei Output Compare PORTB explizit setzt. Am uC tut sich trotzdem nichts.
Zum Debugger kann ich nichts sagen, ich arbeite nicht damit. Wie gesagt, bei mir läuft das Programm 1:1, nur eben mit der einzigen Änderung, dass beim ATmega16 OC1A auf D5 liegt.
Ähm.. sind beim ATMega 8 und ATMega 16 nicht PB1 (T1) und PD5 (OC1A) vertauscht? wenn es also auf nem 16er läuft, kann es doch auf 8 nicht (weil falschrum) Ich mein da war mal was... erinner mich nur dunkel 'sid
Angehängte Dateien:
-
ATMega8-Pin-Diagram.png
47 KB -
ATMega16-Pin-Diagram.png
53 KB
ah guck... pin diagram gefunden oh war ich eh zu spät, was :D nadenn 'sid
> Spannung (etwa 200mV messen)
Direkt am Controller?
Kann denn B1 überhaupt Spannung ausgeben oder hängt da etwas dran, am
Ende gar eine Lötbrücke? Vorschlag:
- mal nur B1 direkt einschalten
- PWM auf OC1B (B2) versuchen
Phil schrieb: > Beim debuggen in Atmel Studio wird bei Output Compare PINB bei PB1 true > gesetzt (erwartet PORTB). Wie gesagt: falsch erwartet! Der Timer kontrolliert nicht das Bit im PORT-Register. Hat er nie getan, wird er niemals tun. > Am uC lässt sich am uC eine konstante Spannung (etwa 200mV messen). Also: Hardwareproblem. Ein (Fast-)Kurschluss nach Masse. Sehr wahrscheinlich: Whisker. Sprich: du solltest Löten (oder zumindest erstmal korrektes Gucken nach Löten) lernen...
c-hater schrieb: > ... Der Timer kontrolliert nicht das Bit im Englisch "control" ist etwas anderes als "Kontrolle"
miss schrieb: > c-hater schrieb: >> ... Der Timer kontrolliert nicht das Bit im > > Englisch "control" ist etwas anderes als "Kontrolle" OMG Ein deutschtümelnder Sprachnazi ist auch noch hier unterwegs. Also nehmen wir den auch gleich noch auseinander. Was du lesen wolltest, war vermutlich "steuern". So und nun darfst du erklären, wo der semantische Unterschied zwischen diesen beiden Verben ist. In der deutschen Sprache sind sie meiner Meinung nach nahezu synonym (wie in der englischen auch). Du darfst alle Heiligtümer der Sprachnazis ausgiebigst zitieren! Tu' dir keinerlei Zwang an!
c-hater schrieb: > miss schrieb: > >> c-hater schrieb: >>> ... Der Timer kontrolliert nicht das Bit im >> >> Englisch "control" ist etwas anderes als "Kontrolle" > > OMG > > Ein deutschtümelnder Sprachnazi ist auch noch hier unterwegs. > > Also nehmen wir den auch gleich noch auseinander. Was du lesen wolltest, > war vermutlich "steuern". > > So und nun darfst du erklären, wo der semantische Unterschied zwischen > diesen beiden Verben ist. In der deutschen Sprache sind sie meiner > Meinung nach nahezu synonym (wie in der englischen auch). > > Du darfst alle Heiligtümer der Sprachnazis ausgiebigst zitieren! Tu' dir > keinerlei Zwang an! Weder deutschtümelnd und auch kein Nazi. Nur jemand, der mit natürlichem Sprachverständnis den zitierten Satz zweimal lesen mußte um ihn richtig einzuordnen. Gar nicht geeignet um einem Anfänger die Funktion nahezubringen. Warum nur eine solch eine übertriebene Reaktion auf eine einfache Bemerkung?
Lucy hat es, wieder einmal, ihrem Bruder gegeben: "... weil du die Menschheit nicht liebst, darum"! Und schreitet hochzufrieden von dannen. Linus ist für einen Augenblick getroffen, dann schreit er ihr hinterher: "ICH LIEBE DIE MENSCHHEIT - ich kann nur die Leute nicht ausstehen"! Die Übersetzung auf die Verhältnisse hier überlasse ich dem geneigten Leser.
Beitrag #6270271 wurde von einem Moderator gelöscht.
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.