cycle.py only works up to 254 channels.

[jessecobra]

cycle.py controller only only outputs correctly up to 254 channels. Not sure if the issue is on the controller or dmx server side. I'll debug further eventually.

[kj800x]

The problem lies with the dmx server. I noticed it too while going through the code. The channel is stored as a byte at some point (0-255) which is why it doesn't go all the way up to 512.

[lm1baker]

Two problems. First, the variables for the PRU (pin, length, halt etc.) Are only stored at 0x100, which is just 256 bytes above the array of channel values. Giving the server more than 255 values will overwrite these control variables, including the PRU 'halt' flag.

Second: The length is only stored in a single byte, and the assembly instructions for the compare with the loop counter only act on a single byte (despite the 32-bit registers in the PRU).

I solved the first of these by setting the variables 4 bytes apart, starting from 0x1000 (there is actually quite a lot of memory available to each PRU). For the second, I changed the compare in the PRU assembly to use w0 insted of b0, and simply wrote the number of channels to two bytes using modulo and divide 256.

[lm1baker]

I am using this as a base to extend to both PRUs, and "DMX extended" packets with >1024 bytes. May submit a pull req if I have something a little more polished.

[kj800x]

@lm1baker I don't know if this would be helpful, but I've got something working too (also not quite polished enough for a pull request):
https://gist.github.com/robodoggy/78026f6b70304bd2a6e3

I'm sure how you solved the QBEQ problem using words; The TI documentation makes it look like it only works for a byte. I'd love to see a code snippet.

I ended up just doing comparisons on the low and high bytes, but I think this will add an extra instruction cycle for (channels > 255). I'm not sure how much this will affect the DMX signal, but it's something I'm weary of.

I've never heard of "DMX extended", and a quick google search doesn't turn much up. Is it a real thing? :)

[lm1baker]

The op(255) is a due to a restriction on the number of bits used to encode the argument, means one cannot (for example) offset an address by an integer greater than 255 without first loading it into a register. Removing the .b0 entirely will allow a full 32-bit compare (as shown in the example) - for 4 billion or so channels (not that a BB has enough RAM).

DMX extensions are not real standards, (but when did that ever stop a chip maker?) http://www.colordreamer.com/upfile/files/Colordreamer%20Super%20Decoder%20DIP%20Guide.pdf gives an idea of the common 'extensions' that manufacturers may give to dmx512 (higher bit rates, larger address spaces).

My proof of concept back then called for two "rope lights", each with synchronous update of 400 controllable RGB LEDs (the DMX order was BGR, one byte each for a rather non-standard frame length of 1200 bytes).