Help with Hacked firmware for Jec's DIY Pixel

[cbell]

Trying to use this version of the firmware located in the file library. The pixel functions correctly using JEC's code, but it is not fun setting the DMX address. When using SRM's version, the pixel appears to start correctly, and in programming mode acts as SRM describes in the file library, however the DMX address does not appear to be getting set. After programming I turn on all 512 channels and get nothing. The instructions read


1. pixel power off
2. place programming jumper
3. setup vixen with a dmx profile
– channel 0 (high dmx address)
- channel 1 (low dmx address)
4. power up the pixel
5. start the vixen sequence
6. wait until the pixel is flashing green
7. remove the power
8. remove the programming jumper
9. power up pixel it will now use its programmed address

I am confused by the channel 0/channel 1 part. I have assumed all along that channel 0 meant channel 1 in vixen and channel 1 meant channel 2 in vixen. I am trying to set the pixel to channel 106, so I set channel 1 to 0 intensity, and channel 2 to 106 intensity, but something isn't working right. Am I assuming incorrectly about the channels?

EDIT:
If I set the address in the EEPROM before flashing the PIC, the pixel functions as prescribed.

[scorpia]

try programming the pixel as described to a different address. then read the eprom address and see what it is.

im guessing vixen is setting it wrong somehow. but never having used it for pixel programming i couldnt say for sure.

[cbell]

try programming the pixel as described to a different address. then read the eprom address and see what it is.

im guessing vixen is setting it wrong somehow. but never having used it for pixel programming i couldnt say for sure.

So far, the times that I've tried it, the EEPROM at addresses 0x00 and 0x01 read 0x00, setting the address at 0x01 to 0x6A (106) makes it function properly, which makes me think I'm just not sending out the values correctly from Vixen.

[sparky3]

i had the same problem. it only checks the address once. some times it misses and writes zeros into the start address. into give me a few min i will post some modified code that will run it through the program loop untill it is start address is greater than zero.
i set my up for 3 ch pixels can be changed back to 5 channel.

[sparky3]

try this code it is modified to check for start address greater than zero.
also just needs a temporary short on jumper when powering up. it will aoutomaticaly exit
programing loop when desired address is stored and go into the opperation.
will flash red on program mode enter
it will repeat flashing red if it misses address
flashes blue when data is above zero
flashes green when epprom programing is finished

[cbell]

try this code it is modified to check for start address greater than zero.
also just needs a temporary short on jumper when powering up. it will aoutomaticaly exit
programing loop when desired address is stored and go into the opperation.
will flash red on program mode enter
it will repeat flashing red if it misses address
flashes blue when data is above zero
flashes green when epprom programing is finished

Thanks! I'll give it a try tonight after I get the kids into bed!

[vairmoose]

The JEC code that I looked at several months ago was built to handle channels 1 to 512 by breaking the address into 2 separate bytes,, the first byte read becomes the "lowbyte" and and the second byte that is read is the high byte. The lowbyte can have values of 0 to 255 and the highbyte is limited to the values 0 or 1. It appeared that any other value in the address would be dumped. To program the pixel to channel 10... set channel 1 to "10", and channel 2 to 0. To set the pixel to channel 266 - try setting channel 1 to 10 and channel 2 to 1 (i.e, 10 + 256 = 266). (it might end up being 265 but hopefully you get the gist)


Larry

[mrpackethead]

The JEC code that I looked at several months ago was built to handle channels 1 to 512 by breaking the address into 2 separate bytes,, the first byte read becomes the "lowbyte" and and the second byte that is read is the high byte. The lowbyte can have values of 0 to 255 and the highbyte is limited to the values 0 or 1. It appeared that any other value in the address would be dumped. To program the pixel to channel 10... set channel 1 to "10", and channel 2 to 0. To set the pixel to channel 266 - try setting channel 1 to 10 and channel 2 to 1 (i.e, 10 + 256 = 266). (it might end up being 265 but hopefully you get the gist)
Larry

