Datenübertragung mit RS232 zum PC

wer

Neues Mitglied
02. Juli 2012
485
0
0
Sprachen
  1. Assembler
Für RS485 hat Markus ne Lichtsteuerung im Projektbereich gebaut. Er erklärt seine Projekte immer bis ins letzte Bit.Schau da mal rein.

Ich hab's gefunden. Auf dem Bild kann man leider nicht sehen, wie die Drähte verdrillt sind. Aber das verschiebe ich jetzt auch auf später. Ich muß aufpassen, daß ich nicht fünf Projekte auf einmal beginne.

Ich habe jetzt an einem STK500 und einem ATMega168 begonnen mit der Kommunikation mit dem PC über die vorhandene RS232-Schnittstelle. Assembler reizt mich am meisten, also benutze ich Assembler. Was ich gerne machen würde, ist ein RS232 Modul, daß ich auch in anderen AVR-Mikrokontrollern weiterhin einsetzen kann. Aber ich hab schon bemerkt, daß die Unterschiede da recht groß sind. Das werde ich aber sicher über bedingte Übersetzung in den Griff kriegen. Was mir noch nicht so recht klar ist, ist die Art, wie man Parameter an Funktionen übergibt. Es scheint nur sehr unkomfortabel möglich zu sein, Parameter über den Stack zu übergeben. Bleibt nur die Übergabe in Registern. Welche nimmt man da am besten?

Außerdem löte ich noch sehr verhalten an meinem Display rum. Ich hab ganz schön viel Sorge, daß ich was verheize. Ich denke, sobald ich damit fertig bin, werde ich ein paar Tipps brauchen, wie man so eine Schaltung auf Fehler prüft.
 
Ich habe jetzt eine serielle Verbindung von einem ATmega168 zum PC. Habe noch keinen externen Quarz. Mit 300 Baud geht es aber.
Bei der Programmiererei sind mir vorerst :) zwei Dinge unklar.

1.) Habe PORTB mit den LEDs verbunden. Die oberen beiden LEDs können jedoch nicht benutzt werden. Das hat evebtuell mit dem STK500 zu tun. Der ATmega168 ist dort mehrfach bestückt.
PB7: PCINT7, XTAL2, TOSC2
PB6: PCINT6, XTAL1, TOSC1
Was muß ich tun, um die oberen beiden Bits freizuschalten?

2.) An PORTD hängt die RS232 in den Bits
PD0: RXD
PD1: TXD
Ich benutze PD5 als Input (Taster). Jetzt ist mir nicht klar, welche Bits von PORTD auf Output und welche auf Input gesetzt werden müssen. Theoretisch sollte doch PD5 (Taster) und PD0 (RXD) auf Input gesetzt werden, PD1 (TXD) auf Output. Praktisch funktioniert aber alles, wenn man DDRD überhaupt nicht bearbeitet. Trotzdem bleibt ein ungutes Gefühl. Ich hab mal versucht DDRD zu lesen:

in temp1, DDRD
out PORTB, temp1

Alle LEDs leuchten (bis auf die oberen zwei, siehe Punkt 1). Das paßt also nicht zur Theorie. Kann mich da jemand aufklären?
 
Noch eine Frage zum STK500:

In der Dokumentation hat der STK500 Dialog 6 Tabs (Program, Fuses, LockBits, Advanced, Board und Auto). Ich habe 8 Tabs (Main, Program, Fuses, LockBits, Advanced, HW Settings, HW Info und Auto). Liegt das daran, daß ich ein Update gemacht habe? Wo finde ich eine aktuelle (Firmware 0x020a) Dokumentation?
 
Hallo,

Noch eine Frage zum STK500:

In der Dokumentation hat der STK500 Dialog 6 Tabs (Program, Fuses, LockBits, Advanced, Board und Auto). Ich habe 8 Tabs (Main, Program, Fuses, LockBits, Advanced, HW Settings, HW Info und Auto). Liegt das daran, daß ich ein Update gemacht habe? Wo finde ich eine aktuelle (Firmware 0x020a) Dokumentation?
Die Tabs kommen nicht von der Firmware des STK500 sondern von der Bedienoberfläche des AVR-Studios/Bascom/... was auch immer.

Gruß
Dino
 
1.) Habe PORTB mit den LEDs verbunden. Die oberen beiden LEDs können jedoch nicht benutzt werden. Das hat evebtuell mit dem STK500 zu tun. Der ATmega168 ist dort mehrfach bestückt.
PB7: PCINT7, XTAL2, TOSC2
PB6: PCINT6, XTAL1, TOSC1
Was muß ich tun, um die oberen beiden Bits freizuschalten?

2.) An PORTD hängt die RS232 in den Bits
PD0: RXD
PD1: TXD
Ich benutze PD5 als Input (Taster). Jetzt ist mir nicht klar, welche Bits von PORTD auf Output und welche auf Input gesetzt werden müssen. Theoretisch sollte doch PD5 (Taster) und PD0 (RXD) auf Input gesetzt werden, PD1 (TXD) auf Output. Praktisch funktioniert aber alles, wenn man DDRD überhaupt nicht bearbeitet. Trotzdem bleibt ein ungutes Gefühl. Ich hab mal versucht DDRD zu lesen:

