UART Serial library

[DominicanMS]

Good evening, do you want to know if the library works just like Ralph Doncaster with just one ping? modifying the file core_settings.h file.

#define UART_TX_PIN PB0
#define UART_RX_PIN PB1

[MCUdude]

I don know if I understand your question, but if you only want to use Tx, for instance, it will not initialize the Rx pin if you don't call any of the Serial read functions.

[DominicanMS]

AVR half-duplex software UART supporting single pin operation

[MCUdude]

@nerdralph I guess one can use the setup in the picture above if both Rx and Tx pin is defined to the same pin?

[nerdralph]

No, the version used by MicroCore actively drives the Tx line high. The single-pin version uses open-drain signalling, so puts the line to high-Z, and and it is pulled up externally for high.
It might make sense to use the open-drain version since it will also work fine when Tx and Rx use separate pins, as long as the Tx line is pulled high externally. Many USB-ttl dongles have a pullup on the Rx line for this reason. My PL2303HX adapters have a very weak pullup on Rx, and so need an external pullup for open-drain. I recently tested a CP2101, and they have a strong Rx pullup.

[DominicanMS]

nerdralph Well, I thought it was a bad connection using the BasicSerial3 library and it works correctly

[MCUdude]

@nerdralph would it be possible to implement it and trigger it by a macro in core_settings.h?

#define SINGLE_WIRE_SERIAL

Or even better, define both pins to the same physical pin:

#define UART_TX_PIN PB0
#define UART_RX_PIN PB0

[nerdralph]

I wrote the half duplex code 6 years ago. I'm pretty sure I can do better now. I've already started rewriting my latest BBuart code to use open drain. I'll make sure it works whether UART_TX and UART_RX are the same or different. While I'm at it, I'll improve RxByte so that it's not busy during the full frame. That'll give the user code more time to process the incoming data.

…

On Sun, Jan 19, 2020 at 3:42 PM Hans ***@***.***> wrote: @nerdralph <https://github.com/nerdralph> would it be possible to implement it and trigger it by a macro in core_settings.h? #define SINGLE_WIRE_SERIAL Or even better, define both pins to the same physical pin: #define UART_TX_PIN PB0 #define UART_RX_PIN PB0 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#101?email_source=notifications&email_token=ABKNZ6WCELUAB37FZAJ4EG3Q6SUL3A5CNFSM4KIWD6W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJK2SVQ#issuecomment-576039254>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKNZ6VS2ENMAUISOIL774TQ6SUL3ANCNFSM4KIWD6WQ> .

[nerdralph]

While working on the updated UART code, I think I figured out a way to support lower baud rates (as low as 4800bps at 9.6Mhz). It would require some tricky coding to recognize the low baud rates, and conditionally compile a different version of the bit delay code. What I'm wondering is how useful this would be. If 95% of MicroCore users don't have a need for anything slower than 19.2kbps @9.6M and 9600@4.8Mhz, then I probably won't bother.

[MCUdude]

While working on the updated UART code, I think I figured out a way to support lower baud rates (as low as 4800bps at 9.6Mhz). It would require some tricky coding to recognize the low baud rates, and conditionally compile a different version of the bit delay code. What I'm wondering is how useful this would be. If 95% of MicroCore users don't have a need for anything slower than 19.2kbps @9.6M and 9600@4.8Mhz, then I probably won't bother.

It would absolutely great to have a wider range of supported baud rates for a given clock frequency! So your "new" code will support this plus single-wire RX/TX? I'm more than willing to test all this if you publish your code somewhere!

[nerdralph]

While working on the updated UART code, I think I figured out a way to support lower baud rates (as low as 4800bps at 9.6Mhz). It would require some tricky coding to recognize the low baud rates, and conditionally compile a different version of the bit delay code. What I'm wondering is how useful this would be. If 95% of MicroCore users don't have a need for anything slower than 19.2kbps @9.6M and 9600@4.8Mhz, then I probably won't bother.

It would absolutely great to have a wider range of supported baud rates for a given clock frequency! So your "new" code will support this plus single-wire RX/TX? I'm more than willing to test all this if you publish your code somewhere!

OK. As you wish.
The earlier versions I wrote were in pure asm because I couldn't make much sense of gcc's inline asm rules. Now that I've had a few years to figure it out, I'm writing the new version in inline asm, which should make it easier to integrate with other C/C++ code. I should have something ready for testing in a few days.

