Здравствуйте уважаемые разработчики! У нас есть модуль E14-140m. Хотим понять, можно ли решить, возможно через программирование arm, такую задачу.
Есть три цифровых сигнала.
1. Импульсы, периодически появляющиеся с частотой 30 Гц. Эти импульсы обозначают начало очередного периода сбора данных
2. Импульсы, следующие с частотой 30кГц, то есть по тысяче импульсов на один период между импульсами в линии 1. Они отмечают начала интервалов измерений, то есть разбивают большие интервалы (33 мс) на тысячу малых (33 мкс)
3. Импульсы от прибора. Идут случайно, частота следования до 100 кГц. Нужно считать их количество на малых интервалах, определяемых импульсами линии 2, и накапливать значения счетчиков по ходу циклов, определяемых линией 1.

Значения тысячи счетчиков хранятся в буфере, который мы периодически считываем из модуля, скажем раз в 10 сек.

Какие могут быть пути реализации?
Пока я вижу два основных пути.
1. Основан на периодическом опросе цифровых линий. Но кажется он тупиковый - хватит ли в принципе производительности модуля по чтению цифровых линий для того, чтобы детектировать  импульсы? Если я правильно понимаю, доступ к цифровым линиям возможен только через usart, работающий на 8MHz? И, следовательно, предельная скорость чтения будет порядка 100 кГц? Если так, то детектирование импульсов в линии 3 будет невозможно, так как их длительность, скорее всего, будет в диапазоне 0.1 - 1 мкс (пока изучаем возможности прибора), то есть понадобится частота опроса по крайней мере выше мегагерца. В первой и второй линии импульсы могут быть длиннее и, наверное это как-то решаемо (особенно для случая первой линии).

Тогда второй путь. Может быть как-то можно использовать прерывания (по фронтам импульсов)? Хотя, опять же, похоже что прерывания от INT и SYN идут только на ПЛИС и не транслируются до ARM (?). Или все таки как-то можно их использовать, а импульсы в первой линии детектировать прямым опросом цифрового входа?

Развейте пожалуйста сомнения. Стоит ли браться? Может есть другой путь, или вариант с другим модулем/платой?

Станислав, по традиции сначала прошу уточнить электрическую часть вопроса:
- В каком диапазоне находится длительности каждого  из трёх импульсов?
- Время фронта/спада?
- Уровни напряжения логического нуля и единицы?
- Какие источники импульсов используется? Как далеко расположены он от E14-440D? Источники индивидуально изолированы от земли?

На первый взгляд, задача очень естественна для LTR51 (допустим, в крейте LTR-U-1-4), но потребуется на верхнем уровне устраивать собственную обработку данных (выглядит не слишком сложно).  Но длительность импульса для LTR51 должна быть хотя бы 5 мкс или более.

В E14-140m ARM связан с периферией через ПЛИС. Естественно, изменяя прошивку ПЛИС под Вашу задачу (если заказной вариант), там можно много чего сделать, но это, кажется тяжелым (и дорогим) вариантом. Посмотрите на E-154. Там 8 линий ARM-а прямо выходят на внешний разъём. При низкоуровневом программировании там чудеса можно творить..

Если длительности импульсов порядка 0.1-1 мкс, то, наверное, E14-140M тут мало подойдет. Но если, скажем, затянуть их до 5 мкс внешним формирователем (зная, что частота следования меньше 100 кГц), то можно поэкспериментировать.

Опрос регистра TTL делается через ПЛИС командой, которая занимает 5 9-битных байт (3 на запись, 2 на ответ), то есть, видимо, максимальная частота будет около 8E6/((9+2)*5) ~= 145 кГц.

Я бы посмотрел в другом направлении: использовать потоковый ввод с аналоговых линий с покадровой синхронизацией (от линии 2), а все каналы в кадре настроить на один физический канал. Частота дискретизации для E14-140M до 200 кГц, задается как 8000000/целое_N, правда, точно попасть в 30 кГц не получится: можно взять делитель 44 и кадр из 6 отсчетов, это получится ~30303 Гц.

