Hi Ming, The << operator is a *logical shift left*. See the wiki article here: http://en.wikipedia.org/wiki/Logical_shift
According to the MCP23017 datasheet, the I2C registers 0x12 and 0x13 control the outputs. There are 8 bits per register, so each bit controls a single output: if the bit is high (1), the output is also high, and the LED is on. What the example code does is loop through the range 0 to 7, and toggle one bit on at a time (to turn each output on in sequence). If you take a look at the wiki article for logical shifting, can you work out what happens when (for example), you set I2C address 0x12 to (1 << 5)? Best, Jon On Thu, Nov 15, 2012 at 3:38 PM, Ming kuo <[email protected]> wrote: > Thank you Tom, Jon, and Greg, > > I am grateful for all the help while I go through this challenge. > > Tom, I have previously responded to Jon and Greg privately trying to avoid > too many emails to the group. > > But yes, your tracking of my progress of the project is right, I basically > have proof of concept with hardware, circuits and now it is just the > software programming.. > > Following the code in the previously mentioned example, I am trying to > adapt it to working with the Bar LED.. > > I have isolated the critical piece of code is > > > > for x in range(0,8): > a = 1 << x > set_led(a,0) > time.sleep(delay) > set_led(0,0) > > > in code : set_led(x,y) x is the data and y is the bank. > > so I am confused on x or data piece of the parameter.. > > > > > in the above code set_led(a,0) > > *a= 1 << x what does this statement do?* > > > *and I tried just setting a to various numbers 1,2,3,4,5,6,7,8,9 and the led > seem to light up in no understandable pattern, sometimes individually and > sometimes multiple LEDs go on.. * > > > > So basically, once I get to know how to control the leds on the bar graph, > then I can start deciphering the code for letters and words > > > Thanks to the group > > > > Ming > > > > On Thu, Nov 15, 2012 at 2:36 PM, Tom Metro <[email protected]>wrote: > >> Ming kuo wrote: >> > Hi Guys, I was recently introduced to this group, so here is my first >> post. >> >> Welcome to the group. >> >> >> > I figured out the wiring to get the bar to light up using the same codes >> > as above. >> >> Sounds like you've got the hard part done. If you've gotten that much to >> work, then you've proven the hardware works, and the basic software >> works. Now you just need to tweak the behavior. >> >> >> > I am stuck...on the python code to control the I2C. >> > This is my immediate challenge to figure out how to program the >> > I2C for the LED bar... >> >> Can you clarify? >> >> You said above that you succeeded in getting the bar to light up using >> the same setup as the article you referenced. That implies you have a >> working I2C driver and some Python code using it. >> >> >> > ...I need to program a python code to POV display the messages which >> > i can imaging that it get pretty challenging given how to form a >> > character with LED while timing the rotation. >> >> So POV is persistence of vision? You're looking to build something like: >> http://www.youtube.com/watch?v=fJBYOU-Y-ZU >> >> How do you plan to move the display? >> >> To build on what Jon Evans said in his reply, it sounds like what you >> have left to do is less hardware hacking and more basic Python coding. >> Looking at the sample code: >> http://www.skpang.co.uk/blog/wp-content/uploads/2012/06/ledchaser.py >> >> they provide a set_led() function, so you'll need to remove the two >> chunks of code used to strobe the LEDs ("# Move led left " and "# Move >> led right") and replace them with your character generating code. >> >> Not trivial but given that POV displays seem to be popular, likely you >> can find some existing code for the character generator. If not, you'll >> need to dig up a library or lookup table that maps characters to dot >> patterns. Basically a dot matrix font. Then build a function that when >> given a character, translates that into the equivalent array of dots. >> >> I'd be inclined to use an architecture where rows of dots are pushed >> onto a stack, and then some background process is responsible for >> pulling a row from the stack and lighting up the LEDs on a steady clock >> rate. (I'm not sure if that's easy to accomplish in Python.) >> >> I'm guessing that with most of these POV displays, there isn't any real >> synchronization between the display motion and the strobing. The builder >> simply tunes the strobe rate until it works most of the time for >> whatever RPM their display ends up running at. >> >> >> > So any help through email or in person would be greatly appreciated. >> >> Post some follow up questions as you get stuck and we'll see what we can >> do. >> >> -Tom >> > > > _______________________________________________ > Hardwarehacking mailing list > [email protected] > http://lists.blu.org/mailman/listinfo/hardwarehacking > >
_______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
