Marc V. schrieb:> Randy B. schrieb:>> Was geht hier vor?>> Nix, muss so sein.>> PB.3 ist sowohl TxD1 als auch OC2A.>> P.S.> Bild anbei.
Es geht um den atmega324pb nicht um 328pb!
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...
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.
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...
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.
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.
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...
Das asm-Listing hatte ich Dir auch schon angeboten: wolltest Du nicht
haben. Ich habe es aber kontrolliert und es entspricht dem DB. Auch
alles andere Vorgschlagene habe ich schon durch. Sonst hätte ich kein
Ticket bei MicroChip aufgemacht.