atmega644p - Welche Pins können als I/O benutzt werden?

ja also das JTAGEN ist auf 1 in der hfuse;
nur SPIEN ist auf 0; (Brauch ich das nicht eig. für das programmieren 
über ISP) da kenn ich mich jetzt leider zu wenig aus;
JTAGEN müsst ich ja einfach aus machen können oder?

ne ich seh grad dass da eine 1 beim JTAGEN für disabled steht.
:-(
also ist se schon aus gewesen. kann ich vl. noch ein paar andere sachen 
aus machen wie zb. OCDEN ?

OCDEN ist im Auslieferungszustand abgeschaltet.  Selbst, wenn es
aber eingeschaltet wäre: es benötigt zwingend JTAGEN, damit davon
die IO-Ports beeinflusst werden.

OCDEN disablen hilft leider auch nicht weiter.

p.s.: Ich denke, du hast irgendein Hardware-Problem.  Entweder eine
Zinnbrücke oder sowas, oder aber dein AVR ist kaputt.  Ich hatte
letztens auch einen ATmega88, dessen SDA-Leitung es geschafft hatte,
intern im AVR auf einen Widerstand von ca. 2 Ω zu kommen.  Alles
funktionierte noch, nur beim TWI blieb er beim Warten auf das Ende
der Startbedingung in der Software hängen. :-/

naja das was mich stutzig macht ist dass je nachdem was ich für PORTX 
Und DDRX`s mache, und dann vor dem eig. testprog. noch alle unbenutzen 
ports auf 1 schalte, ein mal der eine pin nicht geht, und ein mal der 
andere nicht.
Also schalten können beide. damit schließe ich ein hardware problem eig. 
aus?!
darf ich eig. auf PORTD ein komplettes byte schreiben, wenn da doch 3 
pins als eingang definiert worden sind?

E. B. schrieb:
> naja das was mich stutzig macht ist dass je nachdem was ich für PORTX
> Und DDRX`s mache, und dann vor dem eig. testprog. noch alle unbenutzen
> ports auf 1 schalte, ein mal der eine pin nicht geht, und ein mal der
> andere nicht.

Haben die beiden eine Brücke zwischeneinander?

> damit schließe ich ein hardware problem eig.
> aus?!

Vorzeitiger Schluss, bis zum Beweis des Gegenteils.

> darf ich eig. auf PORTD ein komplettes byte schreiben, wenn da doch 3
> pins als eingang definiert worden sind?

Wenn du dabei Bits setzt, die sich auf ein als Eingang geschaltetes
Pin beziehen, schaltest du dort die Pullups ein.

Aber du kannst natürlich immer nur ein komplettes Byte schreiben
(OK, von SBI/CBI abgesehen, aber die machen intern auch nur ein
read-modify-write, nur halt in zwei Takten).

Jörg Wunsch schrieb:
> E. B. schrieb:
>> naja das was mich stutzig macht ist dass je nachdem was ich für PORTX
>> Und DDRX`s mache, und dann vor dem eig. testprog. noch alle unbenutzen
>> ports auf 1 schalte, ein mal der eine pin nicht geht, und ein mal der
>> andere nicht.
>
> Haben die beiden eine Brücke zwischeneinander?
Ne. Da hat bei der realisierung jede säule ihren eigenen pin.

>> damit schließe ich ein hardware problem eig.
>> aus?!
>
> Vorzeitiger Schluss, bis zum Beweis des Gegenteils.
  Ich mess jetzt mal mit dem Oszi nach was der pin genau schaltet...
  vl. kann ich mit nem transistor die 5v schalten.
>> darf ich eig. auf PORTD ein komplettes byte schreiben, wenn da doch 3
>> pins als eingang definiert worden sind?
>
> Wenn du dabei Bits setzt, die sich auf ein als Eingang geschaltetes
> Pin beziehen, schaltest du dort die Pullups ein.
>
> Aber du kannst natürlich immer nur ein komplettes Byte schreiben
> (OK, von SBI/CBI abgesehen, aber die machen intern auch nur ein
> read-modify-write, nur halt in zwei Takten).

hm joa daran liegst wohl auch nicht.

Das oszi liefert kein brauchbares ergebnis; evlt. ein bedienfehler von 
mir oder der tastkopf ist kaputt :-( ich glaub ich kauf doch 
schieberegister
und oder nen coldfire...
bzw. nen neuen mega;
ist das normal dass so viele pins nicht gehen bei den atmels oder hab 
ich die echt schon alle geschossen.?

the problem has been solved!
war ein software fehler.
ich hatte natürlich bei der fk die die säulen ansteuert ein bit an der 
falschen stelle.
Danke für die Hilfe!