That is exactly how it works. Highly suggest to everyone that if they look at the new code, primarly because its more stable ( it does'nt hang if no dmx is present ), but because you can use the new hand-held channel setting tool. The tool will feature in several new designs coming up.

You guys are going to love the new pixel strings though.. If you check out JEC's web page, theres a few new hints about what they will do.. NO PROGRAMMING at all.

[cbell]

try this code it is modified to check for start address greater than zero.
also just needs a temporary short on jumper when powering up. it will aoutomaticaly exit
programing loop when desired address is stored and go into the opperation.
will flash red on program mode enter
it will repeat flashing red if it misses address
flashes blue when data is above zero
flashes green when epprom programing is finished

Gave it a quick try this evening. I am guessing I will need to uncomment the parts that are commented to get the Amber and White channels working. My first attempt was the same as with SRM's firmware. Channel 1 set to 0, Channel 2 set to 106. Nothing, the pixel just sat there waiting. Then I tried piecing in what MrPacketHead said, which if I understand, he's saying the channels are backwards. So I set channel 1 to 106 and channel 2 to 0. The firmware accepted this combination, but the address wasn't correct. Turning on channel 106 didn't do anything, but turning on all 512 channels did turn it on, so it must have been some channel.

Upon examining the EEPROM, the location at 0x00 was set to 0x6A (106), as to be expected since channel 1 was set to 106. The location at 0x01 was set to 0x00, which was also to be expected since channel 2 was set to 0. When I reversed the values, putting 0x00 in location 0x00 and 0x6A in location 0x01, the pixel functioned as desired (i.e, turning on channel 106 turned on the red channel).

I'm still thinking maybe I'm just not setting something right in vixen.

[RPM]

Chris,

You mentioned that it uses channel 0 and channel1 to set the address?
Usually channel 0 is reserved as the "start code" and channels 1 and up are the data channels.

Just thought I'd throw that out there.

That's why I decided to make my code so that it will use the sum of channels 1&2, that way it doesn't matter if you had channels 1&2 as 100&50 or 50&100 it would always be 150 no matter what. Makes it easier in my opinion ;)

Robert

[sparky3]

Hi Chris. if you are using enttec pro try using the utility program to set the address channel 1 is the high address, channel 2 is low address. if not what are you using for the DMX interface. i will try vixen in the morning i never used it to set the address.
i just used the enttec utility i also built a field programmer using a 18F2420,LCD,and some pushbuttons. it is menu driven you can select the start address, number of channels the device has,program the device then test it, it will put the same values on all channels that are being tested.
i will repost the code tomorrow with five channels sorry about that.

if any one is interested i will post the code and a schematic for the programmer i put together.

Rob

[sparky3]

Chris
i shafted you, try this new code. the origional one was modified to pull the pin low for led to turn on, i didn't change all that i needed to change for you. the new code is for all five channels.

sorry my bad
Rob

[sparky3]

i have been using vixen to program the pixel.

used the sequence wizzard
set event period = 50ms
channel count = 512
plugin setup = enttec DMX USB pro
hit create it

for 106 start address
channel 1 = 0
channel 2 = 106 ; highlight whole row right click select set intinsity enter number

selected loop pressed play installed jumper hooked up power
once programed hit stop
opened test channels selected the start channel
worked


i tested 20 diffrent channels they all set and tested ok
one of them i didn't have the whole row highlighted when i changed the address it would program to the old one and not the new one.

[cbell]

sparky3, Just tried out your new code. Worked just fine this time. Tried several different addresses, both with the sequence running before power up and starting the sequence after power up... All worked. I know all you changed was to make it work with 5 pixel so I'm not quite sure what's different. I recreated the sequence to your specs. I was only using a 10 channel sequence before, but I don't know enough to know if that made the difference. I'm using RJ's DMX dongle, which from what I understand follows the DMX standard better than the Entec Pro (but still uses the Entec Pro plugin), so I don't think that made a difference.

At any rate it works now. Thank you all for your help!

[sparky3]

glad i could do you some good. sorry about the mix up.

[scorpia]

sparky,

thanks for the info.

i for one would be interested in the programmer details you mentioned earlier.
maybe start a new thread for it. could be a handy little thing to have.

Peter

[cbell]

sparky,

thanks for the info.

i for one would be interested in the programmer details you mentioned earlier.
maybe start a new thread for it. could be a handy little thing to have.

Peter

I'd be interested in checking out the details of your programmer as well.

[mrpackethead]

And the programmer will be much more use than just for JEC's pixels.. A very useful device for programming a dmx start address on any dmx device..

Jec put a video up of his programmer

http://vimeo.com/3979505 and info at
http://response-box.com/rgb/2009/04/field-programmable-source-code/

Awesome wee box and really useful..

Programmer costs $46, I'd ask John if you wanted a PCB to build it yourself, hes generally very happy to help out that way.

[sparky3]

