C komisches Verhalten

[Jan (Gast)]

Hallo,

ich habe im Moment ein mir unerklärliches Problem und zwar geht es um 
eine zeitkritische Ausgabe von Daten. Dazu mal folgender Code-Ausschnitt 
welcher drei Byte ausgibt:

void LED_Ausgabe()
{
  int8_t i;
  char tmp ;
  unsigned char R,G,B;

  R = 255;
  G = 0;
  B = 0;

  for (i=0;i<8;i++)
  {
    tmp = G>>(7-i);
    G -= tmp<<(7-i);

    if (tmp == 1)
      L_High(); //Gibt ein logisches high-Bit aus
    else
      L_Low(); ////Gibt ein logisches low-Bit aus
  }

Diese Schleife gibts danach noch zwei Mal für G und B.

In dieser Konstellation funktioniert auch alles d.h. es dauert 1,25usec 
um 1 Bit auszugeben (so wie gewünscht).

Wenn ich den Code jedoch folgendermaßen anpasse (die RGB Werte werden 
übergaben anstatt sie innerhalb der Funktion fest zu definieren):

void LED_Ausgabe(unsigned char R, unsigned char G, unsigned char B)
{

  int8_t i;
  char tmp ;

  for (i=0;i<8;i++)
  {
    tmp = G>>(7-i);
    G -= tmp<<(7-i);

    if (tmp == 1)
      L_High();
    else
      L_Low();
  }

dann benötigt der Prozessor sehr viel länger pro Bit (zwischen 2 und 
10usec).

Ich arbeite mit einem atmega8 @ 8Mhz und externem Quarz. Die Compiler 
Optimierung steht  „optimize most“

Hat irgendwer eine Idee wie das zustande kommt bzw. wie ich das Problem 
lösen kann?

Mit freundlichen Grüßen

[Drobel (Gast)]

Was glaubst du was das hier für ein Forum ist? Robert Lembke und sein 
Rateteam?

[Peter II (Gast)]

was machst du überhaupt hier?

   tmp = G>>(7-i);
    G -= tmp<<(7-i);


irgenwie sieht es mir sehr umständlihc aus und es ist extrem langsam auf 
einem atmel.

Was ist das ziel davon?

außerdem handelst du dir Probleme mit deinem temp ein, weil es char ist 
und damit signed und nicht unsigned.

[Jan (Gast)]

Anstatt sinnlose Kritik zu äußern hättest du auch sagen können was dir 
an Informationen fehlt, dann könnte ich diese nachliefern.

Ich bin noch recht unerfahren was µC programmiereung angeht und habe den 
Text nach besten wissen verfasst.

MfG.

[Jan (Gast)]

Peter II schrieb:
> as machst du überhaupt hier?
>
>    tmp = G>>(7-i);
>     G -= tmp<<(7-i);


Das tmp signed ist habe ich eben auch gemerkt, macht allerdings keinen 
Unterschied.

Was ich da mache:
Ich gehe das Byte Bit für Bit duch und entscheide jenachdem ob das 
aktuelle Bite eine Null oder eine Eins ist welche der beiden Funktionen 
(L_High oder L_Low)aufgerufen wird.

[Volker (Gast)]

Im 1. Fall sind R,G,B Konstanten und der Compiler kann deine 
Berechnungen wegoptimieren. Im 2. Fall halt nicht mehr.

[Peter II (Gast)]

Jan schrieb:
> Ich gehe das Byte Bit für Bit duch und entscheide jenachdem ob das
> aktuelle Bite eine Null oder eine Eins ist welche der beiden Funktionen
> (L_High oder L_Low)aufgerufen wird.

irgenwie ist mir das zu hoch wie du es gemacht hast.

besser ist es auf jeden Fall so:

  for (i=0;i<8;i++)
  {
     if ( i & 1 )
      L_High();
    else
      L_Low();

    i = i >> 1;
  }

eventuell noch umdrehen, ich verstehe ja bei deim code nicht mal wie rum 
die bits ausgeben werden.

[Peter II (Gast)]

Peter II schrieb:
> for (i=0;i<8;i++)
>   {
>      if ( i & 1 )
>       L_High();
>     else
>       L_Low();
>     i = i >> 1;
>   }

muss natürlich anders sein

 for (i=0;i<8;i++)
  {
     if ( G & 1 )
      L_High();
    else
      L_Low();

    G = G >> 1;
  }

[Helfender (Gast)]

void LED_Ausgabe(unsigned char R, unsigned char G, unsigned char B)
{
  int8_t i;

  for (i = 0; i < 8; i++)
  {
    if ((G & (0x80 >> i)) != 0)
      L_High();
    else
      L_Low();
  }
}

[Peter II (Gast)]

Helfender schrieb:
> void LED_Ausgabe(unsigned char R, unsigned char G, unsigned char B)
> {
>   int8_t i;
>   for (i = 0; i < 8; i++)
>   {
>     if ((G & (0x80 >> i)) != 0)
>       L_High();
>     else
>       L_Low();
>   }
> }

genauso schlecht,

0x80 >> i

sollte man auf einem atmel vermeiden, weil es es nicht in hardware kann. 
Hier baut der compiler selber wieder eine schleife ein.

[Jan (Gast)]

Danke schonmal für eure Verbesserungsvorschläge, allerdings habe ich 
immernoch mein Timigproblem.

Volker schrieb:
> Im 1. Fall sind R,G,B Konstanten und der Compiler kann deine
> Berechnungen wegoptimieren. Im 2. Fall halt nicht mehr.

So ungefähr habe ich mir das auch gedacht allerdings keine Lösung 
gefunden. Ist es denn irgendwie möglich die Variable zu übergeben und 
diese dann zu einer Konstanten werden zu lassen ?

MfG.

[Peter II (Gast)]

Jan schrieb:
> So ungefähr habe ich mir das auch gedacht allerdings keine Lösung
> gefunden. Ist es denn irgendwie möglich die Variable zu übergeben und
> diese dann zu einer Konstanten werden zu lassen ?

dafür müsste man mehr von dem Programm sehen, vermutlich lieg das 
Problem wo anders. Der code von mir oben braucht keine µs zum ausführen.

[Simon B. (nomis)]

Hallo Jan.

Jan schrieb:
> In dieser Konstellation funktioniert auch alles d.h. es dauert 1,25usec
> um 1 Bit auszugeben (so wie gewünscht).
[...]
> dann benötigt der Prozessor sehr viel länger pro Bit (zwischen 2 und
> 10usec).
>
> Ich arbeite mit einem atmega8 @ 8Mhz und externem Quarz. Die Compiler
> Optimierung steht  „optimize most“

Das riecht nach WS2811/WS2812?

Mache Dir mal klar, dass 800kHz (1.25µS/bit) bei einem Takt von 8MHz 
bedeutet, dass Du 10 Zyklen pro Bit zur Verfügung hast. Also maximal 
10 Assembler-Instruktionen.

Schon alleine ein Funktionsaufruf ohne Argumente braucht davon 5 oder 6. 
In dem Rest muss dann noch festgestellt werden welches Bit wie 
ausgegeben werden muss.

Will sagen: Du musst da hand-getuneden Assembler hernehmen, wenn Du 
wissen willst dass das Timing funktioniert. Und selbst dann wird es 
extrem knifflig.

Such mal nach WS2811 oder WS2812 im Forum, da kannst Du verschiedene 
Ansätze dazu begutachten.

Viele Grüße,
        Simon

[Helfender (Gast)]

Sprungtabelle?


void ( * LED_Ausgabe_x ( ) ) [] = {
  LED_Ausgabe_0,
  LED_Ausgabe_1,
  LED_Ausgabe_2,
  LED_Ausgabe_3,
...
  LED_Ausgabe_255
};


void LED_Ausgabe(unsigned char R, unsigned char G, unsigned char B)
{
  LED_Ausgabe_x[R]();
}


void LED_Ausgabe_0()
{
  L_Low(); ////Gibt ein logisches low-Bit aus
  L_Low(); ////Gibt ein logisches low-Bit aus
  L_Low(); ////Gibt ein logisches low-Bit aus
  L_Low(); ////Gibt ein logisches low-Bit aus
  L_Low(); ////Gibt ein logisches low-Bit aus
  L_Low(); ////Gibt ein logisches low-Bit aus
  L_Low(); ////Gibt ein logisches low-Bit aus
  L_Low(); ////Gibt ein logisches low-Bit aus
}

usw.

Braucht aber viel Platz...
Wenn Du es so machen willst, schreibst Dir am besten ein
Programm, was den Source Code erzeugt...

Ist deine L_Low/L_High schnell genug? Inline?
Vielleicht auch LED_Ausgabe inline?

Was ist mit den G und B Werten? Werden die hintereinander
ausgegeben? Oder müssen die zur gleichen Zeit raus?

[Jan (Gast)]

Simon Budig schrieb:
> Das riecht nach WS2811/WS2812?

Genau darum geht es ;)

Hier mal der Code der L_High Funktion:
void L_High()
{
  PORTC |= 0b00000001;
  asm volatile ("nop");
  asm volatile ("nop");
  asm volatile ("nop");
  asm volatile ("nop");

  PORTC &=~ 0b00000001;
  asm volatile ("nop");
  asm volatile ("nop");
}

Mir ist bewusst das dass mit dem "asm volatile ("nop");" nicht das gelbe 
vom Ei ist allerdings funktioniert es vom Prinzip her.

Im Anhang nochmal zwei Bilder.
Bild 1 ist mit dem Code von  Peter II mit übergebenen RGB Werten (Timigs 
stimmen nicht).
Bild 2 ist auch mit dem selben Code allerdings mit Konstaten Werten 
(hier funktioniert alles)

[Ralph (Gast)]

Exakte Bit Timinigs über Software stabil hinzubekommen ist extrem 
schwierig.

Da darf es nicht mal einen Interrupt geben, sonst passt das schon nicht 
mehr.

Wenn du das weiterhin per SW machen willst solltest du den µC controller 
wechseln.
Ist diese Frequenz mit 1.25µS Bit Takt gesetzt, dann solltest du einen 
µC mit so rund 80 MHz anpeilen um da hinzukommen. Also ein Cortex M oder 
sowas in die Richtung.

Ich würde allerdings eher eine HW Lösung hier sehen.
3 Schieberegister mit Latch mit gemeinsamen BitTakt. Nach jeweils 8 Bit 
legst du das Byte als ganzes ins Schieberegister, und von dort wird es 
Bitweise raus geschoben.

[Jan (Gast)]

Ja eine Hardwarelösung wäre mir auch am liebsten.

Im Anhang ist ein Bild wie die Ausgangssignale aussehen müssen.
Ich habe leider keinen Ansatz oder auch nur eine Idee wie ich das mit 
Schieberegistern realisieren soll.

Gibts da eventuell ein Link wo soetwas erklärt ist ?

MfG.

[Helfender (Gast)]

Geht es vielleicht mit SPI?
CLK mit 4 MHz, jeweils 8 Bits einfüllen alle 500 kHz.
Wenn der uC eine FIFO hat,
dann vielleicht sogar x mal 8 Bits auf einmal.
Für eine zu sendende 0 oder 1 werden 10 Bits benötigt.
Für eine zu sendende 0: 2 x H, 8 x L
Für eine zu sendende 1: 5 x H, 5 x L
Die SPI Hardware sorgt dann dafür, dass die Bits zur richtigen Zeit
gesendet werden.

[Tim . (cpldcpu)]

Hi,

man kann das Timing auch bei 8Mhz relativ genau hinbekommen. Allerdings 
hat mit für das High-speed Protokoll des WS2811/2812 nur 3 bis 5 
Taktzyklen Zeit, das Signal auf hi und low zu setzen. Mit ein wenig 
inline-Assembler ist das kein unlösbares Problem. Wie schon woanders 
gepostet (Beitrag "Lightweight WS2811/WS2812 Library"), setzte ich mich 
auch gerade mit diesem Problem auseinander.

Mir ist dabei aufgefallen, dass der AVR-GCC teilweise wenig 
nachvollziehbare Optimierungen macht. z.B. wird für unterschiedliche 
AVRs ohne verständliche Gründe ganz anderer Code erzeugt, der mehr oder 
weniger Taktzyklen benötigt.

[Tim . (cpldcpu)]

Helfender schrieb:
> Geht es vielleicht mit SPI?

Im Forus gibt es eine Lösung mit PWM: 
Beitrag "AVR ASM ws2811 / ws2812 Ansteuerung mit FastPWM". Diese funktioniert aber 
wohl nur mit 16Mhz.

Wie Markus in seiner Dokumentation schreibt, benötigt diese Lösung auf 
den kleineren AVR aber trotzdem 100% der CPU Zeit und benötigt 
zusätzliche noch peripherie. Eine Bitbang-Lösung ist daher wohl 
einfacher. Auf XMEGA sieht es wohl anders aus.

[Ralph (Gast)]

Jan schrieb:
> L_High(); //Gibt ein logisches high-Bit aus
> L_Low(); ////Gibt ein logisches low-Bit aus

Was machst du denn in den beiden Funktionen ?

Ich gehen mal davon aus das deine Übertragung so nicht funktionieren 
wird.
Das Interface des Chip ist ein PWM interface.

Das heißt du brauchst einen festen Datentakt von 400 KHz.
Die Information wird dann über den dutycycle übertragen.
Die "0" hat dabei den dutycycle 20 %  ( 0,5µs highphase)
Die "1" hat dabei den dutycycle ~50 % ( 1,2µs highpahse)

Mit anderen Worten du hast für die "0" genau 0,5 µs +- 150ns Zeit 
zwischen Pin auf High und Pin auf Low.

Also ich kenne da nur eine µc Familie die sowas packt. Das sind die TMS 
570 von TI, und zwar die Varianten die den HET ( HighEndTimer) Baustein 
drin haben. HET ist ein Programmierbarer Timer der unabhängig vom µC 
Core arbeitet und das mit einer Auflösung bis über 60 MHz.
Die Datenausgabe würde dann über diesen HET laufen.

Helfender schrieb:
> Geht es vielleicht mit SPI?

Nein geht nicht, da man bei SPI den Dutycycle nicht manipulieren kann.

[Tim . (cpldcpu)]

>Also ich kenne da nur eine µc Familie die sowas packt. Das sind die TMS
>570 von TI, und zwar die Varianten die den HET ( HighEndTimer) Baustein
>drin haben.

>Wenn du das weiterhin per SW machen willst solltest du den µC controller
>wechseln. Ist diese Frequenz mit 1.25µS Bit Takt gesetzt, dann solltest du
>einen µC mit so rund 80 MHz anpeilen um da hinzukommen. Also ein Cortex M
>oder sowas in die Richtung.

Und ich dachte immer das Microntroller die letzte Bastion der 
laufzeitoptimierten Software wären? Das klingt mir doch sehr nach einer 
"PC" Lösung... :)

