Вопрос может и туповат, но для меня, как начинающего, актуален... Разжевывать не обязательно, можно просто поделиться ссылками на материал по теме.

Проблема следующая: есть контроллер (STM8) с аппаратным IIC на борту. Также в проекте будет использоваться UART... И если с передачей все почти понятно (вкидываю данные в кольцевой буфер, а дальше парится аппаратура и обработчик IRQ), то с приемом у меня ступор... А именно: работаю с PCF8583, я конечно знаю, когда она мне что-то пришлет, мастер я всетаки, но шина довольно медленная, и тупо крутиться в цикле опроса флагов - терять время... С UART то же самое... Я спрашиваю, мне отвечают.

Вопрос: Как это делается правильно? В ОС функция выглядит обычно как что-то типа Read(дескриптор устройства, *куда читать, количество байт, которые читать); как это реализуется? Ведь не могу же я вывалиться из функции не возвратив данные, а то, что к ее вызову они еще не готовы может быть легко...

Вообще программу собирался реализовывать в виде событийной системы по примеру отсюда. Но как прикрутить грамотную работу с приемом данных разобраться не могу.

Если использовать прерывание от модуля I2C, то в самой процедуре прерывания нужно не только данные в/из буфера гонять, но и там же обрабатывать все возможные состояния шины, которые вам модуль I2C выдаст. Это не конкретно про STM8, а вообще.

Ну про состояния я естественно понимаю... Но просто к примеру, нужно получить время из PCF8583, это где-то 3 байта на вскидку (здесь не суть). Итого я выставляю запрос на старт, закидываю в буфер адрес регистра, который будем читать, а после этого нужен еще и рестарт шины...
Итого перед непосредственно чтением еще 3 операции...

Предположим мы попадаем в функцию приема, которая нам должна вернуть эти самые 3 байта, а их еще и в помине нет... Так вот как сделать так, чтобы проц не тупо циклился в ожидании, а выполнил еще пару полезных действий? (Дело не в том, что у меня критичное к времени приложение, я то подожду, просто хочу понять как это правильно делается...)

Я рассматривал кой-какие сырцы на sourceforge, но они были под msp430, который я не знаю, поэтому трудно судить что и зачем там делается... Да и опыта мало... STM8 я назвал просто для представления с чем имею дело, а так меня интересует именно общая схема реализации или ссылка на литературу... Своего опыта нет...

В приложении пример тестового проекта для I2C из IAR EWARM для LPC1114. Я, взяв его за основу, довольно легко адаптировал этот пример для работы с LCD TIC234 на базе PCF8535. Вот здесь Сергей Борщ любезно поделился хедером и примером инициализации для этого LCD. Посмотрите как в этом примере от IAR организован обработчик прерывания I2C. Я к этому примеру (кроме собственно управления LCD) добавил в функцию I2CStart реализацию Bus clear, которая вызывается при таймауте (когда определенное время автомат I2C не может сформировать Start-условие). Bus clear описана в 3-й ревизии спецификации I2C от NXP.

Альтернатива одному обработчику - два обработчика!
Вообще-то эти вещи протоколо-зависимые.
Обычно автомат состояний управляет процессом. Типа так http://caxapa.ru/193312.html
Ну а лихие обработчики прерываний складывают принятое в линейные или циклические буферы.

Добавлю, что типичный программистский прием - это выполнение функции, в которую передается указатель на структуру, в которой находится вся интересующая информация - что принято, что не принято, кто у принятого байта папа-мама и прочее. Затем структура разбирается на атомы или анализируется что-то нужное.
Или функция возвращает, что все байты приняты, а что принято, ищется в другом месте.

Да в конце концов вспомните, как это сделано в Windows!
Да и книжки бывают полезны, на форумах не учат, а калечат!

Спасибо всем за информацию, буду переваривать

ЗЫ: а форум калечит только если его бездумно использовать...