Inline-Assembler für extrem schnellen Interrupt

[Leo B. (luigi)]

Servus zusammen,

ich möchte einen Drehgeber (oft auch Encoder genannt) mit AB-Ausgang 
auswerten. Ganz wie hier beschrieben: 
http://www.mikrocontroller.net/articles/Drehgeber

Nun dreht die Welle, an welcher sich der Encoder befindet recht schnell, 
sodass ich den Interrupt so kurz wie irgendwie möglich halten möchte um 
die Prozessorlast so gering wie möglich zu halten.

Ich habe mich daher an die Arbeit gemacht und mich über inline-Assembler 
schlauer gelesen. Leider habe ich ein paar Schwierigkeiten den Code zu 
compilieren. Das lesen einer Progmem-Variable scheint mir nicht gerade 
DIE Einstiegs-Aufgabe zu sein...
ich scheitere an der Fehlermeldung
error: memory input 1 is not directly addressable
welcher in der Zeile "m" (encoder_tab) auftritt.

Jetzt poste ich einfach meinen ganzen Versuch in der Hoffnung, ihr könnt 
mir etwas unter die Arme greifen und vielleicht seht ihr ja sogar noch 
etwas Optimierungspotential.

also hier mein Versuch:
Der Code in C:

const int8_t encoder_tab[16] PROGMEM = {0,1,-1,0,-1,0,0,1,1,0,0,-1,0,-1,1,0};
volatile int8_t  enc_delta = 0;

ISR( PCINT0_vect )
{
  static uint8_t code;
  // read in new Encoder-Position
  code = (code<<2) & 0x0F;
    code |= PINB & 3;

    enc_delta += pgm_read_byte( &encoder_tab[ code ] );
}

selbiges als inline-Assembler

const int8_t encoder_tab[16] PROGMEM = {0,1,-1,0,-1,0,0,1,1,0,0,-1,0,-1,1,0};
volatile int8_t  enc_delta = 0;

void PCINT0_vect (void) __attribute__ ((signal, naked));
void PCINT0_vect (void)
{
  static uint8_t code = 0;
  __asm__ __volatile
  (
    "push  r1"      "\n\t"
    "push  r0"      "\n\t"
    "in    r0, __SREG__"  "\n\t"
    "push  r0"      "\n\t"
    "push  r30"    "\n\t"
    "push  r31"    "\n\t"
    // tmp = (code<<2) & 0x0F;
    "lds  r30, %0"  "\n\t"
    "ldi  r31, 0x04"  "\n\t"
    "mul  r30, r31"  "\n\t"
    "andi  r0, 0x0F"  "\n\t"
    // tmp |= PINB & 3;
    "in    r30, 0x03"  "\n\t"
    "andi  r30, 0x03"  "\n\t"
    "or    r30, r0"  "\n\t"
    // code = tmp;
    "sts  %0, r30"  "\n\t"
    // tmp = pgm_read_byte( &encoder_tab[ tmp ] );
    "ldi  r31, 0xFF"  "\n\t"
    "subi  r30, %A1"  "\n\t"
    "sbci  r31, %B1"  "\n\t"
    "lpm  r30, Z"    "\n\t"
    // enc_delta += tmp;
    "lds  r31, %2"  "\n\t"
    "add  r31, r30"  "\n\t"
    "sts  %0, r31"  "\n\t"
    "pop  r31"  "\n\t"
    "pop  r30"  "\n\t"
    "pop  r0"  "\n\t"
    "out  __SREG__, r0"  "\n\t"
    "pop  r0"  "\n\t"
    "pop  r1"  "\n\t"
    :  "+m" (code)
    :  "m" (encoder_tab),
      "m" (enc_delta)
    :  "memory"
  );
  asm volatile ( "reti" );
}

ich hoffe man muss nicht direkt die Hände über dem Kopf zusammenschalgen 
und es besteht noch Hoffnung für mich. Ich habe mich wirklich sehr 
bemüht das Beste aus meinem Unwissen zu machen!

Danke schonmal
lg Leo

[(prx) A. K. (prx)]

Der AVR kann nicht nur multiplizieren, sondern auch schieben. Das spart 
dir R0,R1 ein.