[Jan (Gast)]

Ralph schrieb:
> Helfender schrieb:
>> Geht es vielleicht mit SPI?
>
> Nein geht nicht, da man bei SPI den Dutycycle nicht manipulieren kann.

Doch mittels SPI klappt es ;)
Man kann einfach z.B 3 Einsen (750us)gefolgt von 2 Nullen 
(500us)ausgeben um die logische 1 darzustellen.

Dafür muss die SPI Frequenz 4Mhz betragen, ist also mit meinen 8Mhz 
Prozessortakt möglich.

MfG.

[amateur (Gast)]

Hast Du mal folgendes probiert?

// für low --> high
tmp = 1;

for (i=0;i<8;i++)
{
  if ( G & tmp )
   L_High();
  else
   L_Low();
  tmp = tmp << 1;
}

// oder für high --> low
tmp = 128;

for (i=0;i<8;i++)
{
  if ( G & tmp )
   L_High();
  else
   L_Low();
  tmp = tmp >> 1;
}

Ist nicht so viel geschubse. Du kannst tmp auch für die anderen Dinger 
benutzen. Also eine "Große" Schleife und nur am Ende Schiebung.

[Ralph (Gast)]

Jan schrieb:
> Man kann einfach z.B 3 Einsen (750us)gefolgt von 2 Nullen
> (500us)ausgeben um die logische 1 darzustellen.

