Дык...ХОН-ХОФФ, аппаратная синхра...

Дык ждать-то по-любому нужно. Вопрос в том, делать ли чего полезное при этом или нет. А это скорее к механизмам шедулинга.
В случае достаточно долгого ожидания есть прямая целесообразность выйти из ожидания (отдать управление ОС), а потом иногда заходить и проверять или ждать(проверять) извещения о событии (буфер не полон) и уж тогда добивать.
while(On){
if(len<=0) break;
if(putc(*src)==EOF){
OS_Yield();//тут передаём управление ОС
}
src++;
len--;
}
Я, правда, чаще использую для выхода/входа в ожидающие функции не OS_Yield(), а механизм статических сопрограмм реализованный макросами http://www.chiark.greenend.org.uk/~sgtatham/coroutine.h
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

Придумали уже давно,читайте внимательно пост 34.
Самый простой дернуть ногу CTS сом-порта ,он аппаратно приостановит передачу данных из него.
XON\XOFF - это еще нужно такой режим включить на дровах.
Хотя эти способы не освобождает от отслеживания на случай переполнения отправного буффера на ПК.

Угу, спасибо. А без ОС единственная возможность использовать это время - натолкать в прерывания побольше функциональности, логично? Я то работаю без ОС.

Использование статических сопрограмм требует только большого цикла (round-robin), хотя этим применение не ограничиваетчся. А Adam Dunkel наваял на этом деле даже нечто типа операционки - Protothreads http://www.sics.se/~adam/pt/

Спасибо. Я где-то рядом болтаюсь в подходах, используя switch или вызовы функций по индексу, а у него хорошо все проанализировано и систематизировано.

На отправку (тобиш TX буфер) - опорная точка - всегда пропускная способность канала, от нее и синхронизироваться. Регуляторов только 2 - размер буфера и задержка между вливанием очередной порции данных.

Там где канал с "узким горлышком" 300-1200 бод, а данных передавать много - ставлю 32k-128k внешней памяти. +2$ к стоимости устройства, +5см^2 места на плате.