@oov8

!здравствуйте уважаемые!
В программировании уже довольно давно.
Задумался по поводу по поводу довольно простенького вопросика.
Кольцевые буфера ввода-вывода. Точнее UART. Еще точнее PIC/AVR.
Самое простое - выводим данные:
Для вывода вызываем функцию и данные для вывода помещаются в буфер.
По прерываниям это данные отправляются куда надо.
Если буфер полн - ждем пока освободится.
Ввод данных посложнее:
Проверяем кол-во принятых данных, и если их нет - продолжаем ждать.
Динные появились - все их вытаскиваем пока не кончились (данные попадают
в буфер посредством механизма прерываний).
И задумался по поводу обработчика прерывания ввода:
Что делать с данными, если буфер полн, и данные некуда складывать?
В AVR можно было просто игнорировать эти данные, и следующие прерывания
нормально генерировались.
PIC вроде требует обязательно считать данные, чтобы запустилась система
прерываний.
И вот вопросик: что делать с этими данными?
a) просто игнорировать?
b) складывать в конец буфера?
ест-но выставлять флаг переполнения.
Кто как обрабатывает такое состояние?

0

@stt

ЮАРТ для МК - очень медленный интерфейс. Чем занят ваш контроллер, что не успевает обработать проходящие данные?

0

@oomomstir

Нет места - значит, данные теряются. Точка.

Единственное - можно заранее (когда в буфере мало места) просигналить другой стороне, чтобы заткнулась - см. flow control.

0

@oov8

Для просигналить - сейчас ножек просто нет. На будущее совмещу со светиком.
В основном вопрос, куда девать данные - выбрасывать или складывать в конец?
Потеря данных не критична.

0

@oomomstir

Выбрасывать - складывать-то некуда.
Для просигналить лишние ножки не обязательны - см. software flow control (норм, если у вас чисто текстовый протокол).

0

@oov8

Модифицировал обработчик прерываний.
Сейчас данные ВСЕГДА складываются в конец буфера,
а потом проверяется - можно/нельзя было этого делать.
Правда флагов переполнения не выставляю. Да они мне и не нужны.
Все из-за того, что в PIC для возобновления прерываний обязательно
нужно прочитать данные.
Удалось сэкономить целй байт программной памяти...
если интересен код - могу выложить...

Для software flow control памяти и так в обрез - уже лишних более 100 байт...

0

@u37

Так делать нельзя. Теряется монотонность событий. Надо ИЛИ останавливать прием ИЛИ его продолжать. Первый вариант лучше.
Разрывы обмена очень плохо воспринимаются, особенно для текстового вывода. Какой смысл в наличии 1 байта из какого-то другого сообщения в конце буфера? При последующем вычитывании этот _неправильный_ байт будет восприниматься как "нормальный" в конце сообщения, что приведет к неверному анализу сообщения.

0

@инкер

Буфер это информация, ее ценность не может знать посторонний человек
u37 правильно написал, новые данные могут испортить всё
Если для возобновления прерываний нужно читать, то не обязательно писать прочитанное в буфер
Есть данные, которые нужно писать только группами, не помещается группа - нужно решать, стереть самые старые или пожертвовать новыми.
Мы этого не знаем, что важнее.

0

@oov8

А кто как обрабатывает ошибки железного UART, такие как ошибка формата и переполнение?

0

@soumt_imobti

Первый вопрос: это происходит в ОСРВ или без нее? Если есть ОСРВ, есть смысл использовать штатные средства межпроцессовой коммуникации: мьютексы, семафоры, очереди сообщений итд.
Если же без ОСРВ, то есть разные техники.
Флаг "Очередь полна" и проверка флага перед записью в фифо.
Функция записи в буфер, мгновенно возвращающая ошибку если попытаться записать больше данных чем есть в буфере. Например, функция UARTwritebuf(&UART_Ptr, *char), которая возвращает число байт, "не влезших" в буфер. Если всё влезло тогда 0, ошибки нет.
Ошибки аппаратного UART надо обрабатывать внутри функций работы с портом - например не очищать буфер пока нет подтверждения успешной отправки или таймаута без ошибок. С автоматическим повторением сообщения после.
Но лучше всего это грамотный протокол поверх всего этого. Что-то типа zModem если надо блоки данных или Modbus если надо короткие сообщения.

0