OC0A & OC0B gleichzeitig toggeln?

[Jannik (user_name123)]

Hallo,

ich möchte mit einem ATmega328 zwei komplementäre Rechtecksignale 
erzeugen (D=50%). Für ein einzelnes Signal ist der CTC modus mit toggel 
on compare match natürlich am einfachsten. Jetzt hab ich mir die Frage 
gestellt ob ich OC0A und OC0B mit dem selben T/C gleichzeitig toggeln 
kann. Aus dem Datenblatt entnehme ich auf den ersten Blick nichts was 
dagegen spricht. Wenn ich die Pins gegengleich initialisiere sollte ich 
so 2 komplementäre Signale haben. Geht das oder lässt sich pro T/C immer 
nur ein OC0x Pin toggeln?

LG

[Falk B. (falk)]

Jannik schrieb:
> ich möchte mit einem ATmega328 zwei komplementäre Rechtecksignale
> erzeugen (D=50%).

Dann tu das doch.

> Für ein einzelnes Signal ist der CTC modus mit toggel
> on compare match natürlich am einfachsten.

Das ist egal. CTC ist nur dahin anders, als daß man die Periodendauer 
feiner einstellen kann.

> Jetzt hab ich mir die Frage
> gestellt ob ich OC0A und OC0B mit dem selben T/C gleichzeitig toggeln
> kann.

Sicher. Warum nicht?

> Aus dem Datenblatt entnehme ich auf den ersten Blick nichts was
> dagegen spricht. Wenn ich die Pins gegengleich

Gegengleich? Eher invers, invertiert.

> initialisiere sollte ich
> so 2 komplementäre Signale haben. Geht das

Ja.

>oder lässt sich pro T/C immer
> nur ein OC0x Pin toggeln?

Nein.
Warum probierst du das nicht einfach aus? Das dauert keine 3 Minuten.

[Jannik (user_name123)]

Moin Falk,

danke für die Antwort. Habs jetzt mal ausprobiert allerdings bekomme ich 
zwei identische Signale statt ein invertiertes. Ich wollte das ja 
realisieren indem ich einen Ausgang initial high und den anderen low 
setze.
Kann es sein, dass dadurch: "If one or both of the COM0A1:0 bits are 
set, the OC0A output overrides the normal port functionality of the I/O 
pin it is connected to". - meine high/low Initialisierung verloren geht?

LG

[Volker B. (Firma: L-E-A) (vobs)]

Jannik schrieb:

> Habs jetzt mal ausprobiert allerdings bekomme ich
> zwei identische Signale statt ein invertiertes. Ich wollte das ja
> realisieren indem ich einen Ausgang initial high und den anderen low
> setze.

Guck' Dir nochmals den Abschnitt "19.7.3 Fast PWM Mode" im Datenblatt 
an,
ibs. Figure 19-6. Fast PWM Mode, Timing Diagram.

OCnx: (COMnx[1:0] = 0x2)
/OCnx: (COMnx[1:0] = 0x3)

Ich vermute, dass das nur im Fast PWM Mode funktioniert.

> Kann es sein, dass dadurch: "If one or both of the COM0A1:0 bits are
> set, the OC0A output overrides the normal port functionality of the I/O
> pin it is connected to". - meine high/low Initialisierung verloren geht?

Nein, das heißt nur, dass Du den jeweiligen Pin nicht mehr über DIR oder 
OUT steuern kannst.

Grüßle,
Volker

P.S.: Wie so oft in diesem Forum wäre es hilfreich wenn Du Deinen Code 
zeigen würdest, denn das mit dem Hellsehen klappt nur sehr 
eingeschränkt...

[Ingo L. (corrtexx)]

Jannik schrieb:
> Kann es sein, dass dadurch: "If one or both of the COM0A1:0 bits are
> set, the OC0A output overrides the normal port functionality of the I/O
> pin it is connected to". - meine high/low Initialisierung verloren geht?
Ja, dass ist so. Entweder nimmst du die Fast-PWM mit Top = 0xff oder mit 
Timer1 Top = ICR1 und dann Fast-PWM Mode, Duty je 50% und Abfahrt...

Die 8 Bit Timer der alten AVR sind da etwas zäh. Die neuen AVRs können 
einfach einen IO invertieren, damit wäre das kein Problem.

[Volker B. (Firma: L-E-A) (vobs)]

Ingo L. schrieb:
> und dann Fast-PWM Mode, Duty je 50% und Abfahrt...

Lt. Datenblatt Figure 19-7. Phase Correct PWM Mode, Timing Diagram kann 
auch im Phase Correct PWM Mode ein komplementäres Signal an OC0A und 
OC0B ausgegeben werden.

Grüßle,
Volker

[Ingo L. (corrtexx)]

