No safe way ... apart from programming the micro correctly so it can keep up with the data stream.
Yeah.
Shure.
Ensure that a 20 MHz micro reacts fast enough compared to a 500 MHz SOC.
I plan to do more useful things with my micros than to wait for data from the host.
Especially when servicing time critical tasks like multiple regulation loops in the 1000-2000 interrupts/seconds range.
Ummm... last time I checked RS232 had baud rates plenty slow enough for a 20MHz micro to respond to and still have time left over for other things. It's all down to good programming.
You could always send a special character to say "I'm getting full!" and a different character to say "OK, start sending again".
Suuure.
Yeah.
Does not work here.
The micro cannot react and do SW handshake before corruption happens, because it has no Hardware buffer, so it needs to service each byte with an interrupt....
I don't know what 'micro' you're referring to. The micros I use (AVR based) have a one byte buffer in hardware which gives you plenty of time to respond to an interrupt. I believe this is a common in other chips, too.
If your micro
doesn't have a 1-byte hardware buffer you could toggle a data pin in the interrupt handler when, that lets the sender know you're ready for the next byte and would hardly slow things down at all (what's the interrupt response time on a 20MHz micro? Less than a microsecond?).
Give me a few seconds and I could come up with half a dozen other ways to make it work, too. It's all down to what I call "good design and programming".
So the conclusion is still : i2C is the only option for a communication with a host including a positive hardware ack.... as long as you don't use a RPI
Or... you can use I2C and rely on clock stretching for flow control (assuming your 'micro' can do clock stretching in hardware).
I don't get your assertion that a Raspberry Pi can't do I2C. "I2C master" is one of the easiest protocols to do in software.