I wasn't trying to carefully measure the limits of the comms. It was a "are the calculated dividers good enough for a for a borderline setup?" The answer was yes, better than expected.
New round of tests indicate an rx smartpin needs sysclock at 5x the baud before it is reliable. There were some 3's and 4's that appeared to be functioning but it wasn't obvious why.
I am a bit puzzled as to why it is a surprise that TX works reliably at 2x sysclk and RX requires 5x sysclk. The smart pin timing and sysclk are coming from the same source so they are synchronized, whereas on RX the data is coming from a source whose sysclk is not synchronized to the RX smart pin timing. Even if the RX and TX are coming from smart pins on the same P2 there may be enough sysclk phase difference and transmission delays to be a problem.
There were some 3's and 4's that appeared to be functioning but it wasn't obvious why.
Can you expand on what 'some' means here ?
Given my tests on UB3, I might have expected values of 3.0 and 4.0 to work ? (ie ones with no NCO jitter, just sampling jitter )
Did you try with 2 stop bits ? I found UB3 did not manage 8MBd (/3) without 2 stop bits.
P2 may have a similar caveat around Mid-Stop -> RX-Edge handover, needing to be some N SysClks min.
New round of tests indicate an rx smartpin needs sysclock at 5x the baud before it is reliable.
Do you mean in a more general any-baud sense ?
At larger X, the NCO jitter jumps get smaller, and (eg) the increment from 5 to 5+1/8 fraction, is ~ 2.4%, so there you are getting to the region of covering any baud.
There will be caveats, but hopefully no unexpected ones
eg I do not expect the NCO fraction to be useful at very small integer divides.
One test I like to run on UARTS, is to map the hardware possible increments in BAUD. On most chips, you can derive a virtual baud clock, eg 24MHz/N is common, as is 12MHz/N
As expected, as baud get higher, the granularity increases, and you cannot cover all MHz values
Q: Do you know how many Sysclks P2 needs, to transition from Mid-Stop bit to Rx-Start-Edge sampling modes ?
All my tests are at fractions. So when I say reliable I mean every tested fraction from there on.
Ah, well at low integer values, those fractional bits will have huge jitter effects, right?
Yes, if you expect every possible fraction to give a valid baud output, you will need to be in the region where the fractional step is a small %.
The reported 5 and above, is slightly worse than I would have expected as that is ~ 2.4% steps, which should resolve to a balanced +/- 1.2% from some ideal baud value, provided the maths rounds correctly.
However, if the maths rounds asymmetrically (which I have seen on some UARTS ) then you get 0..2.4% error sawtooths.
At lower divide ratios, there should still be baud solutions, but they may not be continual, the user may have to choose specific baud-MHz values.
eg 4.0 should be fine, and I'd hope that 3.0 was also OK on RX ? ie a 24MHz P2 might Rx an 8Mbd data stream ok, and a 32MHz P2 should manage 8Mbd with 4x ?
The SiLabs EFM8UB3 manages /3 RX taking a 24MHz baud clk to 8MBd Rx.
I just had a look at sysclock of 2x baud on the scope and there is notable idle time between absolutely every character transmitted in the tight transmitting loop. And with fractioning up, the idle gap shortens. That probably means that the receiving loop is speed limited by my code execution time. Not something I'd considered.
And notably, even at 2x baud, the first received character is always correct value. Would seem to be okay with suitably spaced data then ... typing a key sequence, without hitting two keys at once, produces correct data. Cool.
And notably, even at 2x baud, the first received character is always correct value. Would seem to be okay with suitably spaced data then ... typing a key sequence, without hitting two keys at once, produces correct data. Cool.
Is that self testing on P2-Tx to P2-Rx, or is that using an external UART ?
I'd expect self testing to give slightly faster failure points, as the random phase and small skews are avoided. Still, it is good to see x2 works, as that proves the logic.
How many stop bits are needed between two chars ?
I just had a look at sysclock of 2x baud on the scope and there is notable idle time between absolutely every character transmitted in the tight transmitting loop.
What can that reduce to ? I think Chip has mentioned SPI can sustain continual sending, as that's needed for things like i2s.
Such Tx gaps are not drop-dead, but they do lower sustained throughputs, and a more subtle issue is if you use a `spaced Tx` for testing, and then move to a better non-spaced UART, the testing was less use..
For my UARTs tests I use FT232H, as I know that is able to sustain gapless Tx, of whatever Stop/Parity I specify. FT2232H is even better, IIRC it can manage 12MBd full duplex sustained.
That probably means that the receiving loop is speed limited by my code execution time. Not something I'd considered.
Yes, servicing at these high speeds (low divides) needs extra care.
It took me many iterations of hand-crafted Assembler, in a priority interrupt, to get EFM8UB3 to sustain 8MBd (8.n.2) with its 48MHz sysclk.
The UB3 has a 4 byte FIFO, which helps on the longer paths when you hit buffer boundaries.
With UARTS you can easily specify 2 stop bits and MARK parity, to buy a few extra cycles of headroom, but above that is not so portable.
Is that self testing on P2-Tx to P2-Rx, or is that using an external UART ?
You've got a short memory there JMG. I'm just typing at it. Either single keypresses or copy'n'paste, depending on whether I want contiguous or single characters.
What can that reduce to ? I think Chip has mentioned SPI can sustain continual sending, as that's needed for things like i2s.
I know you've been reading my testing with SPI bursting and subsequent use of the streamer. The conclusion there was the software can't go as fast as the smartpin. A streamer is superior for top speed but even then the bursts would either be repeating like with video or still have large gaps to deal with subsequent processing.
Yes, ultimately, but you can adjust PC side to 2 stop bits, or force MARK parity to get 3 stop bits.
Each increment buys more software overhead sysclks.
Chip,
What sort of execution overheads are there on an ISR? I'm guessing 8 clocks including the RETI.
That sounds correct.
Ah, I just realised 8 clocks is what I've measured too. With the 10 clock result I'd gotten, I didn't account for the 2 clocks of the GETCT instruction.
It never occured to me to round the fractional baud computation. Darn.
Chip,
What sort of execution overheads are there on an ISR? I'm guessing 8 clocks including the RETI.
That sounds correct.
Ah, I just realised 8 clocks is what I've measured too. With the 10 clock result I'd gotten, I didn't account for the 2 clocks of the GETCT instruction.
It never occured to me to round the fractional baud computation. Darn.
It that something in the ROM?
It's in the smart pin logic. Instead of starting the sub-bits accumulator at zero, I would have started it at one-half. Each overflow results in the extra one-clock wait.
It's in the smart pin logic. Instead of starting the sub-bits accumulator at zero, I would have started it at one-half. Each overflow results in the extra one-clock wait.
Okay, I think I understand now, like smartpin mode %00110 = NCO frequency.
Upon WXPIN, X[31:16] is written to Z[31:16] to allow phase setting.
Comments
Okay. I was thinking there were some caveats.
Given my tests on UB3, I might have expected values of 3.0 and 4.0 to work ? (ie ones with no NCO jitter, just sampling jitter )
Did you try with 2 stop bits ? I found UB3 did not manage 8MBd (/3) without 2 stop bits.
P2 may have a similar caveat around Mid-Stop -> RX-Edge handover, needing to be some N SysClks min.
Do you mean in a more general any-baud sense ?
At larger X, the NCO jitter jumps get smaller, and (eg) the increment from 5 to 5+1/8 fraction, is ~ 2.4%, so there you are getting to the region of covering any baud.
eg I do not expect the NCO fraction to be useful at very small integer divides.
One test I like to run on UARTS, is to map the hardware possible increments in BAUD. On most chips, you can derive a virtual baud clock, eg 24MHz/N is common, as is 12MHz/N
As expected, as baud get higher, the granularity increases, and you cannot cover all MHz values
Q: Do you know how many Sysclks P2 needs, to transition from Mid-Stop bit to Rx-Start-Edge sampling modes ?
Ah, well at low integer values, those fractional bits will have huge jitter effects, right?
Yes, if you expect every possible fraction to give a valid baud output, you will need to be in the region where the fractional step is a small %.
The reported 5 and above, is slightly worse than I would have expected as that is ~ 2.4% steps, which should resolve to a balanced +/- 1.2% from some ideal baud value, provided the maths rounds correctly.
However, if the maths rounds asymmetrically (which I have seen on some UARTS ) then you get 0..2.4% error sawtooths.
At lower divide ratios, there should still be baud solutions, but they may not be continual, the user may have to choose specific baud-MHz values.
eg 4.0 should be fine, and I'd hope that 3.0 was also OK on RX ? ie a 24MHz P2 might Rx an 8Mbd data stream ok, and a 32MHz P2 should manage 8Mbd with 4x ?
The SiLabs EFM8UB3 manages /3 RX taking a 24MHz baud clk to 8MBd Rx.
And notably, even at 2x baud, the first received character is always correct value. Would seem to be okay with suitably spaced data then ... typing a key sequence, without hitting two keys at once, produces correct data. Cool.
What sort of execution overheads are there on an ISR? I'm guessing 8 clocks including the RETI.
I'd expect self testing to give slightly faster failure points, as the random phase and small skews are avoided. Still, it is good to see x2 works, as that proves the logic.
How many stop bits are needed between two chars ?
What can that reduce to ? I think Chip has mentioned SPI can sustain continual sending, as that's needed for things like i2s.
Such Tx gaps are not drop-dead, but they do lower sustained throughputs, and a more subtle issue is if you use a `spaced Tx` for testing, and then move to a better non-spaced UART, the testing was less use..
For my UARTs tests I use FT232H, as I know that is able to sustain gapless Tx, of whatever Stop/Parity I specify. FT2232H is even better, IIRC it can manage 12MBd full duplex sustained.
Yes, servicing at these high speeds (low divides) needs extra care.
It took me many iterations of hand-crafted Assembler, in a priority interrupt, to get EFM8UB3 to sustain 8MBd (8.n.2) with its 48MHz sysclk.
The UB3 has a 4 byte FIFO, which helps on the longer paths when you hit buffer boundaries.
With UARTS you can easily specify 2 stop bits and MARK parity, to buy a few extra cycles of headroom, but above that is not so portable.
Depends on the speed of the software doesn't it.
Yes, ultimately, but you can adjust PC side to 2 stop bits, or force MARK parity to get 3 stop bits.
Each increment buys more software overhead sysclks.
That sounds correct.
It never occured to me to round the fractional baud computation. Darn.
It that something in the ROM?
It's in the smart pin logic. Instead of starting the sub-bits accumulator at zero, I would have started it at one-half. Each overflow results in the extra one-clock wait.
- First tests with revB silicon - https://forums.parallax.com/discussion/comment/1478437/#Comment_1478437
- Identifying revB XDIVP = 1 lock-up conditions - https://forums.parallax.com/discussion/comment/1481733/#Comment_1481733
Newer more automated Spin based code - https://forums.parallax.com/discussion/comment/1507860/#Comment_1507860