Der Name eines Arrays ist keine direkt adressierbare Variable sondern 
eine Adresskonstante. Daher die Fehlermeldung.

[(prx) A. K. (prx)]

Wenn es wirklich eng zugeht: Viele AVRs stellen im I/O-Bereich ein paar 
frei verwendbare Bytes als "General Purpose I/O Register" zur Verfügung, 
an die man per IN/OUT schneller ran kommt als per LDS/STS ans RAM.

Etwas härterer Tobak: Tabelle so im Speicher platzieren, dass sie nicht 
über eine 256-Byte-Grenze geht, oder noch besser exakt an einer solchen 
beginnt. Reduziert die Adressrechnung.

[Falk B. (falk)]

@  Leo B. (luigi)

>ich möchte einen Drehgeber (oft auch Encoder genannt) mit AB-Ausgang
>auswerten. Ganz wie hier beschrieben:
>http://www.mikrocontroller.net/articles/Drehgeber

Kaum. Denn dann würdest du nicht den Pin Change Interrupt verwenden. 
Aber dazu zum 100202034mal zu diskutieren hab ich keine Lust.

Wenn man schon schnelle ISRs braucht, sollte man sie besser komplett in 
ASM als eigene Datei aufsetzen, das ist deutlich einfacher und wartbarer 
als Inline ASM.

[Leo B. (luigi)]

Ihr seid einfach einsame Spitze! Danke

A. K. schrieb:
> Der AVR kann nicht nur multiplizieren, sondern auch schieben. Das spart
> dir R0,R1 ein.
Haste recht. Zugegeben, ich hab den Compiler meinen C-Code compilieren 
lassen und hab mich am lss-File orientiert. Etwas gemogelt, aber für nen 
Einsteiger wie mich nicht Falsch glaube ich.

A. K. schrieb:
> Der Name eines Arrays ist keine direkt adressierbare Variable sondern
> eine Adresskonstante. Daher die Fehlermeldung.
Danke das löst den Fehler. Nur muss ich dann die Adresse oder die 
Variable übergeben? also "i" (encoder_tab) oder "i" (&encoder_tab)?
und stimmt der Constraint i dann überhaupt?

A. K. schrieb:
> Wenn es wirklich eng zugeht: Viele AVRs stellen im I/O-Bereich ein paar
> frei verwendbare Bytes als "General Purpose I/O Register" zur Verfügung,
> an die man per IN/OUT schneller ran kommt als per LDS/STS ans RAM.
Hab ich nun umgesetzt denke ich. Danke für den Hinweis!
( enc_delta ist ne globale variable und wär mich auch lieber wenn es 
eine solche bleibt )

A. K. schrieb:
> Etwas härterer Tobak: Tabelle so im Speicher platzieren, dass sie nicht
> über eine 256-Byte-Grenze geht, oder noch besser exakt an einer solchen
> beginnt. Reduziert die Adressrechnung.
Da geb ich dir Recht, nur wie ich dem guten Compiler beibringe wo ich 
die Daten gerne hätte?! Da hab ich absolut keinen Ansatz wo ich anfangen 
sollte google oder Bücher zu bemühen...


Jetzt sieht's folgendermaßen aus:

const int8_t encoder_tab[16] PROGMEM = {0,1,-1,0,-1,0,0,1,1,0,0,-1,0,-1,1,0};
volatile int8_t  enc_delta = 0;

