Shop OBEX P1 Docs P2 Docs Learn Events
Serial Interface Concept — Parallax Forums

Serial Interface Concept

This discussion was created from comments split from: New P2 Silicon.

Comments

  • I just published a long and slightly boring demonstration of an idea about a serial interface which can perform digital communication full-duplex (so both sides talking to each other at the same time) over a single wire, self-adjusting baudrate at bit level, and other things.
    Maybe one day it can enter the P2 silicon too? It is certainly sufficiently simple for that.

  • evanhevanh Posts: 15,912

    That's truly asynchronous. I remember once reading that the regular UART is only asynchronous by its start bit. The baud spacings are supposedly still classed as synchronous ... although I did take that with a little salt given there is no lock on the individual arriving bits.

    It will be interesting to see what speed your interface can do. Latencies will compound and implicitly define the bit rate.

  • evanhevanh Posts: 15,912

    For longer distances or high voltage or hazardous environments, being able to use optocouplers or transformers for electrical isolation is very desirable. Would SWEET be adaptable for such?

  • @knivd said:
    I just published a long and slightly boring demonstration of an idea about a serial interface which can perform digital communication full-duplex (so both sides talking to each other at the same time) over a single wire, self-adjusting baudrate at bit level, and other things.
    Maybe one day it can enter the P2 silicon too? It is certainly sufficiently simple for that.

    I've looked over this carefully and I have a few questions:
    1. How does the Transmitter know whether to use or discard a bit coming back from the Receiver if it matches the bit sent?
    If the Transmitter already knows when and what the Receiver is going to send then it doesn't really need to be sent, right?
    Perhaps, if each bit is sent twice in a row, then the Receiver could echo (or invert) both copies for a transmitted bit, but intentionally echo the first and invert the second for acknowledgement only (or vice versa).

    1. How does the Receiver know to start listening again after the EOT sequence?
      I could see the Receiver just waiting for the line to change from the idle state (because I don't see how you could start a transmission otherwise), so is this included just to allow arbitrary length bitstreams (rather than relying on known frame lengths)?

    2. How does this interface deal with the situation where both ends find the line idle and start transmitting at the same time (How do you sense collisions)?
      I recognise that this isn't really a problem for something operating like USB where all exchanges are initiated by one end, but for a conversation between peers (think early EtherNet) you'd want something like CSMA/CD.
      If the first bit is the same state from each end then it looks to me that the sequence jams up, with each end waiting for the line to change as Acknowledgement.
      What if one sends a 1 while the other sends a 0 without either one knowing that the other has started an exchange? I suppose that each end would see that as a fast Acknowledgement of their first bit, but how do they know that they've received a valid bit from the other end?
      Could the EOT sequence do double duty as a SOT sequence also, perhaps with Brk+1 being SOT and Brk+0 being EOT?
      Another method might be to require that all new transmissions start with a sequence of 2 throwaway 1 bits, which the state machines at each end would need to look for to sense collisions.

    I don't know if this should continue in this thread, or a new one be created to discuss this.

  • Probably best to isolate this in a separate thread, and I am happy to answer the questions there.

Sign In or Register to comment.