Тема открыта по горячим следам недавней острой дискуссии.

В ней одним из участников (defunct) была приведена программа, в которой использовался циклический буфер для работы с последовательным портом МК AT90S2313. На взгляд автора программа написана достаточно грамотно, но как-то слишком размашисто, без учёта мизерности ресурсов данного МК. Предлагаю участникам поделиться примерами и приёмами использования циклического буфера в программных разработках.

Для затравки предлагаю следующие фрагменты.

А. Запись байта из регистра AL в циклический буфер

Код

      mov     xl,qhead    ;указатель на запись
      st      x+,al       ;запишем байт
      cp      xl,qend     ;конец буфера?
      brne    .+2         ;нет, обходим
      ldi     xl,buffer   ;да, установим начало

Б. Чтение байта из циклического буфера в регистр AL

Код

      mov     xl,qtail    ;указатель на чтение
      ld      al,x+       ;прочитаем байт
      cp      xl,qend     ;конец буфера?
      brne    .+2         ;нет, обходим
      ldi     xl,buffer   ;да, установим начало

Если использовать буфер не произвольной длины, а кратный степени 2, и размещать его в памяти не произвольно, а начиная с адресов, кратных длине буфера, то размер кода можно немного сократить. Например.

В. Запись байта из регистра AL в циклический буфер длиной 32

Код

      mov     xl,qhead    ;указатель на запись
      st      x+,al       ;запишем байт
      cbr     xl,0xE0     ;держим указатель в предписанных рамках

Г. Чтение байта из циклического буфера длиной 32 в регистр AL

Код

      mov     xl,qtail    ;указатель на чтение
      ld      al,x+       ;прочитаем байт
      cbr     xl,0xE0     ;держим указатель в предписанных рамках

Здесь qhead, qtail, qend – регистровые переменные, содержащие адреса-указатели ячеек в озу для записи, чтения и конца буфера соответственно.

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

Дык ждать-то по-любому нужно. Вопрос в том, делать ли чего полезное при этом или нет. А это скорее к механизмам шедулинга.
В случае достаточно долгого ожидания есть прямая целесообразность выйти из ожидания (отдать управление ОС), а потом иногда заходить и проверять или ждать(проверять) извещения о событии (буфер не полон) и уж тогда добивать.
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 места на плате.