AVR Freaks

OK so I had to give that a go:

D:\c>type lcd.c
#include <stdio.h>

char text[17] = "Hello Good World";
char c;

int main(void)  {
        int i, n;
        for (n = 0; n < 16; n++) {
                printf("%s\n", text);
                // do the string shuffle
                c = text[0]; // take copy of the left most character
                // shuffle all the others one place to the left
                for (i = 0; i < 16; i++) {
                        text[i] = text[i + 1];
                }
                // put the saved character on the end
                text[15] = c;
                // just in case it's disturbed
                text[16] = 0; // end of string marker
        }
}
D:\c>cl lcd.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

lcd.c
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:lcd.exe
lcd.obj

D:\c>lcd
Hello Good World
ello Good WorldH
llo Good WorldHe
lo Good WorldHel
o Good WorldHell
 Good WorldHello
Good WorldHello
ood WorldHello G
od WorldHello Go
d WorldHello Goo
 WorldHello Good
WorldHello Good
orldHello Good W
rldHello Good Wo
ldHello Good Wor
dHello Good Worl

D:\c>

I believe that if these strings had all been printed at the same place on an LCD (with a delay after each to give a chance for it to be seen) this would have given the impression of scrolling.

 

For completeness here's the "other" version going in the opposite direction:

D:\c>type lcd.c
#include <stdio.h>

char text[17] = "Hello Good World";
char c;

int main(void)  {
        int i, n;
        for (n = 0; n < 16; n++) {
                printf("%s\n", text);
                // do the string shuffle
                c = text[15]; // take copy of the right most character
                // shuffle all the others one place to the right
                for (i = 15; i > 0; i--) {
                        text[i] = text[i - 1];
                }
                // put the saved character at the start
                text[0] = c;
                // just in case it's disturbed
                text[16] = 0; // end of string marker
        }
}
D:\c>lcd
Hello Good World
dHello Good Worl
ldHello Good Wor
rldHello Good Wo
orldHello Good W
WorldHello Good
 WorldHello Good
d WorldHello Goo
od WorldHello Go
ood WorldHello G
Good WorldHello
 Good WorldHello
o Good WorldHell
lo Good WorldHel
llo Good WorldHe
ello Good WorldH

As this demonstrates it is ASTRONOMICALLY easier to prototype this kind of thing in a PC program - when you have the mechanism worked out only THEN move to your AVR+LCD (and a few tweaks as printf() no longer works)

I don't think the OP even took notice of Cliff's work.  Not even an acknowledgement, comment, or thanks was offered. :\

The "solution" appears to be a new homework assignment to me, with no apparent connection to any scrolling.

To a certain extent I write replies to broaden my own understanding (never done the LCD shuffle thing before!) so I don't actually care too much if no one listens anyway :-)

That's because the "project" has to build (and then link together) both experiment-1.c and lcd.c (or whatever the file that contains your LCD functions is called). If you are using a "makefile" then add the LCD source file to the list of sources.

Time for a split, then!

Oh dear God no.

I calculate about 920us for updating my ring of 24 LEDs (at four bytes per - it's an GRBW ring).  Not quite 2,930us.

I was calculating based on 96 GRB LEDs, rather than 96 bytes (24 GRBW LEDs), but the arithmetic is the same.

 

Since you're talking GRBW, I assume that means the SK6812 or similar.  Some are RGBW, not GRBW, but other than the colour order the specs are the same.  That's 32 bits per LED, and the bit times are spec'd at a nominal 1.25 us, so one LED takes 40 us to update.  With 24 LEDs, that's 960 us, plus the 80 us nominal reset pulse for a total of 1040 us.  So I still don't see how 48 us kills you given that the update bitstream takes 20 times that long to send, even though there is a quite a bit of tolerance for the bit times.

 

While bitbanging the stream to the LEDs timing precision is important.

Not nearly as important as you think.  The critical parameter is T0H, which is spec'd at 200ns-500ns for both the WS2812, and the newer WS2812B.  There is far greater latitude in T0L, T1H, and T1L.  The SK6812 specs 150ns-450ns, and I expect it has similarly flexible timings.

 

Have a look at:

https://www.avrfreaks.net/forum/how-generate-pulse-under-1us?page=all

 

I've found that for GRB/RGB you can stretch the bit times all the way to 7125 ns, far longer than the nominal 1250 ns.  The only real (as opposed to spec'd) timing values are that T0H be less than about 500 ns, and that T1H be greater than about 500 ns.  As long as T0H+T0L and T1H+T1L is between about 1000 ns and 7125 ns, it will work, although T1L likely has a simlar constraint to T0H.  Low times longer than about 8625 ns are seen as a reset.

 

