ПЛАТА: L-761 (2185)
СИНХРО: ПОКАДРОВАЯ 
ОS: DOS

Имеется следующая проблема:

По приходу синхросигнала ,кроме сбора данных необходимо подавать управляющий сигнал(6 байт)на другой комп через LPT.Поскольку нет гарантии, что DOS будет обрабатывать прерывание без неуправляемых задержек возник вопрос:

можно ли запрограммировать DSP для решения этой задачи? Т.е. через TTL "эмулировать" протокол ECP?

С уважением Андрущенко

У меня похожая задача, пришлось для этого приделать более медленный девайс к цифровым линиям. Прикинем: строб 500нс = 7 клоков DSP. По-моему вписаться в протокол ECP одновременно с оцифровкой трудно.

Запрограммировать можно все.
-Только на кой ляд 6 байт передавать ? Да еще и через  LPT
- 500нс - это не 7 клоков
- строб - это не 500 нс, а эээ... понятие растяжимое
- Dos - это неспортивно ;-)
- писать программу под DSP эээ...тут мало кто пишет

Хоть DOS и не спортивно, но там как раз мамсимум гарантий, что все будет работать как нам хочется. Все отдано на откуп прогаммисту, и возможности , но и ответсвенность. Как напишишь так и будет работать.

Управляющие 6 байт надо посылать после оцифровки:
1.пришёл синхроимпульс (200Hz)
2.сняли кадр (22 канала)
3.посмотрели есть ли то, чего надо в нужном канале
4.записали в порт байтик,(а надо 6 шт.)

Вопрос в том, чтобы сократить время с прихода синхро до пересылки последнего управляющего байта,
плюс, как уже говорил, быть железно уверенным, что
пропусков не будет (LCARD в ДОСе сидит на 12 прерывании)- т.е. организовать вышеуказанный алгоритм на DSP (независимо от центрального процессора)

С уважением Андрущенко

2Evgeny

> 500нс - это не 7 клоков

А сколько? Кварц 14,7Мгц

> строб - это не 500 нс, а эээ... понятие растяжимое

Для стандарта EPP строб 500нс. Или я ошибаюсь?

2Андрущенко

> 1.пришёл синхроимпульс (200Hz)

Тогда конечно успеете передать. Можно и без DSP, используя функцию вывода через цифровые порты.

Согласен,что за 5 миллисек это можно сделать, вопрос в МАСКИМАЛЬНОЙ скорости передачи этих 6-ти байт: ведь (если не ошибаюсь) скорость ЕСР составляет 2Мб/сек, таким образом  за 1 одну миллисек можно передать аж 2Кб!Практически это возможно? Либо ссылку забавную по этому вопросу,
потому, что кроме описания IEEE 1284 ничего не находиться и выведения символа на БЕЙСИКЕ ничего нет

С уважением Андрущенко

Вообще-то я согласен с Evgeny относительно доса и посоветовать ничего не смогу. Каким образом можно притормозить стандартный протокол такими древними средствами я не знаю.Если бы принимающий порт был бы под нормальной ОС, (в моём случае линукс) то было бы проще.Наверное вам придётся реализовывать досовский драйвер самому. Может посмотреть в сторону другой ОС? В линуксе мне пока хватает точности единиц микросекунд, но комп кроме моей задачи пока ничем не занят. Если понадобится более точная подстройка или жёсткая рантаймовость, то я планирую использовать rtlinux. Сам пока не попробовал, но согласно описанию там уже считаются наносекунды.Заставлять dsp работать коммуникационным контроллером да ещё на тактовой 14МГц лично мне кажется бесперспективным.Но это дело вкуса, конечно. Можно ещё попробовать передавать не через цифровые порты L761, а через EPP компа собирающего информацию.

1. Тактовая частота DSP есть удвоенная частота кварца, т.е. для платы L-761 она равна 2*14.7456 = 29.4912 МГц.
2. Доступна хорошая книга Владимира Кулакова "Программирование на аппаратном уровне". Там есть целый раздел про ECP режим параллельного порта с примерами программирования на ассемблере. Эту книжку можно заказать через интернет:
http://www.piter.com/book_about.phtml?i … web_ok=yes
3. Посмотрите ссылочки:
http://konstantinv.boom.ru/appar/1.htm
http://www.fapo.com/files/ecp_reg.pdf
http://www.beyondlogic.org/ecp/ecp.htm
http://www.beyondlogic.org/pardebug/pdebug.htm
http://www.lvr.com/parport.htm

То есть для создания строба 500нс надо 14-15 клоков dsp? Это несколько облегчит задачу товарищу. Сорри, про удвоение что-то забыл.Сергей, есть такое предложение выложить подборку модифицированных лбиосов на сайте - возможно это будет небесполезно для всех желающих использовать dsp в новых режимах.

Сергей спасибо за ссылки

