Uart.configure() problem

Feature Requests & Bug Reports
1

I’m using multiple uarts on an imp project. It’s necessary for the uarts to switch baud rate, framing configuration and even bind to different callbacks at various points during runtime. I’ve noticed a problem where the TX line will dip low for about 100us whenever I call uart.configure(). At low baud rates (4800 and lower), this can be really frustrating as it will be interpreted as a valid start bit, causing bogus frames to be read by any devices I’m talking to.

I understand that uart.configure() changes the settings of the relevant I/O pins by possibly clearing the previous config and replacing it using the new parameters, but it should only do that if the changes I’m requesting actually force a change on the I/O pins.

For instance, going from uart.configure(9600,8, PARITY_NONE,1,NO_CTSRTS,callback) to uart.configure(9600,7,PARITY_EVEN,1,NO_CTSRTS,callback) shouldn’t have any impact on the state of the TX line (but it does). I find that the line goes low even if I call uart.configure with unchanged parameters. I can remove the dip by putting weak external pull-ups on the TX lines, but this is surely something that can be resolved in ImpOS SW.

2

Hmm, try configuring the TX pin as DIGITAL_IN_PULLUP inbetween the reconfigures. I did work on this to get rid of the glitch on initial config, I suspect that reconfigures are disabling the peripheral briefly.

3

Yes, I did try this without success.

4

You may also want to try including uart.disable(), which should be called before the UART pins are reconfigured:

uart.configure(9600,8, PARITY_NONE,1,NO_CTSRTS,callback); ... uart.disable(); uart.configure(9600,7,PARITY_EVEN,1,NO_CTSRTS,callback);

5

No luck with uart.disable() either. It actually makes matters worse if I call it immediately before uart.configure() as the period the line goes low will extend to include the start bit and the first data bit (at low baud rates). I think the issue may be related to the default state of the I/O pins, which they clearly revert to (during uart.disable() and uart.configure()). If they are being used as uart tx lines, they are typically high when idle and should surely remain so even after uart.disable() is called.

6

We’ll take a look…