The Renard DMX code and PICs programmed with it do not support on-the-fly setting of the DMX start address. You have to compile the ASM file with the correct start address for the first PIC on the board. All other PICs on the device will use the same firmware with 1 as the start address. The Renard DMX code does not pass the entire DMX packet through, each PIC will strip off 8 channels (and any channels before the start address) before sending the packet on to the next PIC, e.i. the packet gets smaller as it moves through the PICs. If you mixing standard DMX and Renard DMX devices together, you need to be aware that the entire packet is not being passed around and set up the order of the devices and the addressing appropriately. If you using just Renard devices, the PICs/devices are self addressing based on the order in which you chain them - just as the Renard protocol functions. In this case, all PICs get the same firmware with 1 as the starting address.
1. That's the approach that the Renard developers took - set the address of the first PIC on a board or in the chain, and everything downstream just takes the next X slots. So when they developed the DMX firmware, they chose to do the same thing. Strip off the next 8 channels and pass on the rest to anything following, including the next PIC on the board.
2. I asked the same question - why not pass thru the full DMX stream? But since the board designers didn't want to change anything to accommodate DMX specifically, they did it that way.
There's no DMX "standard" as far as how you treat the data stream. Normal DMX convention is that the signal is repeated to any downstream devices, but in this case, convention wasn't followed. If I use the DMX firmware in my Renard controllers (currently Ren48LSD), I'm planning to use a splitter to distribute the DMX stream and not place any devices downstream from the Ren's.
That is really odd. Why write firmware that seems to make it harder to cable and position your controllers? Sure makes you be on your toes as it applies to display layout. It's like the renard stuff tries to be more complicated than it needs to be. Cheap yes...but complicated. Thanks for the information..
I guess we could come at this from both sides. I could say that being forced to have to set the start address on every controller is complicated and burdensome. I could also say that positional auto-addressing is intuitive and simple.
With standard DMX, I can rearrange my cabling any way I want, and not have to worry about device addressing issues. Channel 24 is always on the same device and on the same port. But replace a 16 port device with a 24 port device, and you have issues. The first 16 channels are just as I expected, but the top eight channels on the new 24 port controller will mirror the first eight channels of the next device in the DMX addressing scheme. With the renard protocol (and it's brother Renard DMX), positional auto addressing makes sure I sure I don't I have any of the device addressing overlap that is allowed in the standard DMX protocol. I could also say that the ability to overlap or mirror channels is an advantage in the standard DMX world.
But I may still need to go back and rearrange my sequence channel mappings in either situation...
Ideally, to follow this to its logical conclusion: Why is there a device start address and then it just grabs the ports for the device in channel order? I should be able to set the DMX address of every single port of each device. Why fix my sequence? - just update my port addressing scheme to match my sequence. Talk about a setup and configuration utopia or nightmare - you pick...
In reality, I ended up running the renard DMX code on all renard hardware, because of the way I got started with this hobby. I thought I would be running DMX devices only, so I built a DMX dongle. Once I determined that the renard hardware design was less expensive and more open to development than my original path, I built renard controllers. But I am glad I have the DMX protocol to build on as I added several of the TigerDMX controllers to my setup this year.
To be honest, it's not that hard to have a hardware address of a controller, and set a "software" address of that controller over the wire. That way, I don't have to worry about which controller is plugged into another one, or to have a single chain.
I started out with AL hardware and that's how they did it and it made it easy for me to put controllers where I wanted, but change the connection between controllers at will. The software allowed me to keep my sequence the same, but reassign channel numbers to different controllers as needed.
It's similar with DMX. Yes, I have to set an address of a controller, but that usually stays the same, and I can change the wiring if I need to. With controllers that support RDM, setting the software "address" in a DMX world would be painless and done without having to visit the controller. No DIY controllers support RDM today, but it's headed in that direction.
Is it that hard to do with Renard? Not sure, and it may be limited by the speed of the processors, but some of the guys have already modified the Renard firmware to be able to "change" the address without recompiling. This is for the stock Renard firmwarel - not the DMX one.
Both the Renard DMX and the new Renard Start Address code store the start address in EEPROM, but neither have code to set the start address over the wire. And the current renard hardware does not have a spare pin to have a set address hardware toggle switch incorporated into its software design.
So yeah, the renard folks just layout the design, then figure out what channel that device will get because of its physical location in the chain. If we add a new device in the middle of a chain, we have to re-map the sequence channels to their new locations for the now further down the chain devices.
If you have splitters/or serial repeaters (such as the REN-W) then you need to start worrying about start addresses as multiple devices will start picking up the same address. This is when you need the Renard Start Address code to solve the problem. But yeah, the start address is compiled into the firmware.
If the PICkit programmer can change EEPROM values, then yes, you could update the value that was compiled in. I would need to research that.
The Renard DMX code takes in DMX frame/packet and outputs DMX frame/packet - so the downstream device would also need to be a DMX device. It does not convert the protocol to the renard stack. The Renard DMX difference from a standard DMX device, is that PIC "eats" the channels it uses, so the DMX frame/packet gets 8 channels smaller as it passes through each PIC.
Budude - That will work! I would hate pulling the chips just to change the DMX address each time I re-arrange. Last year was not a problem as I had all Renard hardware, bu this year I am mixing in some other DMX devices, so addressing may change.
smartalec - Yes, that is the Renard DMX code we are discussing.