Nein passt nicht.
"0" ist 2µs zu 0.5µs :
Also brauchst du 10 Bit ; 2 Bit High dann 8 Bit Low
"1" ist 1,2 µs zu 1,3 µsec
Dann brauchst du 5 Bit high, dann 5 Bit Low

Das Problem ist aber, das zwischen den Datenbits kein Abstand sein darf.
Also muss sofort nach der LowPhase das nächste Bit, der SPi Übertragung 
kommen, ohne Zeitversatz.
Ansonsten passt das Low timing nicht, eventuell gibt es auch ein Reset 
des Interface.

Aber stimmt soweit, das SPI dürfte die einzige Chance sein das mit einem 
8 MHz µC hinzubekommen.

Die Frage ist nur was der  µC nebenbei noch machen kann wenn die SPI in 
dem Tempo nachgeladen werden muss.

Es bring ja auch nichts wenn der µC mit dem Treiben der LED's schon zu 
100 % ausgelastet ist.
Das hat man dann zwar geschafft, aber im Endeffekt auch nichts gekonnt.

[Tim . (cpldcpu)]

>Es bring ja auch nichts wenn der µC mit dem Treiben der LED's schon zu
>100 % ausgelastet ist.
>Das hat man dann zwar geschafft, aber im Endeffekt auch nichts gekonnt.

