Propeller programming & timing question newbie

SteveW719 · 2011-02-21 11:17

In order to try and understand the timing relationships in the propeller I created a challenge project to work on. The cog software handling the LED refresh for an 8X8X8 RGB LED cube like you may have seen on youtube. 64 RGB LED per layer. LEDs driven by a string of 12 bit led drivers loaded with a serial shift & clk output. So we have 64 leds X 3 colors X 12 bits =2304 bits or 72 longs (each layer) . I will take as a given I can fit my PASM routine into memory along with space for the 72 longs it should be fairly straight forward. Some other cogs are formtting the data so it is ready to shift out as is. I will set my refresh rate at 62.5HZ which is 16 ms/8 layers = 2 ms per layer. Everything is based on an 80MHZ clock.

The first question for me was should I copy the 72 longs the cog and then blast it out at once or read one long shift it out then read another etc... It seemed to me most efficent to read the whole array as fast as I can then shift it as fast as I can. I have to lock out the other cogs from access so I am sure I read in one complete layer. If not it would be likely the other cogs would start writng a new frame before I finshed reading this one. This would be required either way I went and loading all longs into cog ram would free up the hub data array faster so the other cogs working on writing the data could access it.
Reading 72 longs X 22 clocks (worst case) = 1584 clks X 12.5 ns ?? =19.8 us to read the 72 longs. Shifting them out should be pretty fast so I would have plenty of time given my 2ms window.

Have I grasp this correctly or embarrased myself. Thanks for the help.

kuroneko · 2011-02-21 15:47

Up to you really. As long as the timing is right anything goes. I'd go for the single-long-read first as it may void your need for locking the frame.

MagIO2 · 2011-02-21 23:39

Well .... I would do it slightly different ;o)

You know as everywhere there is also a Yin and Yang of programming. If you waste more RAM you can gain in programming efford and vice versa.
So, in your case you currently only had a look at the "shift out bits"-task and used a straight forward approach: All the bits you want to shift out are kept in memory in a row - one bit after the other.

But if you have a look at the task of creating the data it might be a good idea to have the data in a different format. 1 word per color/pixel. Yes, you would waste 4 bits per color/pixel but the access to the data is much easier. Packing the data in a continuous stream means that you have to shift bits, split bits across 2 longs ..... This is a waste of runtime.
Having 16bit values does not change the send-algorithm very much. You read a word and send 12 bit of it.

And ... by the way ... I'd also keep a whole 8x8x8x3 frame in the RAM. Because this way you can have much better light effects. For example a 3d plasma algorithm. Any kind of algorithm which needs the 3d neighbours of one pixel to calculate the next value would then be possible.
And as you can imagine, 2 buffers would be usefull as well. 1st buffer is send and 2nd buffer can be used to calculate the next frame where using the 1st buffer as input is possible. If sending and calculation is done the role of the buffers is exchanged: 2nd buffer is send and 1st buffer is used to calculate the next frame.

This makes 8x8x8 x 3 x 2 x 2 Bytes = 6144 bytes .... that's not to much.
8x8x8 => number of LEDs
x3 => RGB
x2 => 1 word = 2 bytes
x2 => for 2 buffers

One plane would have 8x8x3x2 bytes = 96 longs ... so you can still load a full plane into the COG and send that data continuously. But it does not make a difference, as those kind of LED drivers takeover the data to the output registers when you singnal the takeover.

MagIO2 · 2011-02-21 23:49

Talking about it really makes me think that I should do something like this as well.

Having a cubic frame of copper just for stability and having this small wirewrap wires going from left to right with small SMD RGB LEDs soldered directly on the wires.

Running a nice plasma-fire simulation. Who needs this table fire then. (don't know the right word for this http://www.amazon.de/s/?ie=UTF8&keywords=tischfeuer&tag=googhydr08-21&index=aps&hvadid=8678118121&ref=pd_sl_65xvc4a7by_e ) Funny ... guess I'll follow you ;o)

SteveW719 · 2011-02-22 08:05

Thanks for the comments. I was planning on keeping the whole cube data in hub ram. I was taking a different tatic on the animations I was thinking I might take a video feed and take it apart in another cog and somehow scale it tothe 512 pixels in the cube. I have not really thought about how to do that yet.

I like you idea of making it with SMD leds suspended on a wire frame. How did you imagine that would work??

MagIO2 · 2011-02-22 12:01

I've thought over it ... so current planning is to use plexiglass ... 2 square pieces of plexiglass ... one for the left side, one for the right side, somehow mounted to a plate of ... whatever ... wood, another piece of plexiglass, black plastic ... for each row of LEDs one has to drill 4 tiny holes, one for the common anode and 3 for the kathodes of RGB. "Outside" the 4 wirese are drilled and go down to the base.

I plan to use common anode LEDs in a PLCC4 housing, as these have one contact close to each corner. Have to test that out.

I also don't know if temerature differences are an issue here. In a cold room everything is fine, in a warm room the wires are no longer straight, hanging down instead? Then on one side springs or weights might be needed.

MagIO2 · 2011-02-22 12:27

Does someone know a cheap source for PLCC 4 RGB LEDs? Just found one which sells those for € 0,99. For 512 LEDs that's an expensive project ;o)

tonyp12 · 2011-02-22 13:28

60cent each at 500
http://www.mouser.com/ProductDetail/OSRAM-Opto-Semiconductors/LATBT66C-RS-1+ST7-35+P7Q7/?qs=sGAEpiMZZMtEjy7lsqBi5QFquLJ6nimbvx6de8EP4pQ%3D

MagIO2 · 2011-02-22 14:02

Thanks for the link, but these are not available in germany .... sh....

Found a manufacturer in china who has the RGB LEDs listed for $0.099 ... I sent a mail to make sure that this is really the price and not a typo. We'll see ... but ~ $50 would be a good price for this project.

tonyp12 · 2011-02-22 15:06

It looks like mouser does not have right to sell them in germany
But maybe digikey does
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=475-1377-1-ND

MagIO2 · 2011-02-24 11:11

I got an answer from the chinese manufacturer. It's basically true. When ordering 1000 LEDs these only cost $114.44 which is $0.1144 per LED.
Gooooood price! ;o)

Here is the full answer they send me:

"Thanks for your inquiry.

$0.099/pc is basic price for our PLCC4RGBCT-CA.
But order below $199=surcharge, over $199=discount.

For example:
PLCC4RGBCT-CA 1000pcs $114.44 $0.1144/pc
10000pcs $838.43 $0.0838/pc
100000pcs $7040.88 $70.4088/K

You can order from us directly. Pls inform us exact quantity
you want, then will send you the PI asap.

Here is info on how to order, pay, delivery time,
warranty, shipment, samples:
http://www.ledz.com/?p=info

Have a nice day
"

Propeller programming & timing question newbie

Comments