Volker B. schrieb:
> Lt. Datenblatt Figure 19-7. Phase Correct PWM Mode, Timing Diagram kann
> auch im Phase Correct PWM Mode ein komplementäres Signal an OC0A und
> OC0B ausgegeben werden.
Ja, dass geht ebenfalls.

[Ingo L. (corrtexx)]

Jannik schrieb:
> Kann es sein, dass dadurch: "If one or both of the COM0A1:0 bits are
> set, the OC0A output overrides the normal port functionality of the I/O
> pin it is connected to". - meine high/low Initialisierung verloren geht?
Benutze einfach Force Output Compare, dann kannste einen der beiden 
Ausgänge umschalten, was du vermutlich auch vor hattest ;)

[S. L. (sldt)]

 sbi   DDRD,6
 sbi   DDRD,5
 puti  TCCR0A,(1<<COM0A0)+(1<<COM0B0)+(1<<WGM01)
 puti  OCR0A,123
 puti  TCCR0B,(1<<CS00)+(1<<FOC0B)  ; !

[Jannik (user_name123)]

Leider müssen die Signale 125kHz haben, da sind die PWM modi zu langsam.

Force output compare sehe ich mir mal an.

Ob die Initialisierung verloren geht da seid ihr euch offenbar uneinig 
:D

// 8-bit T/C0 -> toggle OCR0A & OCR0B for 125 kHz constant signal

DDRD |= (1<<DDD5)| (1<<DDD6);  // Pin 5 6 output

TCCR0A = 0;
TCCR0B = 0;

TCCR0A |= 1 << COM0A0;  // Toggle OC0A on compare match
TCCR0A |= 1 << COM0B0;  // Toggle OC0B on compare match
TCCR0A |= 1 << WGM01;   // CTC Mode

TCCR0B |= 1 << CS00;  // no prescaler

OCR0A = 63;  // count 32-1 times to generate 125kHz output, 250kHz toggle for 125kHz square wave
OCR0B = 63;  // count 32-1 times to generate 125kHz output, 250kHz toggle for 125kHz square wave

PORTD &=~(1 << PD5);  // set pin 5 low OC0B
PORTD |= (1<<PD6);    // set pin 6 high OC0A

[S. L. (sldt)]

an Jannik:

Es sollte kein Problem darstellen, das gezeigte Assemblerprogramm auf C 
umzusetzen.

[S. L. (sldt)]

Was für Hinweise, Volker B.?
  Ich folge den ursprünglichen Anforderungen von Jannik.

[Volker B. (Firma: L-E-A) (vobs)]

Jannik schrieb:

> Force output compare sehe ich mir mal an.

OMG!

> Ob die Initialisierung verloren geht da seid ihr euch offenbar uneinig

Welche Initialisierung denn? Die vom Port.OUT Register? Ja, die hat 
keine Bedeutung, wie von Dir weiter oben Zitiert.

> TCCR0A |= 1 << COM0A0;  // Toggle OC0A on compare match
> TCCR0A |= 1 << COM0B0;  // Toggle OC0B on compare match

OMG! Du willst OC0A setzen und OC0B löschen (und anders herum), also 
guck' Dir nochmals
Table 19-6. Compare Output Mode, non-PWM an:

COM0B1 COM0B0 Description
----------------------------------------------
0      0      Normal port operation, OC0B disconnected.
0      1      Toggle OC0B on Compare Match.
1      0      Clear OC0B on Compare Match.
1      1      Set OC0B on Compare Match.

Die Bilder Figure 19-6. und Figure 19-7. Phase Correct PWM Mode, Timing 
Diagram zeigen m.E. genau das Verhalten, das Du haben willst. Warum 
initialisierst Du dann  TCCR0A nicht genau so, wie dort beschrieben?



Grüßle,
Volker

[Volker B. (Firma: L-E-A) (vobs)]

S. L. schrieb:
> an Jannik:
>
> Es sollte kein Problem darstellen, das gezeigte Assemblerprogramm auf C
> umzusetzen.

...nur dass es auch nicht funktioniert...

> Was für Hinweise, Volker B.?

Die Hinweise auf das Datenblatt des mega328
Figure 19-7. Phase Correct PWM Mode, Timing Diagram
Figure 19-6. Fast PWM Mode, Timing Diagram

Grüßle,
Volker

[S. L. (sldt)]

> ...nur dass es auch nicht funktioniert...

?
Natürlich läuft das, ich sehe es doch vor mir.

[Jannik (user_name123)]

Volker B. schrieb:
> OMG! Du willst OC0A setzen und OC0B löschen (und anders herum), also
> guck' Dir nochmals
> Table 19-6. Compare Output Mode, non-PWM an:

Ich will beides setzen weil ich ja beide Pins toggeln will? (PWM modi 
sind keine Option!)

Der Force Output Compare Einzeiler

TCCR0B |= 1 << FOC0B;

 hat tatsächlich gereicht. Habe jetzt mein gewünschtes Ergebnis.

