Announcing - New Firmware for the RGB Pixels

[JEC]

So...

The first several hundred pixels I sent out, I was hard-coding the start address in firmware, then re-compiling, then programming the PIC. It worked well but was tedious, inefficient and boring.

To that end, I'm nearly done with a new firmware which allows the address to be set in the field. Since my PIC doesn't have enough pins for DIP switches (we'd need nine at least) I've come up with an elegant solution.

Here's how it works: at programming time, every pixel gets a default address of '1'.

The pixels respond to two specific DMX packets, Packets with a 'zero' start code (signifying dimmer data) are treated normally and the R, G, and B LEDs are controlled appropriately. Channel N is red, N+1 is green and N+2 is blue if you're using the 3-channel firmware.

Packets with a specific *non-zero* start code (for safety, these packets are repeated several times in a row) contain data for re-setting the DMX address *and* switching back and forth between 3-channel and 4-channel (intensity, R, G & B) operation.

This configuration data is stored in the chip's EEPROM and can be changed at any time.

It's a bit like a secret knock at the treehouse door. It the PIC hears the right one, the door is opened and the furniture can be re-arranged.

Also, on startup the pixel's LEDs will flash in a specific pattern representing the start address.

I'm running a stack of small circuit boards containing an 8x2 LCD display, a few pushbuttons and connectors of the proper flavour. This programmer board will either send out (a) a full standard DMX packet for testing your lighting rig or (b) the special 'door knocking' packet for changing a pixel's start address.

------------

Everything should be ready by the end of next week or so. Just thinking about *not* re-compiling that code hundreds of times warms the cockles of my heart.

Hope this makes the system even more user-friendly and versatile.

And best of all, if you already own pixels from the first two batches, you can re-flash them with this new firmware if you choose.

Cheers,

John

[DynamoBen]

You just described how RDM works. RDM packets have a standard non-zero start code followed by the data packet.

[wbuehler]

Any ideal how much the programmer will cost?

Bill

[P. Short]

Is there any convenient way to change the address when the pixels are formed into a string, or do you have do each one individually?

--

Phil

[JEC]

Is there any convenient way to change the address when the pixels are formed into a string, or do you have do each one individually?

--

Phil

Don't know - I was envisioning programming a pixel, then adding it to a larger light rig, but still one at a time.

The RDM protocol Ben mentioned above would solve this nicely, but requires some decent firmware modifications on both the pixels and the control system. Plus it's DMX-only. And true RDM, as far as I can tell, is bi-directional. The remote gear can talk back to the master using the same RS-485 link.

If a processor will always and forever be part of a string, it may make sense to hard-code each pixel, then use something like the offset machine (described a few postings down) to set a master address for the entire string.

The offset machine could receive your choice of serial protocol (DMX, Renard, TBA Vixen Serial Procol) and raster it out in a language the pixels can understand.

Sort of like NAT, but for lighting gear.

EDIT: Perhaps one could design one's string of pixels to include a 2" tactile pushbutton, or maybe a pair of pins on .1" centers. Then, one could push the button or short the pins together, forcing the pixel's firmware into re-addressing mode. That way, pixels could be chained but still accessed discretely.

EDIT EDIT: But if you're using a 10F part, it's all moot anyway, since there's no EEPROM. Can those little guys write to their own code space?

[JEC]

Any ideal how much the programmer will cost?

Bill

No idea yet, but certainly under $50. At least for now, it's not real fancy - just a bare PCB and some rubber feet on the bottom. No enclosure or chassis.

[stephenwolf]

so, are you saying the everyone will have to buy the programmer board if they want to use the pixels? No offense, but I don' t really want to have to do that. Would I then have to assign an address in firmware and reprogram the pics?

Have you looked at what RJ did with the lynx? he has one jumper on the board that changed between normal mode and programing mode. When it is in programming mode it takes the value of what is currently being sent out via dmx and makes that its starting address. You then move the jumper to normal mode and you are done. Example: if you want it at channel 18, you set your dmx to output channel one at level 18 of the 256, move the jumper to programming, plug it into the dmx, and then move the jumper back.
I think it looks like a great way to easily program addresses and only need one jumper to do it.

I realize that you can't change the board now to add a jumper, but I thought you might find the idea useful with what you are going for.

My problem is that I will be controlling this from a computer, and don't want to have to build/buy another board, and I don't have any experience programming pics. guess I can learn though, and I will need to know for other things I am going to build. :-)

Maybe you could make a plugin for vixen that would output the packets for programing... that would make it nice and easy for those of us using a computer to control the pixels.

ps. If I got the lynx info wrong, let me know. I think I got it close enough anyway.

pps. I am really looking forward to playing with these pixels. I will mail you a cup of coffee if you send mine out first. :-)

[JEC]

