ungewollte komische interne-Verspätung von dem Microcontroller ATMEGA32A

[Saad Y. (Firma: Student) (saad)]

Vielen Dank für die Umfangreiche Webseite.

Ich benutze einen ATMEGA32A mit einem 16MHz extern Oszilattor für ein 
Projekt für meine Bachelorarbeit.
Das Projekt ist ein Schaltung entwürfen, um ein extern-Signal zu lesen 
und später drauf antworten zu können(Simulationsgerät).
Das Signal kommt von einem 12Volt Gerät.
Ich habe eine Spannungsteiler benutzt um den Pin des Microcontroller von 
der 12 Volt zu schützen.
meine Spanungsteiler Widerstände sind:
R1= 100KOhm und R2=50KOhm.

Während programmieren gab es immer eine Komische Verspätung beim Lesen 
des PIN von dem Microcontroller, und ich wüsste nicht woran sie liegen 
könnte, deswegen habe den einfache Code in meiner while schleife 
geschrieben, um die Verhalten des Microkontroller mit dem Oszilloskop zu 
untersuchen bzw. genauer anzugucken:
 while (1)
      {
      // Place your code here
      if (PIND.0) PORTC.0=0;
        else PORTC.0=1;
      }

Trotzt dem einfachen Code ist der Ausgangsspannung (PortC) immer noch 
mit 3.2Microsekunde verspätet( sehe Anhang ).
Hat jemand mal dieses Problem gehabt?.
gibt es einen Kondensator in dem Aufbau des Pin in dem Microkontroller, 
der u dieser Verspätung führt? oder woran könnte diese Verspätung 
legen?.
Ich freue mich auf eure Antworte.
Vielen Danke im Voraus!.

der Gesamte Code ist:

Chip type               : ATmega32A
Program type            : Application
AVR Core Clock frequency: 16.000000 MHz
Memory model            : Small
External RAM size       : 0
Data Stack size         : 512
*******************************************************/

// I/O Registers definitions
#include <mega32a.h>

// Declare your global variables here

void main(void)
{
// Declare your local variables here

// Input/Output Ports initialization
// Port A initialization
// Function: Bit7=In Bit6=In Bit5=In Bit4=In Bit3=In Bit2=In Bit1=In 
Bit0=In
DDRA=(0<<DDA7) | (0<<DDA6) | (0<<DDA5) | (0<<DDA4) | (0<<DDA3) | 
(0<<DDA2) | (0<<DDA1) | (0<<DDA0);
// State: Bit7=T Bit6=T Bit5=T Bit4=T Bit3=T Bit2=T Bit1=T Bit0=T
PORTA=(0<<PORTA7) | (0<<PORTA6) | (0<<PORTA5) | (0<<PORTA4) | 
(0<<PORTA3) | (0<<PORTA2) | (0<<PORTA1) | (0<<PORTA0);

// Port B initialization
// Function: Bit7=In Bit6=In Bit5=In Bit4=In Bit3=In Bit2=In Bit1=In 
Bit0=In
DDRB=(0<<DDB7) | (0<<DDB6) | (0<<DDB5) | (0<<DDB4) | (0<<DDB3) | 
(0<<DDB2) | (0<<DDB1) | (0<<DDB0);
// State: Bit7=T Bit6=T Bit5=T Bit4=T Bit3=T Bit2=T Bit1=T Bit0=T
PORTB=(0<<PORTB7) | (0<<PORTB6) | (0<<PORTB5) | (0<<PORTB4) | 
(0<<PORTB3) | (0<<PORTB2) | (0<<PORTB1) | (0<<PORTB0);

// Port C initialization
// Function: Bit7=In Bit6=In Bit5=In Bit4=In Bit3=In Bit2=In Bit1=In 
Bit0=Out
DDRC=(0<<DDC7) | (0<<DDC6) | (0<<DDC5) | (0<<DDC4) | (0<<DDC3) | 
(0<<DDC2) | (0<<DDC1) | (1<<DDC0);
// State: Bit7=T Bit6=T Bit5=T Bit4=T Bit3=T Bit2=T Bit1=T Bit0=0
PORTC=(0<<PORTC7) | (0<<PORTC6) | (0<<PORTC5) | (0<<PORTC4) | 
(0<<PORTC3) | (0<<PORTC2) | (0<<PORTC1) | (0<<PORTC0);

// Port D initialization
// Function: Bit7=In Bit6=In Bit5=In Bit4=In Bit3=In Bit2=In Bit1=In 
Bit0=In
DDRD=(0<<DDD7) | (0<<DDD6) | (0<<DDD5) | (0<<DDD4) | (0<<DDD3) | 
(0<<DDD2) | (0<<DDD1) | (0<<DDD0);
// State: Bit7=T Bit6=T Bit5=T Bit4=T Bit3=T Bit2=T Bit1=T Bit0=T
PORTD=(0<<PORTD7) | (0<<PORTD6) | (0<<PORTD5) | (0<<PORTD4) | 
(0<<PORTD3) | (0<<PORTD2) | (0<<PORTD1) | (0<<PORTD0);


while (1)
      {
      if (PIND.0) PORTC.0=0;
        else PORTC.0=1;
      }
}

