Aurochs

Т.е. Вы имеете ввиду, что сбрасываются они автоматически? Имеется цель на базе FIQ-прерывания создать некое виртуальное устройство и нужно из FIQ-обработчика инициировать в AIC запрос на прерывание для обычного драйвера. А это можно сделать только для прерываний по фронту.

Работал до этого только с прерываниями по уровню (от внутренней периферии). И, как говорится, горя не знал. Теперь вот обстоятельства вынуждают использовать прерывания по фронту (тоже от внутренней периферии). И обнаружил следующее - AIC почему-то не сбрасывает автоматически прерывания по фронту. Обработку произвожу в точном соответствии с даташитом. После выставления периферией AICу запроса на прерывание эти прерывания потом валят беспрерывно и все затыкается. Спасает только одно - сбрасывние прерывания в ручном режиме прописыванием рег-ра AIC_ICCR. В этом случае нормальная работа восстанавливается. Уже не один раз проштудировал даташит (и errata в том числе: уже жизнью научен) - везде, где касаются этой темы прописано, что-то типа И еще раз подчеркиваю: при работе с прерываниями по уровню подобных проблем вообще не возникало. Поделитесь, пожалуйста опытом по данному вопросу, буду очень признателен. А то теперь не дает покоя почти гамлетовский вопрос: кто же здесь дурак? :)

Здравствуйте, Булат! Отвечу Вам прямо на форуме, хотя, к сожалению, вряд ли смогу Вам помочь по существу вопроса. В свое время я принципиально отказался от использования драйвера atm6124 по причине его множественных странностей. Это и Вам могу посоветовать ;) Если объем передаваемых данных невелик, то лучше пользоваться M$-ским usbser. Он работает без вопросов, но у него один существенный недостаток - сильно тормозной (больше 60 кБод эффективной скорости мне из него выжать не удалось). В противном случае нужно искать другой драйвер или писать свой. P.S. Еще, как вариант, могу предложить обратиться в службу поддержки Atmel. По крайней мере мне там в свое время помогли дельным советом, хоть и не очень оперативно.

Вызов ClearCommError драйвер atm6124 не поддерживает вообще. Да, есть такие причуды. Драйвер этот вообще, мягко говоря, далек от совершенства... Нужно анализировать значение, которое возвращается в параметре реально прочитанных байт и, если оно =0, то повторять вызов ReadFile У меня встречный вопрос по поводу драйвера atm6124ser. Это полноценный драйвер или только надстройка над майкрософтовским usbser.sys? Если Вас не затруднит, то вышлите мне этот драйвер почтой, пользуясь ссылкой на этой странице

Ну, дык конечно :) Нужно так TCHAR devName[MAX_PATH]; strcpy( devName, DevInfoDetail->DevicePath ); strcat( devName, _T( "\\PIPE00" ) ); А затем для devName вызывать CreateFile

Похоже, наши переводчики суют термин "дескриптор" во все места, где нет соответствующего русскоязычного термина :) Поэтому непонятно, о каком дескрипторе речь. Скорее всего имеется в виду хендл открытого или созданного устройства, который возвращает ф-ция CreateFile. Эти хендлы могут быть разные даже от вызова к вызову. Что тут делать? 1. Попробовать изменить GUID. Для драйвера из пакета AT91-ISP я задаю его так: DEFINE_GUID( guidAtmel6124, 0xE6EF7DCD, 0x1795, 0x4A08, 0x9F, 0xBF, 0xAA, 0x78, 0x42, 0x3C, 0x26, 0xF0 ); 2. Попробовать убрать GENERIC_READ из вызова CreateFile 3. Если первые 2 пункта не помогут, то сообщить код ошибки, который возвращает GetLastError после вызова WriteFile

Драйвер at6124 хитро скроен. Для него нужно открывать 2 устройства - отдельно для чтения и записи. Для получения имени устройства для записи нужно к уже полученному Вами имени дописать "\\PIPE00", а для чтения "\\PIPE01"

Принимающая программа на PC может читать данные не побайтно и, поэтому не реагировать на одиночный байт, а ждать, например, заполнения некоторого буфера. Ничего конкпетного не могу сказать про LabView, но попробуйте использовать в качестве принимающей программы, например, HyperTerminal. Он должен быть в любой винде и точно читает входные данные побайтно.