void PCINT0_vect (void) __attribute__ ((signal, naked));
void PCINT0_vect (void)
{
  asm volatile
  (
  "push  r30"      "\n\t"
  "in    r30, __SREG__"  "\n\t"
  "push  r30"      "\n\t"
  "push  r31"      "\n\t"
  // tmp = (code<<2) & 0x0F;
  "in    r31, %1"    "\n\t"
  "lsl  r31"      "\n\t"
  "lsl  r31"      "\n\t"
  "andi  r31, 0x0F"    "\n\t"
  // tmp |= PINB & 3;
  "in    r30, %2"    "\n\t"
  "andi  r30, 0x03"    "\n\t"
  "or    r30, r31"    "\n\t"
  // code = tmp;
  "out  %1, r30"    "\n\t"
  // tmp = pgm_read_byte( &encoder_tab[ tmp ] );
  "ldi  r31, 0xFF"    "\n\t"
  "subi  r30, %A3"    "\n\t"
  "sbci  r31, %B3"    "\n\t"
  "lpm  r30, Z"      "\n\t"
  // enc_delta += tmp;
  "lds  r31, %0"    "\n\t"
  "add  r31, r30"    "\n\t"
  "sts  %0, r31"    "\n\t"
  "pop  r31"      "\n\t"
  "pop  r30"      "\n\t"
  "out  __SREG__, r30"  "\n\t"
  "pop  r30"      "\n\t"
  :  "+m" (enc_delta)
  :  "I" (_SFR_IO_ADDR (GPIOR0)),
    "I" (_SFR_IO_ADDR (PINB)),
    "i" (encoder_tab)
  :  "memory"
  );
  asm volatile ( "reti" );
}

Kann noch jemand Fehler oder Verbesserungen sehen?
vielen Dank
lg Leo

Edit: hab grad noch ein paar r30 zu r31 und ein r0 zu r 31 gemacht... 
Flücktigkeitsfehler, wollte auch schnell sein so wie ihr...

[Leo B. (luigi)]

Ja ich entdecke einen Fehler! Nur eine Lösung? wo ist der Fehler 
genau???
Der Compiler sollte ja die Adresse der encoder_tab irgendwie so 
auflösen, dass später im Code steht:

subi  r30, 0xCC  ; 204
sbci  r31, 0xFF  ; 255

was er allerdings tut ist:

subi  r30, 0x34  ; 52
sbci  r31, 0x34  ; 52

Dass da noch das Einer-Komplement mit drin steckt ist mir klar aber mein 
Ergebniss ist ja völlig Falsch...
Wie löst man das??

Ich versuche mich verzweifelt an folgendem Beispiel aber irgendwie 
klapt's nicht!
http://www.rn-wissen.de/index.php/Inline-Assembler_in_avr-gcc#Zugriff_aufs_SRAM

[(prx) A. K. (prx)]

%A3/B3 ergibt nur bei Registern Sinn. Bei Konstanten wärs eher lo8(%3) 
und hi8(%3).

[Leo B. (luigi)]

Ah ok, danke. ja das löst das halbe Problem. Nur wie ich ihm beibringe 
das Komplement zu bilden ist mir noch unklar. Er weigert sich 
hartnäckig.
Minus klappt nicht, die Schlange ~(...) auch nicht...
Wird wohl auch nicht allzu häufig gebraucht hab ich das Gefühl, da die 
allwissende Suchmaschine mich nicht aufklären möchte. Ich hab hier einen 
echten Hänger. Sehr nervig!

Danke für jeden Tip!

[(prx) A. K. (prx)]

Minus klappt durchaus - aber an der richtigen Stelle.

Q: Wie kriege ich sowas raus?

A: Frag den Compiler, der muss es ja wissen:

extern char a[];

char * f(int x)
{
        return a+x;
}

ergibt

        subi r24,lo8(-(a))
        sbci r25,hi8(-(a))

[Leo B. (luigi)]

Genial, Danke!
so ganz 100% klar ist mir zwar gerade noch nicht, wie du das raus 
bekommen hast (auch wenn du mir das wohl gerade beibringen wolltest, 
danke dafür). aber ich werde da dran bleiben und mir das nochmal genauer 
ansehen!

[troll (Gast)]

Leo B. schrieb:
> so ganz 100% klar ist mir zwar gerade noch nicht, wie du das raus
> bekommen hast
A.K. dürfte einfach den gezeigten C-Code compiliert und dann ins 
Listfile (.lss) geschaut haben.

[(prx) A. K. (prx)]

troll schrieb:
> A.K. dürfte einfach den gezeigten C-Code compiliert und dann ins
> Listfile (.lss) geschaut haben.

Das lss-File bringt nix, ich will ja den Code vor dem Assembler 
wissen, nicht disassemblerten Code. Also
   avr-gcc -S t1.c
und dann ins t1.s schauen.

[fonsana (Gast)]