[Jens M. (schuchkleisser)]

Schau mal in die Assembly.
Und: wie stehen die Fuses, nicht zufällig auf "Teile den Takt durch 8"? 
;)

[Saad Y. (Firma: Student) (saad)]

Danke für Ihre Antwort, ich glaube die Fuses sind richtig gestellt.?
sorry das ist mein erstes Embedded Projekt und habe noch ne so ein 
Problem gehabt.

[Falk B. (falk)]

Saad Y. schrieb:
> Danke für Ihre Antwort, ich glaube die Fuses sind richtig gestellt.?

Das kann man dort nicht sehen, denn das sind ja nicht die ausgelesenen 
Fuses. Das sind Einstellungen, welche programmiert werden SOLLEN! Aber 
der Haken dafür fehlt, also wird nicht programmiert.

Du must die Fuses direkt auslesen, das geht im Microchip Studio unter 
Progamm Target / Read Fuses etc.

[Oliver S. (oliverso)]

Jens M. schrieb:
> wie stehen die Fuses, nicht zufällig auf "Teile den Takt durch 8"?

Eine CLKDIV8-Fuse hat der Mega32 nicht.

Jens M. schrieb:
> Schau mal in die Assembly.

Das würde ich auch empfehlen. Und, falls nicht geschehen, die 
Optimierung beim kompilieren einschalten.

Oliver

[Sebastian (Gast)]

An der fallenden Flanke ist die Verspätung viel geringer. Das 
Oszilloskop scheint den Pegel an PIND.0 viel früher als HIGH zu erkennen 
als der ATMEGA32A.

LG, Sebastian

[asd (Gast)]

Auch wenn es das nicht sein sollte weil keine definiert sind: 
Deaktiviere mal alles Interrupts.

[Dyson (Gast)]

asd schrieb:
> Auch wenn es das nicht sein sollte weil keine definiert sind:
> Deaktiviere mal alles Interrupts.

Den Sinn deines Vorschlages kannst du aber schon erklären oder?

[Werner (Gast)]

Saad Y. schrieb:
> Ich habe eine Spannungsteiler benutzt um den Pin des Microcontroller von
> der 12 Volt zu schützen.
> meine Spanungsteiler Widerstände sind:
> R1= 100KOhm und R2=50KOhm.

Deine 'Quelle' hat damit 33 kOhm. Bei einer 'Last' von 100 pF 
(Steckbrett) gibt das schon mal ein tau = 1/(R*C) = 3.3 usec ...

Just my 2 ct

[Falk B. (falk)]

Werner schrieb:
> Deine 'Quelle' hat damit 33 kOhm. Bei einer 'Last' von 100 pF
> (Steckbrett) gibt das schon mal ein tau = 1/(R*C) = 3.3 usec ...

Das Steckbrett hat keine 100pF, ein Tastkopf mit 1:1 Teiler schon. Sieht 
man ja auf dem Oszibild ;-)

[MaWin (Gast)]

Schicker Bart.

[Stefan F. (Gast)]

Werner schrieb:
> Deine 'Quelle' hat damit 33 kOhm. Bei einer 'Last' von 100 pF
> (Steckbrett) gibt das schon mal ein tau = 1/(R*C) = 3.3 usec

