Weirdo baud rates should work, per page 791-792 of this massive tome: http://www.st.com/web/en/resource/technical/document/reference_manual/CD00171190.pdf
There's clearly no support for a TX_EN exposed in Espruino, and a brief (hah) reading of that section seems to indicate there is no such functionality available in the hardware either (same section of that monstrosity). They have CTS and RTS, described on page 808, and you could enable them with appropriate poke()ing.... but neither of them look like what you're looking for.
You could certainly do it in software though.
There was another question recently related to someone doing this for a motor controller.
In the end, they had some success using a setTimeout and digitalWrite with a period that they'd worked out from the data length...
It's not ideal... I guess another option might be if I added a 'waitUntilSent' method for serial. Due to the delay of executing the pin might not change state immediately, but it may well be good enough.
This could be done in software by setting a required pin that you wanted to use for the TXEN when configuring the UART. Then before data was loaded into the UART and its FIFO this TXEN pin could be set. Then by having a simple interrupt handler for the TC (transmit complete) interrupt of the UART you could reset this TXEN pin. If the TXEN bit was not specified or was 0 when the UART was configured then GPIO pin would be toggled.
This would be nice as no timers would be required, would work no matter what the baud rate and should require very little additional code.
Note it would be could to be able to specify the state the TXEN pin should be in for Transmit, by default for a MAX485 type 8 pid device TXEN should be high for transmit, and low for recieve. In this case as soon as the UART is configured with TEXN support, the requested TXEN line should be taken low to allow RS485 reception (Which should be the default state)
Yes, I was wondering about that - I guess ideally there would be a more general purpose solution, but that could definitely work.
IRQ is a bit tricky because you're interrupted when a new byte is needed - NOT when the last byte has been fully sent.
On the implementation side it might be worth adding a new flag for the 'device type' that would allow a pin to be set of cleared. That way the event could be queued up in non-IRQ logic - it even means that it might be possible to queue a set and then a reset, pulsing a specific pin after serial data was sent.
If you look at the Data sheet there is an interrupt called the TC (Transmit complete) interrupt that is triggered when the last bit of the last byte has been transmitted see page attached on the TC / TXE behaviour, you would just need to check for the TC bit in the UART interupt and if a Portline was defined as TXEN then just toggle it. Do you use DMA for UART transmission? don't think this would cause an issue but you world need to ensure that the TXEN line was asserted before the TXE bit was set and the first byte was loaded into the transmit buffer.
I'm guessing you could add a callback event that gets called when ever the Transmission is complete, and this could set/reset the port line you were using for the TXEN
Yes, that could work - thanks :)
The issue with a callback is that as there is no preemption, you can't guarantee that it'll be called right after transmission is complete.
I would like to interface one of the UART's to a Half Duplex RS485 link. Specifically this would be for Modbus RTU communication at 115200 baud. You could use an interupt handler in the TC bit of the UART to toggle a GPIO line off at the end of transmission, but would need to set this GPIO at the start of transmission. It doesn't look like the STM32 chip provides direct hardware support for toggling a TX_EN line like some chips do. Any idea's how I might go about doing this?
Also can I set non standard baud rates like 250,000 baud (DMX) and 31,250 (MIDI) for the UARTS, I'm guessing you can as they have fractional divisors for the baud rate generators.