...Aber dort finden sich nur Kabelbäume und die Verbindung zu den Erweiterungsports. Die Verbindungen zwischen dem grünen Sockel und JP901(XTAL1), JP900 (OSCSEL) und den PORTB und PORTE Headern wird dort nicht aufgezeigt....
Doch, die Kabelbäume sind doch die Verbindung... und der PORTB-Header hat beim grünen Sockel eben keine Verbindung zu PB6/PB7
Der grüne Sockel ist U402 in Sheet 4. Pin9=PB6 liegt demnach auf dem XT1-Netz des STK500, Pin10=PB7 auf dem XT2-Netz. Verfolgst Du die Netze, erkennst Du unter anderem, daß sie auch U403 landen, außerdem "verlassen" sie das Sheet rechts mit den anderen Bussen, und dem !RST-Netz. Beide sollen sich auf Sheet 5 und 7 wiederfinden lassen, XT1 zusätzlich noch auf Sheet 9.
Auf Sheet 5 befinden sich nur weitere Sockel, die (wie eben auch die in Sheet 4) auch mit den XT1/2-Netzen verbunden sind, klar.
Genau in der Mitte von Sheet 7 findet man die Netze XT1/XT2 wieder, und kann sie (über den Bus) zu J701 (Pin17/18) verfolgen (das ist einer der Expand-Header, ich denke(!) mal Expand1), und eben auch zu J704 (Pin 7/8). Das ist der PORTE/AUX-Header.
Auf Sheet 9 findet sich in der unteren Hälfte links das Signal PCLK. Das ist der, vom MasterController generierte Takt, der letztendlich auf JP900 (OSCSEL-Jumper) ankommt. Darunter erkennt man eine Schaltung, die mit dem Quarz(sockel) XC900 einen Takt generiert, der auch auf dem JP900 landet. Dieser kann eine der beiden Taktquellen (über Schutzdioden/Schmitt-Trigger) auf JP901 (XTAL1-Jumper) weiterleiten, welcher sie wiederum auf das XT1-Netzlegen kann.
Wenn der Controller also per Fuses mit seinem internen Oscillator läuft (ja, das ist default), folglich die beiden Beinchen normale I/Os sind (default ist tristate), und Dein Programm jetzt irgendwas mit den Beinchen macht, liegt das Ergabnis eben auch auf dem Expand-Header, dem PORTE-Header, und bei PB6 auch auf Pin2 vom XTAL1-Jumper an. Wenn dieser geschlossen ist, das STK mit seiner Takt-Logik aber irgendwas anderes über den OSCSEL-Jumper dahin schickt, treffen sich hier eventuell wiedersprüchliche Signale.
Nochwas zu den anderen PortB-Beinchen. Diese landen in Sheet 4 auf dem PBT[7..0]-Bus (ohne PB6,PB7 !). Dieser läßt sich unter anderem auch (unten) auf Sheet 7 wiederfinden, wo er zum PORTB-Header (J705) läuft.
*************************************************************
So, nun räume ich mal mit den restlichen Sachen da oben auf...
...
Was meinst Du mit der groß bzw. klein geschriebenen Variante?...
Oft findet man irgendwo auch die Bezeichnung Port bzw Portx für die Schnittstelle, als (mehrere) Beinchen des Controllers. Diese sind nicht mit dem PORT-LATCH-Register (eben auch PORTx) zu verwechseln. Letztendlich hat zur Auflösung Deiner Verwirrung aber nur der Fakt gefehlt, daß der Ausgang des DDRxn-D-Q-Latches den Ausgangstreiber (vom PORT) des Beinchens sperren kann. Wie die 3 Signale auf den Pullup wirken war ja bereits klar, oder?
...Nein! Dann müßten meine LEDs, die an PB6/7 hängen ja im Takt des Mastercontrolers an und aus gehen. Sie sind aber aus...
Du hast aber an PB6/7 des Controllers (grüner Sockel) gar keine LEDs hängen, oder?
Wenn Du den LED-Header mit dem PortB-Header verbindest, liegt (siehe oben) PB6/PB7 des grünen Sockels ja nicht mit auf dem PortB-Header. deswegen sind die LEDs aus. Was Dein Programm mit den Beinchen tut, läßt sich am PortE-Header abgreifen, und der ist mit der STK-internen Takt-Geschichte verbunden... aber das hatte wir ja auch schon oben...
...Den Unterschied zwischen den letzten beiden Varianten verstehe ich nicht...
Schau dazu mal ins Datenblatt des Controllers (S.28 bis 34).
Der Controller kann über die beiden Beinchen XTAL1 und XTAL2 einen (externen) Quarz oder Resonator "treiben/zum schwingen bringen". Das ist ein aktiver Prozeß. Aus diesen Schwingungen wird dann der Takt abgeleitet. Hierfür werden beide Beinchen von der normalen I/O-Logik von PortB getrennt. Es gibt dabei unterschiedliche Modi (unterschiedliches Schwingverhalten, unterschiedliche Frequenzbereiche), die bei der Festlegung der Fuses (CKSEL und ggf daraus folgend auch die SUT) zu beachten sind.
Der Controller kann mit einem seiner internen Oszillatoren betrieben werden (8MHz(default, aber durch 8 geteilt -> effektiv also 1MHz) oder 128kHz), dann bleiben beide Beinchen I/Os.
Der Controller kann seinen Takt aus einer externen Clock an XTAL1 ableiten. dann ist PB6 von der I/O-Logik getrennt, PB7 nicht. Bei dieser Methode wird die Clock aber nicht "getrieben", die Flanken müssen "von sich aus" vorliegen, klar?
(und um Deine Mißverständnisse dazu zu beseitigen: Die Clock-Möglichkeiten des STK500 nutzen nur diesen Weg - Der Quarz in Sockel des STK wird durch das STK getrieben, am OSCSEL-Jumper liegt also schon eine "externe Clock" an (XTAL2 nutzt das STK also gar nicht). Dementsprechend wäre bei dieser Methode im Controller die Fuse für externe Clock zu setzen (CKSEL3..0 = 0000). Wenn man den Controller aber wirklich einen Quarz treiben lassen will, muß dieser (mit den entsprechenden Abblockkondensatoren) an die XTAL1/2-Netze (am PORTE-Header), dann sollte aber keine Verbindung zur Clockerzeugung des STK bestehen (XTAL1-Jumper)
Warum spielt das aber genau genommen keine Rolle? Weil die externe Clock "stärker" ist, als der Controller interne Quarz-Treiber. Wenn die Fuses also irgendeinen externen Quarz erwarten lassen (und den zu treiben versuchen), da aber eine externe Clock drauf liegt, übersteuert diese den eventuellen Quarz, und zwingt dem Controller ihren Takt auf. Auf diesem Wege kann man also zT "verfuste" Controller "reanimieren" (<- genau genommen sind die ja nicht tot oder so - sie warten nur auf den korrekten Takt)
, zusammengebraten. Teilweise unter abenteuerlichen Verrenkungen. Für mich ist immer noch eine offene Frage, wie man z.B. eine dreipolige Jumper-Stiftleiste GERADE einlötet, OHNE sich die Finger zu grillen. Bevor ich das Teil in Betrieb nehme möchte ich unbedingt irgendwelche Tests machen. Was könnte man den da so testen? Wie geht man da systematisch vor?
