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.
Ä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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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"
