Danke für die vielen Antworten:
@p_mork: Mit dem Register kann ich schon umgehen, keine Angst. Ich habe mir genug Quellen dazu durchgelesen. Und diese Zeile bedeutet nichts anderes, als dass die Variable nicht im RAM zu finden ist, sondern in r3, d.h. in einem Register, so dass er bei einem Zugriff nicht aus dem RAM lesen oder hineinschreiben muss. Diese Zeile hat den Ablauf stark beschleunigt.
In den Quelle, die ich benutzt habe, ist angegeben, dass r3 vom GCC unbenutzt bleibt. Und selbst wenn es benutzt würde, außerhalb der Schleife ists mir egal.

Ja natürlich wird 81 mal gelesen. Durch meine Experimente hatte ich für diesen Post den Originalzustand wiederhergestellt und vergessen, dass das '--' vor dem Cnt stehen muss.

Ich hatte den selben Code benutzt wie Du, nur dass ich per Array-Zugriff die Adresse berechnet hatte, das macht aber keinen Unterschied:
Code:
uint8_t *p = &global_cam_pic[MAX_X];
Das komische ist, dass dieser Ablauf länger dauert, als der ohne Pointer. Deshalb bin ich ja so enttäuscht.


@Besserwessi:
Ich glaube auch, dass man mit Inline-Assembler noch was kitzeln kann.
Man könnte ja z.B. den Beginn des Arrays nehmen, und dann drauf los schreiben, ohne jedes Mal das High-Byte des RAMs mit setzen zu müssen. Die Startadresse des Puffers ist nämlich glücklicherweise auf 512. (Warum auch immer) Dann könnte man sogar über 200 Pixel schreiben, ohne das High-Byte des Pointers neu setzen zu müssen.

Fakt ist, dass ich tatsächlich 80 unterschiedliche Pixel bekomme. Ich habe das ja schon auf den PC übertragen und mir angeschaut. Genau, wie Radbruch sagt, keiner versteht so genau, warum, aber der ADC läuft schneller als im DB angegeben.


@sprinterSB: Siehe meinen Abschnitt an Besserwessi und Radbruchs Antwort: Ich lese de facto 80 unterschiedliche Bits in 50µs.


@radbruch: Danke, den Link habe ich gesucht.
Ja, das kann schon sein, aber das Problem ist, dass ich nicht denke, dass ich 26 Takte brauche. Aber wie gehabt, wird wahrscheinlich einfach unten abgeschnitten.