Leo B. schrieb:
> Nun dreht die Welle, an welcher sich der Encoder befindet recht schnell,
> sodass ich den Interrupt so kurz wie irgendwie möglich halten möchte um
> die Prozessorlast so gering wie möglich zu halten.

Was heisst denn recht schnell in Zahlen?
Wieviele Impulse erzeugt denn der Encoder je Umdrehung?

Das sollte doch ersteinmal ueberschlagen werden, bevor man ueberhaupt 
ueber Tricks und Klimmzuege nachdenkt.

fonsana

[troll (Gast)]

A. K. schrieb:
> troll schrieb:
>> A.K. dürfte einfach den gezeigten C-Code compiliert und dann ins
>> Listfile (.lss) geschaut haben.
>
> Das lss-File bringt nix, ich will ja den Code vor dem Assembler
> wissen, nicht disassemblerten Code. Also
>    avr-gcc -S t1.c
> und dann ins t1.s schauen.

Ah so, wieder was gelernt. Danke.

[Leo B. (luigi)]

troll schrieb:
> Ah so, wieder was gelernt. Danke.

Dem schließe ich mich an, Danke.

fonsana schrieb:
> Was heisst denn recht schnell in Zahlen?
> Wieviele Impulse erzeugt denn der Encoder je Umdrehung?

1000 Striche pro Umdrehung, jeder löst 4 Interrupts/Flanken aus, bei 
einer Drehzahl von 1000U/min und mehr. Der aktuelle Interrupt brauch mit 
rjmp zum Interrupt und reti 39 Zyklen. Macht 2.600.000 Zyklen pro 
Sekunde für den Encoder. Statt den 68 Zyklen den Compilierten C-Codes 
por Interrupt, respektive 4.533.333 Zyklen pro Sekunde finde ich ist das 
eine starke Verbesserung. Da der µC noch 3 zeitkritische Trigger (so 
genau wie möglich, auf jeden Fall aber weniger als 100µs Abweichung vom 
Soll) verwalten soll, nebenbei noch SPI-Master an einem Bus mit 3 Slaves 
und eine UART->RS232->USB->PC Verbindung verarbeiten darf, ist der µC 
doch nicht schlecht ausgelastet. Ich bin also froh um die paar Prozent 
gewonnener Prozessorzeit!

[Leo B. (luigi)]

Ich glaube ich hab da einen Fehler, kann ihn aber nicht ganz 
nachvollziehen. Vielleicht könnt ihr mir nochmal kurz auf die Sprünge 
helfen.
Es geht um die Berechnung der Speicheradresse:
Der Compiler produziert aus dem c-Code folgendes:

  uint8_t tmp;
[...]
  code = tmp;
  90:  e0 93 02 01   sts  0x0102, r30  // => r30 = tmp

  tmp = pgm_read_byte( &encoder_tab[ tmp ] );
  94:  ff 27         eor  r31, r31
  96:  e7 fd         sbrc  r30, 7
  98:  f0 95         com  r31
  9a:  ec 5c         subi  r30, 0xCC  ; 204
  9c:  ff 4f         sbci  r31, 0xFF  ; 255
  9e:  e4 91         lpm  r30, Z

Wenn ich das richtig deute, dann lässt sich der 2. Absatz in folgenden, 
für mich leserlicheren "nicht ganz C"-Code zurück übersetzen:

  uint16 tmp = (uint16)(tmp);  // r30 = tmp; r31 = 0
  if( tmp >= 128 )             // sbrc  r30, 7
    tmp -= 1;                  // com  r31
  tmp -= (uint16)(-34);
  tmp = pgm_read_byte( tmp );  // lpm  r30, Z

Aber warum das ganze mit dem -1 ?
Entweder ich mach beim übersetzen einen Fehler oder mir ist nicht klar 
warum er das macht, der gute Compiler?

Kann mir da grad nochmal jemand helfen bitte?
lg Leo

[Piefke (Gast)]

Leo B. schrieb:
> Kann mir da grad nochmal jemand helfen bitte?

Folgenden Hinweis einfach beachten:

Falk Brunner schrieb:
> Wenn man schon schnelle ISRs braucht, sollte man sie besser komplett in
> ASM als eigene Datei aufsetzen, das ist deutlich einfacher und wartbarer
> als Inline ASM.

