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) Как такое обрабатывать?

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

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

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

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

Нашел тут у себя свои наработки. Использовал ACEX1K для связки AT91SAM7S64 и модуля SDRAM (от компьютера :) ). Суть в том, что полную шину организовать на этом MC - ну никак, а памяти надо было много-го-го. Причем надо было максимально большую скорость. Узкое место здель именно интерфейс между MC и ПЛИС. Често скажу, подробностей не помню. Помню что работало где-то так: если надо читать память, выставляем одной командой (благо регистр портов 32 бита - доступен одной командой) rd=0, wr=1, на 8-bit шину - младший байт адреса. Затем одной командой rd=1, wr=0 (инверсия обоих сигналов), шина - следующий байт адреса и т.д. После адреса перестраиваем биты, соотсетствующие шине, на прием, инвертируем биты управления и читаем байт. Инвертируем опять... читаем следующий :) Запись аналогично. Возился долго. Но до стабильности вроде довел. Специально гонял туда сюда целые ночи данные через ПЛИС - проверял на ошибки. Насколько помню, все работало на максимальной скорости MC (33Мгц вроде). Единственное, тактовая памяти была маленькая (25МГц, если не ошибаюсь), как как подключал целую планку(использовал только 16 бит из 64-х), а там у всех CLK от одного контакта, ну выходной мощности тактового генератора и не хватало, кажется использовал MAX3000 для этого). Но и такой частоты хватало с лихвой. Вот, кому интересно, пожалуйста! Там че-то такого понаворочено... Шучу. Там несколько автоматов состояний. Готов разобраться (заново :) ), если помощь потребуется! Можно выдать какому-нибудь преподу как плод гениального ума! :) tdf для Алетеры (как это, AHDL вроде называется?) P.S. Не помню, почему я не использовал SPI. Медленно? Да, контроллер SDRAM - мой! Без burst, конечно, но лучше, чем тот, с которого я его делал 8) spider.rar

Недавно купил subj и вот только обнаружил что корпус сниу слева и сбоку очень сильно греется (нельзя дотронутся рукой). Там как раз что-то привинчено винтом. Греется и при выключенных паяльнике и фене. Разобрать не могу (гарантийная наляпка). Подскажите, пожалуйста, так и должно быть или деффект какой?

Путаешь симулятор с эмулятором. В симуляторе только m68k эмулируется, эмулятора ARM там нет. Вместо этого системные библиотеки написаны и исполняются на x86. Вроде бы хотели сделать эмулятор ARM для пользовательских программ в симуляторе PalmOS 6 Cobalt, но вроде бы он глюкавый (хотя я полгода назад с ним игрался).

Пробовал год назад, но только в текстовом режиме (эмуляция UART). Linux запускается. Сильно не разбирался, только поигрался немного. Радует наличие исходников - при желании можно специфичное железо запрограммировать.

Не КПК конкретно, но ARM архитектуры: http://www.skyeye.org (там есть что-то и с LCD) А КПК, думаю, вам не очень подойдет, так как у него периферия специфична и часто не документированна.

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