Why not use some on-board signal for flow control of the UART port?

[NeoNatural]

Since this machine is of no UART interrupt or timer-based polling mechanism for RX, the programme should take full responsibility to read out the received byte before the next one coming in. This may constrain the programme staying within a polling loop for not missing any bytes. I think a hardware flow control signal like RTS/CTS may help avoid data loss while maintaining code flexibility (the PC terminal side is with much larger TX buffer than only one byte RX buffer on this board).

I guess 2 signals within the UART receiver block can server as the RTS: the output Q of the SR latch (marked with blue frame) or the DATA_READY (DR, marked with orange frame) signal. The former one turns High after the first falling edge of RX input while the latter one turns High after the entire byte being received. And they both will not turn Low unless the received byte is read out, which makes them suitable to act as the RTS flow control signal.

I will link these wires to the CTS pin of the serial adapter and check whether this would work (as soon as I receive the chips and PCB and build up this machine). Post this issue here for discussion first.

[slu4coder]

Hi NeoNatural,

I've tried Q and DR as RTS and connected the signal to CTS of my FTDI interface with RTS/CTS handshaking enabled. This works well in principle, however, unfortunately if Q goes high at the start of a datum (DR does the same at the end of a datum), this does not prevent the sender from sending one more(!) datum. It seems to already be in the pipeline of my FTDI chip. This 2nd datum is too much for the single-byte buffer of the Minimal CPU if the CPU is busy and thus not constantly polling. So we have to stick to avoid that situation in software.

It's a bit of a pity, but this very nice idea does not work in practice - and this is not because of the Minimal CPU System but because the FTDI chip being as it is. Anyway, thanks a lot for thinking through this and for coming up with this plan.

Cheers, slu4.

[NeoNatural]

Hello slu4,

Thank you for testing this and I'm sorry for my late response. There is something going wrong and I have not yet received my chips for building the Minimal CPU. Therefore, I use Arduino to simulate the RTS signal, which detects the start bit of UART and immediately sets RTS high. After 10ms, the programme sets RTS low and lets the following bytes pass.

I tested two USB serial interfaces based on CH340 and CP2102 chips respectively, under baud rates of both 9600 and 115200. They could both work well. I sent a text "12345". When receiving the first character "1", the RTS signal turned high and blocked the transmission. When the RTS turned low after 10ms, the left "2345" was sent. No data were lost. D0 is referred to for the simulated RTS signal. D2 is referred to the UART data. The waveforms of the two chips look very similar.

Best regards, NeoNatural

[slu4coder]

Hi NeoNatural,

now this is interesting! I've used the same setup as you have described, i. e. a Nano sampling the TX line and as soon as it goes low then outputting a RTS->CTS signal for some short time. Enclosed are my results.

I can confirm too that the CH340 stops right after RTS->CTS goes low, only sending one datum. However, my FTDI again shows this wired behavior of sending a 2nd datum even after receiving ~CTS=HIGH.

Bottom line: Your idea should be working with the CH340 (Sparkfun?) breakout board but unfortunately not with my FTDI (Deek Robot). It is a bit of a shame that these two behave so differently.

I think I'll order a CH340 breakout board and implement RTS->CTS. The existing software should be "downwards compatible" since it all works fine without hardware handshaking. RTS/CTS could be used as an option without

"additional costs".

Thanks for diving into this!

Best regards, slu 4

[NeoNatural]

Hi! I'd like to make a supplement. I tried simulating the DR line of the UART receiver module, which turns high after receiving one datum. This could work (Figure 1), but the actual time delay should be considered further. Roughly speaking, if the RTS signal was given after the half time of the stop bit, the second datum would not be blocked (Figure 2).