<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
  <channel>
    <title>Alan's Ramblings - Responses</title>
    <link>http://bleaklow.com:80/</link>
    <description>My opinions may be incorrect, but they are my own</description>
    <language>en</language>
    <copyright>Alan Burlison</copyright>
    <pubDate>Mon, 29 Apr 2013 08:31:47 GMT</pubDate>
    <dc:creator>Alan Burlison</dc:creator>
    <dc:date>2013-04-29T08:31:47Z</dc:date>
    <dc:language>en</dc:language>
    <dc:rights>Alan Burlison</dc:rights>
    <image>
      <title>Alan's Ramblings</title>
      <url>http://bleaklow.com:80/</url>
    </image>
    <item>
      <title>Re: Driving the WS2811 at 800KHz with a 16MHz AVR</title>
      <link>http://bleaklow.com:80/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html#comment1367224307502</link>
      <content:encoded>&lt;p&gt;So are we now agreeing that the critical timing is about seeing that the signal is stable high or low at roughly 625 ns after the rising edge (ie: having it fall and stay low long enough before that, or stay long long enough after that, to cover error margins)? &amp;nbsp;In which case the overall cycle is not as important. &amp;nbsp; We can't shrink it too much, but it has some room for being stretched.&lt;/p&gt;
&lt;p&gt;Of course the trace of the output from a 2811 will have a precise 1250ns cycle time if the input into it has that cycle time - the chip is going to have the same output bit cycle length since it doesn't buffer the bitstream and retime the bit rate on output - all it can do to reshape &amp;amp; clean the output is to change the timing of the falling edge it sends to the next pixel, within each bit cycle. &amp;nbsp;The length of the reshaped high pulses is more of a clue, albeit a sloppy one (since it too is subject to variation).&lt;/p&gt;
&lt;p&gt;Some people are using SPI inverted to drive these. &amp;nbsp;Since the AVR's SPI inserts at least a couple clock's worth of idle time (high) between bytes, after inversion this just stretches the &amp;quot;low&amp;quot; time (and thus the bit cycle time) before the next rising edge, which isn't as critical. &amp;nbsp;&lt;/p&gt;
&lt;p&gt;What does this mean? &amp;nbsp;Sometimes being able to insert a cycle or two here or there can be handy - eg: reducing the need to exactly balance branch times.&lt;/p&gt;
&lt;p&gt;We can even insert time for a short ISR between bits, stretching the low time before the nest rising edge &amp;nbsp;(I don't know if it matters whether the stretched bit cycle is between pixels, between bytes in a pixel, or within a byte).&lt;/p&gt;
&lt;p&gt;Some believe that 10 us is safe, but not much more. &amp;nbsp;It's going to depend on the batch, the temperature, etc.&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;</content:encoded>
      <pubDate>Mon, 29 Apr 2013 08:31:47 GMT</pubDate>
      <guid isPermaLink="false">tag:bleaklow.com,2012-12-02:default/c/1354481520000/1367224307502</guid>
      <dc:date>2013-04-29T08:31:47Z</dc:date>
    </item>
    <item>
      <title>Re: Driving the WS2811 at 800KHz with a 16MHz AVR</title>
      <link>http://bleaklow.com:80/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html#comment1367096573591</link>
      <content:encoded>&lt;p&gt;&amp;nbsp;The first version of the library does - i've dropped support for the lpd6803's in subsequent versions of the library however. &amp;nbsp;The problem with the 6803's isn't going to be anything that you can achieve at a code level. &amp;nbsp;It uses SPI for pushing data out to it, and even the most optmized bitbanging is still not going to match or beatthe fastest hardware SPI speeds (though, i've gotten really really close on avr - but on arm on the teensy 3, i'm capping out at about 4.5Mbit for bit-bang'd SPI and over 22Mbit for hardware SPI). &amp;nbsp;The problem with the 6803's however is that they don't have anything onboard to drive the pwm, unlike just about everything from the ws2801's and on. &amp;nbsp;Which means I needed to have a timer function that ran in the background that continuously strobed the clock line to &amp;quot;drive&amp;quot; the pwm. &amp;nbsp;To add insult to injury, if I just blasted all the data out to the 6803's, the clock would run really fast for that block of time, then slower for the rest of time time which resulted in this really really annoying pulsing effect. &amp;nbsp;I'm not terribly interested in continuing to support things that require a running clock in the background in the future. &amp;nbsp;&lt;/p&gt;
&lt;p&gt;There is a chance I'll be able to continue supporting the 6803's on the teensy 3 - as the spi system there has an option to run the clock line continuously in the background. &amp;nbsp;I'm going back and forth on whether or not to do this, however.&lt;/p&gt;
&lt;p&gt;I really wish the 6803's would just die off, already. &amp;nbsp;&lt;/p&gt;</content:encoded>
      <pubDate>Sat, 27 Apr 2013 21:02:53 GMT</pubDate>
      <guid isPermaLink="false">tag:bleaklow.com,2012-12-02:default/c/1354481520000/1367096573591</guid>
      <dc:date>2013-04-27T21:02:53Z</dc:date>
    </item>
    <item>
      <title>Re: Driving the WS2811 at 800KHz with a 16MHz AVR</title>
      <link>http://bleaklow.com:80/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html#comment1367093710103</link>
      <content:encoded>&lt;p&gt;I believe the &lt;a href="http://code.google.com/p/fastspi/"&gt;FastSPI&lt;/a&gt; library supports the LPD6803, I suggest you use that.&lt;/p&gt;</content:encoded>
      <pubDate>Sat, 27 Apr 2013 20:15:10 GMT</pubDate>
      <guid isPermaLink="false">tag:bleaklow.com,2012-12-02:default/c/1354481520000/1367093710103</guid>
      <dc:date>2013-04-27T20:15:10Z</dc:date>
    </item>
    <item>
      <title>Re: Driving the WS2811 at 800KHz with a 16MHz AVR</title>
      <link>http://bleaklow.com:80/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html#comment1366795692547</link>
      <content:encoded>&lt;p&gt;Hi Alan&lt;/p&gt;
&lt;p&gt;I&amp;nbsp;used your code to drive a 40-pixel WS2811 string on an Arduino Uno and it works perfectly. No flicker or anything! Whilst I&amp;nbsp;can program to an acceptable level in C/C++ my skills with assembler hover about the zero mark. I&amp;nbsp;have another bunch of LEDs which use the not-so-good LPD6803. Whilst the C I've written is as good as I can get it, it obviously wouldn't be as fast as hand-coded assembler, is there anything you could do to help? Quite happy to bribe you with beer money if that helps!&lt;/p&gt;
&lt;p&gt;Cheers&lt;/p&gt;
&lt;p&gt;Tim&lt;/p&gt;</content:encoded>
      <pubDate>Wed, 24 Apr 2013 09:28:12 GMT</pubDate>
      <guid isPermaLink="false">tag:bleaklow.com,2012-12-02:default/c/1354481520000/1366795692547</guid>
      <dc:date>2013-04-24T09:28:12Z</dc:date>
    </item>
    <item>
      <title>Re: Driving the WS2811 at 800KHz with a 16MHz AVR</title>
      <link>http://bleaklow.com:80/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html#comment1366540705511</link>
      <content:encoded>&lt;p&gt;&amp;nbsp;Also, since you know the timing of each cycle of the loop, at the end of writing a chain of led data out you could adjust the timer info to line itself back up.&lt;/p&gt;</content:encoded>
      <pubDate>Sun, 21 Apr 2013 10:38:25 GMT</pubDate>
      <guid isPermaLink="false">tag:bleaklow.com,2012-12-02:default/c/1354481520000/1366540705511</guid>
      <dc:date>2013-04-21T10:38:25Z</dc:date>
    </item>
  </channel>
</rss>