Непонятно, правда, дадут ли эти 6 отсчетов достаточно информации.

Кстати, теоретически ведь можно как-то аппаратно проинтегрировать сигнал (предварительно сформированный по уровню и длительности) за 33 мкс и вычислить количество импульсов через напряжение на выходе этой цепи. Хотя на такие авантюры вряд ли стоит идти, если есть возможность применить более подходящий для задачи прибор.

Что касается прерываний, то линия INT вообще-то приходит через триггер Шмитта и ПЛИС на ногу IRQ1 (PA30), просто в штатной прошивке она не используется, все функции синхронизации выполняет ПЛИС. Но я пока не очень представляю, как это применить.

Сигналы TTL, длительность 1 мкс. Первые две линии - цифровой выход схемы управления вибратором, третья линия - амплитудный анализатор импульсов рентгеновского детектора. Земля у них общая. Идут по РК кабелям около 3 метров. Все вместе - спектрометр ЯГР.
Если у LTR51 предел по длительности 5 мкс, то он видимо не пойдет (амплитудный анализатор выдает либо 0.1 либо 1 мкс. Управление вибратором выдает сейчас импульсы 1 мкс - можно и увеличить длительность, но по правде - не хочется.
Вариант с E-154 выглядит многообещающе. Получается, что скорость опроса цифровых входов будет ограничиваться только скоростью самого ARM? И еще - после первого просмотра документации ARM мне показалось, что его входы можно сконфигурировать так, чтобы они были источниками прерываний по изменению уровня. В таком случае, все изменение прошивки будет заключаться в добавлении трех обработчиков (перевод указателя на начало массива, на следующий элемент массива и добавление единицы к текущему элементу), функции старта счета и функции передачи массива по внешнему запросу. Наверное это самый оптимальный путь для сбора?

Пошивка E-154 делается только через JTAG или по USB тоже?

По поводу E-154. Да, скорость опроса цифровых входов будет ограничиваться только скоростью самого ARM, а точнее скоростью его периферии, которую будете задействовать.
Поскольку источники сигнала заземлённые, то их землю и точку заземления (корпус) компьютера нужно будет коротко объединить, чтобы по кабелю USB (которым присоединён E-154) не гуляли сквозные токи.

Там есть USB-загрузчик, подробности
http://www.lcard.ru/download/e154_programmers_guide.pdf п.2.3 и далее...

Спасибо, будем думать.

Прерывания с высокой частотой следования тоже надо делать с оглядкой, 100 кГц = 480 тактов на 48 МГц, это не так много, особенно есть в системе есть другие прерывания.
Но по рисунку 4-1 в http://www.lcard.ru/download/e154_manual.pdf (стр. 12) одна из линий попадает на TCLK0, т.е. от нее можно затактировать таймер, и он превратится в аппаратный счетчик импульсов. Вот это уже интересно.

Пытался компилировать исходники прошивки. В проекте есть ссылка на некую директорию с заголовочными файлами "C:/prj/E154/ARM_BIOS/VERSION02/INCLUDE", которая не включена в архив e154_arm_sources.zip
А локальная папка include содержит не все .h файлы
По-крайней мере:
Fatal Error[Pe005]: could not open source file "ioat91sam7s64.h"

этот файл стандартный от компилятора (интерфейс к регистрам контроллера), поищите в arm/inc/
Надо include path туда прописать.

Действительно... я полагал, что iar сам зайдет в папку Atmel в arm/inc/ (архитектура ведь ему указана...)
Но была ошибка: несоответствия деклараций функции USBSendCtrl
в ./INCLUDE/USB.h   - void USBSendCtrl(byte *, int)
в ./HAL_SAM7S/USB.c - void USBSendCtrl(byte *, int, int)
все вхождения по коду имеют три аргумента!
после правки USB.h компиляция проходит.
Учитывая вышесказанное, наверное вам имеет смысл проверить соответствие состава архива исходников и проекта, который вы компилируете у себя (вдруг имеются еще расхождения, не вызывающие ошибок при сборке).