-         

Ergebnis 1 bis 9 von 9

Thema: Problem mit Pullups.Alle Pins reagieren anders

  1. #1
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    26.07.2005
    Beiträge
    108

    Problem mit Pullups.Alle Pins reagieren anders

    Anzeige

    Ich hab da ein ganz blödes Problem mit meinem RN-Control 1.4 mit Mega 32. Ich will gerade diverse 1wire Sensoren anschließen. Das ganze scheitert jetzt schon an folgendem Problem: Bei 1wire muss der Bus von einem Wiederstand (empfohlen 4,7k) auf 5V gezogen werden. Ich hab das Problem mal soweit isoliert das das wie folgt aussieht. Ich hab ein Programm geschrieben das einen beliebigen Pin auf Ausgang setzt und auf Low. jetzt schaltet das Programm den Pin als eingang und wartet bis er auf High pegel liegt. Die Zeit wird gestoppt. and den Entsprechenden Pin schließe ich ein 4,7k Wiederstand an und den an +5V. Wenn ich jetzt z.B. PINC 1 nehme dann ist der Pin innerhalb von ein paar us wieder auf 5V und alles ist gut. bei jedem anderen Pin des ganzen Controllers braucht das ganze mehrere ms was definitiv zu langsam ist. PINC1 wird ja auch für I2C benutzt und is bei RNControl ja mit nem pullup schon verbunden. Dachte zuerst daran liegts aber der is 1. 10k und 2. funktionierts an pin c2 der ja genau so beschaltet ist auch nicht. Ich hab schon überprüft nur Pins zu nehemen die nicht noch intern beim RNControl beschaltet sind zu benutzen etc. etc. aber ich kriegs nicht hin. Woran kann das liegen? 4,7k ist doch als pullup nicht zu groß oder? bei PinC1 geht das ganze ja auch. Sind die kapazitäten der i/o Pins so unterschiedlich?

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    20.05.2006
    Ort
    Lippe
    Alter
    48
    Beiträge
    524
    Hallo,

    als erstes schau mal ob der JTAG deaktiviert ist? Sonst sind intern an PC2, PC3 und PC5 Pullups aktiv.

    Gruß

    Jens

  3. #3
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    26.07.2005
    Beiträge
    108
    ja ist deaktiviert. Außerdem währen interne pullups die zusätzlich aktiviert sind ja nicht problematisch da ja von außen eh noch ein pullup dranhängt, d.h. die internen dürften sich dann ja nicht negativ auswirken, theoretisch. Außerdem hab ich auch schon port b und d probiert und immer das gleiche problem. Nur C1 scheint zu funktionieren

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Dirk
    Registriert seit
    30.04.2004
    Ort
    NRW
    Beiträge
    3.791
    Hallo mwoidt,
    Ich hab ein Programm geschrieben das einen beliebigen Pin auf Ausgang setzt und auf Low. jetzt schaltet das Programm den Pin als eingang und wartet bis er auf High pegel liegt. Die Zeit wird gestoppt.
    Ich habe noch nie darüber nachgedacht, wie lange ein AVR braucht, bis er nach dem Umschalten eines Pins von Ausgang auf Eingang nutzbar ist und man den anliegenden Pegel lesen kann.

    Ich wäre aber davon ausgegangen, dass es nur Nanosekunden dauert.

    Das stürzt mich jetzt in tiefe Verzweiflung.

    Wie hast du das denn gemessen?

    Gruß Dirk

  5. #5
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    15.11.2004
    Ort
    Aachen
    Alter
    32
    Beiträge
    246
    Am einfachsten ist es immer, wenn du gleich deinen Code mit postest, vielleicht liegt da ja irgendwo der Wurm.

    Das Datenblatt des ATMega32 sagt auf Seite 51:
    As
    indicated by the two arrows tpd,max and tpd,min, a single signal transition on the pin will be delayed
    between ½ and 1½ system clock period depending upon the time of assertion.
    Bei 16MHz sollte das Signal also nach max. 94ns im Register erscheinen.
    Hast du die Zeit mal mit internem Pullup gemessen?

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    20.05.2006
    Ort
    Lippe
    Alter
    48
    Beiträge
    524
    Hallo,

    habe mal zur Hand genommen was da war. Atmega 16 @ 16 Mhz
    Obere Kurve PD5 untere PD 7 mit 4,7K Pullup.
    Wie man auf dem Bild vielleicht erahnen kann ist eine Zeiteinteilung von 1µs/div gewählt.

    Code:
    #include <avr/io.h>
    #define NOP asm("nop")
    
    int main (){
    	DDRD |= (1<<PD5);  
    	while (1)
    	{
    		PORTD |= (1<<PD5);   	          //a
    		DDRD |= (1<<PD7);
    		PORTD &= ~(1<<PD7);		//b	
    		DDRD &= ~(1<<PD7);		//c
    		NOP;
    		NOP;
    		PORTD &= ~(1<<PD5);		//d
    	}
    	return 0;
    }
    Das ist etwa das was ich erwartet habe. Ein weiter Test bei dem nicht die Pegeländerung am Beinchen, sondern der interne Zustand des PIN's auf einen anderen Ausgang gelenkt wurde, bestätigt, dass was zerush geschrieben hat. Darum Code und Messverfahren posten.

    @zerush Wobei das Problem ja darin besteht, dass der Übergang von Ein- auf Ausgang auffällig lange dauert. Erst durch den Übergang wird eine Pegeländerung des PIN's hervorgerufen, die dann sicher auch beim OP schnell genug erkannt wird.

    Gruß

    Jens
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken dsc00094_1.jpg  

  7. #7
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    26.07.2005
    Beiträge
    108
    Hab den Code gerade nicht zur Hand aber werd ihn nochmal posten wenn ich wieder zu hause bin. Das tolle ist ja, dass er bei C1 (bzw, C0 wie man will) Anstandslos nen vernünftigen Wert ausgibt. Aber bei allen anderen io pins eben nicht, das ganze also grundsätzlich nicht ganz falsch sein kann. Hatte auch noch keine Zeit das ganze gründlicher zu untersuchen werd die tage nochmal n oszilloskop dranhängen und das ganze näher untersuchen

  8. #8
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Ganz leichte Variationen sind da möglich. Die Zeit hängt unter anderem von der kappatzität an den Pins ab. Wenn da eine Lange Leitung dranhängt dauert es halt etwas länger bis sich der Pegel ändert.

  9. #9
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    26.07.2005
    Beiträge
    108
    Ja aber ich nenne nen Faktor von über 500 nicht ne leichte Variation. Da liegt ja das Problem

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •