What is the purpose of muxSelectDigitalPin and muxSelectUart? It's only used in order to set the parameters in the serial communication? Or are essential in your code? You also could set the parameters with these commands:
ttyS0 is the port in the Digital pins (0 and 1).
system("stty -F /dev/ttyS0 250000");
system("stty -F /dev/ttyS0 cs8");
system("stty -F /dev/ttyS0 cstopb");
I toggle between digital output and UART pin modes to achieve the DMX specific "SAPCE for BREAK" signal as listed in the DMX512 link above, which should be a low level pulse on the TX pin of at least 88 us.
The problem is that with version 1.0.4, this pin multiplexing takes much longer than before, 5.5 ms vs. 45 ms.
In principle the break signal could be faked by switching to a lower baud rate and then sending a zero byte.
But switching between different rates via consecutive serial1.begin() call takes even longer, creating huge unnecessary gaps between two DMX frames.
After all the DMX protocol spec allows an update rate (= frame rate) of around 40 Hz, but only if the break pulses are not significantly longer than required.
Setting 250000 via stty didn't work. However I tested it in the shell with using the "setserial" command and its "custom divisor" option which does under the hood the same as my Arduino x86 core modification above. There was some problem, which I don't remember now, where setting all this from multiple system() calls was not appropriate.
I found a small work around, setting the gpio multiplexer from the linux terminal to regular pin mode and back to UART:
system("echo 1 > /sys/class/gpio/gpio41/value && echo 0 > /sys/class/gpio/gpio41/value");
This gives a low level break gap of under 3 ms, which is fine and even faster than using the mux* functions of the Arduino API before.
However, as soon as I put the two commands in separate system() calls, it takes a bit above 10 ms.
So I suspect that, instead of the API internals, maybe the compiler settings for Arduino sketches have be changed since Verison 1.0.4. in the Intel Arduino IDE!
Are debug symbols maybe now activated? Has the optimisation level been changed?
For the records, it is possible to set the serial1 to 251345 baud (almost 250k, well enough within DMX spec limits) with the following setup() config:
// set custom divisor 11 to get 251345 baud: system("setserial /dev/ttyS0 spd_cust"); system("setserial /dev/ttyS0 divisor 11"); Serial1.begin(38400); //this virtual rate setting of 38400 only tells the system to respect the custom baud rate set above system("stty -F /dev/ttyS0 cstopb"); //enable 2 stop bits
This works if the Baud_base is set too 2764800 (2764800 / 11 = 251345). It can be verified with "setserial -a /dev/ttyS0".
Now I remember, I added DMX baud rate configuration to the x86 Arduino core (available on github link above) to be independent of the base baud rate. Parsing the current base baud rate from the output of the setserial command would be too ugly inside the Arduino sketch IMHO. That's why I added code in the core to set the rate as close as possible to 250k depending on the actual base rate value.
Can it be assumed that all Intel Galileo boards will always be shipped with the same base baud rate of 2764800? Is it maybe a 16550A UART specific thing of the Quark, which can't be changed anyways? (calling e.g. "setserial /dev/ttyS0 Baud_base 3000000" fails)
If anyone wants a complete example sketch on how to send DMX packets on the Galileo equipped with a RS-485 driver shield I can provide it.
But it seems there is not much interest. My posts here contain all relevant details, though.
CMata_Intel, of course a lot of baud rates can be set (and thanks for the link to the manual never the less), but the one I need for DMX - something close to 250k - can't be set straight forward, as it is not a standard baud rate. Is is also not a standard baud rate on most *nix systems. Just test the commands you proposed! "stty -F /dev/ttyS0 250000" doesn't work, because it is not a standard baud rate, the error is "stty: invalid argument '250000'".
If you are curious, arduino-cores/TTYUART.cpp at master · ozel/arduino-cores · GitHub, defines all the supported baud rates. Which is why I started changing the code there, as an alternative to mess with setserial and stty calls on the command line.
I might publish an example sketch as a project. But as I wrote, the relevant code lines I used to create valid DMX packets are all documented above.