Arduino inline ASM Fragen.

[Trulla O. (obertrulla)]

Es geht um folgenden code auf atmega328p der 7 WS2812 parallel 
ansteuert:

#define mask 0b01111111
#define ws2812_PORTREG PORTC
#define ws2812_DDREG DDRC

void  ws2812_sendarray(uint8_t *data,uint16_t datlen)
{
  uint8_t curbyte,ctr;
  while (datlen--) 
  {
    curbyte=*data++;
    asm volatile
    (
    "       st    x,%3  \n\t"    //  set maskhi 
    "       rjmp .+0 \n\t"       //  wait 
    "       st    x,%1  \n\t"    //  set byte
    "       rjmp .+0 \n\t"       //  wait 
    "       st    x,%4  \n\t"    //  set masklo 
    "       rjmp .+0 \n\t"       //  wait 
    : "=&d" (ctr)
    : "r" (curbyte), "x" (&ws2812_PORTREG), "r" (mask), "r" (~mask)
    );
  }
}

Frage 1:
Die variable "ctr" brauch ich nicht, aber wenn ich die zeile rausnehme 
reklamiert der compiler. Ich versteh die syntax nicht.

Frage 2:

  while (datlen--) 
  {
    curbyte=*data++;

Sollte auch in asm sein um das timing genau einzustellen. KA wie ich in 
asm einen pointer auf ein array auslese. Funktioniert zwar ohne, aber 
ein delay zwischen den bytes ist sichtbar.

[OMG (Gast)]

Trulla O. schrieb:
> aber wenn ich die zeile rausnehme
> reklamiert der compiler.

Du schreibst nicht welche Zeile du "rausnimmst".
Du schreibst nicht wie der Compiler "reklamiert".

Wie wär's wenn du präzise Angaben machst?

[Peter D. (peda)]

Trulla O. schrieb:
> Es geht um folgenden code

Es ist immer ne ganz schlechte Idee, Code aus dem Kontext heraus zu 
reißen.
Magst Du mal den Ursprung verlinken. Da ist bestimmt beschrieben, was 
dieser Code überhaupt machen soll.
Und der Autor wird sich bei "ctr" auch was gedacht haben.

[Falk B. (falk)]

Trulla O. schrieb:
> ie variable "ctr" brauch ich nicht, aber wenn ich die zeile rausnehme
> reklamiert der compiler. Ich versteh die syntax nicht.

Ich auch nicht ;-) Inline Assembler ist zu 99% write only.
Eine derartige einfache und kurze Funktion würde ich als reinen 
Assembler in einer .S Datei schreiben. Das geht einfacher als man denkt.

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Assembler_und_Inline-Assembler

https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591235

AT1886

[Trulla O. (obertrulla)]

ctr hab ich eleminiert.

    :: "r" (curbyte), "x" (&ws2812_PORTREG), "r" (mask), "r" (~mask)

und %nummer um eins reduzieren da weniger parameter.

Warum hier ST 16-bit-pt verwendet wird und nicht OUT 8-bit-pt ist mir 
nicht klar. Mit OUT bring ich das nicht zum laufen.

Jetzt noch *data in einen 16-bit-pt laden und von dort lesen ...

[Falk B. (falk)]

Trulla O. schrieb:
> und %nummer um eins reduzieren da weniger parameter.
>
> Warum hier ST 16-bit-pt verwendet wird und nicht OUT 8-bit-pt ist mir
> nicht klar. Mit OUT bring ich das nicht zum laufen.

Warum meinst du, ohne einen Hauch von Kenntnissen zum Thema Inline-ASM 
dort rumschrauben zu müssen? Die Funktion hast du irgendwo her kopiert, 
sie funktioniert. Was soll das Ganze?

[Trulla O. (obertrulla)]

Das original ist das aus der ws2812_light library.

Wozu das ganze ändern? Das original steuert 1 pin, einen string von LED. 
Ich möchte aber 7 strings von LED ansteuern. 7 mal schneller. Die 
chinesen bauen damit audio spektrum displays.

Es geht darum 7 serielle signale zu produzieren, nicht nur eines. Und du 
wirst zugeben müssen das ist ziemlich genial ✨