Um ne kurze Erklärung was der Force Output Compare macht wäre ich 
trotzdem dankbar. Aus dem kurzen Abschnitt im Datenblatt werde ich mit 
meinen begrenzten Kenntnissen nicht schlau.

[Jannik (user_name123)]

S. L. schrieb:
> Natürlich läuft das, ich sehe es doch vor mir.

Also auf meinem Osci siehts auch gut aus :D

[Ingo L. (corrtexx)]

Jannik schrieb:
> Um ne kurze Erklärung was der Force Output Compare macht wäre ich
> trotzdem dankbar. Aus dem kurzen Abschnitt im Datenblatt werde ich mit
> meinen begrenzten Kenntnissen nicht schlau.
Es erzwingt einen Compare-Match, was bei deiner Konfiguration ein 
Pin-Toggle an dem Pin erzwingt. Somit sind die Pins dann automatisch 
gegenphasig.

Volker B. schrieb:
> OMG!
Gleichfalls

Volker B. schrieb:
> Warum
> initialisierst Du dann  TCCR0A nicht genau so, wie dort beschrieben?
Weil dann die PWM-Frequenz nicht mehr fein genug eingestellt werden 
kann, dass hast du offensichtlich nicht bemerkt

[Volker B. (Firma: L-E-A) (vobs)]

Jannik schrieb:
> S. L. schrieb:
>> Natürlich läuft das, ich sehe es doch vor mir.
>
> Also auf meinem Osci siehts auch gut aus :D

OK, der Code von S.L. funktioniert auch. Nur darf da nichts 
dazwischenkommen, also kein Stop des Timers oder Interrupt bei der 
Initialisierung. Deshalb würde ich dem TO die Initialisierung gem. der 
mehrfach erwähnten Diagramme aus dem Handbuch empfehlen.

Grüßle,
Volker.

[Ingo L. (corrtexx)]

Volker B. schrieb:
> Nur darf da nichts
> dazwischenkommen, also kein Stop des Timers oder Interrupt bei der
> Initialisierung. Deshalb würde ich dem TO die Initialisierung gem. der
> mehrfach erwähnten Diagramme aus dem Handbuch empfehlen.

 // 8-bit T/C0 -> toggle OCR0A & OCR0B for 125 kHz constant signal
DDRD |= (1<<DDD5)| (1<<DDD6);  // Pin 5 6 output
TCCR0A = 0;
TCCR0B = 0;
TCCR0A |= 1 << COM0A0;  // Toggle OC0A on compare match
TCCR0A |= 1 << COM0B0;  // Toggle OC0B on compare match
TCCR0A |= 1 << WGM01;   // CTC Mode
TCCR0A |= (1<<FOC0A);
OCR0A = 63;  // count 32-1 times to generate 125kHz output, 250kHz 
//toggle for 125kHz square wave
OCR0B = 63;  // count 32-1 times to generate 125kHz output, 250kHz 
//toggle for 125kHz square wave
TCCR0B |= 1 << CS00;  // no prescaler

So sollte das ohne Probleme funktionieren.

Volker B. schrieb:
> Deshalb würde ich dem TO die Initialisierung gem. der
> mehrfach erwähnten Diagramme aus dem Handbuch empfehlen.
Gemäß Diagrammen lässt sich garnichts initialisieren

[S. L. (sldt)]

Volker B.:
> Nur darf da nichts dazwischenkommen ...

Ist das jetzt nicht etwas an den Haaren herbeigezogen, "Stop des 
Timers"? Und gegen die Unterbrechung während der Initialisierung lässt 
sich ja vorbeugen, indem man z.B., wie in meinem Programm, TCCR0A auf 
einen Schlag setzt; oder in cli...sei kapselt.

[Volker B. (Firma: L-E-A) (vobs)]

S. L. schrieb:
> Volker B.:
>> Nur darf da nichts dazwischenkommen ...
>
> Ist das jetzt nicht etwas an den Haaren herbeigezogen,

Weißt Du was der TO programmiert hat?

[Volker B. (Firma: L-E-A) (vobs)]

Ingo L. schrieb:

> Volker B. schrieb:
>> Deshalb würde ich dem TO die Initialisierung gem. der
>> mehrfach erwähnten Diagramme aus dem Handbuch empfehlen.
> Gemäß Diagrammen lässt sich garnichts initialisieren

OK, Punkt für Dich :-)

Also gem. der in Klammern hinter dem jeweiligen Timingdiagramm 
geschriebenen Hinweisen auf die Initialisierung der COMnx[1:0] 
Register-Bits.

Hoffe, das war jetzt präszise genug!

[S. L. (sldt)]

Jannik ist zufrieden - das war der Sinn der Übung.
  Guten Tag.

[Peter D. (peda)]

Jannik schrieb:
> Habs jetzt mal ausprobiert allerdings bekomme ich
> zwei identische Signale statt ein invertiertes. Ich wollte das ja
> realisieren indem ich einen Ausgang initial high und den anderen low
> setze.

