Propellor Clock POV Style Display Example Code

[Benj]

Hello,

Here is my attempt at creating a propellor display, I started out with PIC then moved to AVR for speed and then to dsPIC when this became available again for the speed and extra number crunching capabilities.

The PIC and AVR boards had quite large LEDs which meant that at 32 LEDs the board was quite big. You got a steady display but going near it with your hand was dangerous

For the dsPIC board I found much smaller RGB LEDs and reduced the count to 24 so the board became much smaller and therefore spun without requiring anywhere near as much force and electrical power.

(32 x 3) / 8 = 11 Buffer ICs + 8-bit Port
(36 x 3 x 240) / 8 = 3240 bytes @ 3 bit colour

(24 x 3) / 8 = 8 Buffer ICs + 8-bit Port
(24 x 3 x 240) / 8 = 2160 bytes @ 3 bit colour

Here is an image of the AVR board

prop4.jpg (22.12 KiB) Viewed 45125 times

prop3.jpg (25.19 KiB) Viewed 45125 times

These images are of the dsPIC board

Prop1.jpg (26.14 KiB) Viewed 45125 times

prop2.jpg (29.27 KiB) Viewed 45125 times

The code was all written and design for use with v4 so I'm not sure if it will work correctly with v5 though I don't see any reason why not.

PIC16BIT_Custom2.c

(22.72 KiB) Downloaded 2123 times

The code can be adopted for use with a PIC, AVR or ARM but obviously you will need a bit of C knowledge to be able to do this. You should also be able to replicate the functionality directly in Flowcode. I believe I started out like this and then moved the Flowcode C code into a custom component to provide a bit of optimisation on the code in order to get the fastest refresh possible.

I can only seem to find the dsPIC custom component at the minute but I will have a dig and see if I can find anything else.

There are basically 2 interrupts that drive the display and a further interrupt which drives the variables used for time keeping which can be used to display a clock etc.

Macros

PWM control - Called by a timer interrupt to switch between display segments during the revolution, controls all the LED I/O and reads from the display buffer.

Spin Sync - Called by a hall effect driven INT interrupt to synchronise a full revolution and adjust the pwm control interrupt frequency.

Tick 100hz - Called by a timer interrupt to give a known frequency output which is translated into ticks per second to allow the time variables to be updated.


The rest of the functions are manually called by the User's application rather then called directly from an interrupt.

Clear display - clears the display buffer

rotate display - moves the start segment offset, allows the display image to rotate in either direction

reset display - resets the start segment offset back to factory default

modify pixel - allows a single RGB pixel to be assigned data within the buffer, addressed by segment and then position

modify pixel xy - allows a single RGB pixel to be assigned data within the buffer, addressed by x and y on the display, not sure if I got this fully working

draw circle - sets a led on every segment to a specific colour in the buffer and provides fill options

draw axle - sets a full or partial segment to a specific colour in the buffer

draw arc - same as draw circle but allows segments to be left out

draw text - draws circular text to the display buffer

read temp - calls on a look up array of real work celcius data to allow the temp to be printed to the display

get count - returns number of revs of the display per second

update time date - allows the time and date to be set

read time date - alows the time and date to be read

v15.fcf_pic16

(17.4 KiB) Downloaded 1999 times

The anode pins of the LEDs are all driven from buffer chips which are chained together with the output of one going to 8 LED signal lines and the input of the next buffer. This requires that the buffer has a latching output which is driven from a clock signal. This setup allows me to output a byte to a port and then clock it into the first buffer and then along to the end buffer.

I also use a mosfet on the cathode pins and this is switched off while manipulating the buffer chain otherwise the LEDs that are meant to be off will glow slightly as the data for the other LEDs moves along the chain.

I power and spin the display board by modding a £0.30 motor from Rapid so that it passes the 3 phase motor voltage through the front of the motor to the board. With the addition of 6 rectifier diodes on the display board this guarentees a continuous suppy voltage and ground while the display is rotating. The downside to this is that it is hard to control the speed of the motor without effecting the amount of current the board has to play with. I generally provide enough power to allow the motor to run fast enough and for all the LEDs to glow white and then try to stick to this setting.

By running the segment mechanism at a faster multiple speed it would be possible to allow for more then simple 3 bit colour by multiplying the buffer size by the number of extra bits you want to add to each colour and then modifying the pixel manipulation routines to match. You could maybe even spin the display fast enough so you overlay colour channels rather then use more basic PWM techniques as this tends to smear the pixels. Think this may be the next investigation next time I fire up the board.

At the moment my main stumbling block is getting data to the display from outside eg using IR or wireless to allow reprogramming of the firmware and for dynamic data to be fed in from a PC. I briefly tried IR and passing data via the motor windings but there were problems with both which I can't quite remember now.

