So, this project was sidelined until I had to make another BatchPCB purchase. Thankfully it wasn’t too long until I had the opportunity to work on it again! The current setup is basically 4 of the original 4 RGB LED Controller boards and 12 of the updated DR1r3 boards. All 16 are wired in parallel and being controlled by my desktop machine. You can see an extended version of this RGB test sequence after the break and I’m also including the (uncommented, sorry!) Processing 1.1 code that I used to control the boards.
Here’s an extended cut of the video display (which is displaying an RGB Test Sequence). Note that the current maximum throughput is approximately 12-13 frames per second due to the RS-232 baud rate bottleneck, but I’m looking for ways to speed up the data transfer without requiring a faster oscillator.:
The Processing 1.1 code:
VideoDisplay (includes the .pde file and the video used)
very nice update. the FPS is surprisingly OK, even if its only 12-16FPS.
I have just built the first pixel and i am trying to get it working. My first question is what C compiler are you using for the code? I cant seem to get it to compile.
Also i tried to use your premade .hex file but im guessing i need to set an address for it to work as ic ant get any output atm.
Also i have what i think is a fixed eagle file with an updated pic part to fix the hole problem. but i need to reomplie the code as my pin layout is different to your layout in an effort to make the PCB easier to route.
Im currently using the DR1r@ VB app + the DR1r8 pic .hex file. any updates would be great.
I just checked the microchip website. check out the 16f1826 / 16f1827 chips. internal 32Mhz osc with a price cheaper than the 16f628a. i have some coming on sample. would be worth a look.
@Peter: I am currently using CCS PIC-C version 4.104, although this code compiled with older versions. Please let me know what the errors are and I’ll be happy to help troubleshoot the problem.
If you use the premade hex, the board should default to a low-white state (where all of the outputs are a PWM value of 1). If you look at the EEPROM in MPLAB (or whatever programming environment you are using to burn the chips), then the 1st byte is the address (default 0) and the remaining 12 bytes are the default on state, which should all be 1. If none of the LEDs are turning on, triple check to make sure that they are common cathode. One way to make sure they are working is to use a multimeter’s diode setting and just make sure that they are conducting/lighting when you apply a voltage to them.
I moved to Processing 1.1 simply because it is open source and a bit faster than my VB source code. If you run this, it should make the board blink, as long as its address is anything from 0x01 to 0x10 (16): http://www.semifluid.com/wp-content/uploads/2010/06/VideoDisplay.zip Also, if you are working on rerouting the PCB, I’d go your route and consider changing the PIC to a faster/more robust one that could handle higher baud rates.
@Peter: Wow, good find! I just checked them out on Microchip’s website and they certainly look like a good deal. AND, they appear to be pin-compatible with the PIC16F628, which would mean that I wouldn’t have to deal with redoing my current boards.
One more recommendation, if you are changing the PCB, is to consider resistor arrays rather than the discrete resistors. Soldering those resistors is the biggest pain in the butt of the entire project, IMHO.
Looks to me that the CCS compiler isnt a free C compiler. well at least the version that I have that seems to come with MPLAB is asking for a file. Any chance of a Hitech C lite version of the code?
I will have a look at converting it but i havnt played with it before so i dont know how i will go.
ok, i managed to get the dr1r7 code running with the vb app using the precompiled .hex but i cant get the dr1r8 code working, seems like its constantly reseting or something. next is to try and move the code over to hitech C so i can recompile with my hardware changes in the code
@Peter: The reason that it appears as though it is constantly resetting is because the code now looks for a “sync byte” at the beginning of each command: 0xAA
To get the VB code working with the DR1r8 firmware, a modification needs to be made to the Form1.vb source code in Private Sub timerPlayMovie_Tick. Change the following snippets of code:
tempData = Chr(&H10)
tempData = tempData & Chr(Int(movieColor(currentFrame,…
To:
tempData = Chr(&HAA)
tempData = tempData & Chr(&H10)
tempData = tempData & Chr(Int(movieColor(currentFrame,…
Basically, this just appends the sync byte to the beginning of the packet.
Hmm how do you did it?… I have build 8 PCB…. with 4 everting went well, but with 8 not… and you have 16?
and i have try dr1r7 ( this one works alright , if i don’t send data to fast…
but dr1r8 (with the &Haa) shows something but with al lot of wrong colors and not good…
so I hope you give the source and visual basic program for this…
download processing 1.2.1 and your file…. and try it with my hardware….
and also not working well…flashing…. and on the movie they are al red (for example) and then 1 pcb stays the color before….
maybe my wires are to long?
tomorro i first make them alright…
somebody try the 16f1826 / 16f1827 already?