ok here is the programmer. it works really well for what it is. i still need to do more work on it. it is expandable i plan to add more transmitting features and recieving features later. i need to figure out how to roll the transmitting routine in a ISR so it transmitts a full 512 channels all the time and just changes the data output as needed. i am a very novice programmer so don't tear me up too bad on how the code looks.
i have included a zip file that hass the asm code, schematic, and pictures with captions.

Rob

[sparky3]

more pictures

[cbell]

Very cool little device. I would love to try developing stuff like that, but I'll be lucky if I get all I have planned for my display this year done :D. Might be a good reason to justify purchasing a scope though :)

Thank you for sharing!

[P. Short]

Here is some sample code that I wrote about 1-1/2 years ago that transmits DMX frames on an interrupt basis. It uses a timer interrupt to determine when to send each byte. I don't remember why I did it that way, it was a long time ago, but it probably had something to do with how I was handling the break or the make-after-break.

The code is for a USB-DMX dongle using a PIC18F part, although not quite the same part as you are using. The program used a triple-buffer scheme, where one buffer is used for receiving a frame from the USB chip, one buffer is a completely filled buffer that is waiting for the previous DMX transmission to finish, and the third buffer is the one that is currently being transmitted. This scheme is intended to make sure that each frame is transmitted exactly as it was received from the host PC, with no possibility of merging frames.

There is a lot of buffer handling code in the ISR, but I hope that all of the code for setting up the interrupts and the template for handling the interrupts will help.

At this time I consider this code to be essentially dead, in that there are so many other DMX dongle projects out there that there is no need for another one.

[sparky3]

thank you Phil i will play with that.

Rob

[P. Short]

Which LCD is that in the photos in posts 19/20 of this thread?

[sparky3]

it is a 20 x 4 line i picked it up from circuit-ed
http://www.circuit-ed.com/20x4-YelGrn-Character-LCD---77x47mm-P160C8.aspx
it has a backlight and is only 10.50

[LabRat]

Here is some sample code that I wrote ...

The code is for a USB-DMX dongle using a PIC18F part, although not quite the same part as you are using. ...

At this time I consider this code to be essentially dead, in that there are so many other DMX dongle projects out there that there is no need for another one.

Phil, I'm interested in the project (morbid curiosity perhaps, or perhaps because I have a bare UBW board that I think I could push into service as a DMX dongle ("yet another" to you, but my first to me;)). Do you have a schematic for what you had been working on?
I see references to FTDI in the code, and I thought FTDI was a usb2serial adapter. Can I take it that you weren't using the Microchip USB stack?

Interesting stuff though. :D

[P. Short]

Sparky3,

Thanks for the link.

LabRat,

The design uses a USB-parallel adapter from FTDI. The reason for this is that there was the belief that the FTDI USB stack is not fast enough to handle the throughput of a DMX512 universe (or perhaps universes, I don't remember anymore). The design was discussed more in this thread (http://doityourselfchristmas.com/forums/showthread.php?t=2480), although my schematic should be taken as quite rough and having errors (the DC-DC converter is not what I would use these days). The design was prototyped on perfboard and working as far as I needed it to at the time that I dropped it and moved onto other projects.

[LabRat]

Thanks for the update.. I will peruse that thread.

;o)

[mrpackethead]

Thanks for the update.. I will peruse that thread.

;o)

ubw old or new ubw32... ? I've been pondering that design for a while.. It would be great if it could work on a pic32 chip.. theres large truck loads of cpu in those!

[LabRat]

No.. the older 18F2550 UBW (or.. the board that I made BASED on the UBW) :)

I haven't played with the PIC32's at all yet. I'm only just getting "into" the 18F's.

Here's the link to the discussion where I first pitched my schematic, and then followed up a year later when I had the two boards made. It also details my board "bring up", and some of the mistakes I made/learned along the way.

Discussion at electro-tech-online (http://www.electro-tech-online.com/micro-controllers/38150-feedback-schematic.html)

[sparky3]

P.Short
sent me a message awhile back ago about a typo in my program for the DMX address programmer. miss spelled the word channels most of you that looked may have noticed that. my bad, late nights what can i say.

also the question about the code. if it was JEC's programmer code that goes along with his new pixel firmware. it is not, and it will not work for JEC's new pixel firmware. i put this together for " SRM's modification of JEC's original pixel code ", to program device address.

i am sorry if i confused anyone.
thanks

Rob

[srm]

Hi All,

sorry for not helping, i've been away doing other stuff

that little box looks great.

the code i modified worked for me on my workbench

regards,

Stephen.