Исходники UART with PDC для Atmel ARM, Состряпал от нифиг делать :) Опции

[Andrey_Sudnov]

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

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

Прикрепленные файлы

 uartpdc.rar ( 2.3 килобайт ) Кол-во скачиваний: 457

 

[aaarrr]

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

Ваши слова:

выключает(!) передатчик

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

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

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

[Andrey_Sudnov]

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

Не помню что там выключается. Я рассматривал исходя из передачи, поэтому так написал. Имел ввиду весь UART. Ведь если при передаче выключается передатчик, то при преме должен выключаться приемник. Ведь так? К тому же передача из произвольных буферов я еще представляю, а прием в произвольные - это как? Вызвали GetData, передав указатель, вернулись, что-то делаем, потом каким-то образом узнаем что данные получены. Ну, буфер заполнен. Новые данные принимать некуда. Надо подставлять новый. А в этот момент бабац, и пресловутое запрещение прерываний. А мы ведь в пользовательском коде, ваще самые некотируемые.
Нее. Так не правильно.

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

Обработчик прерываний не должен выполнять никакой длительной работы работы внутри себя. Это даже по Windows (далеко не реал-тайм) - закон! Если же в программе допускаются такие задержки, то ни при каком способе работы с UART нельзя гарантировать, что не произойдет потери принятого байта. Ведь задержка может произойти между переключениями буферов в пользовательском коде (а такое переключение более длительное, чем метод, используемый у меня).

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

Переключаться между режимами может быть и можно, но не правильно. Думаю, в данном случае надо всегда работать через PDC. После "+IPD<размер>:" есть таймаут или сразу данные идут? В любом случае, настраиваем таймаут (ну там, возможны другие команды, URC), указываем буфер, ждем когда он заполнится (полностью или нет, не важно). По любому парсим начиная с начала. Если нашли "+IPD<размер>:", остальную часть буфера рассматриваем как данные. Три варианта: 1) после данных есть еще строковые ответы, 2) данные кончаются в конце буфера, 3) не все данные влезли в буфер. Во третьем случае указываем еще буфер, но после заполнения помним, что там данные вначале. А потом могут быть строки.
Алгоритм не тривиален. Если его делать влоб - не получиться. Но могу псевдокодом расписать, как делать.

Кстати, что насчет URC? У некоторых телефонов возможны такие фишки:
AT+CMGL=0 (запрос списка новых входящих SMS)
+CMGL: 1,0,,24 (ответ: индекс, статус,,длина)
0791xxxxxxxxxxF1040B919720380422F6 (это PDU - закодированная SMS)
+CMTI: "ME",39 (хопа, пришло URC - уведомление - о новом сообщении)
00006001701041130005C8329BFD06 (продолжение PDU)
Как такое обрабатывать?