Ja, das funktioniert bereits, es geht darum das zu optimieren / 
verstehen. Wahrscheinlich ist bei OUT das timing zu schnell ...

Da fragt man was und alle antworten sind ziemlich demotivierend. ausser 
dem hier:

Falk B. schrieb:
> Ich auch nicht ;-)

[Jörg W. (dl8dtl) (Moderator)]

Trulla O. schrieb:
> Warum hier ST 16-bit-pt verwendet wird und nicht OUT 8-bit-pt ist mir
> nicht klar.

Weil sie offenbar nicht garantieren können oder wollen, dass das 
Portregister auch tatsächlich im per OUT adressierbaren Bereich liegt.

"ctr" wird im Original gar nicht benutzt und daher vom Compiler eh 
wegoptimiert.

Trulla O. schrieb:
> Ich möchte aber 7 strings von LED ansteuern. 7 mal schneller.

Dann ist es in der Tat das Einfachste, du folgst Falks Rat und schreibst 
das Ding komplett neu in Assembler und linkst es zum C-Code dazu.

[Oliver S. (oliverso)]

Trulla O. schrieb:
> Die variable "ctr" brauch ich nicht, aber wenn ich die zeile rausnehme
> reklamiert der compiler. Ich versteh die syntax nicht.

https://rn-wissen.de/wiki/index.php/Inline-Assembler_in_avr-gcc#Instruktionen_und_Constraints

UNd ich würds ja in C schreiben. Wofür hat man schließlich den Compiler

#pragma GCC push_options
#pragma GCC optimize ("Os")
void ws2812_sendarray2(uint8_t *data, uint16_t datlen)
{
  while (datlen--)
  {
    uint8_t curbyte = *data++;
    ws2812_PORTREG = mask;
    asm volatile ("nop");
    ws2812_PORTREG = curbyte;
    asm volatile ("nop");
    ws2812_PORTREG = ~mask;
  }
}
#pragma GCC pop_options

Oliver

[Falk B. (falk)]

Trulla O. schrieb:
> Das original ist das aus der ws2812_light library.
>
> Wozu das ganze ändern? Das original steuert 1 pin, einen string von LED.
> Ich möchte aber 7 strings von LED ansteuern. 7 mal schneller. Die
> chinesen bauen damit audio spektrum displays.

Ich hab da meine Zweifel, daß ein AVR-Arduino dafür die richtige Wahl 
ist. Denn das Konzept beruht darauf, daß die CPU den Datenstrom vorher 
berechnet und in den RAM schreibt. Die Funktion gibt die nur aus. Dazu 
braucht es aber ne MENGE an RAM. Und ob das dann schneller ist als der 
Standardansatz mit einem Bit, ist fraglich. Für größere CPUs, vor allem 
ARM mit DMA etc. gibt es solche Mehrkanalfuntkionen, die auch wirklich 
mehr Leistung bringen.

WS2812 Ansteuerung

[Jörg W. (dl8dtl) (Moderator)]

Oliver S. schrieb:
> UNd ich würds ja in C schreiben.

Was gleich noch mit den Vorteil hat, dass der Compiler automatisch OUT 
benutzt, wenn der Port im dafür erreichbaren Bereich liegt.

[Trulla O. (obertrulla)]

Oliver S. schrieb:
> UNd ich würds ja in C schreiben.

Geht nicht. Aber mit 3 nop gehts. 🤩🤩🤩

#pragma GCC push_options
#pragma GCC optimize ("Os")
void ws2812_sendarray(uint8_t *data, uint16_t datlen)
{
  while (datlen--)
  {
    uint8_t curbyte = *data++;
    ws2812_PORTREG = mask;
    asm volatile ("nop \n\t nop \n\t nop");
    ws2812_PORTREG = curbyte;
    asm volatile ("nop \n\t nop \n\t nop");
    ws2812_PORTREG = ~mask;
    asm volatile ("nop \n\t nop");
  }
}
#pragma GCC pop_options

[Trulla O. (obertrulla)]

Falk B. schrieb:
> Dazu
> braucht es aber ne MENGE an RAM. Und ob das dann schneller ist als der
> Standardansatz mit einem Bit, ist fraglich.

