ATmega328P - ADC Conversion: Unterschied der Befehlverarbeitung innerhalb ISR

[LeDay (Gast)]

Guten Tag.

Ich habe eine mir nicht erklärbare Anomalie bei einem ATmega328P, der 
mit einem 16MHz Oszillator getaktet wird, feststellt. Es geht dabei um 
die Durchführung einer ADC-Conversion und das Umschalten eines Ausgangs 
hinsichtlich seines digitalen Levels.
Ich habe dabei zwei unterschiedliche Codevarianten implementiert, die 
eigentlich das Umschalten des PD1 Pins auf die selbe Art durchführen 
sollten. Anbei habe ich dann die Spannungsverläufe des PD1 Pins 
angehängt.
Man kann erkennen, dass beim ersten Fall der Pin jeweils nur eine 
Taktdauer auf dem gesetzten Pegel ist. Im zweiten Fall ist aber der Pin 
für die erste Portanweisung für zwei Taktperioden auf dem Low-Level.

Weiß möglicherweise jemand, wie das zustande kommt? Ich habe mir 
überlegt, dass es irgendwas mit dem Springen zur ISR zu tun haben 
könnte. Das sollte ja aber eigentlich schon bis zur dieser Codeposition 
erfolgt sein, weshalb ich nicht wirklich weiß, was die Ursache ist.
Ich würde mich freuen, wenn jemand etwas dazu sagen könnte.

MfG LeDay


Code Fall 1:

#include <avr/io.h>
volatile unsigned char Test;
int main(void)
{
  DDRD = 0x02;
  PORTD = 0x02;
  ADMUX = (1 << REFS0) | (1 << ADLAR);
  ADCSRA = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0) | (0 << ADIE) | (1 << ADEN);
  ADCSRA |= (1 << ADSC);
  while(1)
  {
    while(!(ADCSRA & (1 << ADIF)));
    Test = ADCH;
    PORTD = 0x00;
    PORTD = 0x02;
    PORTD = 0x00;
    PORTD = 0x02;
    PORTD = 0x00;
    PORTD = 0x02;
    PORTD = 0x00;
    PORTD = 0x02;
    ADCSRA |= (1 << ADSC);
  }
}

Code Fall 2:

#include <avr/io.h>
#include <avr/interrupt.h>
volatile unsigned char Test;
int main(void)
{
  DDRD = 0x02;
  PORTD = 0x02;
  ADMUX = (1 << REFS0) | (1 << ADLAR);
  ADCSRA = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0) | (1 << ADIE) | (1 << ADEN);
  sei();
  ADCSRA |= (1 << ADSC);
  while(1)
  {
  }
}
ISR(ADC_vect)
{
  Test = ADCH;
  PORTD = 0x00;
  PORTD = 0x02;
  PORTD = 0x00;
  PORTD = 0x02;
  PORTD = 0x00;
  PORTD = 0x02;
  PORTD = 0x00;
  PORTD = 0x02;
  ADCSRA |= (1 << ADSC);
}

[Niklas G. (erlkoenig)]

Am Besten erstmal den disassemblierten Code ansehen und posten. Nicht 
dass der Compiler irgendwas zwischen die beiden ersten 
PORTD-Schreibzugriffe in der ISR packt.

[S. Landolt (Gast)]

> irgendwas zwischen die beiden ersten
> PORTD-Schreibzugriffe in der ISR packt
Zum Beispiel ein ldi. Vielleicht auch mal die Compiler-Optimierungen 
umschalten.

[Norbert (Gast)]

Fand ich spannend, hab's mal compiliert.
Mag nicht der richtige chip sein, zeigt aber genau das Problem.

$ avr-g++ -mmcu=atmega32u4 -O2 code2.c -S

.global  __vector_29
  .type  __vector_29, @function
__vector_29:
  push r1
  push r0
  in r0,__SREG__
  push r0
  clr __zero_reg__
  push r24
  push r30
  push r31
/* prologue: Signal */
/* frame size = 0 */
/* stack size = 6 */
.L__stack_usage = 6
  lds r24,121
  sts Test,r24
  out 0xb,__zero_reg__

HIER ISSER:
  ldi r24,lo8(2)

  out 0xb,r24
  out 0xb,__zero_reg__
  out 0xb,r24
  out 0xb,__zero_reg__
  out 0xb,r24
  out 0xb,__zero_reg__
  out 0xb,r24
  ldi r30,lo8(122)
  ldi r31,0
  ld r24,Z
  ori r24,lo8(64)
  st Z,r24
/* epilogue start */
  pop r31
  pop r30
  pop r24
  pop r0
  out __SREG__,r0
  pop r0
  pop r1
  reti

[LeDay (Gast)]

Wow, danke euch.

Also helfen würde dann wahrscheinlich, vor dem ersten Low-Befehl, den 
Port wiederholt auf High zu setzen, damit das Register vorgeladen wird.
Ich muss mal überprüfen, ob das noch einen Performancegewinn im 
Vergleich zur Polling-Variante darstellt.

Oder einfach ASM lernen :).

[Niklas G. (erlkoenig)]

LeDay schrieb:
> Oder einfach ASM lernen :).

Das ist hier die einzig richtige Antwort, denn nur so kann man solche 
Taktgenauen Sachen bauen. Der C-Compiler kann einem immer irgendwas 
umsortieren. Oder noch besser das Signal-Timing per Timer/PWM o.ä. in 
Hardware erzeugen.

LeDay schrieb:
> Also helfen würde dann wahrscheinlich, vor dem ersten Low-Befehl, den
> Port wiederholt auf High zu setzen, damit das Register vorgeladen wird.

So etwas kann vielleicht helfen, aber wenn du irgendwo irgendwas anderes 
änderst, klappt's dann vielleicht nicht mehr.

[Einer K. (Gast)]

LeDay schrieb:
> Also helfen würde dann wahrscheinlich, ...
Statt der Brachialmethode die Pin Toggle Fähigkeit zu nutzen.

Statt:

  PORTD = 0x00;
  PORTD = 0x02;
  PORTD = 0x00;
  PORTD = 0x02;
  PORTD = 0x00;
  PORTD = 0x02;
  PORTD = 0x00;
  PORTD = 0x02;

Dieses:

  PIND = (1 << PD1);
  PIND = (1 << PD1);
  PIND = (1 << PD1);
  PIND = (1 << PD1);
  PIND = (1 << PD1);
  PIND = (1 << PD1);
  PIND = (1 << PD1);
  PIND = (1 << PD1);
  PIND = (1 << PD1);

[LeDay (Gast)]

Ja, das hat tatsächlich geholfen. Meine Intention ist nicht die ganze 
Zeit zu togglen, aber generell kann ja dann eine entsprechende 
Verzögerung implementiert werden bis es zur nächsten gewünschten 
Änderung kommt, und dann mit dem Toggle-Befehl der Pin umgeschaltet 
werden.
Danke für den Tipp!