Flex strip GRB rather than RGB?

[rm357]

While RJ will assist you in writing software, he does not release source code or design documentation for his devices. Also, there is a general prohibition against making firmware for other people's hardware unless you have been given permission to do so.

The ssc has its own processor, so there is no contention with anything going on with the scheduler host machine.

As far as the order swapping in firmware goes, you need not have any concerns. There is no Microsoft junk in the firmware to cause bizarre operation for no apparent reason. There is no need to reduce the workload in the ssc as there is plenty of horsepower left after  doing the conversion from pixelnet to the 180x bitstream for the pixels.

My guess is that the ssc starts counting data bytes after the 170 marker until it gets to its start address. Then it starts storing those bytes based on the node type setting such that the data in memory is ordered rgbrgbrgbrgb... The bitstream is at slightly slower data rate than the pixelnet string, so you could have a simple delay of 3 or 4 pixel times after the start address is reached to start an bitstream out process that will run until the maximum number of pixels in the string is transmitted, then stop. The pixelnet receive process would be allowed to interrupt the bitstream out process to write each byte of data it receives to the data buffer.

I'd guess that the code running the lynx express is far more complicated, and it runs on the same type PIC micro controller/processor.

[fyb2000]

I have not, and I am still not asking for the release of any software, modification of the firmware or anything of the sort. I am just trying to figure out, when faced with 2 different solutions to solve one common problem, what the best approach is for ->my<- own setup, based on as much information I can gather. I am not saying there is a problem with any of the goodies we have to play with, or that their design was missing something. I am not asking anyone to work anymore than they are willing to, modify something they have designed or give the keys to the whole thing when they are not willing to. Again, as I said several times, there is 2 solutions to solve the same issues, I just like to be able to judge which is more efficient for my own use and that will be the one I'll adopt. In no way have I implied that the current firmware was causing delays leading to artifacts, with the current configurations and the general use.
To be 100% clear, I am neither asking for a rewrite of the firmware, nor planning of reverse engineering the current one and rewrite it and distribute it to 3rd party or use it myself. There is several ways to write the part you gave a guess to, I appreciate your input and wil assume that you have knowledge of the way the firmware is written. If this is the case, could you just tell me if, when selecting a flex string (or square...) rather than the default smart string in the utility, the firmware ends up spending more cycles at run time due to the swizzeling operation or not. That is really all I want to know so I can setup my system based on my own preferences.
Thanks,
Francois

[rm357]

Whoa whoa whoa, I think you took what i said wrong.

I didn't mean to offend, just point out that the cycles you want to save are a moot point.

it was also a good opportunity to remind everyone of DLA policies and rules before this headed down the wrong path. There are lots of new folks and I don't think everyone reads the rules... I know I tend to give too much technical detail, which helps some and just confuses others. We want this hobby to be accessible to all.