Die gebe Linie auf dem Oszilloskop bestätigt dies. Das Gelbe Signal 
erreicht den LOW Pegel erst verzögert.

Und die rote Linie (ich nehme an, das ist PORTC.0) folgt den Logik 
Pegeln prompt ohne sichtbare Verzögerung. In dem Moment wo das gelbe 
Signal den LOW Pegel erreicht, geht es auf HIGH. Und in dem Moment wo 
das gelbe Signal den HIGH Pegel erreicht, geht es auf Low.

Saad Y. schrieb:
> Ich benutze einen ATMEGA32A mit einem 16MHz extern Oszilattor für ein
> Projekt für meine Bachelorarbeit.

Warum benutzt so ein uraltes Modell?

[Werner (Gast)]

Saad Y. schrieb:
> Trotzt dem einfachen Code ist der Ausgangsspannung (PortC) immer noch
> mit 3.2Microsekunde verspätet( sehe Anhang ).
> Hat jemand mal dieses Problem gehabt?.
> gibt es einen Kondensator in dem Aufbau des Pin in dem Microkontroller,
> der u dieser Verspätung führt? oder woran könnte diese Verspätung
> legen?.

Die Flanke des gelben Signals (Vermutlich das Signal nach dem 
Spannungsteiler) ist nicht gerade schnell.

Dei digitaler Kanal (grün) hat wahrscheinlich eine andere 
Schaltschwelle, als der ATMega.

Der Spannungsteiler hat ja auch kapazitäten. Du könntest ihn, ähnlich 
wie ein Tastkopf am Oszilloskop auch, mit zwei Kondensatoren versehen 
und diese dann so anpassen, dass das Zeitverhalten Deines 
Spannungsteilers besser wird (steilere Flanke).

Ansonsten, könntest Du auch hingehen und den unteren Widerstand duch 
eine 3,9V (oder 4,7V) Z-Diode ersetzen. Dadurch wird die Flanke 
vermutlich auch steiler. Kapazitiv abstimmen halte ich aber für die 
elegantere Lösung.

Werner

[Jens M. (schuchkleisser)]

Oliver S. schrieb:
> Eine CLKDIV8-Fuse hat der Mega32 nicht.

Ah ok, kurzer Lesefehler, hatte 328 gesehen, war wohl schon zu warm 
hier.
Danke.

[Saad Y. (Firma: Student) (saad)]

vielen Dank für alle euere Antworte.

Ich habe den Spannungsteiler Faktor 10 kleiner genommen und somit die 
Verspätung von max. 3.3Microsecunde zu max. 700 ns verkleinert wurden.
diese 700 ns wird leider 10 mal großer wenn ich irgendwelchen Timer in 
dem Microcontroller benutze, um den Pin abzufragen und das Signal zu 
lesen.
Es ist auf jeden fall schon mal viel besser als vorher, da die 
Verspätungen schon mal halb so groß wie vorher sind.

[Saad Y. (Firma: Student) (saad)]

Stefan ⛄ F. schrieb:
> Werner schrieb im Beitrag
> Saad Y. schrieb im Beitrag:
>> Ich benutze einen ATMEGA32A mit einem 16MHz extern Oszilattor für ein
>> Projekt für meine Bachelorarbeit.
>
> Warum benutzt so ein uraltes Modell?

Das ist leider was in Stock verfügbar war

[Sebastian (Gast)]

Saad Y. schrieb:
> diese 700 ns wird leider 10 mal großer wenn ich irgendwelchen Timer in
> dem Microcontroller benutze, um den Pin abzufragen und das Signal zu
> lesen.

Ja natürlich. Timer lösen nun mal nur zu bestimmten Intervallen aus, und 
dann vergehen auch noch einige uC-Takte für die PC- und Stackverwaltung 
bevor die Interruptroutine überhaupt abgearbeitet wird.

LG, Sebastian

[Dyson (Gast)]

Saad Y. schrieb:
> vielen Dank für alle euere Antworte.
> Ich habe den Spannungsteiler Faktor 10 kleiner genommen und somit die
> Verspätung von max. 3.3Microsecunde zu max. 700 ns verkleinert wurden.
> diese 700 ns wird leider 10 mal großer wenn ich irgendwelchen Timer in
> dem Microcontroller benutze, um den Pin abzufragen und das Signal zu
> lesen.
> Es ist auf jeden fall schon mal viel besser als vorher, da die
> Verspätungen schon mal halb so groß wie vorher sind.