Es braucht 12.5% mehr ram wie die 1-bit variante. Und es ist 7 mal 
schneller. Wenn alle 8 pins eines ports rausgeführt wären wäre ram 1:1, 
speed 8 fach.

Motivationsvideo: https://www.youtube.com/watch?v=2p-FsQTYz1Q

[Oliver S. (oliverso)]

Trulla O. schrieb:
> Geht nicht. Aber mit 3 nop gehts. 🤩🤩🤩

Was dann ja auch deine Frage beantwortet, warum im Original st und nicht 
out verwendet wurde. Irgendwie muß man die Zyklen anscheinend 
verballern.

Oliver

[Falk B. (falk)]

Trulla O. schrieb:
> Es braucht 12.5% mehr ram wie die 1-bit variante. Und es ist 7 mal
> schneller.

Nö. Das ist die Milchmädchenrechnung, vor der ich gewarnt habe. Die 
AUSGABE ist 7x schneller! Aber vorher mußt du die Daten berechnen! Wie 
lange dauert das?

> Wenn alle 8 pins eines ports rausgeführt wären wäre ram 1:1,
> speed 8 fach.

Bla.

Beitrag "Re: Frage zu IR-Remote+LED-Strips an AVR"

Die Funktion brauch keine Umrechnung, da werden die RGB Daten direkt 
ausgegeben und auch in Echtzeit berechnet.

[Falk B. (falk)]

Oliver S. schrieb:
> Irgendwie muß man die Zyklen anscheinend
> verballern.

Man muss ein relativ genaues Timing einhalten. Schneller bringt da nix, 
außer Farbfehlern.

[Trulla O. (obertrulla)]

Jetzt brauch ich noch einen vernünftigen "datendreher".

[Falk B. (falk)]

Trulla O. schrieb:
> Jetzt brauch ich noch einen vernünftigen "datendreher".

Das sind 5x8=40 LEDs. Bei 800kbit/s und 24 Bit/LED sind das 1,152ms für 
einen Update mit einer Datenleitung. Das die Dinger intern sowieso nur 
mit ca. 400Hz PWM arbeiten, ist ein Update in weniger als 2,5ms sinnlos. 
Für einen Equalizer sowieso, denn 400Hz Bildrate braucht kein Mensch, 
20-100 reichen.
D.h. bei 100Hz LED-Refresh bleiben dir "nur" ~8,8ms bzw. 88% CPU Last 
übrig, um die Daten für die LEDs zu berechnen.

[Peter D. (peda)]

Trulla O. schrieb:
> Jetzt brauch ich noch einen vernünftigen "datendreher".

Hier mal für ne 8*12 Matrix:

void pwm_set()
{
  uint16_t *pval = pwm_val; 
  uint8_t pdat[PWM_BITS] = {0};               // optimized to register
  
  for( uint8_t mask = 1; mask; mask <<= 1 ){
    uint16_t v = *pval++;
#define MOVE_BIT(x) if( PWM_BITS > x && (PWM_POL ? v : ~v) & 1<<x ) pdat[x] |= mask
    MOVE_BIT(0);  MOVE_BIT(1);  MOVE_BIT(2);  MOVE_BIT(3);
    MOVE_BIT(4);  MOVE_BIT(5);  MOVE_BIT(6);  MOVE_BIT(7);
    MOVE_BIT(8);  MOVE_BIT(9);  MOVE_BIT(10); MOVE_BIT(11);
    MOVE_BIT(12); MOVE_BIT(13); MOVE_BIT(14); MOVE_BIT(15);
  } 
#define STORE_PWM(x) if( PWM_BITS > x ) pwm_data[x]  = pdat[x]
  STORE_PWM(0);  STORE_PWM(1);  STORE_PWM(2);  STORE_PWM(3);
  STORE_PWM(4);  STORE_PWM(5);  STORE_PWM(6);  STORE_PWM(7);
  STORE_PWM(8);  STORE_PWM(9);  STORE_PWM(10); STORE_PWM(11);
  STORE_PWM(12); STORE_PWM(13); STORE_PWM(14); STORE_PWM(15);
}

Beitrag "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle"

[Trulla O. (obertrulla)]

Peter D. schrieb:
> Beitrag "AVR: Fast-PWM (BAM) 12 Bit für 8 Kanäle"

