When I tried to fix what I expected to be a minor TODO (making <512 channels work and/or improving throughput), I found that the actual reason for e.g. 256 channels not working was an endianness issue. While I was aware endianness in terms of hi/lo byte of a 16-bit word, I missed that on the 32-bit stage. Not only resulted this in channels being swapped but also in some garbage at the end of the whole packet and this obviously confused some fixtures.
Because endianness is sometimes kind of counterintuitive and mixing UART/I2S in code was getting a bit messy (you already noticed the same), I decided to put the I2S code into 2 classes. I added documentation and test in the test folder, therefore I won't explain again here.
Using the former implementation, there were also few options for optimization of the frame rate other than reducing the number of channels, because every byte needed to reside inside a 16-bit block. This is now completely flexible although I recommend to still use alignment. See also the docs.
Because analysis on the oscilloscope became annoying and error-prone, I recently bought a very basic logic analyzer and made sure the signal matches the "working" one as closely as possible. When I attached the knowingly buggy fixture, it worked out the box like a charm. I found BTW that my controller actually sends only 192 channels although it's sold as DMX512.
I hope the comments in the code and the test/README.md will be verbose enough to understand the concepts.
I am working on a feature for the webserver to set the number of channels and timings parameters at runtime to find working ranges for my fixtures quicker than before.
Right now I used trial and error, interval nesting, and repeatedly upload of my sketch to the esp8266.
I did not want to pack this in this pull request to avoid information overflow but I'd gladly do so when it finally works and you don't mind.
Hi Robert.
When I tried to fix what I expected to be a minor TODO (making <512 channels work and/or improving throughput), I found that the actual reason for e.g. 256 channels not working was an endianness issue. While I was aware endianness in terms of hi/lo byte of a 16-bit word, I missed that on the 32-bit stage. Not only resulted this in channels being swapped but also in some garbage at the end of the whole packet and this obviously confused some fixtures.
Because endianness is sometimes kind of counterintuitive and mixing UART/I2S in code was getting a bit messy (you already noticed the same), I decided to put the I2S code into 2 classes. I added documentation and test in the test folder, therefore I won't explain again here.
Using the former implementation, there were also few options for optimization of the frame rate other than reducing the number of channels, because every byte needed to reside inside a 16-bit block. This is now completely flexible although I recommend to still use alignment. See also the docs.
Because analysis on the oscilloscope became annoying and error-prone, I recently bought a very basic logic analyzer and made sure the signal matches the "working" one as closely as possible. When I attached the knowingly buggy fixture, it worked out the box like a charm. I found BTW that my controller actually sends only 192 channels although it's sold as DMX512.
I hope the comments in the code and the test/README.md will be verbose enough to understand the concepts. I am working on a feature for the webserver to set the number of channels and timings parameters at runtime to find working ranges for my fixtures quicker than before. Right now I used trial and error, interval nesting, and repeatedly upload of my sketch to the esp8266.
I did not want to pack this in this pull request to avoid information overflow but I'd gladly do so when it finally works and you don't mind.
Greeting from Cologne, Artur