Hallo Forengemeine,
kämpfe etwas mit meinem Programm. Es geht mir der PC7 nicht auf High,
trotz gesetzten Pullup. Setze ich in den Fuses das Häckelchen bei JTAG,
dann geht hier zumindst der Pin auf High.
Entferne ich ich das Häckelchen, um die JTAG-Schnittstelle zu
deaktivieren, geht der PC5 wieder auf Lo (0).
Setze ich nun den Pullup, geht krzfristig der Pin auf High, dann aber
ist er Lo. Es ist nur das Messgerät auf dem Pin.
Was ist falsch? oder habe ich den Pin geschossen?
Mein Code-Schnippsel:
1
voidinitial(void)
2
{
3
// **** Einrichten von Ein- und Ausgängen ***************
Zumindest in dem Programmschnipsel wird an Port C überhaupt kein Pullup
gesetzt.
Und wenn du PC7 als Ausgang konfigurierst, wie im Programm gemacht,
hilft ein Pullup auch nicht mehr.
Matthias S. schrieb:> Zumindest in dem Programmschnipsel wird an Port C überhaupt kein Pullup> gesetzt.
Wieso?
PORTC |= (1<<PC5); // Pull Up an Pin27 - Chip Request aktivieren
Matthias S. schrieb:> Und wenn du PC7 als Ausgang konfigurierst, wie im Programm gemacht,
Naja weil PC7 ein Ausgang ist, aber PC5 ein Eingang sein soll. Das
müsste doch das Direction-Register machen, wie oben gesetzt.
Was mach ich falsch. Alles andere funktioniert soweit ja schon. Und der
ganze Code ist auch bereits entsprechend komplex.
Da war von mir in der Tat ein Fehler drin. PB7 muss Eingang sein, und
Pullup aktiviert.
Ändert aber noch nichts am PC5 Problem - Kein High
Oh - Habe mich oben verschrieben PC5 war gemeint.
Thomas S. schrieb:> Ändert aber noch nichts am PC5 Problem - Kein High
Vermutlich gibt es noch mehr Code, der irgendwie auf PC5 zugreift. Oder
der Pin wird von außen auf Low gezogen. Oder es wurden nicht alle
VCC/GND Pins angeschlossen.
Und was, bitte, ist nun dies:
> PB7 muss Eingang sein
Also erstmal dieses initial grundlegend überdenken, dann bearbeiten
und hier nochmals vorstellen - dann sehen wir weiter.
Thomas S. schrieb:> PORTB |= (1<<PB0); // Pull Up an Pin0 - aktivieren
Warum schreibst du das setzen der DDR-Bits nicht im selben
Stil? Das wäre auffällig und deutlich weniger fehleranfällig.
Stefan Frings meinte:
> Vermutlich gibt es noch mehr Code, der irgendwie auf PC5 zugreift.
Das passt zu
> Setze ich nun den Pullup, geht krzfristig der Pin auf High ...
Aber solange nicht einmal eindeutig klar ist, um welchen Pin es geht,
ist das hier vergeudete Zeit.
Wenn JTAG aktiviert ist, sind die Pins PC2...PC5 beim Mega 32 auf Pullup
und können nicht als I/O-Pins genutzt werden. Da bin ich auch schon mal
beinahe verzweifelt.
Seite 220 im Datenblatt hat mich dann aufgeklärt.
Der andere Thomas S. ;-)
S. L. schrieb:> Aber solange nicht einmal eindeutig klar ist, um welchen Pin es geht,
Ja sorry, habe mich im Eingangspost verschrieben. Es geht um PC5 (Pin
27)
Derzeit hängt am PC5 (Pin 27) nur das Messgerät. Es kommt kein High.
Es waren in den Port-Inits tatsächlich Ungereimtheiten, die ich durch
Umsetzen anscheinend nicht nachgezogen habe. Aber es hatte
erstaunlicherweise alles funktioniert. Jede der Eingänge - ohne Problem.
Habe nun die Direction usw. angepasst.
hier nochmal der korrigierte Codeschnipsel:
1
voidinitial(void)
2
{
3
// **** Einrichten von Ein- und Ausgängen ***************
> Warum schreibst du das setzen der DDR-Bits nicht im selben> Stil? Das wäre auffällig und deutlich weniger fehleranfällig.
Joo, das nervt richtig. Er hat keinen Stil ausgelassen.
Na gut, dezimal fehlt, kommt aber bestimmt noch.
Sieht aus wie aus ganz vielen Beispielen zusammenkopiert.
> Derzeit hängt am PC5 (Pin 27) nur das Messgerät. Es kommt kein High.
Hast Du wie schon gesagt wurde geprüft,
ob JTAG (bei den Fuses) deaktiviert ist?
Thomas S. schrieb:> Wenn JTAG aktiviert ist, sind die Pins PC2...PC5 beim Mega 32 auf Pullup> und können nicht als I/O-Pins genutzt werden.
Das weiß ich mittlerweile auch. Habe dies im Eingangstread auch
geschrieben.
Ist das Häckelchen drin, geht der Pin auf High, ist das Häckelchen weg,
ist der Pin Lo.
Ich ziehe auch immer den MK2 ab, wenn fertig programmiert.
Ben B. schrieb:> Sieht aus wie aus ganz vielen Beispielen zusammenkopiert.
Nicht wirklich, nur weil ich hier und da mal was versuche, mal so, mal
anders. Und nu bin ich halt draufgekommen, wegen der Lesbarkeit in Binär
zu schreiben, aber halt nur mein Problemfall. Ich find binär lesbarer
als hex.
Miss am abgeschalteten AVR mal die beiden Schutzdioden, vor allem den
Pin nach Masse. 0mV? -> Pin tot.
> Ich find binär lesbarer als hex.
Finde ich bei den Pin-Konfigurationen auch, wenn man nicht jedes Bit
einzeln setzen will. Aber dann muss man den Stil auch durchhalten, sonst
wird's unübersichtlich.
> hier nochmal der korrigierte Codeschnipsel
Also gut, sieht, soweit C5 betroffen, okay aus. Dann gilt wohl
> ... Code, der irgendwie auf PC5 zugreift
Folglich ein Main erstellen, welches nur dieses initial aufruft, dann
muss C5 auf high gehen. Anschließend im eigentlichen Programm
weitersuchen.
S. L. schrieb:> Also gut, sieht, soweit C5 betroffen, okay aus. Dann gilt wohl>> ... Code, der irgendwie auf PC5 zugreift
Es ist nichts außer dem Messgerät an diesem Pin angeschlussen.
Ben B. schrieb:> Miss am abgeschalteten AVR mal die beiden Schutzdioden, vor allem den> Pin nach Masse. 0mV? -> Pin tot.
Dann dürfte beim setzen (häckelchen gesetzt) von Jtag nix ändern. Da
geht aber der pin auf High.
Habe den Pin mal extern mit 4,7K hochgezogen. Dann habe ich annähernd
+Ub. Aber das Programm reagiert da nicht.
Wie bereits gesagt wurde... Programm erstellen, was NUR den AVR bzw.
NUR die Portpins konfiguriert und sonst nichts weiter tut. Irgendwie
kommt mir das auch so vor, als wäre im restlichen Programm ein Fehler
drin.
Edit:
> habe nun mal ein Testprogramm geschrieben. Da geht der Pin auf High.
Dann hast Du diese Vermutung damit bestätigt.
Viel Spaß beim Suchen in Deinem Code...
Das kann Dir keiner abnehmen.
Minimalbeispiel ist immer gut.
Was sagt denn das Bit PUD Special Function I/O Register – SFIOR Bit2?
Das ist nach einem Reset 0, wird das irgendwo gesetzt?
Ben B. schrieb:> Viel Spaß beim Suchen in Deinem Code...> Das kann Dir keiner abnehmen.
Oh ja, das war ein grober Fehler.
Das stammt noch aus den Anfängen. und bisher hatte es nicht gestört,
dass ich auf den Ausgang geschrieben hatte. Nun aber brauchte ich von
diesem Port einen Pin (PC5) als Eingang, und da stört nun das:
1
intmain(void)
2
{
3
initial();// Initialisierung Ports etc.
4
check_eeprom();
5
6
//PORTC =0; // PORT Bit wird gesetzt
7
PORTD|=_BV(4);// PORT Bit wird gesetzt
8
9
Update_Ballfreigabe();// gleich mal sperren
10
11
_delay_ms(100);
12
update_display(kredits);// Display auf '0' setzen
13
14
update_Score_Digits();// Punktezähler auf '0' setzen
15
16
while(1)
17
{
Aber wieso meckert da nicht der Compiler, dass ich auf einen Eingang
rausschreiben will?
> Aber wieso meckert da nicht der Compiler,> dass ich auf einen Eingang rausschreiben will?
Warum sollte er?
Wenn Du den Pin als Eingang definierst, kannst Du ja weiterhin auf PortX
schreiben. Das braucht man schließlich, um den PullUp ein- oder
auszuschalten. Dem Compiler ist völlig egal, ob Du einen Pin als Eingang
definiert hast, oder nicht.
Man kann sogar Konstrukte bauen und auf das PinX-Register schreiben -
das führt nur zu nichts weil die Hardware das einfach ignoriert.
Torsten B. schrieb:> Was sagt denn das Bit PUD Special Function I/O Register – SFIOR Bit2?
Ähm, .... ist das was zum Essen..?
Bitte helf mir auf die Sprünge, was das mir helfen kann in der Zukunft.
> Ähm, .... ist das was zum Essen..?
Nein, das ist der Zaunpfahl, daß Du vielleicht mal das Datenblatt lesen
solltest. :)
SFIOR PUD (Bit 2) ist PullUp Disable.
Und sorry fürs Meckern, aber mach Dir mal Gedanken über den Sinn Deiner
Kommentare. Wenn Du sowas dranschreibst, dann stelle Dir die Frage, ob
das auch ein Fremder lesen und verstehen könnte. Wenn Du hinter PortX=0
sowas wie "Port setzen" schreibst, ist das sinnfrei. Das weiß man auch
ohne den Kommentar und wozu Du das machst, ist nicht ersichtlich. Genau
so wie "update_display(credits); //Display auf 0 setzen" auch nur wahr
ist, solange credits den Wert 0 hat.
> Man kann sogar Konstrukte bauen und auf das PinX-Register> schreiben - das führt nur zu nichts weil die Hardware das einfach> ignoriert.
Das mag für einen ATmega32 noch stimmen, aber für die späteren gilt:
"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"
Ok, dann war das PinX Register ein schlechtes Beispiel.
Nehmen wir stattdessen ADCH und ADCL.
Wobei ich da auch nicht weiß, ob der AVR das schreiben verhindert. Kann
sein, daß man damit einfach das ADC-Ergebnis überschreibt.
Ben B. schrieb:> Das weiß man auch> ohne den Kommentar und wozu Du das machst, ist nicht ersichtlich. Genau> so wie "update_display(credits); //Display auf 0 setzen" auch nur wahr> ist, solange credits den Wert 0 hat.
Das geschieht ja in der Initial in Zeile 4612.
[c]
score = 0;
kredits =0;
Chips_to_go =0;
Service_Taster_Counter =0;
[/c}
Ben, die ADCH und ADCL sind read-only, da passiert beim Reinschreiben
gar nichts, siehe Datenblatt Seite 202 (Figure 98. Analog to Digital
Converter Block Schematic) der Pfeil geht nur in eine Richtung
und Seite 217 (Register – ADCL and ADCH) bei Read/Write steht nur R.
Thomas, hast du in deinem geheimen Code schon mal nach SFIOR (Adresse
$30 ($50)) oder PUD gesucht?
Torsten B. schrieb:> Thomas, hast du in deinem geheimen Code schon mal nach SFIOR (Adresse> $30 ($50)) oder PUD gesucht?
Ich habs nicht reingeschrieben.
Wo sollte das sein?
Wenn man an SFIOR nicht rumfummelt, sollte PUD auf 0 sein, und die
Pullups damit aktiv sein. Allerdings sind im SFIOR auch die Auswahlbits
für den ADC-Trigger und es könnte damit bei der lässigen Tipperei des TE
aus Versehen mit beschrieben werden.
> Ben, die ADCH und ADCL sind read-only,> da passiert beim Reinschreiben gar nichts
Prima, dann passen die für das Beispiel. Man kann halt den Befehl
assemblieren ohne eine Fehlermeldung zu bekommen, aber der macht dann
halt nichts.
Thomas S. schrieb:> Ich find binär lesbarer> als hex.
Ich finde magische Nummern generell schlecht lesbar und damit
fehleranfällig.
Ich weise allen Portpins daher an nur einer Stelle Namen zu und verwende
im Code nur noch diese Namen. Dann ist es auch kein Problem, die Pins
nachträglich zu ändern.
Hier mal ein Beispiel:
Beitrag "Re: Port als Variable"
Thread beobachten
Seitenaufteilung abschalten