Atmega 644 Ports - Besonderheiten

[Tilmann W. (tilmann)]

Hallo,

nach langer Sucherei habe ich gefunden, das man JTAG deaktivieren muß, 
damit Port C funktioniert.

Gibt es noch andere solche Hinterhältigkeiten, die Ports A und D 
betreffend ?

Ich habe mir nämlich ein Lauflicht als Hardwaretest auf der STK500 
programmiert, und das geht nur an Port C.

Von den Ports A und D gibt kein Pin einen Mucks von sich, obwohl es 
genauso programmiert ist wie für Port C.

Gruß Tilmann

[Quarzbastler (Gast)]

Tilmann W. schrieb:
> obwohl es genauso programmiert ist wie für Port C.

Glaub ich nicht.

Zeig dein Programm.

[c-hater (Gast)]

Tilmann W. schrieb:

> nach langer Sucherei habe ich gefunden, das man JTAG deaktivieren muß,
> damit Port C funktioniert.

Nunja, man könnte auch einfach das DB lesen, bevor man anfängt zu 
programmieren...

> Gibt es noch andere solche Hinterhältigkeiten, die Ports A und D
> betreffend ?

Ja, es gibt auch für diese Ports etliche alternative Pin-Funktionen, die 
die normale Portfunktionalität "überschreiben" (also unwirksam machen) 
können.

Auch wenn du es kaum glauben magst: Das steht doch ebenfalls tatsächlich 
alles haarklein im DB...

> Von den Ports A und D gibt kein Pin einen Mucks von sich, obwohl es
> genauso programmiert ist wie für Port C.

Da hast du wohl mehr als einen Fehler in deinem Programm und/oder deinen 
Fuse-Settings. Weil: mit einem einzigen Fehler kann man unmöglich diesen 
Zustand erreichen...

Tja, irgendwie schon Scheiße, dass so ein µC immer nur genau das macht, 
was man ihm sagt und das nicht unbedingt identisch ist mit dem, was man 
eigentlich will...

[Quarzbastler (Gast)]

c-hater schrieb:
> Auch wenn du es kaum glauben magst: Das steht doch ebenfalls tatsächlich
> alles haarklein im DB...

Es könnte sein dass der TO sich fragen wird was DB bedeuted ....
(... und was "TO" bedeuted ....)

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

Tilmann W. schrieb:
> Von den Ports A und D gibt kein Pin einen Mucks von sich, obwohl es
> genauso programmiert ist wie für Port C.

Dann solltest du auch mal schauen, ob du AVCC auch brav an VCC 
angeschlossen hast. Ausserdem sind Abblockkondensatoren an allen 
(A)VCC/GND Pärchen Pflicht.

[Quarzbastler (Gast)]

Matthias S. schrieb:
> Dann solltest du auch mal schauen, ob du AVCC auch brav an VCC
> angeschlossen hast.

Tilmann W. schrieb:
> auf der STK500 programmiert

[Karl M. (Gast)]

Quarzbastler schrieb:
> Matthias S. schrieb:
>> Dann solltest du auch mal schauen, ob du AVCC auch brav an VCC
>> angeschlossen hast.
>
> Tilmann W. schrieb:
>> auf der STK500 programmiert

Sorry ich verstehe deine Zitate nicht !
Matthias S. fragt doch nur, ob sichergestellt ist, dass..

[Quarzbastler (Gast)]

Karl M. schrieb:
> Sorry ich verstehe deine Zitate nicht !
> Matthias S. fragt doch nur, ob sichergestellt ist, dass..

Wenn man auf einem STK500 arbeitet (das übrigens vom Hersteller
ATMEL stammt) dann ist das sichergestellt. Höchstens ein
AVCC Jumper könnte fehlen so es diesen überhaupt gibt.

Korinthenkacker könnten natürlich jetzt postulieren dass der
TO auf einem STK500 (nur) programmiert und den Prozessor dann
woanders einsteckt.

[Tilmann W. (tilmann)]

Hallo Quarzbastler,

> Glaub ich nicht.
>
> Zeig dein Programm.

danke, Du hast mir geholfen.

Ich hatte ein Programm mit lauter einzelnen Anweisungen. Weil es mir 
peinlich war, dieses hier zu präsentieren, habe ich es mit Schleife neu 
programmiert. Und siehe da: Alle drei Ports funktionieren, wie sie 
sollen.

Es war ein PC-Speicherort-Verzeichnis-Problem. Ich habe nicht das 
geflasht, was ich gerade kompiliert hatte. Mein Mißtrauen galt aber 
hinterhältigen Fuses, aus der Erfahrung mit Port C.

Danke !

Gruß Tilmann