Ne, im PWM-Mode ist das Ausgangsregister wirkungslos.
Du kannst aber einen PWM-Ausgang auf invertiert setzen, das geht in 
allen PWM-Modi.

[S. L. (sldt)]

Peter Dannegger schlug vor:
> Du kannst aber einen PWM-Ausgang auf invertiert setzen,
> das geht in allen PWM-Modi.

Gefordert sind aber zwei Ausgänge bei 125 kHz - wie geht das auf einem 
ATmega328 mit Timer0 - Beispielprogramm?

[Falk B. (falk)]

S. L. schrieb:
> Gefordert sind aber zwei Ausgänge bei 125 kHz - wie geht das auf einem
> ATmega328 mit Timer0 - Beispielprogramm?

Wurde schon mehrfach geschrieben. Wird nur immer wieder ignoriert.

Beitrag "Re: OC0A & OC0B gleichzeitig toggeln?"

Ja, dann kann man die Periodendauer NICHT feingranular einstellen, weil 
der CTC Mode den Kanal A blockiert. Das geht aber mit Timer1, der hat 
nicht nur 16 Bit sondern auch noch ICR, mit welchem man den CTC Modus 
auch nutzen kann und GLEICHZEITIG die beiden OCR1A und OCR1B Kanäle 
gegenphasig laufen lassen kann. RTFM.

[S. L. (sldt)]

> Wurde schon mehrfach geschrieben. Wird nur immer wieder ignoriert.

Ich kann rechnen wie ich will, ich erhalte für die 125 kHz einen 
Systemtakt von 32 MHz.

> geht aber mit Timer1

Das ist unbestritten; aber schon im Betreff steht Timer0.

[Falk B. (falk)]

S. L. schrieb:
>> Wurde schon mehrfach geschrieben. Wird nur immer wieder ignoriert.
>
> Ich kann rechnen wie ich will, ich erhalte für die 125 kHz einen
> Systemtakt von 32 MHz.

Stimmt, hab ich nicht beachtet.

>> geht aber mit Timer1
>
> Das ist unbestritten; aber schon im Betreff steht Timer0.

Dann sind das die Grenzen. Entweder geringere Ausgangsfrequenz oder nur 
ein Kanal.

[S. L. (sldt)]

... Oder eben die Lösung mit dem 'Force Output Compare' FOC0x.

[Falk B. (falk)]

S. L. schrieb:
> ... Oder eben die Lösung mit dem 'Force Output Compare' FOC0x.

???
Wie willst du das bei 125kHz in Software machen? Wenn man denn WIRKLICH 
zwei komplementäre Ausgänge braucht, kann man einen mittels externem 
Inverter machen. Fertig.

[S. L. (sldt)]

Beitrag "Re: OC0A & OC0B gleichzeitig toggeln?"

[S. L. (sldt)]

So ganz verstehe ich die Diskussion jetzt nicht: der Vorschlag kam von 
Ingo L.,er kam auch von mir, ich sah, dass es funktioniert, Jannik hat 
das bestätigt, bei ihm läuft es auch - ... ?

[C-hater (c-hater)]

S. L. schrieb:

> Beitrag "Re: OC0A & OC0B gleichzeitig toggeln?"

Hmmm...

Im Prinzip richtig, im Detail meiner Meinung nach aber wohl nicht ganz.

Kritikpunkte:

1) Das erzeugt nur ca. die Hälfte der gewünschten Frequenz von 125kHz 
(bei angenommenen 16MHz Systemtakt).

Matchfrequenz:
16.000.000 / (123 + 1) = 129.032,...

Da mit der gewählten Initialisierung jeder Match nur ein Toggeln des 
Ausgangs bewirkt, beträgt die Frequenz am Ausgang nur die Hälfte der 
Matchfrequenz. Also nur ca. 65kHz.

2) Die Flanken der beiden Signale sind um eine Periode des Systemtakts 
gegeneinander verschoben.

Die Signale toggeln beim Compare-Match (des jeweiligen Kanals!). D.h.: 
damit das Toggeln gleichzeitig erfolgt, müssen beide OCR0x-Register 
denselben Wert enthalten.

3) Während der Initialisierung gibt es eine kurze Periode, in denen die 
Signale schon aktiv, aber noch nicht invers zueinander sind. Je nachdem, 
was dran hängt, kann das u.U. tödlich sein.

Ich denke also, das müßte korrekterweise so lauten:

[asm]
.EQU F_OUT = 125000

 ldi R16, (FCLOCK + F_OUT / 2) / (2 * F_OUT) - 1  ; 63
 out OCR0A, R16
 out OCR0B, R16

 ldi R16,(1<<COM0A0) | (1<<COM0B0) | (1<<WGM01)
 out  TCCR0A,R16

 ldi R16, (1<<CS00) | (1<<FOC0B)
 out TCCR0B, R16

 sbi   DDRD, 6
 sbi   DDRD, 5