Unfortunatley I fried the dsPIC board trying to perfect the communication technique so I have to rebuild it from scratch which is fairly labour intensive I will more then likely get back to it and finish the design one day....

prop5.jpg (74.45 KiB) Viewed 45124 times

[Benj]

I have managed to dig out the AVR version though it is quite a bit behind the dsPIC version in that the code is still based within Flowcode and the draw routines have not been implemented.

[Enamul]

Hi,
Nice work Ben . I was thinking to make one earlier its good that you have made one. So I can have some guideline from you.
Enamul

[mtqc76]

Thanks Sir for posting POV FCF.

[wayne millard]

Hi Benj,

What a great project

[Spanish_dude]

I'd love to see a video of it

Awesome project.

[Benj]

I think I have a video of the dsPIC board lying around at home so I will check.

There is a early vid of the AVR version board here if this helps.

[/youtube]

This video was using my first technique to mod the DC motor and so I think you can hear it ticking as it spins. For the dsPIC motor I improved the technique by adding a bearing to take the weight of the spinning circuit board so the motor could be free to do what it does best, spin.

The artifacts are picked up by the camera only, in real life you get a constant display. Again the dsPIC board is much faster so the camera doesn't pick up the missing portions of the display.

[Benj]

Found another AVR video file on my PC, this time of it actually doing something. have to get the dsPIC version fired up again and take a vid of it in action.

[/youtube]

[mtqc76]

Thanks sir:

Project is very nice, but hard to understand how it works.

[Benj]

Project is very nice, but hard to understand how it works.

Let me know which bits are hard to understand or not explained well enough and I will try and change so that the mechanisms are easier to understand.

[mtqc76]

Sir, plz upload circuit schematic that you used for propeller clock. Other thing is that you made custom c file, can we make just 8 bit rgb propeller display with PWM without custom c file by just using c block and some c code.

[mtqc76]

Sir, I made a simple 32 bit single color POV setup. I created LUT in rom with four byte to make it 32 bit. in proteus simulation everything is working fine and i feel it will work perfectly.

I want to add external EEPROm 24c64a chip I2c. for what i have to use at least 877a chip. I am stuck in figuring out how to use EEPROM both software and hardware wise.

Should I make LUT table for each byte separately and store it in EEPROM via programmer. if so, plz guide.
How to make arrangement in flowcode to retrieve data from eeprom and use it to transmit to leds.

I am attaching flowcode fcf, proteus and image. Plz have a look and guide me.

Thanks
Waseem

[Benj]

Hello Waseem,

I first tried an approach that used external memory and I found this was much too slow to use. However I think I may have been getting greedy as I was trying a 4MB SRAM chip and the memory banking system was very complicated and added a lot of overhead. After this I always went for uC chips with enough RAM memory on board as it allows you to access the memory directly. Latest chip I'm using is the dsPIC33FJ128MC804 with 16K of RAM onboard.

Maybe check the spec for the EEPROM and checkout the read and write cycle times to see if they are good enough for your application. I suppose if you want to display a fixed banner then read time is really all your interested in.

Also for the buffer ICs instead of having them like you currently have them setup where each has the same 8-bit bus but unique data strobe lines. What about commoning the data strobe to all ICs and then chaining the data bus so that the 8 signals out of the first IC feed the next IC and so on. This allows you to scale up the number of ICs without needing any additional pins.

Are you making a single colour POV display? This is much more straightforward then RGB and should look good with 32 LEDs

One last issue I found is LEDs with rounded tops. They tend to smear the pixel and may light up other components such as caps leaving a ring as the display spins. Try if you can to get as small LEDs as possible that you can still solder to the PCB and try to ensure they have flat tops. This will give you the best looking display. My latest board has rounded lenses on the LEDs but I very carefully use a grinder to take the top of the lens down to a flat edge and this gives a much better display.

[mtqc76]

Great sir!

I am actually trying to first make 32 bit display to master first. You suggested good ram for better access and display and get rid of complications, as i am novice and learner I prefer using readily avaiable chips to make it first. I want to make analog and digital clock and some icons to display as billboard or something like it. For time being I leave idea to use 24c64 chip as I have to program it separately and then access it via microcontroller.

If you guide me, can we make such arrangements in flowcode icon only with some c code supplementary code to make simple 32 bit analog and digital clock pov? I got its theory but little confusion if you clear plz. In custom custom C file, there is

