atmega324pb: Konflikt Timer2 und USART2?

Randy B. OP #5574511
Lesenswert?
• ▲
▼ 
Hallo zusammen,

mir ist gerade aufgefallen, dass es wohl einen Ressourcenkonflikt 
zwischen TC2 und USART2 beim Mega324PB gibt:

1
int main() {

2
    TCCR2A = 0xf3;

3
    TCCR2B = 0x03;

4
    OCR2A = 128;

5
    OCR2B = 128;

6
    DDRD |= _BV(6) | _BV(7);

7
    

8
    UCSR2B = 0x10; // oder 0x08

9


10
    while(true);

11
}


Wird der USART2 eingeschaltet (UCSR2B) stellt OC2A den Betrieb ein. Bei 
OC2B habe ich noch meine Impulse.

Was geht hier vor?

Danke für Hinweise!
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
c-hater Gast #5575128
Lesenswert?
• ▲
▼ 
Randy B. schrieb:

> mir ist gerade aufgefallen, dass es wohl einen Ressourcenkonflikt
> zwischen TC2 und USART2 beim Mega324PB gibt:

Nicht "gibt". Nur "kann geben".

> Wird der USART2 eingeschaltet (UCSR2B) stellt OC2A den Betrieb ein. Bei
> OC2B habe ich noch meine Impulse.
>
> Was geht hier vor?
>
> Danke für Hinweise!

Lies' einfach mal das verdammte Datenblatt. Da steht das doch alles 
drinne. Erste Instanz der Lektüre sind die Abschnitte 5. und 6. Und dann 
könnte man auch noch nachlesen, wie man USART2 korrekt initialisiert, 
wenn man keinen synchronen Modus haben will und damit XCK2 unbenutzt 
bleibt...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Randy B. OP #5575178
Lesenswert?
• ▲
▼ 
c-hater schrieb:

> Lies' einfach mal das verdammte Datenblatt. Da steht das doch alles
> drinne. Erste Instanz der Lektüre sind die Abschnitte 5. und 6. Und dann
> könnte man auch noch nachlesen, wie man USART2 korrekt initialisiert,
> wenn man keinen synchronen Modus haben will und damit XCK2 unbenutzt
> bleibt...

Dann erkläre mir doch mal, wo ich in dem obigen Beispiel den synchronen 
Mode eingeschaltet habe! Wenn Du möchtest, gebe ich Dir das asm-Listing, 
damit Du es besser verstehst.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
c-hater Gast #5575183
Lesenswert?
• ▲
▼ 
Randy B. schrieb:

> Dann erkläre mir doch mal, wo ich in dem obigen Beispiel den synchronen
> Mode eingeschaltet habe! Wenn Du möchtest, gebe ich Dir das asm-Listing,
> damit Du es besser verstehst.

Es genügt, wenn du für die Intialisierung symbolische Namen verwendest, 
dann versteht man das sofort, egal ob C oder Asm...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Randy B. OP #5575189
Lesenswert?
• ▲
▼ 
c-hater schrieb:
> Randy B. schrieb:
>
>> Dann erkläre mir doch mal, wo ich in dem obigen Beispiel den synchronen
>> Mode eingeschaltet habe! Wenn Du möchtest, gebe ich Dir das asm-Listing,
>> damit Du es besser verstehst.
>
> Es genügt, wenn du für die Intialisierung symbolische Namen verwendest,
> dann versteht man das sofort, egal ob C oder Asm...

Dann schau Du mal nach, in welchem SFR man denn den synchronen Mode 
aktivieren würde, bevor Du so herummoserst.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
c-hater Gast #5576086
Lesenswert?
• ▲
▼ 
Randy B. schrieb:

> Da dieses Verhalten bei TC1 und USART1 (auch ein Pin-Multiplex zwischen
> OC1B und XCK1) so nicht besteht, komme ich zu dem Schluss, dass es ein
> Bug im atmega324pb ist.

Das wäre durchaus denkbar.

Ich habe auch schon den einen oder anderen AVR8-Bug gefunden, der nicht 
im DB unter den Errata gelistet war. Allerdings noch nie einen derart 
gravierenden. Meistens nur Zeug im (sowieso eher lausig dokumentierten) 
Analogkram.

Aber ich würde an deiner Stelle die Hoffnung noch nicht völlig aufgeben. 
Es bleiben nämlich noch Freiheitsgrade. So z.B. ein Fehler im 
C-Compiler. Den hast du bisher nicht ausgeschlossen. Dazu musst du nur 
dasselbe Programm in Assembler schreiben. Die paar Zeilen werden ja wohl 
kein Problem sein, oder?

Auch möglich: ein Hardware-Bug, der zwar existiert, aber leicht zu 
umgehen ist. Sprich: was passiert eigentlich, wenn du UCSR2C und UCSR2D 
explizit mit den gewünschten Werten initialisierst (also mit denen, die 
sie nach Reset sowieso haben sollte), nachdem du UCSR2A und UCSR2B 
gesetzt hast?

Ach so: wie kommt dein Programm eigentlich auf das Device? Eventuell per 
Bootloader? Dann hast du eine Multiplikation möglicher Bugs des jeweils 
verwendeten C-Compilers und der des jeweils verwendeten Nutzcodes...

Mittels Programmierung in Asm kannst du ganz sicher eine ganze Klasse 
von Fehlern in beiden Störvektoren ausschliessen...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren