I am wondering about something. what would be my best way to control a LED matrix? would I want to put the data on the rows, or the columns.
If I had 8-bits, would I want those bits to go from top to bottom, or left to right?
Also, what order should the bits be in? MSB->LSB or LSB->MSB
The order should not matter - the code can sort it out. For simplicity sake, one way would be to start with an array in Hub ram, one long per pixel. Store the data as xxxxxxxx_RRRRRRRR_GGGGGGGG_BBBBBBBB where x is 'don't care'. That is very similar to the .bmp bitmap protocol. To change a pixel, change the long in the hub array, so that makes is easy for any program to modify pixels.
Now run a cog that constantly reads that hub array and sends it out to the multiplexed leds.
First step - you might decide you only want 3 levels of brightness for each led. So (thinking in pasm now) - strip out the RRRRRRRR part with an AND mask (one instruction), then rotate it right by 24 bits (one instruction) and now you have binary RRR which is a decimal number from 0 to 7. Set up a counter from 0 to 7, if RRR is zero the led never goes on, if RRR is not zero, turn the led on, start the counter, and when the counter gets to the RRR value then turn the led off. Repeat for green and blue, and repeat for each led.
This sets some parameters. Say you have 8 levels of brightness for each led, and you have 16 rows and 16 columns and each row is actually 3 rows (3 different coloured leds), you can output to the 48 rows with HC373 latches (or HC595s though they are serial so a bit slower). Then turn on a transistor for column 1 then turn it off after a delay. Then update new row data, and turn column 2 on and off. Only one column is ever on at any time, so each column can be decoded with HC138 or HC154 chips.
If there are 16 columns and there are 8 levels of brightness, that gives 128 updates to refresh the screen. For moving pictures, say we use 25 frames a second, so that is 3200 updates per second. A cog runs at 20 million instructions a second, so the propeller will be easily fast enough.
I'm sure this has been done before. In many ways it depends what sort of leds you get. Is each RGB led something with 6 pins (separate anodes and cathodes) or does it have 4 pins (common cathode or common anode) or does it have some other number of pins.
In any case, there are solutions using a propeller and a few HC logic chips that are only 30c each, and there are also lots of solutions using dedicated led driver chips.
kwinn said
If the leds are not bright enough you may have to split the array and double up on the column drivers so each row would be on 1/8 of the time.
Good point. That could be something to test fairly easily - take one led, add an appropriate dropping resistor, and then drive it with a propeller pin at a ratio of 1:16 and see how bright it is. If 1/16 works it makes things simpler.
Ok, 4 pin, common anode. The design using transistors on the columns is for common cathode. It is no problem.
So we swap things round. Instead of the high current transistor being on the columns, it is now on the rows. And the latches drive the columns. So the transistors are now PNP instead of NPN, and the latch logic is inverted now, a Low means the led is on, and High means it is off. Instead of the display leds sweeping from left to right, now the sweep is from the top to the bottom. It is all too fast to see so it doesn't matter.
It should be possible to get something working fairly quickly with one led and one transistor. (and 4 resistors, one for each led, and one for the base of the transistor)
Looking at what Ray found, a few tips along the way, like tweaking the resistors for R G and B so the brightness is matched and it is white balanced.
Ok, 4 pin, common anode. The design using transistors on the columns is for common cathode. It is no problem.
So we swap things round. Instead of the high current transistor being on the columns, it is now on the rows. And the latches drive the columns. So the transistors are now PNP instead of NPN, and the latch logic is inverted now, a Low means the led is on, and High means it is off. Instead of the display leds sweeping from left to right, now the sweep is from the top to the bottom. It is all too fast to see so it doesn't matter.
It should be possible to get something working fairly quickly with one led and one transistor. (and 4 resistors, one for each led, and one for the base of the transistor)
Looking at what Ray found, a few tips along the way, like tweaking the resistors for R G and B so the brightness is matched and it is white balanced.
I really like what Ray did, there is a lot of information.
I was thinking of using this to control the columns. It seams like it would do great on the prop. Shift 192 bits, latch it in, then clock the grey scale 4096 times. the Prop would not have to figure out if the LED should be on or not. Plus, it has dot correction that is stored in its internal EEPROM. I was thinking I could use that to fix the color, and for brightness control (prop would not have to waist time worrying about it).
I was also thinking, while the prop is clocking the grey scale, it could be getting the next batch of data ready. Then move to the next row, and do it again.
That TLC5940 looks like a great choice for the column driver, and the IRF7314PBF is also a good choice for the row select driver.
I have one reservation about the '138 for the row select. If you have a software bug that stops the prop from updating the '138 address you may burn out any leds that are on in the selected row. Perhaps you should add a 555 timer wired as a missing pulse detector to disable (tristate) the '138 outputs if the row select address is not updated frequently enough.
That TLC5940 looks like a great choice for the column driver, and the IRF7314PBF is also a good choice for the row select driver.
I have one reservation about the '138 for the row select. If you have a software bug that stops the prop from updating the '138 address you may burn out any leds that are on in the selected row. Perhaps you should add a 555 timer wired as a missing pulse detector to disable (tristate) the '138 outputs if the row select address is not updated frequently enough.
I never thought of that, that would be really bad and it would be my luck.
Lets say I use the tlc5940, each channel is 12-bit. So I would have to use a "word" for each channel. Now there are 3 channels per pixel, that would be 3 "word" array per pixel. Now we take 512 pixels times them by 3, and I would need 1,536 "word" arrays just to buffer one frame of a 16x32 array.
My question is, does the prop have the RAM to do what she wants?
Lets say I use the tlc5940, each channel is 12-bit. So I would have to use a "word" for each channel. Now there are 3 channels per pixel, that would be 3 "word" array per pixel. Now we take 512 pixels times them by 3, and I would need 1,536 "word" arrays just to buffer one frame of a 16x32 array.
My question is, does the prop have the RAM to do what she wants?
The prop hub ram is 32KB and 1536 longs would be 6144KB so you could buffer several frames. I can't help but think about the best way to do this, and I have an idea that might simplify the programming and the wiring as well as reducing the hub ram requirement. Give me about 1/2 an hour to see if it is practical or out to lunch and I will let you know.
Hardware wise the columns are connected as per the attached block diagram (very basic) and the rows are selected with the '138 as you proposed.
A spin program creates an image of 32 x 16 bytes in hub ram. Each byte in the image is used by a PASM program running in a cog to select one of 256 longs.
Each long contains a color that consists of 10 bits R, 10 bits G, and 10 bits B.
The cog PASM program does the following to scan the image
1 Read the first long from the image data is read from hub.
2 - Look up the color for the first byte of the long and load it in the color register.
3 - Two zero bits (lsb's) are shifted out followed by 10 bits of R, two bits of zero followed by 10 bits of G, and two bits of zero followed by 10 bits of B are shifted out.
4 - Steps 2 and 3 are repeated for the remaining 3 bytes.
5 The next long from the hub image data is read and steps 2 to 5 are repeated.
6 After every 8 longs read from hub the row address is incremented.
7 After every 16 rows the row address is set to zero and steps 1 7 are repeated.
I was wondering if someone would please look at this schematic I created for a 16x16 RGB matrix. this is just a ruff drawing, but I like to have a schematic before I do any wiring.
The schematic looks ok. What are you going to mount the leds on. Boards 16.5" x 16.5" would be costly. Even 32/64 narrow strips would not be cheap.
I would think that 1/8" peg board would be perfect for this. Drill the holes out to 5mm for the leds to fit through and the wiring could be run between the leds. Mount the leds so the leads are in a diamond pattern and they could be bent to make connections without risk of shorts and it would still be relatively simple to replace a bad led.
The schematic looks ok. What are you going to mount the leds on. Boards 16.5" x 16.5" would be costly. Even 32/64 narrow strips would not be cheap.
I would think that 1/8" peg board would be perfect for this. Drill the holes out to 5mm for the leds to fit through and the wiring could be run between the leds. Mount the leds so the leads are in a diamond pattern and they could be bent to make connections without risk of shorts and it would still be relatively simple to replace a bad led.
I can't imagine you really needing (or wanting) 12-bits per color. There's a lot of software around which uses one byte per color. JonnyMac's drivers tend to use pack the color (as Dr_Acula described above) in the three lowest bytes of a long. This wastes 1/4 of the RAM where your pixel image is stored but it makes it easier to shift the pixels (but IMO not by much). In my RGB array project I use three bytes per pixel. I've toyed with the idea of switching to packing them in longs but I haven't really seen the need. Plus the three byte method only uses 75% of the RAM when compared to packing them in longs.
Whichever way they get packed you'll probably need a PASM driver to update the display fast enough to do real time animations.
I can't imagine you really needing (or wanting) 12-bits per color. There's a lot of software around which uses one byte per color. JonnyMac's drivers tend to use pack the color (as Dr_Acula described above) in the three lowest bytes of a long. This wastes 1/4 of the RAM where your pixel image is stored but it makes it easier to shift the pixels (but IMO not by much). In my RGB array project I use three bytes per pixel. I've toyed with the idea of switching to packing them in longs but I haven't really seen the need. Plus the three byte method only uses 75% of the RAM when compared to packing them in longs.
Whichever way they get packed you'll probably need a PASM driver to update the display fast enough to do real time animations.
I don't know if TC intends to do what I suggested earlier but if he does each pixel would be stored as a byte in hub ram, so 512 bytes or 128 longs per 16 x 32 image.
The cog that updates the display would use the bytes from the hub to look up 1 of 256 longs in the cog ram that have 30 bits of color data to shift out to the TLC's.
The color long would have 10 bits of R, G, and B information, and the two lsb's would be zero. After the color is loaded into a register and aligned with the output pin 12 bits of data are shifted out to the TLC's. The register is then shifted left 2 bits, the 2 lsb's set to 0, and then 12 more bits shifted out. This is repeated to shift the last 12 bits out.
The end result is that 36 bits of color data (12R, 12G, 12B with the 2 lsb's of each color set to 0) are shifted into the TLC. Repeat this for each pixel in the row (392 bits) until the entire row has been shifted out.
By having the cog download the color lookup table from the spin program you can have a different color palette for different programs and save hub ram by reusing that space as a double buffer for the image after the cog downoads the 256 color longs.
I can't imagine you really needing (or wanting) 12-bits per color. There's a lot of software around which uses one byte per color. JonnyMac's drivers tend to use pack the color (as Dr_Acula described above) in the three lowest bytes of a long. This wastes 1/4 of the RAM where your pixel image is stored but it makes it easier to shift the pixels (but IMO not by much). In my RGB array project I use three bytes per pixel. I've toyed with the idea of switching to packing them in longs but I haven't really seen the need. Plus the three byte method only uses 75% of the RAM when compared to packing them in longs.
Whichever way they get packed you'll probably need a PASM driver to update the display fast enough to do real time animations.
2 resions I want to use 12-bits. 1, to push myself for programing. I am taking on a large task doing this, most of the stuff I have no idea on what I am doing. and 2, for future use. never know I might be able to use 12-bits.
I don't think it could be that hard for the prop to convert a 3-bit value to a 12-bit equivalent in real time. What I was thinking was 3-bit value * 585 = 12-bit equivalent. I could be wrong on that, but still an idea.
2 resions I want to use 12-bits. 1, to push myself for programing. I am taking on a large task doing this, most of the stuff I have no idea on what I am doing. and 2, for future use. never know I might be able to use 12-bits.
I don't think it could be that hard for the prop to convert a 3-bit value to a 12-bit equivalent in real time. What I was thinking was 3-bit value * 585 = 12-bit equivalent. I could be wrong on that, but still an idea.
The biggest problem with trying to go with 3 color values per pixel is that data is stored in multiples of 8, which makes for wasted space and a limited palette of 512 colors. With an 8 bit pixel and a lookup table you only have 256 colors, but that is any 256 colors out of a palette of over a billion colors, and 100% utilization of memory.
I think my main concern about the 12-bit verses 8-bits is most of the LED software available for manipulating pixels uses 8-bits per color. I'm always glad when I can use one of JonnyMac's drivers and methods in my projects and I think there would be a lot more software which could be reused if the colors were 8-bits each. But I'm also of fan of reinventing the wheel. I frequently purposely don't look at other's code so I can see if I can do it myself (like IK software for my hexapod).
I think it's fine to reinvent a RGB LED array driver but I just want to make sure that's what you want to do. IMO, the hardware of this project will be the easy part.
The biggest problem with trying to go with 3 color values per pixel is that data is stored in multiples of 8, which makes for wasted space and a limited palette of 512 colors. With an 8 bit pixel and a lookup table you only have 256 colors, but that is any 256 colors out of a palette of over a billion colors, and 100% utilization of memory.
Ah, I think I'm beginning to understand your scheme better. Very interesting.
I think my main concern about the 12-bit verses 8-bits is most of the LED software available for manipulating pixels uses 8-bits per color. I'm always glad when I can use one of JonnyMac's drivers and methods in my projects and I think there would be a lot more software which could be reused if the colors were 8-bits each. But I'm also of fan of reinventing the wheel. I frequently purposely don't look at other's code so I can see if I can do it myself (like IK software for my hexapod).
I think it's fine to reinvent a RGB LED array driver but I just want to make sure that's what you want to do. IMO, the hardware of this project will be the easy part.
Please I hope you do not think I am trying to be difficult. I could just use others objects, and piece something together, but if someone asked "how did you do that?" I would not be able to tell them. I have never used PSAM before, and when I look at it I see a foreign language. I would think that if I came up with a Spin object, the gurus on here could walk me through converting it to PSAM. there is a good chance I will limit it to 8-bits, mostly because I would like just to experiment with using an external parallel RAM to store the display data. To see if it would make things faster, slower, or not make a difference. Following how a LCD screen is setup.
Ah, I think I'm beginning to understand your scheme better. Very interesting.
I wish I could claim ownership for this idea, but it was done back in the stone age of micros. They used the same idea to store 2 16 color pixels per byte of ram, and the prop does the same thing internally.
There are some additional advantages to going this route.
The TLC chip needs 12 bits for each output driver to work so using a lookup table is faster than trying to shift the 3 bit values (or a 233RGB byte) around to produce the 12 bit color values with the 3 bits in the msb positions.
Using 8 bits per color allows the cog to read 4 pixels at once by using a rdlong instead of 4 rdbyte instructions.
Integrating the pixel fetch, color lookup, and data shifting makes it almost as fast as the data shifting alone would be.
Oh, and in case anyone wonders how hard creating a 256 color lookup table would be, it's very simple. That's what spreadsheets are for.
Please I hope you do not think I am trying to be difficult.
Not at all. I'm just trying to help you make an informed decision. Depending on your hardware you may or may not be able to use code which has already been written.
It's the PASM drivers I'm concerned about. If you haven't used PASM before, writing a driver in PASM can be a big challenge.
I don't want you to realize later you're making the project harder than you wanted it to be.
Not at all. I'm just trying to help you make an informed decision. Depending on your hardware you may or may not be able to use code which has already been written.
It's the PASM drivers I'm concerned about. If you haven't used PASM before, writing a driver in PASM can be a big challenge.
I don't want you to realize later you're making the project harder than you wanted it to be.
Now I understand, Thank you.
This project will push me to learn more. My mind does not like to learn something new if there is no need. I have never had a need to learn PASM.
There are many things this project will help me out with. Using more than one COG, SD card, using KyeDOS that DR_Acula sugeststed. etc...
Then you can run a program like Kyedos which can load and run multiple precompiled programs off an SD card. So you can now compile one program which plays a little movie. And you can take some existing code that might do a graphics simulation and maybe it was written for a VGA display, so you replace the code so it runs your display instead. Once you have swapped one VGA object for your display Object, that process will get simpler. Then you precomile that program and put it on the SD card too, and now you can have many programs that all can be run from the SD card. Some are movies. Some are 'real' programs, like a 'game of life'.
This project will push me to learn more. My mind does not like to learn something new if there is no need. I have never had a need to learn PASM.
I do admire your desire to try out new things, explore new territory and generally learn new stuff.
However, I dare to suggest that this might not be the project to do it with.
You see, you have a customer there. That is not any old customer it's your wife!
It might be wise to get this thing done in a smooth and timely fashion. Use whatever pre-existing idea, modules, objects you can find that get you to completion as quickly and painlessly as possible.
Your wife will be impressed with your skills, prowess and dedication to creating a special thing for her.
She won't know anything of the technical nitty gritty (I assume). So wasting months and years learning and experimenting with creating everything from scratch won't be appreciated.
With a satisfied customer in the bag you might stand a chance of a report order.
Screw it up or take years to completion and you will be the butt of family jokes for years to come.
Do admire your desire to try out new things, explore new territory and generally learn new stuff.
However, I dare to suggest that this might not be the project to do it with.
You see, you have a customer there. That is not any old customer it's your wife!
It might be wise to get this thing done in a smooth and timely fashion. Use whatever pre-existing idea, modules, objects you can find that get you to completion as quickly and painlessly as possible.
Your wife will be impressed with your skills, prowess and dedication to creating a special thing for her.
She won't know anything of the technical nitty gritty (I assume). So wasting months and years learning and experimenting with creating everything from scratch won't be appreciated.
With a satisfied customer in the bag you might stand a chance of a report order.
Screw it up or take years to completion and you will be the butt of family jokes for years to come.
Thank you.
My wife is fully understanding that this is not going to be a easy, or fast project. She knows it could take a year or more just to do the programming. Making the table it self would only take me about a week.
Just encase anyone is wondering why I chose the route I want to go, this is why. They have a ATmega328 running at 16Mhz. It will take the incoming 24-bit data and up-convert it to 36-bit. Control 8x16 RGB matrix. and has 25 FPS.
I bring this up because I believe the Prop could blow it clean out of the water without even trying. Even if I use one prop just to maintain the matrix, while another prop runs the programs.
The prop has NO competition that I know of in the microprocessor market. And I think more people should push the prop to its limits, And do the things Arduino people are doing.
Comments
The order should not matter - the code can sort it out. For simplicity sake, one way would be to start with an array in Hub ram, one long per pixel. Store the data as xxxxxxxx_RRRRRRRR_GGGGGGGG_BBBBBBBB where x is 'don't care'. That is very similar to the .bmp bitmap protocol. To change a pixel, change the long in the hub array, so that makes is easy for any program to modify pixels.
Now run a cog that constantly reads that hub array and sends it out to the multiplexed leds.
First step - you might decide you only want 3 levels of brightness for each led. So (thinking in pasm now) - strip out the RRRRRRRR part with an AND mask (one instruction), then rotate it right by 24 bits (one instruction) and now you have binary RRR which is a decimal number from 0 to 7. Set up a counter from 0 to 7, if RRR is zero the led never goes on, if RRR is not zero, turn the led on, start the counter, and when the counter gets to the RRR value then turn the led off. Repeat for green and blue, and repeat for each led.
This sets some parameters. Say you have 8 levels of brightness for each led, and you have 16 rows and 16 columns and each row is actually 3 rows (3 different coloured leds), you can output to the 48 rows with HC373 latches (or HC595s though they are serial so a bit slower). Then turn on a transistor for column 1 then turn it off after a delay. Then update new row data, and turn column 2 on and off. Only one column is ever on at any time, so each column can be decoded with HC138 or HC154 chips.
If there are 16 columns and there are 8 levels of brightness, that gives 128 updates to refresh the screen. For moving pictures, say we use 25 frames a second, so that is 3200 updates per second. A cog runs at 20 million instructions a second, so the propeller will be easily fast enough.
I'm sure this has been done before. In many ways it depends what sort of leds you get. Is each RGB led something with 6 pins (separate anodes and cathodes) or does it have 4 pins (common cathode or common anode) or does it have some other number of pins.
In any case, there are solutions using a propeller and a few HC logic chips that are only 30c each, and there are also lots of solutions using dedicated led driver chips.
kwinn said
Good point. That could be something to test fairly easily - take one led, add an appropriate dropping resistor, and then drive it with a propeller pin at a ratio of 1:16 and see how bright it is. If 1/16 works it makes things simpler.
addit: Ray has done this sort of thing http://www.rayslogic.com/propeller/programming/AdafruitRGB/AdafruitRGB.htm and he chose 3 bits per pixel. Scroll down for pictures, and for current calculations. It is just a bigger version of that display, right?
I found them on eBay. Once I get back home I will post a link.
So we swap things round. Instead of the high current transistor being on the columns, it is now on the rows. And the latches drive the columns. So the transistors are now PNP instead of NPN, and the latch logic is inverted now, a Low means the led is on, and High means it is off. Instead of the display leds sweeping from left to right, now the sweep is from the top to the bottom. It is all too fast to see so it doesn't matter.
All simple to do in code and hardware. Inverting bits is one line of pasm code. Just a few changes from Ray's design http://www.rayslogic.com/propeller/programming/AdafruitRGB/AdafruitRGB.htm
It should be possible to get something working fairly quickly with one led and one transistor. (and 4 resistors, one for each led, and one for the base of the transistor)
Looking at what Ray found, a few tips along the way, like tweaking the resistors for R G and B so the brightness is matched and it is white balanced.
I really like what Ray did, there is a lot of information.
I was thinking of using this to control the columns. It seams like it would do great on the prop. Shift 192 bits, latch it in, then clock the grey scale 4096 times. the Prop would not have to figure out if the LED should be on or not. Plus, it has dot correction that is stored in its internal EEPROM. I was thinking I could use that to fix the color, and for brightness control (prop would not have to waist time worrying about it).
I was also thinking, while the prop is clocking the grey scale, it could be getting the next batch of data ready. Then move to the next row, and do it again.
I am getting these ideas from a schematic I found.
I have one reservation about the '138 for the row select. If you have a software bug that stops the prop from updating the '138 address you may burn out any leds that are on in the selected row. Perhaps you should add a 555 timer wired as a missing pulse detector to disable (tristate) the '138 outputs if the row select address is not updated frequently enough.
I never thought of that, that would be really bad and it would be my luck.
Im assuming I would monitor "A" input.
Lets say I use the tlc5940, each channel is 12-bit. So I would have to use a "word" for each channel. Now there are 3 channels per pixel, that would be 3 "word" array per pixel. Now we take 512 pixels times them by 3, and I would need 1,536 "word" arrays just to buffer one frame of a 16x32 array.
My question is, does the prop have the RAM to do what she wants?
Yep, and the 555 output would go to the G1 input to make all the outputs high.
The prop hub ram is 32KB and 1536 longs would be 6144KB so you could buffer several frames. I can't help but think about the best way to do this, and I have an idea that might simplify the programming and the wiring as well as reducing the hub ram requirement. Give me about 1/2 an hour to see if it is practical or out to lunch and I will let you know.
Hardware wise the columns are connected as per the attached block diagram (very basic) and the rows are selected with the '138 as you proposed.
A spin program creates an image of 32 x 16 bytes in hub ram. Each byte in the image is used by a PASM program running in a cog to select one of 256 longs.
Each long contains a color that consists of 10 bits R, 10 bits G, and 10 bits B.
The cog PASM program does the following to scan the image
1 Read the first long from the image data is read from hub.
2 - Look up the color for the first byte of the long and load it in the color register.
3 - Two zero bits (lsb's) are shifted out followed by 10 bits of R, two bits of zero followed by 10 bits of G, and two bits of zero followed by 10 bits of B are shifted out.
4 - Steps 2 and 3 are repeated for the remaining 3 bytes.
5 The next long from the hub image data is read and steps 2 to 5 are repeated.
6 After every 8 longs read from hub the row address is incremented.
7 After every 16 rows the row address is set to zero and steps 1 7 are repeated.
16x16.pdf
Thanks
I would think that 1/8" peg board would be perfect for this. Drill the holes out to 5mm for the leds to fit through and the wiring could be run between the leds. Mount the leds so the leads are in a diamond pattern and they could be bent to make connections without risk of shorts and it would still be relatively simple to replace a bad led.
I am going to use 3/16" white plastic.
Whichever way they get packed you'll probably need a PASM driver to update the display fast enough to do real time animations.
I don't know if TC intends to do what I suggested earlier but if he does each pixel would be stored as a byte in hub ram, so 512 bytes or 128 longs per 16 x 32 image.
The cog that updates the display would use the bytes from the hub to look up 1 of 256 longs in the cog ram that have 30 bits of color data to shift out to the TLC's.
The color long would have 10 bits of R, G, and B information, and the two lsb's would be zero. After the color is loaded into a register and aligned with the output pin 12 bits of data are shifted out to the TLC's. The register is then shifted left 2 bits, the 2 lsb's set to 0, and then 12 more bits shifted out. This is repeated to shift the last 12 bits out.
The end result is that 36 bits of color data (12R, 12G, 12B with the 2 lsb's of each color set to 0) are shifted into the TLC. Repeat this for each pixel in the row (392 bits) until the entire row has been shifted out.
By having the cog download the color lookup table from the spin program you can have a different color palette for different programs and save hub ram by reusing that space as a double buffer for the image after the cog downoads the 256 color longs.
2 resions I want to use 12-bits. 1, to push myself for programing. I am taking on a large task doing this, most of the stuff I have no idea on what I am doing. and 2, for future use. never know I might be able to use 12-bits.
I don't think it could be that hard for the prop to convert a 3-bit value to a 12-bit equivalent in real time. What I was thinking was 3-bit value * 585 = 12-bit equivalent. I could be wrong on that, but still an idea.
The biggest problem with trying to go with 3 color values per pixel is that data is stored in multiples of 8, which makes for wasted space and a limited palette of 512 colors. With an 8 bit pixel and a lookup table you only have 256 colors, but that is any 256 colors out of a palette of over a billion colors, and 100% utilization of memory.
I think it's fine to reinvent a RGB LED array driver but I just want to make sure that's what you want to do. IMO, the hardware of this project will be the easy part.
Ah, I think I'm beginning to understand your scheme better. Very interesting.
Please I hope you do not think I am trying to be difficult. I could just use others objects, and piece something together, but if someone asked "how did you do that?" I would not be able to tell them. I have never used PSAM before, and when I look at it I see a foreign language. I would think that if I came up with a Spin object, the gurus on here could walk me through converting it to PSAM. there is a good chance I will limit it to 8-bits, mostly because I would like just to experiment with using an external parallel RAM to store the display data. To see if it would make things faster, slower, or not make a difference. Following how a LCD screen is setup.
I wish I could claim ownership for this idea, but it was done back in the stone age of micros. They used the same idea to store 2 16 color pixels per byte of ram, and the prop does the same thing internally.
There are some additional advantages to going this route.
The TLC chip needs 12 bits for each output driver to work so using a lookup table is faster than trying to shift the 3 bit values (or a 233RGB byte) around to produce the 12 bit color values with the 3 bits in the msb positions.
Using 8 bits per color allows the cog to read 4 pixels at once by using a rdlong instead of 4 rdbyte instructions.
Integrating the pixel fetch, color lookup, and data shifting makes it almost as fast as the data shifting alone would be.
Oh, and in case anyone wonders how hard creating a 256 color lookup table would be, it's very simple. That's what spreadsheets are for.
Not at all. I'm just trying to help you make an informed decision. Depending on your hardware you may or may not be able to use code which has already been written.
It's the PASM drivers I'm concerned about. If you haven't used PASM before, writing a driver in PASM can be a big challenge.
I don't want you to realize later you're making the project harder than you wanted it to be.
Now I understand, Thank you.
This project will push me to learn more. My mind does not like to learn something new if there is no need. I have never had a need to learn PASM.
There are many things this project will help me out with. Using more than one COG, SD card, using KyeDOS that DR_Acula sugeststed. etc...
However, I dare to suggest that this might not be the project to do it with.
You see, you have a customer there. That is not any old customer it's your wife!
It might be wise to get this thing done in a smooth and timely fashion. Use whatever pre-existing idea, modules, objects you can find that get you to completion as quickly and painlessly as possible.
Your wife will be impressed with your skills, prowess and dedication to creating a special thing for her.
She won't know anything of the technical nitty gritty (I assume). So wasting months and years learning and experimenting with creating everything from scratch won't be appreciated.
With a satisfied customer in the bag you might stand a chance of a report order.
Screw it up or take years to completion and you will be the butt of family jokes for years to come.
Thank you.
My wife is fully understanding that this is not going to be a easy, or fast project. She knows it could take a year or more just to do the programming. Making the table it self would only take me about a week.
I bring this up because I believe the Prop could blow it clean out of the water without even trying. Even if I use one prop just to maintain the matrix, while another prop runs the programs.
The prop has NO competition that I know of in the microprocessor market. And I think more people should push the prop to its limits, And do the things Arduino people are doing.
Jim
It does, but the TLC5940 uses 12-bits per channel. The ATmega328 takes that 8-bit per channel input, and changes it so the TLC5940 can use it.