2 PINS an dem PORTC besitzen ein dauerhaftes High Signal

Ist JTAG aktiv?! Denn die Pins gehören zu dieser Schnittstelle.

Die Fuse dazu heißt JTAGEN.

Dann schau dir mal an, welche Fuses gesetzt sind bzw poste sie, wenn du 
dir nicht sicher bist.

Ansonsten steht der Rest im Datenblatt.

MichaelS schrieb:
> Wie meinst du das mit Fuses gesetzt??

"FUSE" (das englische Wort für "Sicherung") bezeichnet 
Konfigurationsbits der AVR Mikrocontroller. Mit diesen Bits kann man 
z.B. festlegen, mit welcher Taktquelle der AVR nach dem Reset losläuft, 
und ob bestimmte Programmierschnittstellen aktiv sein sollen oder nicht.

Beim ATmega32 ist die JTAG-Schnittstelle standardmäßig aktiviert (ja, 
per Fuse) und belegt dann die Pins PC2 und PC3. Du mußt sie 
deaktivieren, dann kannst du die Pins auch aus deinem Programm heraus 
verwenden.

Details findest du im Artikel AVR Fuses

es gibt keinen Code, das muss per ISP gemacht werden, womit 
programmierst du den µC denn (welche Software und welchen 
Programmieradapter?).
Dann können wir dir auch sagen wo du die Fuses ausliest und wieder 
setzen kannst.

Moin,

K. S. schrieb:
> es gibt keinen Code,

Das glaube ich nicht, Tim.


Probiers mal damit, irgendwann recht "frueh" im Programm (obacht, nicht 
dass in r28 schon irgendwas wichtiges steht...):

1

in r28, 0x34

2

ori r28,0x80

3

out 0x34,r28

4

out 0x34,r28; enable port C lines; disable JTAG

Also das MSB im MCUCSR Register setzen und zwar 2x direkt 
hintereinander, sollte JTAG abschalten.
Steht auch im Datenblatt bei der Beschreibung des MCUCSR Registers.

Gruss
WK

Dergute W. schrieb:
>

1

in r28, 0x34

2

> ori r28,0x80

3

> out 0x34,r28

4

> out 0x34,r28; enable port C lines; disable JTAG

oder eben

1

   uint8_t tmp = MCUCSR | (1<<JTD);

2

   MCUCSR = tmp;

3

   MCUCSR = tmp;

Die tmp Variable sorgt dafür, daß die Regel "2x in 4 Takten" eingehalten 
wird.

Carl D. schrieb:
> oder eben   uint8_t tmp = MCUCSR | (1<<JTD);
>    MCUCSR = tmp;
>    MCUCSR = tmp;
> Die tmp Variable sorgt dafür, daß die Regel "2x in 4 Takten" eingehalten
> wird.

Und der würde nicht einen der beiden Befehle wegoptimieren? Logisch ist 
es ja erstmal sinnlos (es sei denn er erkennt, dass es z.B. im Fall des 
MCUCSR Sinn macht).
Ich setze dann lieber
#pragma opt-
.
.
#pragma opt+
ein

c-hater schrieb:
> Nein, tut sie nicht, jedenfalls NICHT garantiert. Denn: keine einzige
> Stelle im C-Standard garantiert dies, es wird überhaupt niemals
> irgendein konkretes Timing garantiert.

Allerdings müsste ein Compiler schon sehr ungünstig implementiert sein, 
damit das nicht klappt. Ich würde hier aber tatsächlich auch ein in 
inline-Assembler implementiertes Makro schreiben.
Für den Fall von Timings, wo man wirklich einzelne Taktzyklen zählen 
muss, halte ich C auch nicht für geeignet.

H.Joachim S. schrieb:
> Carl D. schrieb:
>> oder eben   uint8_t tmp = MCUCSR | (1<<JTD);
>>    MCUCSR = tmp;
>>    MCUCSR = tmp;
>> Die tmp Variable sorgt dafür, daß die Regel "2x in 4 Takten" eingehalten
>> wird.
>
> Und der würde nicht einen der beiden Befehle wegoptimieren?

Nein, darf er nicht. Alle Zugriffe auf MCUCSR müssen durchgeführt 
werden, da MCUCSR volatile ist. Das ist garantiert.

> Logisch ist es ja erstmal sinnlos (es sei denn er erkennt, dass es z.B.
> im Fall des MCUCSR Sinn macht).

Wie gesagt: Wenn etwas volatile ist, dürfen Zugriffe darauf niemals 
wegoptimiert werden.

> Ich setze dann lieber
> #pragma opt-
> .
> .
> #pragma opt+
> ein

Das könnte auch nach hinten losgehen. Wenn dadurch noch zusätzliche 
eigentlich überflüssige, aber nicht wegoptimierte Instruktionen drin 
bleiben, die dir dann das Timing zerhauen.

Eigentlich wollt ich ja nur die Assemblerzeilen für den offenbar in C 
schreibenden TO aufbereiten. Aber auf die(/den) ganz speziellen 
Spezialisten kann man sich verlassen.

Stefanus F. schrieb:
> c-hater schrieb:
>> Aha, und wo genau kann man in der avr-gcc-Doku nachlesen, dass genau
>> diese Eigenschaft garantiert wird?
>
> Kann ich Dir nicht sagen, aber ich weiss wo das Datenblatt des ATmega328
> einen ähnlichen Fall beschreibt. Siehe Anhang.
>
> Wenn so etwas im Datenblatt steht, dann kann man sich darauf verlassen.

Das Datenblatt (Mega32, der Mega328 hat ja kein JTAG) beschreibt nur, 
welches Timing eingehalten werden muß.
Meine "Garantie" fußt eher auf dem volatilen Register (wie schon weiter 
oben von jemand bemerkt, sowie der Beobachtung über mehrere 
Compilergenerationen hinweg, daß das AVR-Compilerbackend des GCC kein 
Problem damit hat, eine Zuweisung auf ein Register mit Io-Adresse unter 
0x40 in das passender eine Assemblerstatement umzuwandeln. Deshalb auch 
eine doppelte Zuweisung und kein doppeltest verOdern.

c-hater schrieb:
> Nur merkbefreite C-only-Apologeten kommen auf so einen Unsinn.

Haty, ich wünsche dir ein Frohes Neues Jahr. Halt die Ohren und das, 
worauf es noch ankommt, steif und lass dich von den bösen 
C-Programmierern nicht unterkriegen. Du schaffst es. Ich zähl auf dich.


PS: Enttäusch mich nicht. Ich hab einen 5er gesetzt, daß du auch 2019 
keinen Herzinfarkt bekommst.