so, are you saying the everyone will have to buy the programmer board if they want to use the pixels? No offense, but I don' t really want to have to do that. Would I then have to assign an address in firmware and reprogram the pics?

)


Sorry for not being so clear.

Everyone who gets pixels from now forward will get this new firmware.

I'm building at least one of these new programmers.

I'm still happy to address pixels for people - that's no problem. I'll just be able to do it in about 1/10 the time as before.

It's totally transparent on the user end. And if you'd like to re-address your pixels in the field, I'll make the programmers available at more-or-less cost.

Didn't mean to imply that the system won't run without you buying yet another adapter board.

John

[wbuehler]

Can I get one of these programmer PCB's?

Thanks

Bill

[JEC]

Can I get one of these programmer PCB's?

Thanks

Bill

No problem. Once the dust settles and I know the design is stable (and have an idea of how much pain and suffering it took to get it there) I'll have a price.

Should be under $50.

I think I ordered 5 or 6 bare circuit boards. At the prototyping stage, 5 boards are only slightly more expensive than one.

[wbuehler]

Cool

Let me know and thanks for all your hard work

Bill

[stephenwolf]

Didn't mean to imply that the system won't run without you buying yet another adapter board.

Alright, I follow you. Cool.
So you are saying that with this board you will be able to get me some pixels by Christmas (tomorrow) so I can put them under my tree for myself, right? :-) Oh come on, I am on the edge of my seat here!

[DynamoBen]

Phil was looking for a way to address his stuff w/o dipswitches and here is the method I suggested.

How about making DMX 511 and 512 the starting address values. The sequence of events would be.

1. Set 511, 512 to desired start address (IE 01, 44 = 300)
2. Power on pixel

At boot the pixel would look at these two values and set its starting address based on them. While this would only happen on boot users would need to be carefull about using these channels (511,512) for dimming (power loss could change all their starting addresses). You may want to suggest that these two channels are "keep out" channels that aren't to be used for dimming.

If you had a programming jumper it might be better to have that set, and power cycle. That allows people to use 511, and 512 w/o the power cycle address reset issue.

The cool thing about this method is there is no special startcode. Which means folks that don't have the DMX Pro still can address their pixels.

Thoughts?

[JEC]

Phil was looking for a way to address his stuff w/o dipswitches and here is the method I suggested.

How about making DMX 511 and 512 the starting address values. The sequence of events would be.

1. Set 511, 512 to desired start address (IE 01, 44 = 300)
2. Power on pixel

At boot the pixel would look at these two values and set its starting address based on them. While this would only happen on boot users would need to be carefull about using these channels (511,512) for dimming (power loss could change all their starting addresses). You may want to suggest that these two channels are "keep out" channels that aren't to be used for dimming.

If you had a programming jumper it might be better to have that set, and power cycle. That allows people to use 511, and 512 w/o the power cycle address reset issue.

The cool thing about this method is there is no special startcode. Which means folks that don't have the DMX Pro still can address their pixels.

Thoughts?


Interesting.

I'm partial to using a programming jumper and/or tiny tactile pushbutton. Putting the pixels in 'program mode' at each power cycle gives me tech support nightmares. Changing the address should be a deliberate - but not difficult - step.

I'd also prefer to have all 512 channels available for show time.

At least in my current case, the factory is soldering a batch of 300 pixels right now - it would be very expensive to change the design mid-stream. Future edits are no problem.

There are still extra pins on the PIC, plus fairly easy access to the 5 volt supply. I suppose someone could air-wire a pull-up resistor and touch a pin to program.

I just received the circuit boards today for the programmer described above. There's been enough interest on and off this forum that I'll keep developing the new firmware.

But I'm open to anything that might make the process easier for the DIY crowd.

John

[RJ]

Yes steve you nailed it.

Ben I don't follow your comment about not having the Pro. Maybe I am not understanding but what would a DMX pro have to do with this working or not? Are you talking about programming it each startup cycle? I did this with the open before I had the Pro and it worked.

[DynamoBen]

Ben I don't follow your comment about not having the Pro. Maybe I am not understanding but what would a DMX pro have to do with this working or not? Are you talking about programming it each startup cycle? I did this with the open before I had the Pro and it worked.

If memory serves with the Pro you can change the start code to something other than zero. So in theory you could program the pixels based on JEC's original post.

[DynamoBen]

I'm partial to using a programming jumper and/or tiny tactile pushbutton. Putting the pixels in 'program mode' at each power cycle gives me tech support nightmares.


I too am partial to the jumper but wasn't sure if one was available. That being said telling folks that two channels are off limits isn't the worst thing in the world.

[RJ]

Ok thanks I understand what you were getting at you just lost me on it.

[mrpackethead]

How about using a boring old rs232 serial port which you attach to a laptop/desktop/pda/phone and configure that way? So not 'inline' on the dmx?