Уважаемые! Хочу хоть как-то вразумительно закончить эту ветку по пошествии полугода. Для тех, кто ее еще будет смотреть, имею честь сообщить следующее. Мистики здесь действительно никакой нет. А дело все в том, что м/к семейств AT91SAM7S и AT91SAM7X очень проблематично использовать в режимах full-modem и hardware handshake. Если же вам все-таки придется когда-либо это делать, то внимательно изучите Errata для этих семейств! Причем самой последней версии. На данный момент это можно сделать здесь http://www.atmel.com/dyn/resources/prod_do...nts/doc6120.pdf Мне удалось добиться относительно безошибочной работы только путем понижения скорости обмена между м/к и модемом до значения скорости эфирной передачи. Всем удачи!

К сожалению, простое отключение режима pull-up не помогает. Но проблема полностью решена изменением номиналов нагрузочных резисторов. Спасибо всем участникам обсуждения!

Большое спасибо! :a14: Несколько раз просматривал errata, но, как по закону подлости, этот абзац не заметил. Похоже, что именно в этом и кроется причина. Я вообще-то программист и еще новичок в ARM, и полагал, что я просто неправильно программировал контроллер PIO. Буду разбираться с разработчиком платы. Когда разберемся - обязательно доложу.

Вряд ли это приемлемо. К сожалению входных сигналов в проекте будет далеко не один и, как я понимаю для таких целей можно будет задействовать только входные периферийные линии. Да и должен же быть способ решить эту проблему без жертв и разрушений... :laughing: Я же говорю, что когда перепрограммирую линию как периферийную, то линия читается нормально. Да вроде как включено. Может еще чего надо включить?

Да я уже и в отладчике вручную n-ое количество раз пытался это делать, а результат - все тот же... Когда я разрешаю работу пина на выход, то читается уже не 1, а значение, которое я прописываю. И когда он задействован как периферийный, то тоже читается нормально. А как только перепрограммирую этот пин как чистый вход, то постояноо читается 1. Документация тоже свежая и ничего по этому поводу не нашел...

Уважаемые специалисты! Помогите пожалуйста! Не могу прочитать входной сигнал контроллером PIO. Прследовательность действий следующая: 1. Подаю тактовую, прописывая 1 в бит 2 регистра PMC_PCER(для контроллера А) 2. Запрещаю работать линии как выход, для чего устанавливаю 1 в соответствующем бите регистра PIO_ODR 3. Разрешаю управление линией контроллером PIO, для чего устанавливаю 1 в соответствующем бите регистра PIO_PER 4. Читаю регистр PIO_PDSR с надеждой получить искомое значение, но там в соответствующем бите все время торчит 1. Что я не так делаю? Попутно хочу заметить, что если запрограммировать линию под работу с переферийным устройством (а конкретно модемом), то этот входной модемный сигнал читается без вопросов. Заранее благодарен за любую помощь.

Прошу меня извинить за длительную паузу, не было возможности проверить... К сожалению результат тот же: как только перепрограммирую US_MR, данные перестают читаься. Мистика какая-то. В документации про режим full-modem всего пол-страницы, которые я уже до дыр зачитал...

Из зафиксированных изменений - переход DCD из 1 в 0. Но парадокс в том, что даже если просто посадить DCD на землю без установки коннекта, то идет нормальный обмен в обе стороны Не исключено, что при установке связи имеют место какие-то аналоговые эффекты, т.к. для платы в этот момент существенно меняется режим работы - модем жрет по полной программе. Но в таком случае все равно непонятно, почему это проявляется только в режиме full modem.

Да, именно так. Я только прописываю режим NORMAL в US_MR и ARM начинает читать данные.

Модем - SIM300C CTS=0 DCD=0 DTR=0 RTS=0 Из ARMa в модем при этом данные идут нормально и тот их передает в эфир. С другого конца модем тоже принимает данные и передает их в ARM, но тот их почему-то игнорирует...

Очень нужна помощь специалиста. Помогите пожалуйста! Подключаю GSM модем на USART1 AT91SAM7X256 в режиме full-modem (прописываю 3 в поле USART_MODE регистра US_MR). Все работает прекрасно до того момента, когда устанавливается CSD-соединение (соединение с другим модемом через GSM-сеть). С этого момента AT91SAM начинает игнорировать все поступающие с модема данные и так продолжается до тех пор, пока связь не будет прервана. Схема подключения: Модем ARM RX <--> TX TX <--> RX DTR <--> DTR DCD <--> DCD DCD <--> DSR (у модема нет выхода DSR) RTS <--> RTS CTS <--> CTS RI <--> RI Выходные для ARM сигналы DTR и RTS все время установлены в активное состояние (0). Если же запрограммировать USART1 на нормальный режим (прописать 0 в поле USART_MODE регистра US_MR), вышеописанный эффект исчезает. Но обязательно нужна аппаратная поддержка управления потоком, поэтому такой режим не подходит... Заранее благодарен за любую помощь.