Die LEDs halten den Status bis zum nächsten Update. Wenn man z.B. nur 
mit 30Hz updated hat die CPU noch eine Menge "Freizeit", je nach anzahl 
der LEDs im String.

[Fallobst (Gast)]

Ralph schrieb:
> Aber stimmt soweit, das SPI dürfte die einzige Chance sein das mit einem
> 8 MHz µC hinzubekommen.

In Assembler ist das mit 8 Mhz ein Klacks. Da dürfte das sogar mit 4 Mhz 
funktionieren.

[Tim . (cpldcpu)]

>Da dürfte das sogar mit 4 Mhz  funktionieren.

Zeigen!

[Besserwisser (Gast)]

Einige Tips:

>  while (datlen--) {
besser: while (--len), da er das Zero-Flag direkt (=ohne einen Compare) 
auswerten kann. Len muss vorher um eins korrigiert werden.


Bei der Loop: der Counter kann entfallen, wenn die Mask mit dafür 
verwendet wird:

mask=0x80;
do {if (data & mask) Pin = low; else Pin = high;} while((mask>>=1)!=0);

Ich würde aber tatsächlich Unrolling machen:
  if(data&0x80) Pin = low; else Pin = high;
  if(data&0x40) Pin = low; else Pin = high;
  if(data&0x20) Pin = low; else Pin = high;
  if(data&0x10) Pin = low; else Pin = high;
  if(data&0x08) Pin = low; else Pin = high;
  if(data&0x04) Pin = low; else Pin = high;
  if(data&0x02) Pin = low; else Pin = high;
  if(data&0x01) Pin = low; else Pin = high;

[Besserwisser (Gast)]

high und low sind vertauscht, richtig ist:
mask=0x80;
do {if (data & mask) Pin = high; else Pin = low;} while((mask>>=1)!=0);

Ich würde aber tatsächlich Unrolling machen:
  if(data&0x80) Pin = high; else Pin = low;
  if(data&0x40) Pin = high; else Pin = low;
  if(data&0x20) Pin = high; else Pin = low;
  if(data&0x10) Pin = high; else Pin = low;
  if(data&0x08) Pin = high; else Pin = low;
  if(data&0x04) Pin = high; else Pin = low;
  if(data&0x02) Pin = high; else Pin = low;
  if(data&0x01) Pin = high; else Pin = low;

[Tim . (cpldcpu)]

Ok, ich habe mich doch selbst daran gewagt - und siehe da, es 
funktioniert auch mit 4Mhz auf einem ATtiny 10! Allerdings weicht das 
Timing deutlich von der Spezifikation ab. Ob das unter kritischeren 
Bedinungen auch noch zuverlässig funktioniert, wage ich anzuzweifeln.

/*
  Timing optimized for 4Mhz tinyAVR with reduced core.
  (ATtiny 4/5/9/10/20/40)

  2013/08/14 - [e-mail]
  
  The main difference is a reduced instruction timing for cbi and sbi 
  with 1 cycle instead of 2 for normal AVR.

  The total length of each bit is 1.25µs (5 cycles @ 4Mhz)
  * At 0µs the dataline is pulled high.  (cycle 0+1)
  * To send a zero the dataline is pulled low after 0.5µs (spec: 0.375µs)  (2+1=3 cycles).
  * To send a one the dataline is pulled low after 0.75µs  (spec: 0.5µs) (3+1=4 cycles).

  The timing of this implementation is significantly off, however it seems to 
  work empirically. Not recommended for actual use.
  
  Final timing: 
  * 8 cycles for bits 7-1
  * 13 cycles for bit 0    
*/


void ws2812_sendarray_4Mhz_rc(uint8_t *data,uint16_t datlen)
{
  uint8_t curbyte,ctr;
  
  if (!datlen) return;
  
    asm volatile(
    "olop%=:ld  %1,Z+    \n\t"      
    "    ldi  %0,8       \n\t"    
    
    "ilop%=:             \n\t"    
    "    sbi  %2,  %3    \n\t"    // 1    
    "    sbrs %1,7       \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3                    
    "    cbi  %2,  %3    \n\t"    // 4
    "    lsl  %1         \n\t"    // 5
    "    dec  %0         \n\t"    // 6
  
    "    brne ilop%=     \n\t"    // 8

    "    dec %5          \n\t"    
    "    brne olop%=     \n\t"    
    
    :  "=&d" (ctr), "=&d" (curbyte)
    :   "I" (ws2812_port), "I" (ws2812_pin), "z" (data), "r" (datlen)
    );    
}

[Tim . (cpldcpu)]

Ok, mit loop unrolling geht es bei 4Mhz auch mit korrektem Timing. Die 
Frage ist nur: Warum sollte man den AVR mit 4Mhz betreiben? :)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Tim .  schrieb:
> Die Frage ist nur: Warum sollte man den AVR mit 4Mhz betreiben? :)
Wenn ich mal den Smiley geflissentlich übersehe, dann fallen mir 2 
Antworten ein:
1. Wegen der geringeren Stromaufnahme
2. Evtl. ist die Versorgungsspannung nur 1,8V