in temp1, DDRD
out PORTB, temp1

Alle LEDs leuchten (bis auf die oberen zwei, siehe Punkt 1). Das paßt also nicht zur Theorie. Kann mich da jemand aufklären?

Ich weiß nicht, vielleicht habe ich mich nicht klar genug ausgedrückt. PORTB habe ich über ein 10-poliges Kabel mit den LEDs verbunden, bei PORTD ein 2-poliges von PD0/PD1 zur RS232, PD4/PD5 sowie die Stromversorgung zu den entsprechenden Pins bei Switches über zwei weitere 2-polige Kabel.
 
Ich weiß nicht, vielleicht habe ich mich nicht klar genug ausgedrückt. PORTB habe ich über ein 10-poliges Kabel mit den LEDs verbunden, bei PORTD ein 2-poliges von PD0/PD1 zur RS232, PD4/PD5 sowie die Stromversorgung zu den entsprechenden Pins bei Switches über zwei weitere 2-polige Kabel.

Ist die Frage zu blöd oder zu schwer oder nicht ausreichend klar formuliert?
 
Hallo,

Ist die Frage zu blöd oder zu schwer oder nicht ausreichend klar formuliert?
kann aber auch einfach daran liegen das die Leute etwas platt von der Arbeit kommen und abends grad die Luft fehlt sich noch mit etwas komplexer erscheinenden Sachen zu befassen :rolleyes: Einfach ein wenig Geduld :cool: Kommt schonmal vor das grad bei dem der es sich ansehen könnte zwei, drei Tage lang die Luft raus ist.

Gruß
Dino
 
Danke Dino, ich hatte gestern erstmal einen nicht fahrenden Bus->Zug nicht bekommen, der Zug eine Stunde später ist dann auf halber Strecke wegen eines "Oberleitungsschadens" liegengeblieben->40 min auf den Schienenersatzverkehr gewartet... Heimweg gestern: ca 5h (Hinweg waren knapp 3 - ich arbeite derzeit 6h...)
aber zum Thema:
-in meiner Doku wird der 168er vom STK500 nicht geführt, ich gehe davon aus, daß der aber wie der 88er in den "grünen" Sockel kommt. Dann liegen die Prozessorpins nicht auf dem entsprechenden Header - wie Du vermutet hast wegen der externen "Becklockung". Die Prozessorbeinchen sind an das entsprechende STK500-interne Takt-Netz angeschlossen (Achtung, hier bin ich mir nicht mehr sicher!) - dementsprechend solltest Du die beiden auch an PORTE/AUX abgreifen können, ABER dort liegt (wie gesagt) normalerweise das Takt-Netz drauf. Wenn Du also da ran willst, kannst Du das mit dem XTAL1 Jumper trennen. Siehe dazu Handbuch zum STK Abschnitt 3.4 bis 3.8
Die andere Frage ist mir nicht ganz klar...
zu den Tastern:
-nö, prinzipiell(!) mußt Du die Taster nicht auf Eingang schalten, Du kannst das PIN-Register jederzeit auslesen (und erhältst dann den entsprechenden logischen IST-Wert), ABER wenn Du den als Ausgang einstellst, legt der Controller je nacht PORT-Register Vcc oder Gnd auf das Beinchen (Spannungsabfall an den internen Treibern mal vernachlässigt). Wenn Du das Beinchen jetzt also über einen Taster (niederohmig!) auf ein anderes Potential zwingst, schließt Du die Spannung quasi über den Controller kurz, bzw es fließt zuviel(!) Strom durch den Controller (siehe el. Characteristics im Datenblatt). Ist das Beinchen Eingang, hängt das Beinchen (je nach PORT-Register) entweder komlplett in der Luft (tristate), oder wird über einen Widerstand im zweistelligen k-Ohmbereich auf Vcc gezogen.
Warum gehts jetzt aber auch, wenn man das vorher gar nicht festlegt? Gegenfrage: Hast Du Dir mal die initial values der entsprechenden PORT/DDR-Register der betreffenden Beinchen angesehen (Datenblatt des Controllers)?
zum UART:
Wenn ich mich recht erinner, wird der RxD mit dem RXEN0-Bit, der TxD mit dem TXEN0-Bit (je aus UCSR0B) aktiviert. Dabei wird das jeweilige Beinchen intern vom Port abgetrennt, und auf den UART geschaltet. Folglich haben Manipulationen von PORT- und DDR-Register (derzeit) keinen Effekt.
Dabei stellen sich (mir) folgende Fragen:
-liefert das Auslesen des Pin-Registers auf diesen Bits trotzdem korrekte Werte? Wenn nicht, welchen Wert dann?
-"verharren" Veränderungen in den PORT-/DDR-Registern dann dort, und werden automatisch bei Deaktivierung von RXD/TXD wirksam?
-hat das schreiben einer 1 in das entsprechende Pin-Register-Bit "den üblichen Effekt", ggf mit der Einschränkung auf den vorigen Punkt?
 
