Andrey_Sudnov

Ложки нет, ложкодержатели есть;) Выкладывай что ли свой вариант, а то не очень понятно, что значит "теребить". Ну или в subj укажи, что можно упростить по твоему. Только когда он делался, я еще не знал про next. В версию алгоритма с приемником около 100 строк добавляется

Согласен насчет того, что можно принимать через один буфер. Сложности с атомарностью и прерываниями начинаются при работе с двумя буферами. Зачем нужны два буфера? Они позволяют на HIGHLOAD обрабатывать входящие данные прямо в тех же буферах, которые заполнялись PDC, БЕЗ КОПИРОВАНИЯ! Насколько все это нужно, каждый решает в меру своей испорченности;) Можно сделать как-то эдак хитроватисто, но надо проверять. А зн велком.

Взрыв из прошлого;) Кому интересен subj, у мну есть что добавить. Первое. Это актуально на новом железе Atmel(поменялся ли интерфейс UART и PDC)? Второе. Появились ли какие новые реализации работы через PDC хорошие?(та, что была в linux kernel времен 2.6 - мне не нравится) Третье. Теоретически возможно написать поблочный, а не посимвольный алгоритм для приемника, который будет работать в паре с предложенным алгоритмом передатчика БЕЗ ОТКЛЮЧЕНИЯ КОНТРОЛЛЕРОВ UART/PDC(читайте первый и седьмой пост, а также последние несколько). Этот алгоритм сложнее, чем алгоритм для передатчика(а он сам не прост, по сравнению с linux версией). И он возможен, так как настройку PDC МОЖНО начинать с установки второй пары указатель-счетчик(которая Next)! Аппаратно значения переносятся сразу в первую пару(текущую) и сразу же начинается прием в этот буфер. Т.е. возможна такая настройка буферов: 1) проверяем свободен ли Next 2) Настраиваем Next 3) переходим к 1. Какбэ не очевидный момент, но выявленный экспериментально на AT91SAM7S64. В SDK от Atmel же происходит сначала проверка и заполнение первой пары, и только если она не свободна - заполнение пары Next. ЭТО ДЕЛАЕТ НЕВОЗМОЖНЫМ АТОМАРНУЮ УСТАНОВКУ ОБОИХ ПАР И ПРИХОДИТСЯ ОТКЛЮЧАТЬ КОНТРОЛЛЕР. Да, перенос происходит в момент установки регистра счетчика. Публиковать пока не буду, но кому интересно, готовый исходник пришлю, так как надо тестить.

Спасибо

Снова прошу о помощи в связи со своим ником. Ох уж дернуло меня пробел использовать в имени! На форум захожу нормально что под Andrey_Sudnov что под "Andrey Sudnov". Но в любом случае имя отображается в пробелом. И на страничке смены пароля к ftp он меняется тоже для этого имени. Помогите пожалуйста или подскажите как мне сменить пароль на ftp для Andrey_Sudnov?

Плз, перезалейте, кто успел скачать. Буду призналелен, очень

Не нахожу ответа на свой вопрос... Уточняю условие. Можно использовать poll, можно select, разницы нет, дело вкуса. Проблема в том, что БЕЗ этих функций невозможно отследить окончание операции с файлом (read, write, recv, send, conect, etc...). Ситуация следующая. Есть два потока. Один - интерфейс, и там есть кнопка Exit. Другой - работа с сокетами. Работа с сокетами должна быть немедленно прекращена, как только нажали кнопку Exit. Для этого необходимо ждать одновременно и файловый дескриптор (poll/select) и event от pthread (если мы работаем через них). Это невозможно - нет такой функции. В Windows есть такой тип: HANDLE. Он общий и для событий (SetEvent) и для дескрипторов ввода/вывода. Соответственно, оба можно одновременно передать в функцию WaitForMultipleObjects. Вижу два варианта. Первый: вызывать poll/select с установленным таймаутом в несколько миллисекунд, затем проверять событие и так по кругу. С кнопкой это конечно прокатит, но в случае жесткого реального времени задержка на обработку события будет составлять именно этот таймаут. К тому же постоянное верчение в юзеровском коде не делает чести с точки зрения использования ресурсов и производительности. Второй вариант: отказаться от синхронизирующих функций pthread нафиг. Использовать pipe. Здесь встает вопрос, насколько эффективно реализованы эти каналы в коде ОС/libc. И не перекрывает ли потенциальная кривая реализация преимуществ над первым вариантом? Варианты еще?

На ftp сервер пускает только по старому логину. К кому можно обратиться, чтоб поменять и его тоже? Разобрался. Ввел заново пароль на http://electronix.ru/index.php?pid=13, как написано в http://electronix.ru/forum/index.php?showtopic=115