[Oliver (Gast)]

Besserwisser schrieb:
> Einige Tips:
>>  while (datlen--) {
> besser: while (--len), da er das Zero-Flag direkt (=ohne einen Compare)
> auswerten kann. Len muss vorher um eins korrigiert werden.

Ein besserer Tip:
Optimierungen aus der Computersteinzeit, aus "urban legends" , "ham wer 
immer schon so gemacht" oder "ich hab da mal was gehört" einfach sein 
lassen, statt dessen den erzeugten Assemblercode anschauen und danach 
entscheiden.

Die Zeiten der seligen Z80, 6502 etc. sind lange vorbei, und aktuelle 
C-Compiler optimieren so etwas durchaus zuverlässig.

Abgesehen davon wäre der Tip sowieso Unsinn, da in beiden Fällen auf 0 
geprüft wird, was ja angeblich dank Zero-Flag scheller gehen soll..

Oliver

[Peter D. (peda)]

Simon Budig schrieb:
> Du musst da hand-getuneden Assembler hernehmen, wenn Du
> wissen willst dass das Timing funktioniert. Und selbst dann wird es
> extrem knifflig.

Nö.

Nimm einfach einen neueren AVR (ATmega88) mit UART im SPI-Mode. Durch 
den Sende-Puffer kann man beliebige Datenmuster lückenlos ausgeben.

[Tim . (cpldcpu)]

Lothar Miller schrieb:
> Tim .  schrieb:
>> Die Frage ist nur: Warum sollte man den AVR mit 4Mhz betreiben? :)
> Wenn ich mal den Smiley geflissentlich übersehe, dann fallen mir 2
> Antworten ein:
> 1. Wegen der geringeren Stromaufnahme
> 2. Evtl. ist die Versorgungsspannung nur 1,8V

