Atmega32 - PortPin geht nicht auf High wenn Pullup gesetzt

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.

Thomas S. schrieb:

DDRB = 0xd8; // PortB Ausgänge

Nach dieser Zeile hast du

PB3, PB4, PB6 und PB7 auf Output gesetzt. Da hilft kein Pullup.

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.

Was mach ich falsch.

der PC7 nicht auf High

geht der PC5 wieder auf Lo

Wastl schrieb:

.... Mist ....

Hab mich wohl im Port verschaut

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.

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

void initial(void)

2

 {    

3

    // **** Einrichten von Ein- und Ausgängen *************** 

4

    DDRA = 0xff;    // PortA Ausgänge

5

    DDRB = 0x48;    // PortB Ausgänge 

6

 //   DDRC = 0xdf;        // PortC Ausgänge - Bit 5 Eingang - Chip Quitierung

7

    DDRC = 0b11011111;  // PortC Ausgänge - Bit 5 Eingang - Chip Quitierung

8

    DDRD = 0xff;    // PortD Ausgänge 

9

10

     // PullUps für die Eingänge aktivieren

11

   PORTB |= (1<<PB0);  // Pull Up an Pin0 - aktivieren

12

  PORTB |= (1<<PB1);  // Pull Up an Pin1 - aktivieren

13

  PORTB |= (1<<PB2);  // Pull Up an Pin2 - aktivieren

14

  PORTB |= (1<<PB4);  // Pull Up an Pin4 - Starttaste Eingang aktivieren

15

  PORTB |= (1<<PB5);  // Pull Up an Pin5 - Goal- Eingang aktivieren

16

  PORTB |= (1<<PB7);  // Pull Up an Pin7 - Service-Taste aktivieren

17

18

  PORTC |= (1<<PC5);  // Pull Up an Pin27 - Chip issued aktivieren

19

20

     // **** Einrichten von Timer 1 ***************

21

    // timer mode 4, CTC, prescaler 1

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.

Thomas S. schrieb:

Aber das Programm reagiert da nicht.

Zeige den Teil des Codes der auf den Port zugreift.

Gleich Wastl,

habe nun mal ein Testprogramm geschrieben. Da geht der Pin auf High.

1

*

2

 * Atmega32_Test.c

3

 *

4

 * Created: 06.04.25 20:20:37

5

 *  Author: Thomas

6

 */ 

7

8

#include <avr/io.h>

9

10

int main(void)

11

{

12

    DDRC = 0b11011111;  // PortC Ausgänge - Bit 5 Eingang - Chip Quitierung

13

    PORTC |= (1<<PC5);  // Pull Up an Pin27 - Chip issue aktivieren

14

15

    while(1)

16

    {

17

18

    }

19

}

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?

Das kann Dir keiner abnehmen.

Nun, man könnte den PC losschicken, mit CTRL-F, und DDRC, PORTC, PINC sowie C5 mit auf den Weg geben.

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

int main(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}

Initial auf jeden Fall, und da wird das auch funktionieren. Aber irgendwann steigen die Credits halt an und dann stimmt es nicht mehr.

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"