Ok, I need someone with a more intimate relationship with the various PWM ICs

Ok, I need someone with a more intimate relationship with the various PWM ICs to possibly explain this to me. The POV code I’m using has an odd number delay in it:

  for (j=0; j < (sizeof(image1) / (sizeof(prog_uchar) * NUM_LEDS)); j++) {
    for (i=0; i <= NUM_LEDS; i++) {
      unsigned char cur = (uint32_t)(pgm_read_byte_near(&image1[i+j*NUM_LEDS]));
      unsigned char r = cur & Rmask;
      unsigned char g = (cur & Gmask) << 2;
      unsigned char b = (cur & Bmask) << 4;
      leds1[i].r = r;
      leds1[i].g = g;
      leds1[i].b = b;
    }
    LED1.showRGB((byte*)leds1, NUM_LEDS);
    memset(leds1, 0, sizeof(struct CRGB) * NUM_LEDS);
    _delay_us(STRETCH1);
  }

That _delay_us(STRETCH1) is what’s baffling to me. STRETCH1 is defines as 951, so it’s a delay of 951 micro seconds before it scans the next column of data and display it.

So my question here is: is it a) the required delay for a specific PWM IC? or b) is it for the refresh timing, in the hopes that a human eye won’t notice the PWM “dots”?

For example, the WS2801 needs a delay of 500uS (datasheet specific). So I’m wondering if whatever IC this was originally written for needed that odd number. The original code is pumping data out via ISP too by the way.

They were probably trying to achieve a very specific frame rate - and figured out that this delay time gave them the “right” amount of time between each frame.

Also - you can save some time if you don’t bother with the memset between the show and setting the next round of data, since you’re overwriting all the leds anyway :slight_smile:

For some reason, early on, I had an issue with it not resetting the string. It seems to be adding the values, as opposed to overwriting it. Not sure why. But you’re right, I should remove it now and save some cycles …