[/asm]

Damit ergibt sich dann sogar exakt die gewünschte Frequenz lt. Formel 
aus dem DB (s.S. 100, fast ganz oben):

  16.000.000
---------------- = 125.000
2  1  (1 + 63)

Und dadurch, dass der Match für beide Kanäle gleichzeitig erfolgt (und 
mittels FOC0B für Kanal B einmal "vorgetoggelt" ist), ist das Signal an 
OC0B tatsächlich das invertierte Signal von OC0A.

[C-hater (c-hater)]

C-hater schrieb:

Verdammt, Quoting für die Formel vergessen. Also die nochmal:

  16.000.000
---------------- = 125.000
2 * 1 * (1 + 63)

[Veit D. (devil-elec)]

Hallo,

den Timer sollte man immer zum Schluss starten. Dann spielt die 
Reihenfolge der Konfiguration keine Rolle und man hat keine negative 
Effekte.

[C-hater (c-hater)]

Veit D. schrieb:

> den Timer sollte man immer zum Schluss starten. Dann spielt die
> Reihenfolge der Konfiguration keine Rolle und man hat keine negative
> Effekte.

Nein, das ist leider falsch. Die Signale sind timerseitig aktiv ab dem 
Moment, in dem die COM-Bits geschrieben werden, nicht erst ab dem 
Moment, in dem der Timer gestartet wird.

Am einfachsten läßt sich das Problem umgehen, indem man erst zum Schluß 
die Pins als Ausgänge schaltet.

[S. L. (sldt)]

an C-hater:

Sie lesen den Thread auch nicht erstmal durch, bevor Sie schreiben, wie 
Falk Brunner oder Peter Dannegger?:
  Zum Zeitpunkt meines Programmes war die Forderung nach 125 kHz noch 
gar nicht bekannt, ich hatte den Wert 123 mehr oder weniger aus der Luft 
gegriffen, in Anlehnung an Janniks Benutzernamen 'user_name123'.

Für Ihre Punkte 2 und 3 bräuchte ich mehr Zeit (und Motivation) - 
vielleicht später.

[C-hater (c-hater)]

S. L. schrieb:

>   Zum Zeitpunkt meines Programmes war die Forderung nach 125 kHz noch
> gar nicht bekannt

Stimmt, diese Angabe kam erst im nächsten Posting nach deinem.

> Für Ihre Punkte 2 und 3 bräuchte ich mehr Zeit (und Motivation) -
> vielleicht später.

[S. L. (sldt)]

Ursprünglich hatte ich da 200 drinstehen, aber dann fand ich 123 netter.
  Nur nebenbei: den Wert kann ohnehin nur Jannik vorgeben, nur er weiß 
(bislang), wie hoch sein Systemtakt ist - allenfalls aus seinem Halbsatz 
"da sind die PWM modi zu langsam" könnten wir versuchen, Rückschlüsse zu 
ziehen; für einen genauen Wert reicht's trotzdem nicht.

[C-hater (c-hater)]

S. L. schrieb:
> Ursprünglich hatte ich da 200 drinstehen, aber dann fand ich 123 netter.
>   Nur nebenbei: den Wert kann ohnehin nur Jannik vorgeben, nur er weiß
> (bislang), wie hoch sein Systemtakt ist - allenfalls aus seinem Halbsatz
> "da sind die PWM modi zu langsam" könnten wir versuchen, Rückschlüsse zu
> ziehen; für einen genauen Wert reicht's trotzdem nicht.

Stimmt, deswegen habe ich beides in meinem Verbesserungsvorschlag auch 
variabel ausgelegt. Zur Perfektion fehlt allerdings noch eine Warnung, 
die "Unzulässigkeit" anzeigt.

Ausserdem war das simple Umkopieren der beiden sbi's zur 
Pinfreischaltung an's Ende der Initialisierung auch auch noch nicht das 
Wahre. Wenn man's wirklich richtig machen will, müßte das natürlich auch 
für beide Kanäle gleichzeitig erfolgen. Also etwa so:

[asm]
 in R16, DDRD
 ori R16, (1<<DDD6) | (1<<DDD5)
 out DDRD, R16
[/asm]

[Harald K. (kirnbichler)]

In der Zeit, in der hier herumdiskutiert wird, hätte man das Problem 
auch mit einem popeligen Inverter lösen können. Bei 125 kHz kann man den 
mit einem Transistor aufbauen, man kann aber auch einen 74xx04 oder eine 
Ein-Gatter-Variante davon verwenden.

Aber das wäre vermutlich alles viel zu einfach, oder ist, weil Hardware, 
vieeeeeeel zu kompliziert.

[C-hater (c-hater)]

Harald K. schrieb:

> Aber das wäre vermutlich alles viel zu einfach, oder ist, weil Hardware,
> vieeeeeeel zu kompliziert.