[nerdralph]

I just finished testing transmit at 9600, 38.4k, and 115.2k. It looks good on the scope, and with a couple different USB-ttl adapters. No docs yet, so I pushed my test code (pu.c) as well.
https://github.com/nerdralph/nerdralph/tree/master/picoUART
p.s. I'm still at the redesign stage for the receive side; no prototype code yet.

[MCUdude]

That's great! The existing (MicroCore) code works with higher baud rates (for 9.6 MHz). Does this code too?

table from core_settings.h

// | Clock & baud | 460800 | 250000 | 230400 | 115200   | 57600    | 38400 | 19200    | 9600     | 4800 | 2400 | 1200 |
// |--------------|--------|--------|--------|----------|----------|-------|----------|----------|------|------|------|
// | 20 MHz       | X      | X      | X      | X (def.) | X        |       |          |          |      |      |      |
// | 16 MHz       | X      | X      | X      | X (def.) | X        | X     |          |          |      |      |      |
// | 12 MHz       |        | X      | X      | X (def.) | X        | X     |          |          |      |      |      |
// | 9.6 MHz      |        | X      | X      | X (def.) | X        | X     |          |          |      |      |      |
// | 8 MHz        |        | X      | X      | X (def.) | X        | X     |          |          |      |      |      |
// | 4.8 MHz      |        |        |        | X        | X (def.) | X     | X        | X        |      |      |      |
// | 1.2 MHz      |        |        |        |          |          | X     | X (def.) | X        | X    | X    |      |
// | 1 MHz        |        |        |        |          |          | X     | X (def.) | X        | X    | X    |      |
// | 600 kHz      |        |        |        |          |          |       | X        | X (def.) | X    | X    | X    |
// | 128 kHz      |        |        |        |          |          |       |          |          |      |      |      |

[nerdralph]

This version is even better. From the comments in picoUART.h: * picoUART is accurate to the cycle (+- 0.5 cycle error) * 0.64% error at 115.2k/8M and 0.4% error at 115.2k/9.6M It'll even go to 460.8k@9.6M. 460.8k is 20.833 cycles/bit at 9.6M, so picoUART will output 1 bit every 21 cycles, making it 0.8% slow.

…

On Sat, Jan 25, 2020 at 11:49 AM Hans ***@***.***> wrote: That's great! The existing (MicroCore) code works with higher baud rates (for 9.6 MHz). Does this code too? table from core_settings.h // | Clock & baud | 460800 | 250000 | 230400 | 115200 | 57600 | 38400 | 19200 | 9600 | 4800 | 2400 | 1200 | // |--------------|--------|--------|--------|----------|----------|-------|----------|----------|------|------|------| // | 20 MHz | X | X | X | X (def.) | X | | | | | | | // | 16 MHz | X | X | X | X (def.) | X | X | | | | | | // | 12 MHz | | X | X | X (def.) | X | X | | | | | | // | 9.6 MHz | | X | X | X (def.) | X | X | | | | | | // | 8 MHz | | X | X | X (def.) | X | X | | | | | | // | 4.8 MHz | | | | X | X (def.) | X | X | X | | | | // | 1.2 MHz | | | | | | X | X (def.) | X | X | X | | // | 1 MHz | | | | | | X | X (def.) | X | X | X | | // | 600 kHz | | | | | | | X | X (def.) | X | X | X | // | 128 kHz | | | | | | | | | | | | — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#101?email_source=notifications&email_token=ABKNZ6T5EWYO6YYPIFU57ULQ7RNQHA5CNFSM4KIWD6W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ47DFI#issuecomment-578417045>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKNZ6SHTHFJTXVIFXVGH7LQ7RNQHANCNFSM4KIWD6WQ> .

[nerdralph]

I just tested 500k & 921.6k on a slow t13 that runs at 9.4M instead of 9.6, with F_CPU=9400000.
At 921.6, one bit is transmitted every 10 cycles vs 10.2 for optimal, making it 2% fast.
No errors receiving with a ch330N.
For a t13 running at an exact 9.6M, 921.6k will be 4.2% fast, and therefore not recommended.

[nerdralph]

The new version is ready for testing.
https://github.com/nerdralph/nerdralph/tree/master/picoUART