Possible idea to fix slow Break time on serial-based controllers degrading refresh rate

Hi.

Having the same problem on another platform (Linux, PC), I found another solution : instead of explicitely sending a Break, if we send a null byte at a slow enough baudrate, it will be interpreted as a Break followed by the Mark-After-Break on the fixtures' side.
(I thought about this trick first for microcontrollers with rudimentary UARTs which can't explicitely send Break states).

Therefore, in the _transmit() method from the SerialController class, instead of :

        # Write
        self.__device.send_break(100e-6)
        sleep(10e-6)
        self.__device.write(data)

I would do something like :

        #self.__device.flush()
        self.__device.baudrate = 80000
        self.__device.write(bytearray(0))
        self.__device.flush()
        self.__device.baudrate = 250000
        self.__device.write(data)
        #self.__device.flush()

Because the serial device stays opened, we need to flush the write operations before changing the baudrate (it is not done in the Serial class, despite the reconfiguration), especially just after writing the null byte at a slower baudrate.
However, whereas a flush after writing the DMX data is required in a raw test of this code snippet, it seems to break things when done inside the SerialController class, for an unknown reason.

So the fix can unfortunately not be validated yet, not counting that I can't test it on several platforms.
By the way, the raw test shows a refresh rate of 34Hz or a bit more (VS the theoretical maximum of 44Hz) for a 512-channel frame : it seems not so bad, given the processor time consumed by the Python interpreter and all software layers down to the kernel.

What do you think about it ?

Commencez par lire la méthode SerialController._transmit() et comparez sa séquence send_break actuelle avec la séquence proposée de débit en bauds et d’octet nul. Reproduisez le test série brut, puis validez le comportement du contrôleur sur les plateformes disponibles ; le travail est considéré comme terminé lorsque l’actualisation DMX est améliorée sans les problèmes de vidage ou de reconfiguration décrits.