Warum zum Taufel sollte man zusätzliche Hardware verbauen, wenn die 
bereits existierende Hardware die Funktion durchaus bereitstellen kann? 
Insbesondere: allein durch ihre sachgerechte Nutzung, nicht durch 
irgendwelche wilden Hacks jenseits ihrer Specs?

Das ergibt doch keinen Sinn. Höchstens für Leute, die halt nicht in der 
Lage sind, die vorhandene Hardware sachgerecht zu benutzen...

[S. L. (sldt)]

So, also:
  Ihr Punkt 2 stimmt natürlich; und gestern hatte ich nachfolgend auch 
das Gefühl, dass da rein programmsymmetrisch etwas nicht stimmt. Aber 
bei dem hohen Compare-Wert sah ich den Versatz auf meinem 
(Analog-)Oszilloskop nicht.
  Zu Punkt 3: ich hatte mir bislang keine Gedanken darüber gemacht, wann 
das TCCR0A bezüglich der Ausgänge greift, war irgendwie naiv davon 
ausgegangen, dass das erst mit dem Aktivieren des Timers, also mit 
TCCR0B, erfolgt - danke für den Hinweis.

Und damit ich selbst auch noch etwas Sinnvolles beitrage, im Anhang für 
Jannik die C-Version (so ungefähr) Ihres Programmes (so gut ich's eben 
konnte).

an Harald K.:
> ... oder ist, weil Hardware, vieeeeeeel zu kompliziert.
Sie ist hier schlicht unnötig. Und wenn Ihnen die Diskussion zu 
langatmig sein sollte, brauchen Sie ja nicht mitzulesen.

[Harald K. (kirnbichler)]

Wenn man einen zusätzlichen I/O-Pin zum sinnlosen Verballern freihat, 
dann kann man das natürlich tun. Andere arbeiten ressourcensparend und 
versuchen nicht, teure I/Os für Banalitäten zu vergeuden.
Klar, für unbenutzte I/O-Pins bekommt man ebensowenig Geld zurück wie 
für leergelassenes Flash-ROM, aber das ist halt nicht immer der Fall.

Hier wäre es interessant zu wissen, wofür der Threadstarter das 
Komplementärsignal zu benötigen meint.

[S. L. (sldt)]

an Harald Kirnbichler:

Also was mich betrifft, so versuche ich grundsätzlich so weit wie 
möglich auf den Fragesteller einzugehen - und da steht nun mal im 
Betreff "OC0A & OC0B".
  Es ist nicht meine Intention, sein Projekt zu verbessern (was ich in 
meiner Unkenntnis für 'Verbesserung' halte). Ihnen aber steht es 
natürlich frei, mit Jannik darüber eine längere Diskussion zu beginnen.

[C-hater (c-hater)]

Harald K. schrieb:

> Wenn man einen zusätzlichen I/O-Pin zum sinnlosen Verballern freihat,
> dann kann man das natürlich tun.

Genau. Deswegen würde ich über einen zusätzlichen Inverter allenfalls 
dann nachdenken, wenn's mit den Pins knapp wird. Und auch dann 
vermutlich zuerst darüber, ob man nicht besser andere Pins funktional 
"sharen" könnte (ohne zusätzliche Hardware verbauen zu müssen).

Grundprinzip ist: Jede zusätzliche Hardware erhöht die Kosten und die 
Ausfallwahrscheinlichkeit.

[Harald K. (kirnbichler)]

S. L. schrieb:
> Also was mich betrifft, so versuche ich grundsätzlich ...

Das kannst Du gerne tun. Andere hören halt nicht gleich mit dem Denken 
auf, sondern überlegen, wie man das eigentliche Problem lösen kann. 
Denn wie die Erfahrung zeigt, die manch einer hier hat (auch ein 
"C-Hater" hat Erfahrung!), haben viele Fragesteller sich in einer 
Problemlösung verrannt und versuchen ein Problem zu lösen, das sich 
entweder mit minimalem Aufwand anders lösen ließe oder letztlich gar 
nicht besteht, weil an anderer Stelle ein Designfehler vorliegt.

Ein Beispiel dafür sind die verschiedenen Versuche eines einzelnen, das 
trivale Thema "Tastenabfrage" zu lösen ... dem einen oder anderen mögen 
die diversen Threads zum Thema noch in Erinnerung sein, ist noch gar 
nicht so lange her.

Ob das hier der Fall ist, weiß ich natürlich nicht, aber meiner 
Ansicht nach ist jemandem besser geholfen, wenn ihm nicht nur wortgetreu 
seine Aufgabe gelöst wird, sondern auch Lösungsalternativen vorgestellt 
werden und sogar Rückfragen gestellt werden, wozu das ganze überhaupt 
gut sein soll.

[Falk B. (falk)]

C-hater schrieb:
> Grundprinzip ist: Jede zusätzliche Hardware erhöht die Kosten und die
> Ausfallwahrscheinlichkeit.