//ASCII Pixel data
const char ASCII[] =
{
0x00 , 0x00 , 0x00 , 0x00 , 0x00 , // 32 = <space>
0x00 , 0x06 , 0x5F , 0x06 , 0x00 , // 33 = !
0x07 , 0x03 , 0x00 , 0x07 , 0x03 , // 34 = "

How you calculated it and it can be used in POV without custom c file.

How to put LUT in program memory of table. does rom char* puts LUT in program memory or eeprom?

I did make POV 8 bit from book Van der Dam and worked fine with little component and little programming, hence i am very much attracted to it.

[Benj]

You can create a POV without using a custom C file but printing text is one of your biggest obsticals as it requires a lot of things to be in place before it will work at all.

You basically need to take the string and break it into character bytes, once you have done this you look up the 5 byte pixel data for that particular character and then you need to output 1 byte from the character on each subsequent segment as your POV display spins around.

I do this in my program above by writing the text data to the display buffer and then as the display spins around it automatically fetches the information from the display buffer and prints it at the appropriate position around the circle. This also means you dont have to sit there and manually output each of the pixel patterns as the display reaches the correct position. It also means that you can switch the sync segment (the segment that gets loaded when the sync pulse is detected) and get the data on the display to rotate with very little effort.

rom char* puts memory into ROM not EEPROM.

const char name[] does the same thing. I think the command is compiler specific so rom char* works for 8-bit PICs on BoostC.

If you need to put data directly into EEPROM then that is posted on the forums, a search should give you the right info.

[mtqc76]

Thanks sir:
Got the point. One thing in confusion, const char ASCII[] in your custom code c file, it is more than 256 byte where LUT cannot be more than 256. As flowcode uses boostc compiler did not it generated error while compiling on your program. If i make LUT via rom char* i cannot make one LUT more than 256 so i have make 3 or 4 LUT to make ASCII table complete, more const char does not work on supplementary code. Plz do put some light on it. Is it possible to make const char in supplementary code of flowcode or in V5 version? If not how you did in custom.C file. (Is it only allowed in AVR, AVR should be used for POV)? A

Second thing what is formula to convert string to character byte eg "matrix" character byte?

[Benj]

Hello,

I used AVR and then moved onto the 16-bit PIC devices which both allow for arrays larger then 256 bytes. With the 8-bit PICs you cannot go over the 256 byte boundary so for these I usually create multiple arrays for the ASCII pixel data and then switch between them as needed. If you want an example of this then look at the Flowcode generated C code for a standard graphical LCD.

A string is an array of bytes so say you passed a string variable to a macro "matrix" you could get the length of the string by using the length function and then loop through from 0 to length-1.

byte = string[idx]

[Benj]

Managed to get the dsPIC version up and running again so finally taken a vid.

[/youtube]

RTC doesn't seem to be working at the moment which is annoying as the various clocks should be kicking in after a minute of running I'll see what I can get it to do and post up another vid soon.

Here is the current source code and component, I have made some minor changes to the custom component to fix a bug in the rotation and to try and further optimise the data output mechanisms vs the display quality.

[brandonb]

thats awesome ben, .... is the music in the last video acoustic metallica orion

[Benj]

Cheers Brandon, Its a band called Rodrego y Gabriella doing a Metallica cover. They record everything live playing only two acoustic guitars to get all the strums and taps .

[Benj]

Here is another vid along with another fw update and a schematic.

[/youtube]

I've left the sound of the motor in this vid, its not as bad as the camera picks up but it is a bit louder then I was hoping for. I think most of the noise is generated from having a slightly imbalanced prop board so I will have a play around with the ballast weight and see how stable it will get.

The two shapes drawn are a cube which uses square faces (rotates about 7-8hz) and a isocahedron which uses triangular faces (rotates about 3-4hz) so that should be all the basis required for displaying most 3D meshes. There are a number of new functions available to handle the 3D shapes. I have also fixed a number of bugs in the other functions as well as added a couple of optimisations to the mechanisms to make them more efficient. The key bug tackled is the cartisian to sperical coordinate system which is now fully tested and working. Functions for text and graphics are also now available which rely on the coordinate conversion process.

There is also the addition of a segment dead time as the light from pixels in a segment were bleeding into surrounding segments. The dead time parameter can be set from 1:0 through 1:1, 1:3, 1:7 etc to control how much of the segment is blanked out. Note that the larger the dead time the faster the segment interrupt has to run which means less processing time for the front end graphics. 1:1 and 1:3 seem to work well.

The display can be ramped up from 240 segments to 360 without any real ill effects though the front end graphics start to slow down a bit. 180 segments looks very crisp and runs fast but is a bit limited in regards to string length etc.

Here is a pretty complicated looking overview of the system showing the coordinate systems and the orientation.

Propellor Display Overview.jpg (108.12 KiB) Viewed 44290 times

Edit: The coordinate at the top should be (180, 0) and not (0, 180) as shown.

Also please note the board has been modded slightly away from the schematic design. If anyone wants specifics then let me know and I will try and remember what I did.

Now to tackle the lack of a functioning RTC and I can try and put together some funky clock designs. I also want to make a spherical space invaders but that requires I get the IR working and that's tricky because its picking up noise from the LEDs at the mo.

[Enamul]

Awesome work Ben

[mtqc76]

Great Sir!!

[mtqc76]

Sir, i did make some work on propeller display via c code. It is not compiling, it was written for Mickro C, i did try in many ways, but compiler does not compile it. Plz have a look and give suggestion.b Us C language is different in flowcode? How to put it in c code/supplementary block.


code:
char counter;
int digit_counter=0;
const char letter_SPC[8]= {0,0,0,0,0,0,0};
const char letter_newline[8]= {0,0,0,0,0,0,0};
const char letter_A[8]= {31,36,68,132,68,36,31};
const char letter_B[8]= {255,137,137,137,137,137,118};
const char letter_C[8]= {126,129,129,129,129,129,66};
const char letter_D[8]= {255,129,129,129,129,70,60};
const char letter_E[8]= {255,137,137,137,129,129,129};
const char letter_F[8]= {255,136,136,136,136,128,128};
const char letter_G[8]= {126,129,129,137,137,143,72};
const char letter_H[8]= {255,8,8,8,8,8,255};
const char letter_I[8]= {129,129,129,255,129,129,129};
const char letter_J[8]= {142,129,129,254,128,128,128};
const char letter_K[8]= {255,16,16,16,40,68,131};
const char letter_L[8]= {255,1,1,1,1,1,1};
const char letter_M[8]= {255,128,128,112,128,128,255};
const char letter_N[8]= {255,64,32,16,8,4,255};
const char letter_O[8]= {126,129,129,129,129,129,126};
const char letter_P[8]= {255,136,136,136,136,136,112};
const char letter_Q[8]= {124,130,138,134,131,130,124};
const char letter_R[8]= {255,136,136,136,140,138,113};
const char letter_S[8]= {98,145,145,145,137,137,70};
const char letter_T[8]= {128,128,128,255,128,128,128};
const char letter_U[8]= {255,1,1,1,1,1,255};
const char letter_V[8]= {248,4,2,1,2,4,248};
const char letter_W[8]= {254,1,1,14,1,1,254};
const char letter_X[8]= {129,2,36,24,36,66,129};
const char letter_Y[8]= {128,0,32,31,32,64,128};
const char letter_Z[8]= {131,133,137,145,161,193,129};

void main() {
int n, i, repeat;
TRISA = 0x00; // set direction to be output
PORTA = 0x00; // turn OFF the PORTD leds
while (1) {
for (repeat=0;repeat<24;repeat++){
for(n=0;n<6;n++){
digit_counter = 0;
printChar('A');
printChar('N');
printChar('D');
printChar('R');
printChar('E');
printChar('W');
printChar(' ');
printChar('\t');

}//end for n
} //end for repeat
}}
//END word cycle


void printChar(char letter){
int n;
digit_counter++;
for(n=0;n<8;n++){

if(letter == 'A') PORTA = letter_A[n];
else if(letter == 'B') PORTA = letter_B[n];
else if(letter == 'C') PORTA = letter_C[n];
else if(letter == 'D') PORTA = letter_D[n];
else if(letter == 'E') PORTA = letter_E[n];
else if(letter == 'F') PORTA = letter_F[n];
else if(letter == 'G') PORTA = letter_G[n];
else if(letter == 'H') PORTA = letter_H[n];
else if(letter == 'I') PORTA = letter_I[n];
else if(letter == 'J') PORTA = letter_J[n];
else if(letter == 'K') PORTA = letter_K[n];
else if(letter == 'L') PORTA = letter_L[n];
else if(letter == 'M') PORTA = letter_M[n];
else if(letter == 'N') PORTA = letter_N[n];
else if(letter == 'O') PORTA = letter_O[n];
else if(letter == 'P') PORTA = letter_P[n];
else if(letter == 'Q') PORTA = letter_Q[n];
else if(letter == 'R') PORTA = letter_R[n];
else if(letter == 'S') PORTA = letter_S[n];
else if(letter == 'T') PORTA = letter_T[n];
else if(letter == 'U') PORTA = letter_U[n];
else if(letter == 'V') PORTA = letter_V[n];
else if(letter == 'W') PORTA = letter_W[n];
else if(letter == 'X') PORTA = letter_X[n];
else if(letter == 'Y') PORTA = letter_Y[n];
else if(letter == 'Z') PORTA = letter_Z[n];
else if(letter == '0') PORTA = letter_0[n];

}

} //end printChar function

[Benj]

Hello,

Registers like PORTA and TRISA should be lowercase eg porta and trisa.

"const char" becomes "rom char * "

Hopefully this should allow the code to compile