Muss mich da einarbeiten. Versteh nur bahnhof.

[Stefan F. (Gast)]

Trulla O. schrieb:
> Jetzt brauch ich noch einen vernünftigen "datendreher".

40 LEDs zu je 60 mA brauchen 2,4 A. Vergleiche das mal mit den 
technischen Daten deines Arduino Boardes oder der USB Spezifikation.

[Beo B. (beobachte)]

Trulla O. schrieb:
> Geht nicht. Aber mit 3 nop gehts. 🤩🤩🤩

Wennschon:

void ws2812_sendarray(uint8_t *data, uint16_t datlen)
{
  cli();  
  while (datlen--)
  {
    uint8_t curbyte = *data++;
    ws2812_PORTREG = mask;
    asm volatile ("nop \n\t nop \n\t nop");
    ws2812_PORTREG = curbyte;
    asm volatile ("nop \n\t nop \n\t nop");
    ws2812_PORTREG = ~mask;
    asm volatile ("nop \n\t nop");
  }
  sei();
}

Und das bit-drehen macht der compiler:

struct bitarr8
{
   uint8_t bit0 : 1;
   uint8_t bit1 : 1;
   uint8_t bit2 : 1;
   uint8_t bit3 : 1;
   uint8_t bit4 : 1;
   uint8_t bit5 : 1;
   uint8_t bit6 : 1;
   uint8_t bit7 : 1;
};

// 8 times one byte bits 0..4
// in 8 bytes out 8 bytes, or in 5 byte out 8 byte

void shuffle(struct bitarr8 in[8], struct bitarr8 out[8])
{  
  // in byte 1 bit 1..8 goes out byte 1..8m bit 1
  out[7].bit0 = in[0].bit0;
  out[7].bit1 = in[1].bit0;
  out[7].bit2 = in[2].bit0;
  out[7].bit3 = in[3].bit0;
etc ...

Aufruf mit void*:

shuffle((void*)&pixelin[i],(void*)&pixelout[i]);

[Falk B. (falk)]

Beo B. schrieb:
> Und das bit-drehen macht der compiler:

Und du bist dir so sicher, daß das auf dem AVR optimal schnell läuft? 
Ich nicht.

[Beo B. (beobachte)]

Falk B. schrieb:
> daß das auf dem AVR optimal schnell läuft?

Der konstruktive weg wäre eine einfachere oder schnellere variante 
vorzuschlagen.

[Jörg W. (dl8dtl) (Moderator)]

Beo B. schrieb:
> asm volatile ("nop \n\t nop \n\t nop");

Wenn du den Reset eh schon in C machst, kannst du auch gleich 
_delay_us() benutzen. Das bezieht dann auch gleich die Taktfrequenz mit 
ein, um entweder eine passende Anzahl von NOPs zu generieren oder eine 
entsprechende Schleife.

[chris_ (Gast)]

Wenn es auf's Zyklen zählen ankommt, würde ich dem C-Compiler nicht 
vertrauen, da ist man bei echten Assemblerbefehlen doch eher auf der 
sicheren Seite.

[Stefan F. (Gast)]

chris_ schrieb:
> Wenn es auf's Zyklen zählen ankommt, würde ich dem C-Compiler nicht
> vertrauen, da ist man bei echten Assemblerbefehlen doch eher auf der
> sicheren Seite.

Kannst du aber, delay_us() kriegst du selbst nicht besser hin.

[Jörg W. (dl8dtl) (Moderator)]

chris_ schrieb:
> da ist man bei echten Assemblerbefehlen doch eher auf der sicheren
> Seite.

Nur dass du dir die eben für jede CPU-Taktfrequenz selbst zusammen 
basteln musst, während der Compiler das für dich automatisch berechnen 
kann. Kleiner als zyklengenau kann er es natürlich auch nicht :-), aber 
das kann er schon. Nicht, weil ein Compiler grundsätzlich besser wäre, 
sondern weil ihm diverse fleißige Programmierer das mal beigebracht 
haben.

(Diese Aussage trifft in der Form erstmal auf den AVR zu. Bei anderen 
Architekturen ist das sicher anders oder gar nicht so machbar.)