In der Theorie und der Massenproduktion. In der Praxis des Bastlers und 
der Kleinstserien ist das bedeutungslos.

"Ich bin dafür, die Dinge so weit wie möglich zu vereinfachen. Aber 
nicht weiter."

Albert Einstein

[C-hater (c-hater)]

Falk B. schrieb:

> C-hater schrieb:
>> Grundprinzip ist: Jede zusätzliche Hardware erhöht die Kosten und die
>> Ausfallwahrscheinlichkeit.
>
> In der Theorie

Nein, auch in der Praxis.

> und der Massenproduktion.

Nö, da wird es halt nur statistisch unwiderlegbar nachweisbar.

Diese Erkenntnisse aus der Massenproduktion für Einzelstücke zu 
ignorieren, ist trotzdem nur genau eins: ziemlich idiotisch...

Denn das Gesetz gilt natürlich auch für das Einzelstück. Es ist halt nur 
nicht nachweisbar, dass es dafür genauso gilt. Es gibt allerdings auch 
keinerlei logischen Grund, warum es dafür nicht genauso gelten sollte...

[Peter D. (peda)]

Es gibt auch AVRs, die haben extra invertierte Ausgänge, z.B. ATtiny85, 
ATtiny861. Und zusätzlich einen Dead-Time Generator.
Der ATtiny861 hat sogar 3 OC1x /OC1x Paare (x = A, B, D).

[Maxim B. (max182)]

Harald K. schrieb:
> Wenn man einen zusätzlichen I/O-Pin zum sinnlosen Verballern freihat,
> dann kann man das natürlich tun.

Wenn eine Platine schon fertig ist, wird es schwieriger, einen 74HC... 
zu schalten, als das Programm etwas zu ändern.
Wenn ein I/O-Pin unbenutzt bleibt, gibt man 1/28 des Preises von 
ATMega328 leider nicht zurück :)

Ansonsten plädiere ich als Amateur, der keine Serienfertigung macht, 
dafür, MK mit mehr Pins als ATMega328 zu wählen. Ich selbst nehme so gut 
wie immer ATMega1284 oder ab und zu ATMega2560. Die Beschränkung auf 2 
MK bringt für Amateur mehrere Vorteile.

[Georg M. (g_m)]

Peter D. schrieb:
> Es gibt auch AVRs, die haben extra invertierte Ausgänge
> Und zusätzlich einen Dead-Time Generator

Timer/Counter Type D (TCD)
Generating Complementary Driving Signals

https://ww1.microchip.com/downloads/en/Appnotes/TB3212-Getting-Started-with-TCD-DS90003212.pdf

[Jannik (user_name123)]

Moin zusammen,

ich melde mich auch mal wieder. Ich habe nach den ersten Hinweisen 
erstmal weiter programmiert und stand jetzt vor dem Problem, dass der 
FOC0B teilweise aufgibt und wieder das nicht invertierte Signal an PD5 
geliefert wird. (So wie Volker B. das denke ich vorhergesehen hat)

Das wäre tatsächlich fatal, da ich mal eine Phase-Shifted-PWM 
Ansteuerung einer Vollbrücke ausprobieren wollte (mit den Optionen die 
ich hier habe=>Arduino Nano) und naja wenn beide Mosfets einer 
Halbbrücke durchschalten gibt's ja bekanntlich nen Kurzschluss.

Wie die Vollbrücke schon vermuten lässt habe ich auch T/C2 genau gleich 
programmiert. Also insgesamt 4 125kHz Signale. FOC2B funktioniert 
einwandfrei. OCR2A & OCR2B werden nach dem setup nicht mehr geändert.

Das Problem von FOC0B kommt denke ich daher, dass ich OCR0A & OCR0B in 
der main des öfteren um 1 erhöhe bzw verringere und in einer Compare 
Match ISR wieder auf den Ursprungs Wert zurücksetze um die 
Phasenverschiebung zu Erzeugen.

Eine andere Möglichkeit könnte am ADC liegen, da die Ausgangsspannung am 
Ende über den Phase-shift geregelt werden soll.

Kann das daran liegen oder hat jemand eine andere Vermutung?
Eigentlich denke ich mir, dass FOC0B den Pin einmal anfangs toggelt und 
das später keinen Einfluss mehr haben sollte

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Wenns noch um den Mega328 geht, mein FU Projekt hat das vor Jahren schon 
mit 3 Timern gemacht. Jeder Timer hat komplementäre Ausgänge und alle 3 
laufen synchron:
https://www.mikrocontroller.net/articles/3-Phasen_Frequenzumrichter_mit_AVR

[S. L. (sldt)]

> OCR0A & OCR0B in der main des öfteren um 1 erhöhe bzw verringere

Es muss natürlich sichergestellt sein, dass dies nicht unmittelbar vor 
Erreichen des Compare-Match geschieht - wie sieht die Stelle in der 
Main-Schleife denn aus?