PS - In a way you've defeated your own argument there.

So why should I muck about for 48us moving memory around if I can rewrite the chips in 9us?  S.

How did you arrive at that conclusion?  It is only the reset pulse which has a real threshold of about 9us, rather than the 50 us quoted in the datasheet.  You cannot update the LED in 9us.

 

The 'update' consists of sending new values for the RGB (or GRB, RGBW, or GRBW, depending on the part) bitstream.  Once received, that value is buffered internally.  The reset serves only to latch those values to the PWM drivers.  Were you to send an unending bitstream i.e. no reset pulse, the LEDs would receive and buffer the new values, but would not update their PWM outputs to match.  It is the reset pulse which is used to trigger a simultaneous PWM update across all connected LEDs (subject to the propagation delay between DI and DO of about 300 ns).

 

You seem to be arguing that you have to make your calculations within a 50 us window in order to meet spec, and that's simply not true.  You can update the LEDs at whichever rate you want, 1000 times per second (provided you have a small enough number of LEDs i.e. (1000us-50us) / 40us[GRBW] = 23 LEDs), or once per second, or once every 7 years.  You are not bound to a 50 us reset, except as a minimum (and the 50 spec is quite conservative).  It is not a maximum.

 

As I've mentioned, your 24 LEDs will take 1040 us to update (to spec... you can get away with a little bit faster, or quite a bit slower).  How is 48 us a deal-breaker?

 

This is now thoroughly OT, and we should continue this in another thread if you want.

 

 

And that, according to the spec, is 50us.

 Again, that's a >>minimum<<.  You are within spec if you take 51 us, or 9 ms, or 7 years.

 

as fast as I can

Updating an array of LEDs 1000 times a second is pointless.  Even if the PWM frequency of the LEDs was that high (for the SK6812 it's 1.2 kHz, but for most WS2812 varieties, it's 400 Hz or lower), you will never perceive updates that fast.

 

Even HFR video is only 48 fps.  Video games are quite happy at 60 or 70 fps.  Anything else is a complete waste of time and resources.  Let's be even more ambitious and say you want 100 Hz.  That means 10 ms updates.  You need a fraction over 1 ms for the bitstream to the LEDs, leaving you nearly 9 ms for your computations.  If you are so close to the edge that 48 us (representing 0.6% of available time) makes or breaks you, then I'd say you have lower-hanging fruit than a data moving loop.  At 8 MHz, 9 ms is 72,000 cpu cycles.  What on earth are you doing to 24 GRBW LEDs that could require that kind of juice?

Signalling to fast photosensors.  This is not entirely for human vision.  S.

An important point you failed to mention until now ;-)

 

Please elaborate.

I'm still reluctant to push them

As would I be, for a commercial product.  For one-offs and hobby projects, no problem.

 

The specs in the datasheet (indeed the datasheet as a whole) are a little hard to have faith in to begin with.  The authors can't seem get basic arithmetic right (see the tolerances for pulses and bit times... they don't add up).

 

In reality, these things very likely use a simple counter to decode the bitstream.  A rising edge resets a running counter, and the falling edge triggers a decode.  The value of the counter determines the value of the bit which has just been decoded.  Lower than a certain threshold, it's a zero.  At or above that threshold, it's a one.  A shift register clocks in 24 (32 for GRBW) decoded bits.  After the 24th bit, the DIN pin is routed to the DOUT pin for downstream LEDs.

 

An overflow on the counter triggers a reset, which latches the bits in the shift register to the PWM units, reinitialises the 24-bit shift register, and drives the DOUT pin low to propagate the reset signal to all downstream LEDs.

 

An interesting consequence of this design (if that is indeed how they're designed) is that a high pulse of the same length as a low pulse would still trigger a reset, because the counter will still overflow without a new rising edge to reset it.  This is in fact how the LEDs I've tested behave.  Sort of.  A long high pulse (>9us) causes DOUT to go low triggering a reset in all downstream LEDs, but does not cause the 1st LED to latch the shift register to the PWM units.