Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Corey Kosak's Content

There have been 3 items by Corey Kosak (Search limited from 13-April 20)


By content type

See this member's

Sort by                Order  

#57286 SimpleNGen 1.4

Posted by Corey Kosak on 01 April 2014 - 11:19 PM in Project Showcase

Gosh, this would be fun to work on. I'm sorry to say that the real-world demands of my job have kept me away from Netduino hacking for a couple of years now. I wish I had a better answer for you :-(




#55121 Help understanding some C# for LED strip

Posted by Corey Kosak on 01 January 2014 - 11:42 PM in General Discussion

Care to post the exact link where you got the code?




#55116 Help understanding some C# for LED strip

Posted by Corey Kosak on 01 January 2014 - 09:21 PM in General Discussion

I think I can demystify some of this for you.

 

First (as another poster pointed out), this is integer division. In most languages, integer division always rounds down. For example, in real life 129/64 = 2.015625 but a computer doing integer division would round it down to exactly 2.

 

The question is, what can we do when we want "round up" behavior rather than "round down"? The standard trick is

 

replace

   numerator / denominator

with

  (numerator + (denominator-1)) / denominator

 

It has to be written this way because we want to add 1 except when the numerator is evenly divisible by the denominator.

 

Consider these examples in real life (using a calculator):

  • (127/64) = [font="helvetica, arial, sans-serif;"]1.984375, which rounds up to 2[/font]
  • (128/64) = 2 (exactly)
  • (129/64) = [font="helvetica, arial, sans-serif;"]2.015625, which rounds up to 3[/font]

Now let's imagine that we are only allowed to round down. Then:

  • [font="helvetica, arial, sans-serif;"](127+63)/64 = 2.96875, which rounds down to 2[/font]
  • [font="helvetica, arial, sans-serif;"](128+63)/64 = 2.984375, which rounds down to 2[/font]
  • [font="helvetica, arial, sans-serif;"](129+63)/64 = exactly 3, which rounds down to 3[/font]

[font="helvetica, arial, sans-serif;"]You can see that we get the same output (2, 2, 3) as we did in the "round up" case, but we were able to solve our problem using only "round down" operations.[/font]

 

You can try it on other cases and see that the substitution trick always gets you the same answer but you only need to ever round down, not up.

 

Now, as for why you want to round up. As you point out, your code fragment looks a little strange because it's all constants and you could have computed it yourself. Normally however this kind of thing appears in programs where one value (say, numLEDs) is a variable, not a constant. If you replace (most) of the occurrences of "32" with "numLEDs" in this program, you can see how this could be convenient.

 

Now as for your other questions:

  • The reason the high bit (0x80) is set on all the color bytes has to do with the protocol, which simply requires it
  • The reason line 13 exists is because the author is trying to write defensive code. The colors array occurs in groups of three. Line 18 sets the red component of each triple (which occur in any given triple at offset 0 of the triple). Line 17 sets the green component (which occurs at offset 1). But you'll notice that the blue component is not set inside the loop. Line 13 exists to make sure that any unset values have the default value of 0x80 (again, the protocol requires that the high bit be asserted in all of these bytes). This is probably overkill. If it were me, I'd probably delete line 13 and insert a new line in the inner for loop, namely:
    [color=rgb(0,0,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]colors[/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);][[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]i [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]*[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);] [/color][color=rgb(0,102,102);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]3[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);] [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]+[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);] [/color][font="monospace;font-size:13px;background-color:rgb(250,250,250);"]2[/font][color=rgb(102,102,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]][/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);] [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]=[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);] [/color][color=rgb(0,102,102);font-family:monospace;font-size:13px;background-color:rgb(250,250,250);]0x80; // put this before line 17[/color]

I'm not sure what source code you adapted this from, but the lengthy comments on top of https://github.com/a...ter/LPD8806.cpp pretty much explain why this is so, almost. (almost!)

 

In particular, there's this paragraph:

[color=rgb(153,153,136);font-style:italic;]Curiously, zero bytes can only travel one meter (32[/color]
[color=rgb(153,153,136);font-style:italic;]LEDs) down the line before needing backup; the next meter requires an[/color]
[color=rgb(153,153,136);font-style:italic;]extra zero byte, and so forth. [/color]

 

If the constants in the array involved "31 and 32" rather then "63 and 64", this would match the above explanation perfectly. In other words, given the number of LEDs we have, we need to compute how many "meters" of strip we have. As a result of the above explanation, I would have expected to see a line like this:

 

 

[color=rgb(0,0,136);font-family:monospace;font-size:13px;]var[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] zeros [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;]=[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][color=rgb(0,0,136);font-family:monospace;font-size:13px;]new[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][color=rgb(0,0,136);font-family:monospace;font-size:13px;]byte[/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;][[/color][color=rgb(0,102,102);font-family:monospace;font-size:13px;]3[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;]*[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;](([/color][font="monospace;font-size:13px;"]numLEDs[/font][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;]+[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][font="monospace;font-size:13px;"]31[/font][color=rgb(102,102,0);font-family:monospace;font-size:13px;])[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][color=rgb(102,102,0);font-family:monospace;font-size:13px;]/[/color][color=rgb(0,0,0);font-family:monospace;font-size:13px;] [/color][font="monospace;font-size:13px;"]32[/font][color=rgb(102,102,0);font-family:monospace;font-size:13px;])];[/color]

 

I can't explain why it's 63 and 64 rather than 31 and 32, but I hope the rest of this explanation helps.

 





home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.