kann aber auch einfach daran liegen das die Leute etwas platt von der Arbeit kommen und abends grad die Luft fehlt sich noch mit etwas komplexer erscheinenden Sachen zu befassen :rolleyes: Einfach ein wenig Geduld :cool: Kommt schonmal vor das grad bei dem der es sich ansehen könnte zwei, drei Tage lang die Luft raus ist.

Sorry, ich war mir nicht so sicher, ob mein Problem nicht vielleicht einfach zu banal war.
 
-in meiner Doku wird der 168er vom STK500 nicht geführt, ich gehe davon aus, daß der aber wie der 88er in den "grünen" Sockel kommt. Dann liegen die Prozessorpins nicht auf dem entsprechenden Header - wie Du vermutet hast wegen der externen "Becklockung". Die Prozessorbeinchen sind an das entsprechende STK500-interne Takt-Netz angeschlossen (Achtung, hier bin ich mir nicht mehr sicher!) - dementsprechend solltest Du die beiden auch an PORTE/AUX abgreifen können, ABER dort liegt (wie gesagt) normalerweise das Takt-Netz drauf. Wenn Du also da ran willst, kannst Du das mit dem XTAL1 Jumper trennen. Siehe dazu Handbuch zum STK Abschnitt 3.4 bis 3.8

Das ganze Fuse/Quarz-Zeugs und die entsprechenden Jumper und Studio-Einstellungen habe ich jetzt schon ein paarmal gelesen und komme immer wieder zu anderen Resultaten. Ich schätze ich muß das nochmal machen mit einer Tasse Baldriantee.

-nö, prinzipiell(!) mußt Du die Taster nicht auf Eingang schalten, Du kannst das PIN-Register jederzeit auslesen (und erhältst dann den entsprechenden logischen IST-Wert), ABER wenn Du den als Ausgang einstellst, legt der Controller je nacht PORT-Register Vcc oder Gnd auf das Beinchen (Spannungsabfall an den internen Treibern mal vernachlässigt). Wenn Du das Beinchen jetzt also über einen Taster (niederohmig!) auf ein anderes Potential zwingst, schließt Du die Spannung quasi über den Controller kurz, bzw es fließt zuviel(!) Strom durch den Controller (siehe el. Characteristics im Datenblatt).

Das heißt zum Einen: Eingang ist Default, Ausgang muß über DDRx eingeschaltet werden.
Und zum Anderen: Wenn man ein Beinchen auf Ausgang schaltet, sollte man kein Eingabegerät daran anschließen, weil man sonst den Controller zerstören kann.

Ist das Beinchen Eingang, hängt das Beinchen (je nach PORT-Register) entweder komlplett in der Luft (tristate), oder wird über einen Widerstand im zweistelligen k-Ohmbereich auf Vcc gezogen.
Das verstehe ich nicht! Was bedeutet das im ersten Fall? Wie kann man da einen definierten Zustand erreichen?

Warum gehts jetzt aber auch, wenn man das vorher gar nicht festlegt? Gegenfrage: Hast Du Dir mal die initial values der entsprechenden PORT/DDR-Register der betreffenden Beinchen angesehen (Datenblatt des Controllers)?

Du hast recht, ich hätte besser suchen sollen: (S. 85) "TXD/PCINT17 – Port D, bit 1: TXD, Transmit Data (Data output pin for the USART). When the USART Transmitter is enabled, this pin is configured as an output regardless of the value of DDD1."

Und entsprechendes für Port D, bit 0.

Dabei stellen sich (mir) folgende Fragen:
-liefert das Auslesen des Pin-Registers auf diesen Bits trotzdem korrekte Werte? Wenn nicht, welchen Wert dann?
-"verharren" Veränderungen in den PORT-/DDR-Registern dann dort, und werden automatisch bei Deaktivierung von RXD/TXD wirksam?
-hat das schreiben einer 1 in das entsprechende Pin-Register-Bit "den üblichen Effekt", ggf mit der Einschränkung auf den vorigen Punkt?

Zum ersten Punkt hatte ich ja geschrieben, daß ein

Code:
in temp1, DDRD
out PORTB, temp1

alle LEDs auf Port B leuchten läßt. Das habe ich getan NACH der Initialisierung des USART.

Zum zweiten Punkt: Das traue ich mich im Moment nicht, dazu müßte ich erst mal Port D von meinem Taster, der RS232 und einem Temperatursensor trennen, an dem ich momentan arbeite.

Zum dritten Punkt: Meinst Du, ob das dann auch nachgeholt wird, sobald der USART wieder freigegeben wird?

Apropos, das heißt ja unter Umständen auch, daß es Sinn machen kann, den USART nach Gebrauch wieder zu deaktivieren?
 
Hallo,

Das ganze Fuse/Quarz-Zeugs und die entsprechenden Jumper und Studio-Einstellungen habe ich jetzt schon ein paarmal gelesen und komme immer wieder zu anderen Resultaten. Ich schätze ich muß das nochmal machen mit einer Tasse Baldriantee.
schau mal im FAQ-Bereich. Da ist der erste Beitrag ein Verzeichnis von interessanten Beiträgen. Unter anderem ist ein Beitrag dabei in dem die Fuses erklärt werden. Eventuell bringt das ja schon etwas mehr Licht.