Ja, nur was hilft einem das, wenn man den AVR nutzt um damit RGB-Leds 
anzusteuern, die mit 5V betrieben werden und pro Stück bis zu 60mA 
ziehen?

Allgemein hast Du natürlich recht...

[Tim . (cpldcpu)]

Besserwisser schrieb:
> Einige Tips:
>
>>  while (datlen--) {
> besser: while (--len), da er das Zero-Flag direkt (=ohne einen Compare)
> auswerten kann. Len muss vorher um eins korrigiert werden.
>

Probiere das 'mal mit AVR-GCC aus. Du wirst Dich wundern..

[Fallobst (Gast)]

Tim .  schrieb:
> Ok, mit loop unrolling geht es bei 4Mhz auch mit korrektem Timing.

Es geht auch ohne - auch wenn es ein bisschen knifflig wurde. Besonders 
der Trick mit dem ori, welches den Zähler zurücksetzt, gleichzeitig das 
Zero-Flag löscht und kein Einfluss auf das Carry-Flag nimmt, war nicht 
leicht zu finden.

void ws2812_sendarray_4Mhz(uint8_t *ptr, uint16_t len)
{  
  if (!len) 
    return;
    
  uint8_t lo_pin = WS2812_PIN;
  uint8_t hi_pin = lo_pin;
  lo_pin &= ~(1<<WS2812_PIN_NUM);
  hi_pin |= 1<<WS2812_PIN_NUM;
  
  uint16_t end_ptr = (uint16_t)ptr + len;
  
  uint8_t bit_counter = 7;
  
  asm volatile(
    "  ld __tmp_reg__, %a[ptr]+ \n\t"
    "  rjmp start               \n\t"
    "loop:                      \n\t"
    "  out %[PORT], %[lo_pin]   \n\t"
    "  lsl __tmp_reg__          \n\t"
    "  cp %A[ptr], %A[end_ptr]  \n\t"
    "  cpc %B[ptr], %B[end_ptr] \n\t"
    "  dec %[bit_counter]       \n\t"
    "start:                     \n\t"
    "  out %[PORT], %[hi_pin]   \n\t"
    "  sbrs __tmp_reg__, 7      \n\t"
    "  out %[PORT], %[lo_pin]   \n\t"
    "  brne loop                \n\t"
    "  ori %[bit_counter], 7    \n\t"
    "  out %[PORT], %[lo_pin]   \n\t"
    "  ld __tmp_reg__, %a[ptr]+ \n\t"
    "  brlo start               \n\t"
  
  :  [bit_counter] "+d" (bit_counter)
  : [lo_pin] "r" (lo_pin), [hi_pin] "r" (hi_pin), [ptr] "e" (ptr), [end_ptr] "r" (end_ptr), [PORT] "M" (_SFR_IO_ADDR (WS2812_PORT))
  );
}

Wenn in dem Code nun kein Fehler steckt, kann man mit ihm bis zu 2^16-1 
Bytes schicken. Ich habe es nur im Simulator testen können, da ich diese 
Leds nicht besitze.

[Tim . (cpldcpu)]

Hi "fallobst",

Du hast die Herausforderung angenommen - super! :) Die Tricks gefallen 
mir sehr gut. Ich habe den code ausprobiert. Leider blieb die LED 
schwarz