[C-hater (c-hater)]

Jannik schrieb:

> Das Problem von FOC0B kommt denke ich daher, dass ich OCR0A & OCR0B in
> der main des öfteren um 1 erhöhe bzw verringere und in einer Compare
> Match ISR wieder auf den Ursprungs Wert zurücksetze um die
> Phasenverschiebung zu Erzeugen.

Ja, das ist natürlich tödlich. Zumal es völlig unmöglich ist, beide 
Register wirklich gleichzeitig zu schreiben.

Da kann man nicht einfach wild drauflosschreiben, man muss 
sicherstellen, dass beide Schreibvorgänge abgeschlossen sind, bevor der 
nächste Compare-Match passiert. Am einfachsten geht das, wenn man 
ausschließlich in der ISR in diese Register schreibt, denn dann ist 
relativ sicher, dass der Match eben gerade passiert ist, bis zum 
nächsten also das Maximum an "Luft" bleibt.

Um dasselbe in Main zu erreichen, ist sehr viel mehr Aufwand nötig.

[Jannik (user_name123)]

S. L. schrieb:
> wie sieht die Stelle in der
> Main-Schleife denn aus?

// ISR to reset OCR0A/B after the compare match value was reached
// -> to keep 125kHz frequency
ISR(TIMER0_COMPA_vect) {
  uint8_t ui8_sreg = SREG;
  OCR0A = OCR0B = 63;
  SREG = ui8_sreg;
}

// ISR to count up
ISR(TIMER1_COMPA_vect) {
    uint8_t ui8_sreg = SREG;
    ui32_counter++;
    SREG = ui8_sreg;
}

void loop() {

// Synchronize the signals of the two timer/counters
if(syncSig == true) {
  TCNT0 = 0;
  TCNT2 = 0;
  OCR0A = OCR0B = 129;  // 129 for 0° phase shift  // 65 = 0°
  syncSig = false;
  startUp = true;
}

// PWM hart programmiert langsam hochfahren
// 1 count = 3° & 62,5ns delay / 8 counts = 23° & 500ns delay
if(startUp == true) {
 if(ui32_counter >= 360) {  // wait for 2s increase phase shift 180*2 180 counts = 1s
    OCR0A = OCR0B = OCR0A + 1;
    ui8_end++;            // count the number of shifts
    ui32_counter = 0;     // reset counter
  }

  if(ui8_end >= 8) {      // after 8 shifts (500ns) end the startup
    startUp = false;      // end start up
    voltReg = true;       // enter regulation via ADC
    ui32_counter = 0;     // reset counter
    ui8_end = 0;          // reset shift counter
  } 
}

// set PWM by ADC voltage
 if((voltReg == true)) {           

  if(ui32_counter >= 180) {
    ADCSRA |= (1<<ADSC);              //start conversion
    while(ADCSRA&(1<<ADSC));          // wait till conversion is finished
    ui16_adcVal = ADCL | (ADCH << 8); // save adc value
    Serial.println(ui16_adcVal);

    if(ui16_adcVal > ui16_adcTop) {   // if voltage is greater than treshold reduce signal shift

      OCR0A = OCR0B = OCR0A - 1;      // set both in one line
    }

    if(ui16_adcVal < ui16_adcBottom) {  // if voltage is smaller than treshold increase signal shift
      
      OCR0A = OCR0B = OCR0A + 1;
    }

    ui32_counter = 0;
    ui8_end = 0;
   }
 }

[S. L. (sldt)]

(Was das Programm genau macht, muss und will ich jetzt nicht verstehen)

Wie bereits geschrieben, und von C-hater näher erläutert, muss 
gewährleistet sein, dass TCNT0 beim Schreiben von OCR0A hinreichend 
unter dem alten wie dem neuen Wert von OCR0A liegt. Was bei den 
verfügbaren 64 Takten (oder noch weniger im Verlauf?) Sorgfalt verlangt.
  Übrigens: Retten von SREG in der ISR - ich dachte, solchen Kleinkram 
nimmt C dem Programmierer ab?

[Veit D. (devil-elec)]

Jannik schrieb:

> [c]
>
> ISR(TIMER0_COMPA_vect) {
>   uint8_t ui8_sreg = SREG;
>   ...
>   ...
>   SREG = ui8_sreg;
> }

S. L. schrieb:

> Übrigens: Retten von SREG in der ISR - ich dachte, solchen Kleinkram
> nimmt C dem Programmierer ab?

Hallo,

nimmt es auch. Innerhalb einer ISR ist sowas nicht notwendig.

[S. L. (sldt)]

Also, um genau zu sein: die 64 bezog sich auf die Gesamtzeit; wenn das 
Schreiben von OCR0A im Main erfolgen soll/muss, dann ist/sind die ISR 
noch abzuziehen - das könnte eng werden.