-nö, prinzipiell(!) mußt Du die Taster nicht auf Eingang schalten, Du kannst das PIN-Register jederzeit auslesen (und erhältst dann den entsprechenden logischen IST-Wert), ABER wenn Du den als Ausgang einstellst, legt der Controller je nacht PORT-Register Vcc oder Gnd auf das Beinchen (Spannungsabfall an den internen Treibern mal vernachlässigt). Wenn Du das Beinchen jetzt also über einen Taster (niederohmig!) auf ein anderes Potential zwingst, schließt Du die Spannung quasi über den Controller kurz, bzw es fließt zuviel(!) Strom durch den Controller (siehe el. Characteristics im Datenblatt).
Das heißt zum Einen: Eingang ist Default, Ausgang muß über DDRx eingeschaltet werden.
Und zum Anderen: Wenn man ein Beinchen auf Ausgang schaltet, sollte man kein Eingabegerät daran anschließen, weil man sonst den Controller zerstören kann.
Genau. Das Prinzip der Eingangs/Ausgangs-Pins ist auch in dem ersten Beitrag bei den FAQs verzeichnet.

Ist das Beinchen Eingang, hängt das Beinchen (je nach PORT-Register) entweder komlplett in der Luft (tristate), oder wird über einen Widerstand im zweistelligen k-Ohmbereich auf Vcc gezogen.
Das verstehe ich nicht! Was bedeutet das im ersten Fall? Wie kann man da einen definierten Zustand erreichen?
Dafür ist der Beitrag sehr gut geeignet. Da du dort siehst was bei den Pins passiert wenn man bestimmte Register verändert.

Warum gehts jetzt aber auch, wenn man das vorher gar nicht festlegt? Gegenfrage: Hast Du Dir mal die initial values der entsprechenden PORT/DDR-Register der betreffenden Beinchen angesehen (Datenblatt des Controllers)?
Du hast recht, ich hätte besser suchen sollen: (S. 85) "TXD/PCINT17 – Port D, bit 1: TXD, Transmit Data (Data output pin for the USART). When the USART Transmitter is enabled, this pin is configured as an output regardless of the value of DDD1."

Und entsprechendes für Port D, bit 0.
Die genaue Anschaltung der Sonderfunktionen an den Pins findest du im Datenblatt. Dort sind die internen Beschaltungen der Pins sehr schön als Schaltzeichnungen zu sehen.

Wenn du an den Pins nichts einstellst dann sind die als Eingang hochohmig. Wenn du also den Finger dranhälst kannst du sie alleine durch den Körperwiderstand nach High oder Low bewegen.


Dabei stellen sich (mir) folgende Fragen:
-liefert das Auslesen des Pin-Registers auf diesen Bits trotzdem korrekte Werte? Wenn nicht, welchen Wert dann?
-"verharren" Veränderungen in den PORT-/DDR-Registern dann dort, und werden automatisch bei Deaktivierung von RXD/TXD wirksam?
-hat das schreiben einer 1 in das entsprechende Pin-Register-Bit "den üblichen Effekt", ggf mit der Einschränkung auf den vorigen Punkt?
Zum ersten Punkt hatte ich ja geschrieben, daß ein
Code:
in temp1, DDRD
out PORTB, temp1

alle LEDs auf Port B leuchten läßt. Das habe ich getan NACH der Initialisierung des USART.

Zum zweiten Punkt: Das traue ich mich im Moment nicht, dazu müßte ich erst mal Port D von meinem Taster, der RS232 und einem Temperatursensor trennen, an dem ich momentan arbeite.

Zum dritten Punkt: Meinst Du, ob das dann auch nachgeholt wird, sobald der USART wieder freigegeben wird?

Apropos, das heißt ja unter Umständen auch, daß es Sinn machen kann, den USART nach Gebrauch wieder zu deaktivieren
Die DDRx, PORTx und PINx Register sind grundsätzlich komplett unabhängig von den Sonderfunktionen. Über die Sonderfunktionen schaltet man ja in der Pinbeschaltung lediglich Gatter oder Multiplexer um. Die Portregister werden eigentlich nicht beeinträchtigt. Wenn man die Sonderfunktion abschaltet sollte also sofort die normale Registereinstellung greifen.

Normal: Atmel_General-IO.png / / / Sonderfunktion: Atmel_Alternate-IO.png

In den beiden Schaltplänen sind die IO-Beschaltungen des Atmels zu sehen. Links der normale IO-Pin und rechts mit Sonderfunktion. Im rechten Bild kann man die normale IO-Beschaltung wiederfinden und sieht das der Pin lediglich über Multiplexer auf die Sonderfunktion umgeschaltet wird oder die Pufferstufen entsprechend gesperrt/umgeschaltet werden. Wenn man also die Sonderfunktion abschaltet wird logischerweise sofort die normale Einstellung über die IO-Register wieder gültig.

Gruß
Dino
 
