Кому нужны готовые, либо как примеры работы с UART через PDC (т.е. ПДП) смело в юз.
Помучился с ними пару дней. Работает уже пару недель. Без ошибок.
Приемник работает посимвольно, и приемник и передатчик работают через прерывания, у каждого свой кольцевой буфер. Функции передачи не ждут, если данные помещаются в кольцевой буфер. Если надо ждать конца передачи - есть фунция. Поддерживается работа в многопоточной среде. Можно легко интегрировать в операционную систему (если переписать функции работы с сигналами).
Кристалл у меня AT91SAM7S64 и AT91RM9200, но, думаю, любой Atmel подойдет.
В общем, кому интересно, смело смотрим. Public domain.

О как! Тока запостил, сразу ошибку нашел! Исправил. Как расценить сей шаг всевышнего даже не знаю, но что не случается, все к лучшему

Ну уже можно скачивать или подождать.

Да, вполне можно. Ошибка была в ветке алгоритма, которую недавно дописал и не тестировал. Проявилась бы при передаче функции PutStr строки длинее, чем внутренний буфер, когда он пуст.

Конечно же возможны и другие ошибки. Но перекачал уже мегов 100 по X modem да и в консоли постоянно работаю - все ОК.

Для Linux драйвер с использованием PDC (AT91RM9200) лежит на www.ipbx.ru/rm9200

Полезная вещь. Сенкс.

Круто, особенно примитивы синхронизации понравились

Глянул на исходники PDC от Linux (древние, правда). Там функция вывода, перед тем как поместить новые данные в буфер и настроить указатели, выключает(!) передатчик. Т.е. если в этот момент произойдет более высокоуровневое прерывание - передатчик будет выключен и данные передаваться не будут. Если же запрещаются все прерывания, значит в течение всего времени копирования выходных данных в буфер нет возможности прерваться на более привелигированную операцию (не помню, запрещаются ли прерывания, но у обоих вариантов есть минусы). К тому же какова цена выключения и включения передатчика? Это просто кажущаяся простота смены значения одного бита, за которой, на самом деле идет много всяких переключений, а это лишняя трата энергии, что иногда немаловажно.

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

А какова цена побайтного копирования данных из приемника в прерывании?
Я уж не говорю о том, что это потенциальная причина потери данных при даже не очень длительном (174uS @ 115200) запрещении прерываний.

??? Не понял.
В каком месте там теряются данные? В приемнике? Да, приемник работает не через PDC. Но я не вижу там проблем.
Не помню детально работу с UART у SAM. Но по идее потеря произойдет только если не уcпеть считать предыдущей принятый байт. Байты приходят через каждые 2864 такта. Прерывания от UART маскируются для копирования порции данных в выходрой буфер. Если в этот момент поступит байт, обработан он не будет. Сразу же. А только после того, как memcpy скопирует данные, прерывание демаскируются и тут же срабатывает. Размер буфера передатчика всего 128 байт, так что байт не потеряется.
Хотя, конечно надо бы и приемник сделать через PDC. И у вас есть пример.
З.Ы. А то что UART вообще выключается, пока копируется буфер, это как повлияет на возможность потери?
Что за 174uS?

Надо. У меня и приемник есть, зачем мне пример


Никак, если все уже передано.


Это время передачи двух байт на скорости 115200. Очень маленькое время, особенно если процессор занят другими задачами.

Т.е. прием и передача идут сразу из пользовательских буферов. Которые, например, локальные. Ню-ню.

К чему это?
Продолжительнорсть маскировки прерывания не превышает копирования 128 байт функцией memcpy. Это сколько, не помню, 128 тактов (1 копирование за 4-е такта)? Для того чтобы принятый байт потерялся, необходимо чтобы MC был занят более привелигированной задачей (ну там время считал) указаное вами время поделить на 2, т.е. 2871 такт (я указал 2864 Это значит ваще каюк пришел реал-тайму.

Я не говорю, что запрещать правильно и хорошо. Просто это не приведет к катастрофическим последствиям.


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

Ну вот выключили мы UART. И отвлеклись. Причем не на 2 байта, а всего на один стартовый бит. Потом включили. Нееет, все нормально, никаких катострофических последствий.

Принимаю, вроде так. Ну дак значит времени на оброботку есть еще больше.

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

Вспомнил насчет копироавния и внутренних буферов. Они нужны для того чтобы вызвать PutStr и сразу же вернуться из нее. При этом буфер, который указывали PutStr можно использовать по новому. Единственное но. Длина не должна превышать свободный размер внутреннего буфера, иначе PutStr будет ждать его освобождения. Размер буфера 128 байт. Для некоторых применеий может быть мало. Но тут нет идеально варианта, в любом случае в чем-то выигрываем, в чем то проигрываем.
В случае если PDC будет работать прям из переданного буфера, функция PutStr вынуждена ждать завершение передачи, иначе данные могут быть испорчены программой, после возврата из нее.
Как вариант - все время передавать из разных мест. Да, в некоторых случаех надо делать так, но это гораздо сложнее, чем вызвать PutStr и забыть.

Ваши слова:

и причем здесь прием?


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

Если Вы не против, подкину еще одну тему для обсуждения. Есть такое замечательное устройство GSM-модем SIM508. Так вот он при приеме пакета данных сообщает об этом следующим образом "+IPD<размер>:". Есть идея обработки обычных сообщений через обычные прерывания. Т.е. посимвольно. Ибо неизвестно, когда же закончится входящее сообщение. А парсить его на предмет <CR><LF> расточительно. Зато принимать пакеты заранее известной длинны оч. удобно через PDC. Есть вопрос: теоретически возможна ли потеря символов при переключении режимов работы. Что-то я в документации ничего толкового не нашел по этому вопросу...