Attention is currently required from: jolly, laforge, neels, osmith.

View Change

5 comments:

• File include/osmocom/core/soft_uart.h:

  • Patch Set #3, Line 100: gets

    "gets passed" or "gets as an argument" -- I will clarify this.

    Done

• File src/core/soft_uart.c:

  • Patch Set #2, Line 398: if (active) /* assert the given line */

    re: if assert and de-assert is terminology from the matching spec, then of course keep using those t […]

    @andreas@eversberg.eu just to confirm, am I using the terminology correctly in this patch? As we agreed in Jabber, in the example case of the RI (Ring Indicator), the modem asserts this line when it's ringing and de-asserts it when it's no more ringing.

• File src/core/soft_uart.c:

  • Patch Set #3, Line 214: OSMO_SUART_STATUS_F_RTS_RTR

    RX must continue. […]

    Done

  • Patch Set #3, Line 324: OSMO_SUART_STATUS_F_CTS

    The current character needs to be finished before the transmitter can stop transmitting.

    Ack. Implemented in the new patchset, verified by unit tests.

  • Patch Set #3, Line 399: else

    If you de-assert DTR, you should reset the transmitter state. […]

    What you suggest looks as follows to me:

    • "If you de-assert DTR, you should reset the transmitter state" - if we can no longer receive, we de-assert the DTR (Data Terminal Ready) and for some reason reset the transmitter state (`suart->tx.flow_state`)?
    • "If you de-assert DSR, you should reset the receiver state" - if we can no longer transmit, we de-assert the DSR (Data Set Ready) and for some reason reset the receiver state (`suart->rx.flow_state`)?

    Could you elaborate on this please? I am trying to understand the idea here.

To view, visit change 35172. To unsubscribe, or for help writing mail filters, visit settings.