Mein zitierter erster Abschnitt bezog sich auf keine Fuses oder so, somdern auf die beiden fehlenden LEDs an PortB. Der Hintergrund ist folgender:
Eigentlich sollten von jedem Controllersockel alle entsprechenden Verbindungen von den Beinchen zu den entsprechenden Port-Headern gehen (dann würden die LEDs leuchten). Somit wären aber auch die jeweils identischen Beinchen aller Sockel miteinander verbunden (über den Port-Header), zB also auch PB6. Bei einem "großen" Mega existieren ja separate Beinchen für XTAL1/2 - die auch auf dem entsprechenden Header landen. Bei'm "grünen" Sockel ist das aber eine alternative Funktion von PB6/PB7. Wenn jetzt alsodiese beiden Pins auch auf dem PORTB-Header liegen würden, hätten die anderen Sockel auch identische Signale auf den XTAL1/2 und PB6/7-Beinchen.

Irgendwo hatte ich im Netz mal 'n kompletten Schaltplan vom STK500 gesehen - da erkennt man das dann auch.
(ich find den nur zum verrecken nicht mehr)
 
Hi,

Irgendwo hatte ich im Netz mal 'n kompletten Schaltplan vom STK500 gesehen - da erkennt man das dann auch.
(ich find den nur zum verrecken nicht mehr)
ich weiß wo ich den habe. Zuhause hab ich alle Pläne die ich irgendwo mal im Netz gefunden habe :cool: Auch die gesamten Erweiterungsboards.

Gruß
Dino
 
Mein zitierter erster Abschnitt bezog sich auf keine Fuses oder so, somdern auf die beiden fehlenden LEDs an PortB. Der Hintergrund ist folgender:
Eigentlich sollten von jedem Controllersockel alle entsprechenden Verbindungen von den Beinchen zu den entsprechenden Port-Headern gehen (dann würden die LEDs leuchten). Somit wären aber auch die jeweils identischen Beinchen aller Sockel miteinander verbunden (über den Port-Header), zB also auch PB6. Bei einem "großen" Mega existieren ja separate Beinchen für XTAL1/2 - die auch auf dem entsprechenden Header landen. Bei'm "grünen" Sockel ist das aber eine alternative Funktion von PB6/PB7. Wenn jetzt alsodiese beiden Pins auch auf dem PORTB-Header liegen würden, hätten die anderen Sockel auch identische Signale auf den XTAL1/2 und PB6/7-Beinchen.
Du hattest von dem XTAL1/2 Jumper gesprochen und der spielt zusammen mit dem benachbarten Quarz Jumper (weiß jetzt gerade nicht, wie der heißt) eine Rolle bei der Art, wie der Controller seinen Takt bekommt. Und das wiederum hat auch mit den Fuses zu tun. Solange ich das nicht komplett überschaue, bin ich da vorsichtig. Ich denke, ich hatte Dich da nicht falsch verstanden.
 
In den beiden Schaltplänen sind die IO-Beschaltungen des Atmels zu sehen. Links der normale IO-Pin und rechts mit Sonderfunktion. Im rechten Bild kann man die normale IO-Beschaltung wiederfinden und sieht das der Pin lediglich über Multiplexer auf die Sonderfunktion umgeschaltet wird oder die Pufferstufen entsprechend gesperrt/umgeschaltet werden. Wenn man also die Sonderfunktion abschaltet wird logischerweise sofort die normale Einstellung über die IO-Register wieder gültig.

Mit diesen Schaltplänen bin ich deutlich überfordert. Mag sein, daß dies durch die amerikanischen Symbole erschwert wird.
 
Erstmal zum ersten Bild:
ganz links ist quasi das Prozessorbeinchen, oben drann ein Widerstand, der über einen Transistor/FET mit Vcc verbunden werden kann. Der interne Pullup halt. Der "Schalter" wird (doppelt invertiert) über ein 3fach-Und-Gatter angesteuert. Dessen Eingänge wiederum sind
-das Pullup-Disable-Bit im MCU Control Register (PUD aus MCUCR), mit welchem alle Pullups disabled werden können. invertiert.
-das entsprechende Bit im Datenrichtungsregister (DDRxn), auch invertiert
-das entsprechende Bit im PORT-Register (PORTxn, nicht invertiert)
Das Beinchen wird also mit dem Pullup auf Vcc gezogen, genau dann wenn PUD=0, DDRxn=0, PORTxn=1
Unter dem And-Gatter ist ein ... ähm ... wie nennt man so ein Gatter eigentlich? Not-Not? 'n Treiber quasi, der den logischen Pegel des PORTxn auf das Beinchen legt, aber nur wenn er durch DDRxn aktiviert wird.
Damit hast Du die 4 Zustände, die Du auf ein Beinchen legen lassen kannst
Ganz unten gelangt der ist-Zustand des Beinchens über einen Schmitt-Trigger in das PINxn

Der lesende/schreibende Zugriff auf DDRxn erolgt mit WDx und RDx, beim PORTxn mit WRx und PRx.
Fürs lesen von PINxn gibts RPx, man erkennt hier aber, daß WPx nicht auf PINxn sondern auf PORTxn wirkt (und zwar toggelnd). Liest man ein PIN-Register, erhält man die logischen Pegel der entsprechenden Beinchen, beschreibt man es werden alle Beinchen invertiert, die eine 1 erhalten.