Bei der Durchsicht des Codes sind mir zwei Sachen aufgefallen:

* Die Schleife benötigt 10 Zyklen. Bei 4Mhz sind nur 5 erlaubt. 
Insbesondere ist das timing für die "1" zu lang. (Mein Beispiel war für 
einen Attiny10, auf dem CBI/SBI nur 1 zyklus benötigen)
* Das Z-Flag ist am Anfang in einem undefinierten Zustand, daher ist die 
Ausführung des ersten "BRNE loop" zufällig.

CLZ eingefügt -> und siehe da, es läuft. Obwohl das Timing etwas daneben 
liegt, scheint es immer noch zu funktionieren.

[Fallobst (Gast)]

Tim .  schrieb:
> * Die Schleife benötigt 10 Zyklen. Bei 4Mhz sind nur 5 erlaubt.
Stimmt. Mir ist erst jetzt aufgefallen, dass die angehängte Tabelle nur 
Low-Speed zeigt. Daher dürfte mein Code die Spezifikationen bei 8 Mhz 
einhalten. Bei 4 Mhz dürfte das wirklich nur mit ausgerollten Schleifen 
zu schaffen sein.
> Insbesondere ist das timing für die "1" zu lang. (Mein Beispiel war für
> einen Attiny10, auf dem CBI/SBI nur 1 zyklus benötigen)
-> out benötigt auch nur einen Zyklus.

> * Das Z-Flag ist am Anfang in einem undefinierten Zustand, daher ist die
> Ausführung des ersten "BRNE loop" zufällig.
> CLZ eingefügt -> und siehe da, es läuft. Obwohl das Timing etwas daneben
> liegt, scheint es immer noch zu funktionieren.

Das habe ich tatsächlich vergessen, danke.

