SWEET protocol questions
AJL
Posts: 517
New thread to discuss some questions I have about @knivd 's innovative duplex serial interface concept.
@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:
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).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)?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.
Comments
First, it is worth noting that although the demo was with single bits, everything in an actual use case should be considered in bytes.
The transmitter's behaviour when receiving bits (or bytes) from the receiver is exactly the same as SPI, where it would receive in any case. Then, once received a byte can be ignored or used.
The received always acts the same way regardless of a previously received EOT. It is more for a higher protocol need to indicate where a data packet ends.
This is something that I have not tested in depth yet, but because of the low-level bidirectional protocol the communication will go on in the way it is supposed to and regardless of the fact both sides have started transfer at exactly the same time. I checked with a couple of bits, but that was as much as I have done on it so far.
EOT used as SOT is a possibility. I don't know which one would be more useful in the real world. But it will have to be either one or the other, not both.
Ok, that makes sense
Right.
I'm not convinced that this claim is correct.
Your demonstration showed that each end requires the other end to send the opposing state as Acknowledgement.
With a sufficiently long wire, propagation delays can allow a situation where both ends, seeing the line idle, transmit the same state at the same time. As each will see the line remain in the transmitted state it will never receive the Acknowledgement it is waiting for and everything will jam up. Perhaps a built in timeout in the state machine (with a consequential propagation delay limit) and a semi-random retry delay would allow recovery from such a logjam state. CSMA/CD does something similar.
I don't see why it can't be both as long as SOT uses a known state (e.g. Brk+1) and EOT uses a trailing bit of known state (e.g. Brk+0), rather than just the last bit of the data packet.
All of that said, if data is always sent in bytes then this EOT function looks like a solution in search of a problem, unless the state machine in the receiving unit has a last_bit_received flag that the software can check. How that flag would be cleared (on receipt of SOT sequence, by the software in the receiver, some other means?) would need to be determined.
I'm impressed by the potential offered by this interface, and I'm asking these questions in an attempt to ensure that all potential problems with the fundamental protocol(s) are addressed before it is committed to silicon.
I've been working on some state tables to capture my understanding of this. I'll share them once they are ready if you are interested.
I experimented a bit more, and you are correct to a certain extent.
Also, just realised that what I have demonstrated in my video is not what I have in the specs document filed in 2021. In the video I say that every device during normal communication assumes a same bit is being received, while in the document it is actually the opposite. There, sending back same bit requires the receiver to activate the break signal. Memory failure, sorry. I may need to redo the video at some future moment. That of course does not change the main principle of operation.
If Device 1 is sending 1 and Device 2 is sending 0 at the same time (same stands for 0 and 1):
Both sides will go on the normal way assuming that the other side is confirming the sent bit, so in fact both will receive bits opposite to what the other side is sending, which is exactly what is supposed to happen. In this process the individual speed of the devices won't matter either, because the state machine of each side will wait for confirmation from the other side.
If Device 1 is sending 1 and Device 2 is sending 1 at the same time (same stands for 0 and 0):
Currently, the only way to deal with this is by a timeout which will let the device sense that there is no confirmation coming from the other side, however, I can see a simple hardware way to detect this and generate a signal informing about a collision. Will include it into my further work on this.
>
Of course. Would be very interesting to see your input.