Warum lässt du dein Eingangssignal keinen Interrupt auslösen?

[Saad Y. (Firma: Student) (saad)]

Dyson schrieb:
> Saad Y. schrieb:
>> vielen Dank für alle euere Antworte.
>> Ich habe den Spannungsteiler Faktor 10 kleiner genommen und somit die
>> Verspätung von max. 3.3Microsecunde zu max. 700 ns verkleinert wurden.
>> diese 700 ns wird leider 10 mal großer wenn ich irgendwelchen Timer in
>> dem Microcontroller benutze, um den Pin abzufragen und das Signal zu
>> lesen.
>> Es ist auf jeden fall schon mal viel besser als vorher, da die
>> Verspätungen schon mal halb so groß wie vorher sind.
>
> Warum lässt du dein Eingangssignal keinen Interrupt auslösen?

weil der PIN, an dem ich mein Input verbunden habe kein Interrupt 
unterstützt und wenn ich mehr als ein Eins nacheinander habe dann kann 
ich nur ein Interrupt lesen bzw. nur ein Eins lesen und so mit kann ich 
nicht das ganze 20 Bit Signal richtig lesen.

[Wolfgang (Gast)]

Dyson schrieb:
> Warum lässt du dein Eingangssignal keinen Interrupt auslösen?

Und was ändert das grundsätzlich?
Auch der Interrupt erzeugt eine gewisse Verzögerung, die sich aus 
Registersicherung und dem eigentliche Code zum Setzen des Ausgangspins 
ergibt.

Wenn es wirklich schnell gehen soll, ist festverdrahtete Logik/CPLD/FPGA 
der richtige Weg. Durch Tiefpassfilterung verschliffene Flanken sind 
natürlich auch dort Gift.

[DerEgon (Gast)]

Saad Y. schrieb:
>> Warum lässt du dein Eingangssignal keinen Interrupt auslösen?
>
> weil der PIN, an dem ich mein Input verbunden habe kein Interrupt
> unterstützt und wenn ich mehr als ein Eins nacheinander habe dann kann
> ich nur ein Interrupt lesen bzw. nur ein Eins lesen und so mit kann ich
> nicht das ganze 20 Bit Signal richtig lesen.

Da stehst Du Dir mit dem Atmega32A natürlich sehr gründlich auf dem Fuß 
herum.

Neuere AVRs bieten einen "pin change interrupt" und können somit jeden 
I/O-Pin als Interruptquelle benutzen.

Was für ein "20-Bit-Signal" ist das, das jetzt hier urplötzlich 
auftaucht?

Beschreib doch dieses "Signal" mal etwas genauer; was ist der maximale 
Takt dieses "Signals", was für ein Gerät erzeugt dieses "Signal", und 
gibt es nur genau eine Leitung dafür?

[Stefan F. (Gast)]

Mir ist überhaupt noch nicht klar, ob die Verzögerung minimiert werden 
soll, oder ob er nur eine Erklärung für die Verzögerung haben wollte.

Saad, wenn da was optimiert werden soll, dann brauchen wir viel mehr 
Infos zum Anwendungsfall.

[Dyson (Gast)]

Wolfgang schrieb:
> Dyson schrieb:
>
>> Warum lässt du dein Eingangssignal keinen Interrupt auslösen?
>
> Und was ändert das grundsätzlich?
> Auch der Interrupt erzeugt eine gewisse Verzögerung, die sich aus
> Registersicherung und dem eigentliche Code zum Setzen des Ausgangspins
> ergibt.
> Wenn es wirklich schnell gehen soll, ist festverdrahtete Logik/CPLD/FPGA
> der richtige Weg. Durch Tiefpassfilterung verschliffene Flanken sind
> natürlich auch dort Gift.

Weil das Signal dann nicht 5 Minuten warten muss, bis der Timer sich 
bequemt, es irgendwann mal abzufragen.

Aber da gerade eine neue Salamischeibe aufgetaucht ist…