[(prx) A. K. (prx)]

Leo B. schrieb:
>   94:  ff 27         eor  r31, r31
>   96:  e7 fd         sbrc  r30, 7
>   98:  f0 95         com  r31

Übersetzt: 8-Bit mit Vorzeichen erweitert auf 16 Bit mit Vorzeichen.

[Stefan E. (sternst)]

A. K. schrieb:
> Übersetzt: 8-Bit mit Vorzeichen erweitert auf 16 Bit mit Vorzeichen.

Was mich doch sehr stark an diesem hier zweifeln lässt:

uint8_t tmp;

[(prx) A. K. (prx)]

Piefke schrieb:
> Folgenden Hinweis einfach beachten:
>
> Falk Brunner schrieb:
>> Wenn man schon schnelle ISRs braucht, sollte man sie besser komplett in
>> ASM als eigene Datei aufsetzen, das ist deutlich einfacher und wartbarer
>> als Inline ASM.

Ist für so ziemlich alle Fragen hier völlig irrelevant. Dafür hat man 
aber Zusatzkram wie File-Kopf und extern-Deklarationen an der Backe, die 
man sich bei inline-Code erspart. Einfacher ist eigentlich nur die 
Tipparbeit der Funktion selbst, weil der \n\t Kram entfällt.

[Leo B. (luigi)]

A. K. schrieb:
> Übersetzt: 8-Bit mit Vorzeichen erweitert auf 16 Bit mit Vorzeichen.

Tatsache... Dann rechnet der GCC offenbar einfach mit einem Vorzeichen 
behafteten Index ohne Warnung, Hinweis, o.Ä.... klingt gefährlich!
Folgender Code ist zweifellos der Quellcode zu obigem assemblierten 
Ausschnitt, ich hab's nochmal nachgeprüft!

ISR( PCINT0_vect )
{
  uint8_t tmp;
  static uint8_t code = 0; 
  tmp = (code<<2) & 0x0F;
  tmp |= PINB & 3;
  code = tmp;

  tmp = pgm_read_byte( &encoder_tab[ tmp ] );

  enc_delta += tmp;
}

[Stefan E. (sternst)]

Leo B. schrieb:
> Dann rechnet der GCC offenbar einfach mit einem Vorzeichen
> behafteten Index ohne Warnung, Hinweis, o.Ä.... klingt gefährlich!

Warum sollte er warnen? Ein Array-Index ist in C immer Vorzeichen 
behaftet.

Leo B. schrieb:
> Folgender Code ist zweifellos der Quellcode zu obigem assemblierten
> Ausschnitt, ich hab's nochmal nachgeprüft!

Schwer zu glauben. Ich würde mich dann mal auf die Suche nach der 
Definition von uint8_t machen.

[Piefke (Gast)]

A. K. schrieb:
> Ist für so ziemlich alle Fragen hier völlig irrelevant. Dafür hat man
> aber Zusatzkram wie File-Kopf und extern-Deklarationen an der Backe, die
> man sich bei inline-Code erspart.

Das ist ja nun keine unlösbare Aufgabe.
Wenn man wenig tippen möchte, kann man sich auch die .c-Funktion in eine 
Assemblerquelle übersetzen lassen und ggf. optimieren. Dann stimmen 
zumindest das Gerüst und die Grundfunktion.
Der obige inline-Text ist doch Spagetti pur!

[(prx) A. K. (prx)]

Stefan Ernst schrieb:
> Warum sollte er warnen? Ein Array-Index ist in C immer Vorzeichen
> behaftet.

Aber nicht die Erweiterung von uint8_t zu int. Die anschliessende 16-Bit 
Addition vom Index zur Basisadresse darf er dann gerne mit Vorzeichen 
machen.

[Stefan E. (sternst)]

A. K. schrieb:
> Aber nicht die Erweiterung von uint8_t zu int.

Natürlich nicht. Habe ich das mit der zitierten Aussage auch nur 
ansatzweise behauptet?

[(prx) A. K. (prx)]

War als Erklärung gemeint, nicht so sehr an dich adressiert.