Forum: Mikrocontroller und Digitale Elektronik Timer1 Probleme


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Phil (Gast)


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

von Ver Wirrter (Gast)


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

von Phil (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von leo (Gast)


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

von P.Loetmichel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der "Betreff" ist auch
> nicht sehr hilfreich

Es soll ja Menschen geben, die etwas anderes benutzen.

von Phil (Gast)


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

von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie sieht das Programm aus, auf zehn Zeilen reduziert?

von Phil (Gast)


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

von leo (Gast)


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

von c-hater (Gast)


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

von c-hater (Gast)


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

von S. Landolt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
an Phil:
Bei mir läuft das; mangels eines ATmega8 auf einem ATmega16A (mutatis 
mutandis).

von Rolf M. (rmagnus)


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

von S. Landolt (Gast)


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

von Phil (Gast)


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

von S. Landolt (Gast)


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

von sid (Gast)


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

von sid (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ah guck... pin diagram gefunden

oh war ich eh zu spät, was :D

nadenn

'sid

von S. Landolt (Gast)


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

von c-hater (Gast)


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

von miss (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> ... Der Timer kontrolliert nicht das Bit im

Englisch "control" ist etwas anderes als "Kontrolle"

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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!

von miss (Gast)


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

von S. Landolt (Gast)


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

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]
  • [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.