Если у Вас есть модифицированные LBIOS - присылайте. Обязательно выложим на всеобщее обозрение.

У меня модификация в стадии тестирования, поэтому пока нечего выложить, я хотел сам подглянуть;) Если результат будет положительный, обязательно пришлю.

To Стас:
С частотой уже разобрались ;-)
>> строб - это не 500 нс, а эээ... понятие растяжимое
>Для стандарта EPP строб 500нс. Или я ошибаюсь?
стандарт EPP не видел, но во всех других местах строб - это от и до или не меньше чего-то.

>Наверное вам придётся реализовывать досовский драйвер самому. Может посмотреть в сторону другой ОС? В линуксе мне пока хватает точности единиц микросекунд, но комп кроме моей задачи пока ничем не занят. Если понадобится более точная подстройка или жёсткая рантаймовость, то я планирую использовать rtlinux. Сам пока не попробовал, но согласно описанию там уже считаются наносекунды.
----
Не буду агитировать в сторону более другой OS, хотя  я сам пользуюсь OS/2 для синхронной работы с парой L761 в более чем риалтаймовом приложении ;-)
Мое мнение таково - для быстрых задач есть DSP, для медленных (миллисекунды ;-) - есть PC со всеми его плюсами - в том числе и сетевизмами. Надежды на то, что что-то там многозадачное обеспечит вам наносекунды - оставьте до тех пор пока не найдете описание/расчеты/просчеты производителей мам+процессоров насчет того, сколько  времени съедают все кэши.
Использование Dos/'а в сочетании с 2185 - это полный нонсенс

> Надежды на то, что что-то там многозадачное обеспечит вам
> наносекунды - оставьте до тех пор пока не найдете описание/ расчеты/ просчеты производителей
> мам+процессоров насчет того, сколько времени съедают все кэши.

В моём случае синхронизация предполагается внешняя, а реальное время реакции процессоров покажет практика. Меня интересуют времена в районе десятков-сотен наносекунд и не вижу пока ничего, что помешает мне их получить. Для dsp в моей задаче отводятся функции управления внешними аналоговым мультиплексором и усилителем/ослабителем сигнала дополнительно к имеющемся. Остальным занимается пентиум, поскольку dsp не справится с нужной мне обработкой.Так штаа... не будем спешить с выводами;)

Ну сколько можно буратин воспитывать....
Ну прочитайте хоть один байт с любого порта и замерьте время....

Папочка,так читаю же - и пока меня микросекунды устраивают.Если не получится с пентиумом наносекунды, я его просто заменю на свою схемотехнику, благо сейчас уже параллельно несколько процессоров крутятся. Оттуда и внешняя синхронизация, кстати. Не думаю что получить 14 разрядов ацп это такая большая проблема. Встроить линукс в какой-нибудь арм это тоже несложная задача. Может ещё скажете там тоже наносекунды невозможны? Как же в камаках получали 200нс стробы,обьясните. А то помру буратиной несмышлёной;)

Флаг в руки и барабан на шею!
После получения граблЕй по лбу можете идти и изучать матчасть, если уговоры изучать матчасть на вас не действуют.
А "Встроить линукс в какой-нибудь арм это тоже несложная задача" - это просто шедевр.

Этим тоже постоянно занимаюсь даже без лишних уговоров. Покажите хоть одну свою разработку в железе, чтобы я мог именовать вас папой. Кроме юмора пока ничего не замечаю. Папами не рождаются, папами становятся, кстати говоря.

Чтобы зря не трепаться, можете ознакомиться с тем, что сейчас имеется.
------------ Start here -------------

Loading parameters......
Loading channel table......
Setting parameters......

table_size: 16

N of channels: 16
frame_size: 32
total_frames: 8
total_size: 256

buf_frames: 1024
frame_size: 32
buf_frames_size: 32768

ADC frequency: 125000 Hz
Frame frequency: 7813 Hz
frames: 0

Start ADC......
Stop ADC......

frames: 8
bytes: 256

dtv.tv_sec: 0
dtv.tv_usec: 271
tik1: 33.0 mks/frame

НУ и шо это за бред ?

Я тоже могу выдать что-нибудь вроде:
======
  asm("DM(" cSport1_Rfsdiv") = %0;"::"c"(l780.DAC_Rate));
  asm("DM(" cSport1_Ctrl_Reg ")=%0;"::"c"(0x7D0F));
  asm("ICNTL=0x07;");
    asm("IFC=0xFF; NOP; NOP;");
   asm("SET FL0;");
   asm("SET FL1;");
   asm("SET FL2;");
======
Но из этого не следует, что
(a) на PC достижима точность измерения времени в наносекунды
(б) на PC возможна реализация времени реакции на внешнее событие в наносекунды
(в) даже если предположить, что у вас реализован DMA и прерывание от DSP мгновенно долетает до обработчика прерывания на PC (а это, очевидно не так), то для выдачи реакции нужно либо записать данные в какой либо порт, либо в DSP. Даже если программа в DSP - моментально среагирует на запись, то все равно время передачи ограничено 10Мб/сек или 5МГц/200нс на слово.

