Unreasonably slow hardware serial support

How slow can something like a Mega go? Experimentation suggests 300 bps.

Is there an "approved" way of getting slower data rates, i.e. which doesn't screw up the rest of the libraries etc.? I'd like 10 bps although I'd settle for 20.

MarkMLl

MarkMLl:
How slow can something like a Mega go? Experimentation suggests 300 bps.

Is there an "approved" way of getting slower data rates, i.e. which doesn't screw up the rest of the libraries etc.? I'd like 10 bps although I'd settle for 20.

MarkMLl

given how slow this data rate is, why not just use software serial library which should go as slow as you want

sherzaad:
given how slow this data rate is, why not just use software serial library which should go as slow as you want

More than anything else, trying to minimise the number of things going on at the same time (i.e. including higher-speed data transfer, "sums" to make sense of what's being seen, and so on).

I've come across https://forum.arduino.cc/index.php?topic=351100.0 which identifies the lowest standard speed as 245 bps. I don't think there's an easy way around that other than using a software implementation; I don't think that anybody's selling USART chips with I2C or SPI interfaces these days, the nearest I see is various UARTs on OpenCores for implementation using an FPGA.

MarkMLl

(deleted)

spycatcher2k:
10 bps - I’d be tempted to write my own function to do this. But WHY do you need to go this slow?

VLF submarine communication?

TheMemberFormerlyKnownAsAWOL:
VLF submarine communication?

Radiocode clock (MSF, 60 kHz), I'm not entirely happy with some of the stuff I've seen in other implementations. If I were totally crazy I'd be comparing received pulse edges with the CW phase.

MarkMLl

For very slow rates bit-bashing isn't too difficult.

MarkT:
For very slow rates bit-bashing isn't too difficult.

I know, I've been doing it for 40 years.

But as I've said: if there had been suitable hardware available, it would have been worth offloading it.

MarkMLl

MarkMLl:
if there had been suitable hardware available, it would have been worth offloading it.

Why?? At that rate, the overhead would be difficult to even measure. Why not spend your time on optimizing something that might actually make a measurable difference?

Regards,
Ray L.

Isn’t it preferable to NOT do this in hardware, so that you have timing information available?

The USART Baud Rate Register (UBBR) sets the hardware baud rate. It can contain 12 bits so the maximum value is 4095.

Baud Rate is 'System Clock / (16 * (UBRR+1))'so the minimum Baud rate is: 16,000,000 / (16 * (4096)) = 16,000,000 / 65536 = 244.140625 Baud

You could run your processor at the supported rate of 8 MHz to get 122.0703125 Baud.

You could run your processor at 4 MHz to get 61.03515625 Baud, 2 MHz to get 30.517578125 Baud, or 1 MHz to get 15.2587890625 Baud. The millis(), micros(), and delay() functions will still work but ‘delayMicroseconds()’ only works at 8, 16, and 20 MHz (anything not 16 or 20 is assumed to be 8).

If you want integer baud rates: 250 Baud (UBRR = 3999) at 16 MHz is 125 Baud at 8 MHz.

TheMemberFormerlyKnownAsAWOL:
Isn't it preferable to NOT do this in hardware, so that you have timing information available?

/If/ suitable hardware had been available, then I would have done something like also tying the signal to a pin which could raise an edge-triggered interrupt.

MarkMLl

If you want to explore very low baud rates, check out the SlowSoftSerial work by Paul Williamson.

It’s for a Teensy 3.x or 4.x board under the Arduino environment

johnwasser:
The USART Baud Rate Register (UBBR) sets the hardware baud rate. It can contain 12 bits so the maximum value is 4095.

Baud Rate is 'System Clock / (16 * (UBRR+1))'so the minimum Baud rate is: 16,000,000 / (16 * (4096)) = 16,000,000 / 65536 = 244.140625 Baud

You could run your processor at the supported rate of 8 MHz to get 122.0703125 Baud.

You could run your processor at 4 MHz to get 61.03515625 Baud, 2 MHz to get 30.517578125 Baud, or 1 MHz to get 15.2587890625 Baud. The millis(), micros(), and delay() functions will still work but ‘delayMicroseconds()’ only works at 8, 16, and 20 MHz (anything not 16 or 20 is assumed to be 8).

If you want integer baud rates: 250 Baud (UBRR = 3999) at 16 MHz is 125 Baud at 8 MHz.

Thanks John, a very useful summary but I feel I have to bow to the consensus opinion :slight_smile:

MarkMLl

MarkMLl:
Radiocode clock (MSF, 60 kHz), I'm not entirely happy with some of the stuff I've seen in other implementations. If I were totally crazy I'd be comparing received pulse edges with the CW phase.

MarkMLl

Ignoring for a moment the baud rate problem and looking at the protocol for the MSF signal encoding, it isn't obvious to me how a hardware UART might be applied to more efficiently decode the signal. Did you have a concept in mind?

MarkMLl:
Radiocode clock (MSF, 60 kHz), I’m not entirely happy with some of the stuff I’ve seen in other implementations. If I were totally crazy I’d be comparing received pulse edges with the CW phase.

MSF isn’t a 7 or 8 bit framed asynchronous protocol. How do you expect to receive it with a standard UART?

aarg:
MSF isn't a 7 or 8 bit framed asynchronous protocol. How do you expect to receive it with a standard UART?

Looks like perfectly adequate 5N2 10 bps to me. I assure you I've seen weirder protocols.

MarkMLl

MrMark:
Ignoring for a moment the baud rate problem and looking at the protocol for the MSF signal encoding, it isn't obvious to me how a hardware UART might be applied to more efficiently decode the signal. Did you have a concept in mind?

Well, as I've said to somebody else: the sequence every second can be interpreted as a start bit, up to four data bits (of which only two are used in most seconds) and an adequate amount of stop bit. /If/ suitable hardware had been available, it would have seemed reasonable to accumulate that into a message to be parsed at the start of the next minute.

However it's been pointed out that finagling the hardware would probably be more trouble than it's worth, and in practical terms a software UART would be easy to code- particularly since it is Rx-only, with the additional advantage that it would be easy to log the falling edge of the per-second start bits.

I guess I'm spoilt by the flexibility of things like the Zilog SCC chips :slight_smile:

MarkMLl