Проблема в том, что в библиотеке PThread нет работы с файловыми дескрипторами. Соответственно, для того чтобы одновременно ожидать завершения какой-либо файловой (или сокетовой) операции или поступления управляющего сигнала от другого потока (например, об отмене операции), приходится использовать неименнованные каналы (pipe и write, вместо SetEvent) и функцию poll (предпочитаю ее, а не select). Перерыл кучу книг, в том числе POSIX стандарт, ничего лучше не придумал. Насколько такое решение накладно по ресурсам? Как организовать такое взаимодействие потоков другим способом?

Обращаюсь к администраторам форума с просьбой поменять ник на следующий: Andrey_Sudnov Фаворитные мой ftp-клиенты не могут нормально листинги парсить, если в нике присутствует пробел. Спасибо!

Не уверен, но как вариант для размышления. Подавать все сигналы с камеры на ПЛИС, делать XOR, выдавать все на выход. XOR с этого выхода подавать на PLL, остальные сигналы с выхода ПЛИС - обрабатывать, как от камеры.

Допустим PDC выключен. В этот момент приходит новый символ. Устанавливается RXRDY, но так как он замаскирован - прерывания не происходит. Закончили работу с буферами, включили PDC. Скорее всего Вы правы - символ, который уже принят, уйдет в буфер. Это было бы логично. Надо конечно проверить для верности. Я признаю, что мой драйвер чрезмерно усложнен из-за того что не выключает PDC. В этом нет смысла, поэтому лучше его использовать только в качестве обучающего (ну там все-таки есть некоторые трюки).

В пункте 3 копируем внутри обработчика прерываний? Мне кажетсе, при приеме необходимости выключать PDC нет (точно PDC? А не UART? А если была задержка перед обработкой прерывания по TIMEOUT и в тот момент, когда выключили PDC как раз поступил новый байт, ну а раз PDC выключен - запомнили и выдали новый запрос на прерывание, но уже без PDC?). Почему необходимо начинать прием в следующий буфер вместо хвоста текущего? Вот это выключение в пункте 4.2, которое мне совсем не нравится, при передаче необходимо, так как устанавливать адрес и счетчик надо вместе, а вызов PutStr может произойти в любой момент. При приеме момент смены указателя и значения только один - в прерывании ENDRX, когда вероятность того, что произойдет переключение буферов в PDC очень мала (не успеет просто так много данных поступить). Символ пропадает в передатчике или приемнике? Вы так спокойно об этом говорите! Ни в коем случае ничего не должно пропадать! Если есть ошибка у меня, а это возможно, о ней надо сообщить, чтобы исправиить ну или отказаться от моего исходника - не исключаю и такой вариант.

Т.е. делать по моему? Я вспомнил! Сделал побайтно из-за того, что так проще принимать строки. Совсем забыл как работает этот PDU. Сейчас глянул. Без отключения приемника не обойтись, так как установить адрес на следующий буфер и счетчик надо одновременно! Это если адрес буфера будет все время разный, "произвольный", для обработчика прерываний, неизвестный ему заранее. Если использовать один и тот же буфер или пару, то без выключения приемника обойтись можно. Плюс с PDC появляется проблема с приемом строк произвольной длины. Как ее организовать? Ловить прерывание по таймауту, копировать (!) буфер от значения до текущего адреса? Или PDC переходит на следующий буфер по таймауту? Опишите пожалуйста парой слов Ваш алгоритм, так сказать путь данных от UART до пользовательского буфера. Куда указывает адрес и следующий адрес в PDC (в течение всего цикла)?

Не помню что там выключается. Я рассматривал исходя из передачи, поэтому так написал. Имел ввиду весь UART. Ведь если при передаче выключается передатчик, то при преме должен выключаться приемник. Ведь так? К тому же передача из произвольных буферов я еще представляю, а прием в произвольные - это как? Вызвали GetData, передав указатель, вернулись, что-то делаем, потом каким-то образом узнаем что данные получены. Ну, буфер заполнен. Новые данные принимать некуда. Надо подставлять новый. А в этот момент бабац, и пресловутое запрещение прерываний. А мы ведь в пользовательском коде, ваще самые некотируемые. Нее. Так не правильно. Обработчик прерываний не должен выполнять никакой длительной работы работы внутри себя. Это даже по Windows (далеко не реал-тайм) - закон! Если же в программе допускаются такие задержки, то ни при каком способе работы с UART нельзя гарантировать, что не произойдет потери принятого байта. Ведь задержка может произойти между переключениями буферов в пользовательском коде (а такое переключение более длительное, чем метод, используемый у меня). Переключаться между режимами может быть и можно, но не правильно. Думаю, в данном случае надо всегда работать через 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) Как такое обрабатывать?