Shop OBEX P1 Docs P2 Docs Learn Events
Dynamic system clock setting and comport baud setting - Page 2 — Parallax Forums

Dynamic system clock setting and comport baud setting

2»

Comments

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    What sort of limitations?

    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.

    Okay. I was thinking there were some caveats.
  • evanhevanh Posts: 15,126
    Well, this is tx only testing. As JMG has indicated, an rx smartpin probably won't work that low.
  • evanhevanh Posts: 15,126
    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.
  • kwinnkwinn Posts: 8,697
    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.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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.
    evanh wrote: »
    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.


  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Okay. I was thinking there were some caveats.
    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 ?


  • evanhevanh Posts: 15,126
    All my tests are at fractions. So when I say reliable I mean every tested fraction from there on.

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    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?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    evanh wrote: »
    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.
  • evanhevanh Posts: 15,126
    edited 2019-08-14 12:06
    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.

  • evanhevanh Posts: 15,126
    edited 2019-08-14 13:43
    Chip,
    What sort of execution overheads are there on an ISR? I'm guessing 8 clocks including the RETI.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    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 ?
    evanh wrote: »
    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.
    evanh wrote: »
    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.

  • evanhevanh Posts: 15,126
    jmg wrote: »
    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.

    How many stop bits are needed between two chars ?
    Depends on the speed of the software doesn't it.
  • evanhevanh Posts: 15,126
    jmg wrote: »
    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.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    .. I'm just typing at it. Either single keypresses or copy'n'paste, depending on whether I want contiguous or single characters.
    Ah, ok, so your test flow is PC -> FT231X -> P2.Rx, at modest baud speeds (SysCLK is made quite low)
    evanh wrote: »
    How many stop bits are needed between two chars ?
    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.

  • evanhevanh Posts: 15,126
    It's probably a hundred or so between key presses.
  • evanhevanh Posts: 15,126
    edited 2019-08-15 06:15
    I think I've worked out it is ten clocks of overhead, including the RETI instruction, for an ISR.
  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    Chip,
    What sort of execution overheads are there on an ISR? I'm guessing 8 clocks including the RETI.

    That sounds correct.

    It never occured to me to round the fractional baud computation. Darn.
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    evanh wrote: »
    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?

  • cgraceycgracey Posts: 14,133
    evanh wrote: »
    cgracey wrote: »
    evanh wrote: »
    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.
  • evanhevanh Posts: 15,126
    edited 2019-08-18 04:01
    cgracey wrote: »
    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.
    
  • evanhevanh Posts: 15,126
    Linking to two topics where I've experimented with the limits of the PLL (Both using this topic's code):
    - 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

Sign In or Register to comment.