void ws2812_sendarray_8Mhz(uint8_t *ptr, uint16_t len)
{  
  if (!len) 
    return;
    
  uint8_t lo_pin = WS2812_PIN;
  uint8_t hi_pin = lo_pin;
  lo_pin &= ~(1<<WS2812_PIN_NUM);
  hi_pin |= 1<<WS2812_PIN_NUM;
  
  uint16_t end_ptr = (uint16_t)ptr + len;
  
  uint8_t bit_counter = 8;
  
  asm volatile(
    "  ld __tmp_reg__, %a[ptr]+ \n\t"
    "  rjmp init                \n\t"
    "loop:                      \n\t"
    "  out %[PORT], %[lo_pin]   \n\t"
    "  lsl __tmp_reg__          \n\t"
    "  cp %A[ptr], %A[end_ptr]  \n\t"
    "  cpc %B[ptr], %B[end_ptr] \n\t"
    "init:            \n\t"
    "  dec %[bit_counter]       \n\t"
    "start:                     \n\t"
    "  out %[PORT], %[hi_pin]   \n\t"
    "  sbrs __tmp_reg__, 7      \n\t"
    "  out %[PORT], %[lo_pin]   \n\t"
    "  brne loop                \n\t"
    "  ori %[bit_counter], 7    \n\t"
    "  out %[PORT], %[lo_pin]   \n\t"
    "  ld __tmp_reg__, %a[ptr]+ \n\t"
    "  brlo start               \n\t"
  
  :  [bit_counter] "+d" (bit_counter)
  : [lo_pin] "r" (lo_pin), [hi_pin] "r" (hi_pin), [ptr] "e" (ptr), [end_ptr] "r" (end_ptr), [PORT] "M" (_SFR_IO_ADDR (WS2812_PORT))
  );
}

[Tim . (cpldcpu)]

Ach ja, hier der ausgerollte Code. Funktioniert nur auf den reduced core 
AVR, da SBI/CBI auf den "großen" AVRs 2 zyklen benötigt. Mit "out" würde 
es aber gehen.

/*
  Timing optimized for 4Mhz tinyAVR with reduced core.
  (ATtiny 4/5/9/10/20/40)
  
  2013/04/08 - [e-mail]
    
  The main difference is a reduced instruction timing for cbi and sbi 
  with 1 cycle instead of 2.

  The total length of each bit is 1.25µs (5 cycles @ 4Mhz)
  * At 0µs the dataline is pulled high.  (cycle 0+1)
  * To send a zero the dataline is pulled low after 0.5µs (spec: 0.375µs)  (2+1=3 cycles).
  * To send a one the dataline is pulled low after 0.75µs  (spec: 0.625µs) (3+1=4 cycles).

  The timing of this implementation is slightly off, however it seems to 
  work empirically. Not recommended for actual use.
  
  
  Final timing: 
  * 5 cycles for bits 7-1
  * 8 cycles for bit 0    
*/


void ws2812_sendarray_4Mhz_rc_unrolled(uint8_t *data,uint16_t datlen)
{
  uint8_t curbyte,ctr;
  
  if (!datlen) return;
  
    asm volatile(
    "olop%=:ld  %1,Z+    \n\t"      
    
    "ilop%=:        \n\t"    
    "    sbi  %2,  %3    \n\t"    // 1    
    "    sbrs %1,7    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3                    
    "    cbi  %2,  %3    \n\t"    // 4
    "    nop        \n\t"    // 5
    
    "    sbi  %2,  %3    \n\t"    // 1
    "    sbrs %1,6    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3
    "    cbi  %2,  %3    \n\t"    // 4
    "    nop        \n\t"    // 5

    "    sbi  %2,  %3    \n\t"    // 1
    "    sbrs %1,5    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3
    "    cbi  %2,  %3    \n\t"    // 4
    "    nop        \n\t"    // 5

    "    sbi  %2,  %3    \n\t"    // 1
    "    sbrs %1,4    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3
    "    cbi  %2,  %3    \n\t"    // 4
    "    nop        \n\t"    // 5

    "    sbi  %2,  %3    \n\t"    // 1
    "    sbrs %1,3    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3
    "    cbi  %2,  %3    \n\t"    // 4
    "    nop        \n\t"    // 5

    "    sbi  %2,  %3    \n\t"    // 1
    "    sbrs %1,2    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3
    "    cbi  %2,  %3    \n\t"    // 4
    "    nop        \n\t"    // 5

    "    sbi  %2,  %3    \n\t"    // 1
    "    sbrs %1,1    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3
    "    cbi  %2,  %3    \n\t"    // 4
    "    dec %5      \n\t"    // 5

    "    sbi  %2,  %3    \n\t"    // 1
    "    sbrs %1,0    \n\t"    // 2
    "    cbi  %2,  %3    \n\t"    // 3
    "    cbi  %2,  %3    \n\t"    // 4

    "    brne olop%=    \n\t"    // 6
    
    :  "=&d" (ctr), "=&d" (curbyte)
    :   "I" (ws2812_port), "I" (ws2812_pin), "z" (data), "r" (datlen)
    );    
}