wrong output mode (UART-DMX, but affects virtually elsewhere)

[rbalykov]

On startup UART sender has empty DMX frame.
This causes UART sequence BREAK-MAB-STARTCODE repeated without mandatory 24-byte payload.
During normal use, it seems to be full 512-byte frame, set to 0x00.

[peternewman]

Hi @rbalykov ,

Well spotted. I think it potentially can continue after start-up depending on how your frame is set, if you use ola_set_dmx, you can populate frame with fewer than 512 slots, which I think will therefore continue to show the problem:
http://docs.openlighting.org/ola/man/man1/ola_set_dmx.1.html

The relevant code is here:
https://github.com/OpenLightingProject/ola/blob/0.10/plugins/uartdmx/UartWidget.cpp#L119-L134

Firstly do you fancy having a go at fixing it? I think it should just be a case of adding a memset of zero if the length returned from the DMX buffer is less than 24, then incrementing the length to write.

If not, are you at least in a position to test it? I've not used the UART plugin, so I'd personally prefer to avoid jumping through all those hoops just to see if it works.

Then we can review which other plugins need fixing too.

[rbalykov]

 Hi Peter.ola_set_dmx is not so useful when you have to write 2-kilobyte command string to init 512 bytesFor me, its more reasonable to init universe on server, so any client on startup has appropriate data set. I could fix it on my own and commit for approval.Also, I made new USB-Serial device based on STM32 VID/PID and can commit it too.

[peternewman]

Hi @rbalykov ,

Sorry, I didn't explain very well, I mean I think if you try with ola_set_dmx and only set e.g. 3 channels, then "during normal use" it will continue to only send three channels, where that should be 24 to meet the timing requirements. We only want to fix it for the specific plugins that require it (rather than forcing everything to transmit 24, or even 512 slots), as existing or future plugins, especially IP ones, may not have that limitation/requirement. Equally something like an Enttec DMX USB Pro will hopefully do the maths internally, so if we set different timing parameters on the device, it will send out the correct minimum slot data.

That's great thanks anyway, a fix would be very appreciated, please can you target the minimum slot count fix at our 0.10 branch, as it's a bugfix.

Also, I made new USB-Serial device based on STM32 VID/PID and can commit it too.

The STM32 device sounds interesting, is that a brand new serial protocol, or have you just implemented the Enttec or another existing one on your microcontroller? That should probably be aimed at our master branch unless it's a very simple change.

[rbalykov]

The changes in code were wanted to add STM32 VID/PID in that tricky usb hotplug detector to make USB-DMXSo I made USB-Serial on STM32 emulating Enttec for now.

[peternewman]

I think the Enttec emulation should "just work", or may just be minor changes to give it more accurate naming, although feel free to push code for either.

For an example of adding a USB device to the hotplug detector, see:
https://github.com/OpenLightingProject/ola/pull/1147/files

There's also a readme for doing development work with this plugin:
https://github.com/OpenLightingProject/ola/blob/master/plugins/usbdmx/README.developer.md

The only thing I would say, someone has asked before, I'd be reluctant to add the generic STM32 VID/PID to OLA, as that means OLA will try and grab and talk to any STM32 device, which may well have unintended consequences. If you want to go down this route (rather than USB-Serial) then I'd recommend registering a PID at pid.codes:
http://pid.codes/

We've already done that for the OLA interface:
http://pid.codes/1209/ACED/

[peternewman]

Hi Peter.ola_set_dmx is not so useful when you have to write 2-kilobyte command string to init 512 bytesFor me, its more reasonable to init universe on server, so any client on startup has appropriate data set. I could fix it on my own and commit for approval.

Hi @rbalykov did you have a chance to do a pull request for this?

[rbalykov]

I have made changes to uart-dmx plugin, adding an option "device"-padding
Unfortunately, it messes with previous pull request (#1572) when I commit these changes.

[rbalykov]

here it is:
cdb1200

[rbalykov]

please can you target fix at our 0.10 branch.

Sorry for dumbness, does it mean:

1. fork ola on github
2. git clone to local machine
3. git checkout 0.10 (or 0.10.7 ?)
4. edit, commit, push

[peternewman]

please can you target fix at our 0.10 branch.

Sorry for dumbness, does it mean:

1. fork ola on github
2. git clone to local machine
3. git checkout 0.10 (or 0.10.7 ?)
4. edit, commit, push

Sorry @rbalykov I didn't realise I hadn't replied.

Yeah that's the idea, so we get a separate PR which is the OLA 0.10 branch with just the commits related to UART-DMX output count changes in, which can then be merged and release.