Was ist beim zweiten Bild im wesentlichen anders? E gibt einige Multiplexer zwischen den "Registern" und de Beinchen, die das Beinchen, statt mit den Registern auch mit anderen Signalen verbinden können. Die alternativen Funktionen eben. Diese Muxe sind aber (wie bereits gesagt) vom Bus aus gesehen "hinter" den Registern. man hat also vom Bus aus Zugriff auf die Register (auch wenn sich der Effekt sich wegen der Muxe nicht am Beinchen zeigt). Wenn die Muxe wieder auf die Register umgeschaltet werden, liegen diese auch wieder am Beinchen an.

Nochmal zu der XTAL-Sache:
Nein, mit den Fuses hatte das bei mir nichts zu tun. Die sind ja genau genommen Software. Deine Beiden LEDs lassen sich durch den Mega aber so aus Hardware-Gründen nicht anschliessen. Die Beinchen 9/10 des "grünen" Sockels sind nämlich nicht mit dem PORTB-Header verbunden (wie Du scheinbar dachtest (ich hab da auch mal stundenlang erfolglos debuggt)), sondern mit Beinchen 7/8 des PORTE/AUX-Headers. XTAL1/2 eben. Wenn 9/10 des grünen Sockels jetzt aber mit beiden Headern verbunden wäre, würde sich diese Verbindung auch auf alle Sockel auswirken, die separate XTAL-Pins haben (die wären ja dann mit ihren eigenen B6/B7 verbunden, klar.
Du kannst aber beim grünen Sockel auf PB6 und PB7 über den AUX-Header zugreifen. Dabei ist aber zu beachten, daß der XT1 Pin von PORTE/AUX=PB6 grüner Sockel=XTAL1-Pin der anderen Sockel über den XTAL1-Jumper mit einem (getakteten) Voltage Converter verbunden ist. Wenn Du die also für was anderes verwenden willst, sollte der XTAL1-Jumper offen sein. Der OSCSEL-Jumper ist eher ein Schalter, mit dem Du die Taktquelle auswählst, die das STK den Sockeln anbieten soll. Entweder einen Oscillator (der Durch die Quarz-Fassung festgelegt wird), oder über die Software der Master-MCU auf dem STK500. Im Prinzip könntest Du an Pin2 des OSCSEL-Jumpers auch irgendeine andere Clock legen (5V), oder halt auch direkt auf das XTAL1-Netz (dann VTG beachten, und ohne XTAL1-Jumper)
 
ganz links ist quasi das Prozessorbeinchen, oben drann ein Widerstand, der über einen Transistor/FET mit Vcc verbunden
werden kann. Der interne Pullup halt. Der "Schalter" wird (doppelt invertiert)

Das sind so Sachen, die bringen mich ins Schleudern. Warum doppelt invertiert? Da kann mans doch gleich bleiben lassen?

über ein 3fach-Und-Gatter angesteuert. Dessen Eingänge wiederum sind
-das Pullup-Disable-Bit im MCU Control Register (PUD aus MCUCR), mit welchem alle Pullups disabled werden können. invertiert.
-das entsprechende Bit im Datenrichtungsregister (DDRxn), auch invertiert
-das entsprechende Bit im PORT-Register (PORTxn, nicht invertiert)
Das Beinchen wird also mit dem Pullup auf Vcc gezogen, genau dann wenn PUD=0, DDRxn=0, PORTxn=1

Warum muß hier PORTxn auf 1 sein? Der Port ist ja dann auf Input (DDRxn=0). Wodurch wird PORTxn gesetzt? Oder muß man das als rohes PINxn sehen?

Unter dem And-Gatter ist ein ... ähm ... wie nennt man so ein Gatter eigentlich? Not-Not? 'n Treiber quasi, der den logischen Pegel des PORTxn auf das Beinchen legt, aber nur wenn er durch DDRxn aktiviert wird.

Wo hat denn dieses Gatter seine Ein- und wo seine Ausgänge? Und was macht es denn eigentlich?

Da ist noch so ein Teil, dessen Funktion mir nicht klar ist. Es sitzt links unten und sieht aus, wie zwei ineinander geschobene Dreiecke mit vier Anschlüssen.
Damit hast Du die 4 Zustände, die Du auf ein Beinchen legen lassen kannst
Ganz unten gelangt der ist-Zustand des Beinchens über einen Schmitt-Trigger in das PINxn

Der lesende/schreibende Zugriff auf DDRxn erolgt mit WDx und RDx, beim PORTxn mit WRx und PRx.
Fürs lesen von PINxn gibts RPx, man erkennt hier aber, daß WPx nicht auf PINxn sondern auf PORTxn wirkt (und zwar toggelnd). Liest man ein PIN-Register, erhält man die logischen Pegel der entsprechenden Beinchen, beschreibt man es werden alle Beinchen invertiert, die eine 1 erhalten.

Das heißt, die Aussage "The Port Input Pins I/O location is read only, ..." ist nicht ganz richtig? Werden nur die invertiert, die eine 1 enthalten, oder alle? In der Documentation heißt es: "However, writing a logic one to a bit in the PINx Register, will result in a toggle in the corresponding bit in the Data Register."

Was ist beim zweiten Bild im wesentlichen anders? E gibt einige Multiplexer zwischen den "Registern" und de Beinchen, die das Beinchen, statt mit den Registern auch mit anderen Signalen verbinden können. Die alternativen Funktionen eben. Diese Muxe sind aber (wie bereits gesagt) vom Bus aus gesehen "hinter" den Registern. man hat also vom Bus aus Zugriff auf die Register (auch wenn sich der Effekt sich wegen der Muxe nicht am Beinchen zeigt). Wenn die Muxe wieder auf die Register umgeschaltet werden, liegen diese auch wieder am Beinchen an.

Verstanden.

Nochmal zu der XTAL-Sache:
Nein, mit den Fuses hatte das bei mir nichts zu tun. Die sind ja genau genommen Software. Deine Beiden LEDs lassen sich durch den Mega aber so aus Hardware-Gründen nicht anschliessen. Die Beinchen 9/10 des "grünen" Sockels sind nämlich nicht mit dem PORTB-Header verbunden (wie Du scheinbar dachtest (ich hab da auch mal stundenlang erfolglos debuggt)), sondern mit Beinchen 7/8 des PORTE/AUX-Headers. XTAL1/2 eben. Wenn 9/10 des grünen Sockels jetzt aber mit beiden Headern verbunden wäre, würde sich diese Verbindung auch auf alle Sockel auswirken, die separate XTAL-Pins haben (die wären ja dann mit ihren eigenen B6/B7 verbunden, klar.
Du kannst aber beim grünen Sockel auf PB6 und PB7 über den AUX-Header zugreifen. Dabei ist aber zu beachten, daß der XT1 Pin von PORTE/AUX=PB6 grüner Sockel=XTAL1-Pin der anderen Sockel über den XTAL1-Jumper mit einem (getakteten) Voltage Converter verbunden ist.

Ok, ich habe in den Schaltplänen von dino gesehen, daß PB7/8 mit XTAL1/2 verbunden ist. Was ich beim besten Willen nicht finden kann, ist die Beschaltung von PORTE/AUX. Vielleicht verstehe ich dehalb bei Deinem letzten Satz nur Bahnhof.

Wenn Du die also für was anderes verwenden willst, sollte der XTAL1-Jumper offen sein.
Was meinst Du mit "für etwas anderes"? PORTB6/7? Dann widerspricht das aber "When the XTAL1 jumper is not mounted, an external clock source or crystal can be connected to the PORTE header."

Also mit diesem Zeug muß ich mich jetzt erst noch mal beschäftigen.

Hängen denn die Zugriffsmöglichkeiten auf PORTB6/7 nicht auch davon ab, ob der Controller mit eigenem internen Takt arbeitet oder nicht. In ersterem Fall ist XTAL1 frei, im zweiten Fall nicht. Wenn man also einen externen Quarz anschließt sollte ein Zugriff auf PORTB6/7 ja nicht mehr möglich sein.

Aber auch da steig ich immer noch nicht durch:
Da ist einmal die Variante, daß der Controller NICHT im STK500 steckt und mit einem Quarz beschaltet ist.
Dann gibt es die Variante im STK500 mit interner Versorgung (Quarzsockel oder MasterControler).
Und schließlich die Variante mit externem Takt im STK500 über PORTE.
Ich kann nicht überschauen, was das alles für die beiden hoherwertigen PORTB Pins bedeutet.

Noch etwas, was ich nicht sicher weiß, sondern nur vermute:
Bei mir ist der XTAL1 Jumper gesetzt und OSCSEL rechts (also auf 1,2). Demnach also eine Versorgung vom MasterControler. Die Fuses sitzen auf internem Takt, mit Vorteiler, so daß sich die Jumperpositionen nicht auswirken, oder?
 
Das sind so Sachen, die bringen mich ins Schleudern. Warum doppelt invertiert? Da kann mans doch gleich bleiben lassen?...
also ich interpretiere die kleinen Kreise an den Leitungen so. Der FET sperrt vielleicht nur bei 'nem high am Gate/Basis? Ist aber eigentlich nicht wichtig, entscheidend ist, daß das Und-Gatter festlegt, wann der Widerstand zum Pullup werden soll.
Warum muß hier PORTxn auf 1 sein? Der Port ist ja dann auf Input (DDRxn=0). Wodurch wird PORTxn gesetzt? Oder muß man das als rohes PINxn sehen?
reingefallen... PORTxn ist das n-te Bit des Registers PORTx. PORTx ist das Port Latch Register von Portx, und nicht zu verwechseln mit dem Data Direction Register von Portx (DDRx), klar. PORTx ist nicht (!) gleich Portx.
Wo hat denn dieses Gatter seine Ein- und wo seine Ausgänge? Und was macht es denn eigentlich?
Eingang ist der Ausgang des PORTxn D-Q-Latches.
Ausgang liegt auf dem Prozessorbeinchen. Es ist ein Treiber, der die Information des PORTxn in einen Pegel am Beinchen umsetzt. Achtung, der Ausgang des DDxn D-Q-Latches bedient den enable-Pin des Gatters.
Da ist noch so ein Teil, dessen Funktion mir nicht klar ist. Es sitzt links unten und sieht aus, wie zwei ineinander geschobene Dreiecke mit vier Anschlüssen.
Ist mir auch nicht ganz klar - deswegen bin ich auf Sleep auch nicht weiter eingegangen.
Das heißt, die Aussage "The Port Input Pins I/O location is read only, ..." ist nicht ganz richtig? Werden nur die , die eine 1 enthalten, oder alle? In der Documentation heißt es: "However, writing a logic one to a bit in the PINx Register, will result in a toggle in the corresponding bit in the Data Register."
Hast Die Antwort doch selbst druntergeschrieben...
Das PIN-Register ist read-only. Wenn Du versuchst, in eines der Bits eine eins zu schreiben (kopieren) (mit OUT, SBI, ST), wird diese nicht ins PIN-Register geschrieben (weils ja readonly ist), SONDERN stattdessen das korrespondierende Bit im ... genau genommen im entsprechenden PORT-Register muß da stehen ... getoggelt.
Ok, ich habe in den Schaltplänen von dino gesehen, daß PB7/8 mit XTAL1/2 verbunden ist. Was ich beim besten Willen nicht finden kann, ist die Beschaltung von PORTE/AUX.
PORTE/AUX ist "J704" in Sheet7 auf Seite 5 der pdf.
Und Du meinst sicher PB6/7
Was meinst Du mit "für etwas anderes"? PORTB6/7? Dann widerspricht das aber "When the XTAL1 jumper is not mounted, an external clock source or crystal can be connected to the PORTE header."
Der OSCSEL-Jumper verbindet entweder einen Oscillator, der mit einem Quarz festgelegt wird, oder einen softwaregenerierten Takt mit seinem Pin2. Dieser Pin kann über den XTAL1-Jumper mit dem XTAL1-Netz (also auch mit PB6 beim grünen Sockel) verbunden werden. Dann läßt sich der Prozessor mit einer externen Clock betakten (eben Software oder Hardware). Wenn der aber mit Seiner internen Clock läuft, und Du die Beinchen für irgendwas anderes (Taster, Leds, Whatever) benutzen willst, sind die ja im STK500 über den Sockel->XTAL1-Netz (inklusive PORTE-Header)->XTAL1-Jumper->OSCSEL-Jumper mit der Hardware/Software-Clock des STK500 verbunden, welche dann also ihren Takt an die LEDs/Taster/Whatever überträgt, klar?
Hängen denn die Zugriffsmöglichkeiten auf PORTB6/7 nicht auch davon ab, ob der Controller mit eigenem internen Takt arbeitet oder nicht. In ersterem Fall ist XTAL1 frei, im zweiten Fall nicht. Wenn man also einen externen Quarz anschließt sollte ein Zugriff auf PORTB6/7 ja nicht mehr möglich sein.
Achtung, Du wirfst den Controller und das STK durcheinander:
mit den Fusebiteinstellungen legst (hierbei) Du im Controller fest, ob PB6 und/oder PB7 normale I/O-Pins sein sollen, oder als Takteingang dienen sollen. Das hat aber keinen Einfluß auf die Verdrahtung des STK.
Da ist einmal die Variante, daß der Controller NICHT im STK500 steckt und mit einem Quarz beschaltet ist.
Dann gibt es die Variante im STK500 mit interner Versorgung (Quarzsockel oder MasterControler).
Und schließlich die Variante mit externem Takt im STK500 über PORTE.
Ich kann nicht überschauen, was das alles für die beiden hoherwertigen PORTB Pins bedeutet.
Nochmal, der Controller kann
-mittels internem RC-Oscillator betaktet werden, dann sind PB6 und PB7 freie I/Os
-mit unterschiedlichen Resonatoren/Quarzen Betaktet werden, dann werden die beiden Beinchen auf die Taktogik umgeschaltete (siehe oben "alternate functions")
-mit einer externen Clock (Quarzoszillator etc) betaktet werden, dafür wird nur PB6 verbraucht, PB7 bleibt I/O
Wie der Controller also mit den Impulsen an den Beinchen umgeht, hängt (in erster Linie) von den Fuses, und danach ggf vom Programm ab. Welche Signale/Impulse das STK auf die Beinchen legt, hängt von den Jumpern und der entsprechenden Einstellung um AVRStudio ab (Was der MasterController ausgeben soll, kann man da festlegen).
Bei mir ist der XTAL1 Jumper gesetzt und OSCSEL rechts (also auf 1,2). Demnach also eine Versorgung vom MasterControler. Die Fuses sitzen auf internem Takt, mit Vorteiler, so daß sich die Jumperpositionen nicht auswirken, oder?
Nein, Dein Controller läuft so mit dem internen Oscillator, der Takt, den der MasterC generiert wird über die beiden Jumper und den PORTE-Header an PB6 weitergeleitet. Wenn Du PB6 als Eingang verwendest, bekommst Du da das entsprechende Signal/die entsprechende Frequenz. Wie das/die zu interpretieren ist, ist Sache Deines Programmes - es hat nichts mehr mit der Taktlogik des Controllers zu tun. Wenn das aber ein Ausgang ist, könnte sogar ein Kurzschluß vorliegen - keine Ahnung, wie das abgesichert ist (wenn die Clock zB grad hi ist, und Du das Prozessorbeinchen auf Gnd schaltest)
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)