1. http://www.fsmlabs.com/ раздел faq

Q: How do Linux processes communicate with RTLinux threads?
A: RTfifos provide a device interface that can be read/written on the Linux side. (Data transfer is over 100Mbytes/second in a modern x86.)

Подробности если надо прочитайте сами.

2. Реакция в асинхронном режиме само собой невозможна, в синхронном возможна. У меня как раз синхронный.

3. Проблема, которую вы раздули из ничего своими голословными высказываниями про кэши, товарищ задавший вопрос обозначил как влияние многозадачности ОС на реакцию РС на событие. Поэтому ему и хочется реализовать свою задачу в досе, чтобы уйти от задержек, связанных с этим. Действительно, если выполнять асинхронный обмен данными, то линукс имеет право задержать его до 10мс, винды до 50мс если не влезать в процессы ядра ОС. Про os/2 не знаю, но думаю что там тоже в этих пределах. С задержками на уровне реакции чипов это совсем не связано (или обьясните физику процесса и ответьте на вопрос по камаку).

4. Повторюсь ещё раз, у меня параллельно обрабатываются несколько синхронных процессов, один из них на РС с участием L761. Тайминг ADC-DSP выполнен с микросекундной точностью разработчиками лкарда. Пока он меня устраивает и в линуксе я в эти времена пока вписываюсь. Наносекунды (если они понадобятся) можно достигнуть установкой rtlinux (см.ссылку) или реализацией отдельного модуля, выполненного например на контроллере adc+arm+eeprom+ethernet/usb без вмешательства PC. В лкард это разработка соответствует H2000, но её стоимость пока для наших задач недоступна. Если вам это не под силу, то ещё не значит, что никто не может этого сделать.

окей.
Домашнее задание:
0.
Научится считать микросекундный таймер,
Построить гистограмму времен между последовательными запросами таймера

1.
Определить среднее время выполнения инструкции....окей...конструкции ну допустим
int i;
....
i++

2.
Определить среднее время выполнения...memcpy в байтах/сек

3. Определить размер кеш-памяти

4. Определить время выполнения из п1 и п2 при наличии операндов в кеше и не в кеше.

5. Определить время выполнения inp()
5.1 для наиболее продвинутых - определить время выполнения inp, inpw, inpd, outp, outpw, outpd для портов на шинах ISA и  PCI

6. Промедитировать над результатами в пунктах 0-5 и определить количество глупостей, написанных вами ранее.

6.1 Для особо одаренных - определить различие в архитектуре PC и специализированных модулей КАМАКа

Относительно ввода-вывода по шине pci для L761 - единицы микросекунд. Но. Попробуйте проделать всё вышесказанное одновременно с форматированием дискеты или обработкой сетевых запросов или тасканием мышкой окон на десктопе. Все измерения пойдут лесом. Заявленные лкардом 10МБ/с я имею без проблем, но мне нужна минимальная рассинхронизация от внешней частоты при любых перечисленных действиях. И здесь у меня пока есть нерешённые вопросы.

Про камак. Представьте себе некое подобие камака, выполненное не на 155й серии, а на современной элементной базе в конструктиве 6U. Затем один из модулей ацп крейта представьте в виде PC+L761. Напрягите воображение и представьте, что несколько модулей работает одновременно от стабильной опорной частоты. Если не получается, попробуйте посмотреть на описание H2000. От связки PC+L761 мне нужны синхронный ввод данных от ацп. коммутация каналов и управление усилением.(всё это рализуется посредством лбиоса) Если бы рассинхронизация составляла микросекунды, то первый этап задачи был бы решен, но пока имею миллисекунды. Этим сейчас и занимаюсь. А с кэшами я пока не связываюсь, будет время, посмотрю.

;-)
И форматирую, и окна таскаю. Правда я не утверждаю что нерперывно при этом общаюсь с платой. Собственно посему DSP и используется, что позволяет нормально управлять быстрыми процессами и одновременно нормально использовать нормальную многозадачность на РС.

Про камак - имелась  ввиду совсем  не архитектура шины, а то, что половина блоков камак вообще не имела никакой связи с шиной и была чисто аппаратной вплоть до всовывания внутрь блока кусков провода для организации линий задержки. соответсвенно стробы в 200нс там генерировались аппаратно.

H2000 - это тот же самый 2185, только вроде частота там 40Мгц.

Что касается синхронизации - я использую программную синхронизацию двух L761. точность одновременного старта предположительно составляет несколько микросекунд, после старта платы работают автономно и  в течении минут никаких видимых признаков рассогласования не наблюдается. Это не означает что это хорошо, но тем не менее...поскольку оно работает,  идея выполнять синхронизацию через ТТЛ порты не была реализована.