Hadgehog

Добрый вечер. Прошу помощи. Необходимо провести испытания проводной или оптоволоконной линии связи работающей в канале Fibre Chennel. Задатчики и приёмники линии изготовлены. Проверка пакетов стандартными средствами канала на основе CRC32. Производится подсчет сбойных пакетов в единицу времени. Необходима нормативная база для создания методики тестирования линии связи и построения зависимости устойчивости канала, от длинны и количества разъемных соединителей.

Уважаемые коллеги, помогите найти более подробное описание на микросхему ADV7400A, регистрация на сайте Analog Devices пока не привела к желаемому результату. :( Спасибо.

добрый вечер, разделение служебной информации от данных производится на основе анализа сформированого кода 8/10, коды данных - кодируются строго по правилам, служебные команды нарушают правила кодирования. Для определения длинны кадра специально предусмотрены служебные символы SOF и POF которые однозначно определяют границы кадра, поэтому объём данных вычисляется по мере приёма кадра, просто должен стоять программый ограничитель на длинну кадра. Если длинна кадра вышла за допустимые граници -сигнализировать о ошибке кадра.

добрый вечер поставками соединителей AMPHINOL в Россию осуществляет фирма bee-pitron (Би питрон) С.Петербург bee-pitron.ru. Вопросами поставки и техническими консультациями занимается Стуколкин Николай.

добрый вечер deast по пункту-1. заполнителль IDLE передаётся всегда когда линия не активна, т.е. по неё не передаётя полезная информация в виде пакетов данных. Отсюда вытекает очень важное правило: все передаваемые данные в канале ориентированы на 32-х разрядную архитектуру. Если надо передать хоть байт, хоть слово необходимо занять минимум 32 бита - слово в терминологии FC. что касается К28.5 и D21.4.. и.т.д все вопросы по правилам формирования к IBM, такая кодировка это их изобретение. символ "К" признак служебного символа, "D" -признак символа данных, отличия в правилах форирования битовой последовательности-разрешённого количества "1" и "0" подряд. Одним словом IDLE - 40 бит в линии связи. Самое простое решение: пользоваться готовыми кодеками с встроеным кодировщиком 8/10, и умножителем с ФАПЧ для востановления несущеёй частоты. по вопросу кодирования 8/10 можно поковырять мегафункцию Альтеры- доступна ограниченая WEB версия, ранние варианты ядра подвергались лечению, настоящие не пробывал. по пункту-2 SOF- четырёх байтный символ начала кадра данных (в линии 40 бит данных ) EOF- четырёх байтный символ конца кадра данных (в линии 40 бит данных) не стоит забывать о обязательных полях: номер кадра в последовательности, номере последовательности, CRC32итд. Предложеная нарезка FC-кадров вполне справедлива, ввиду того что разрядность цвета на точку 32 разряда. В случае если кодировка точки -8, 16, 24 разряда, то FC-кадр необходимо выравнивать до кратного 32, заполняя хвосты 00. То что предполагается для передачи видео вообще не FC в стандартном виде, это HotLink в терминологии Cypress - выхолощеный до нельзя канал уровня FC-PH ориентированый на одностороннюю передачу данных(видео данных). работать будет, но в целом могут быть проблемы позже, если потребуется сменить формат или переключать форматы изображения во время передачи. можно посмотреть драфты стандарта ANSI X3.... для аудио видео приложений FC-AV, там много стандартных реализаций передачи видеоданных.

Выложил в upload/doc/ANSI X3.230-1994 документик, может быть поможет. :rolleyes:

Спасибо! Но я думал, что для входов опорной частоты трансмиттера REFCLK+/- лучше использовать LVPECL-осцилляторы. Вот, у EPSON есть EG-2101CA EG-2102CA-P EG-2121CA-P Но они не подходят по температурному диапазону... :( EV-2101CA-P - подходящий, но у нас его не найти - по efind.ru, во всяком случае. Есть ещё осцилляторы от ICS... А HG-2150CA-BXC - CMOS'овский! Конечно, в PDF'е на трансмиттер указано, что можно использовать только вход REFCLK+ с подключенным к нему источником LVCMOS или LVTTL сигнала. Но я думал, что LVPECL - правильнее. Как же, всё-таки, лучше? :unsure: Вы, наверное, выбирали наиболее доступный компонент? <{POST_SNAPBACK}> Добрый вечер. Честно говоря при выборе опорного генератора было прядка 10 позиций, начальный выбор происходил исходя из требований стабильности и температурного диапазона, на последнем этапе доступность играла основную роль. использование LVPECL конечно более правильное, но как показывает практика использование генератора с уровнем CMOS при подключении к ПЛИС и разгон (умножение), равно как и деление частоты на PLL и последующая выдача на трансмиттер вполне допустима. Хитрость состоит в том, что для надёжного съёма информации при приёме необходимо пользоваться востановленой частотой от трансмиттера.

использовали генераторы типа HG-2150CA-BXC 25МГц от EPSON заказывали в С.Петербурге ф. "Специал Электроник"

добрый день. вчера закончили модуль выдачи и приёма тестового сигнала. Прокачали через канал картинку 640х480 30 к/с, правда картинка цветные полосы, без хитрых элементов, думем как прикрепить на этот фон подвижный объект, хотим посмотреть динамику. Телевизионная камера с выходом FC пока не готова. Очень впечаляет работа трансформатора на витую пару от PulsSpeciality, за не имением под рукой правильного провода на 150 Ом в экране, взяли обычную витую пару 5 категории - сколько было-38 м. смотрим как ведёт себя CRC, пока особых проблем нет. В понедельник будем замешивать в канал помеху.

Уважаемый Uree если есть возможность, положите добытые трансляторы для всеобщего доступа, у меня к сожалению пока нет регистрации ментора и почему то нет выхода на мегратек :rolleyes:

Макетная плата настраевается, запуск канала FC на скорость 250 и 500 Мб/с прошёл нормально, программные модульки приёмника и передатчика успешно формируют и принимают пакеты по ANSI Х3.230.1994, СRС вычисляется. Пока ещё не готовы модульки визуализации принятых данных на мониторе, до конца месяца хочется завершить. Есть определённые вопросы по CRC - не о механизме расчёта, он работает нормально, а о порядке подачи байтов на автомат расчёта, думаю до конца месяца определиться с этим вопросом. Сейчас уже не помю, уточню позже в каком режиме (состояние упр. ножек) произвели запуск. Общее впечатление от микросхемы: чип вменяемый - реакция на управляющее воздействие прогнозируемое, по описанию. потребление достаточно высокое, что интересно от скорости передачи не зависит- или мы не заметили - на скорости 250 и 500 были равные результаты. что интересно, значительное потребление даёт приёмник. награев в режиме когда включен приёмник и передатчик у радиатора 30х30 мм с высотой ребра 7 мм 42 гр.С Был у нас глюк: подключали трансформатор-эквалайзер к чипу с подтягивающими резисторами на 220 Ом (согласование pecl) поимели очень нестабильные результаты по захвату частоты синхронизации, заменили на резисторы на 330 Ом (что рекомендовано в большинстве описаний) всё работает на ура. в планах: когда завершим работу с платой (получим устойчевый канал + визуализация) засуним в камеру тепла и холода, руководство желает использовать :twak: неправильные соеденители - типа СНЦ23, проведём опыт по устойчивости канала с несогласованой нагрузкой :w00t: .

В ближайшее время отправляем в производство макетную печатную плату, если производство не подведёт месяца через 2 можно говорить о результатах.

В зависимости от предназначения печатной платы выбираются типы открытия и закрытия масок. Для опытных и макетных образцов иметь дополнительные точки контроля (ПО) великое благо. Для серийного производства на мой взгляд маски необходимо закрывать. особенно при поточном монтаже на автоматах. Для плат предназначеных под BGA переходные отверстия непосредсвенно под корпусом должны быть закрыты-чтобы не вознили капилярные эффекты с припоем в случае не качественной установки корпуса микросхемы. рассуждения по пунктам "Против" 1. облуживание переходных отверстий не является основной операцией создания электрического перехода. Электрический переход создается электрохимическим осаждением меди на стенки переходного или монтажного отверстия. Коррозия меди при повреждении маски возможна, однако если будущие условия эксплуатации устройства предполагают усиленую корозию то маска не спасё, необходима защита смонтированой печатной платы защитным лаком. 2.Налицо некоторое противоречие с первым пунктром: Электроконтроль обеспечивает прохождение сигнала между контактными площадками по пути которого могут встретиться и переходные отверстия (ПО). Обрыв цепи по вине ПО - брак изготовителя, "лечение" за его счёт. 3. в единичных случаях, при настройке опытного образца, при определённой сноровке можно пропаять и при наличии маски. :rolleyes:

как говорит моё начальство: "сам задал вопрос, сам его решай". по поводу стыковки механических сапр (MDT 6) с электронными (PCAD 200x) через IDF файлы выяснил следующее: 1. PCAD генерит очень глючный IDF файл - если в названии копронентов присутвует пробел, то MDT не прочитает такой файл, так как пробел есть разделитель между полями (спецификация IDF). (можно исправить руками, но долго) 2. PCAD генерит IDF в формате V3.0, а MDT принимает только V2.0, отличия этих форматов в том что в 3 введен новый параметр - высота установки элемента над платой. 3. PCAD генерит IDF читая библиотеки проекта а не topsilk-иногда происходят сбои и контур элемента превращается не в то что задумано. 4. РCAD генерит IDF толко в mil-ах, поэтому рекомендую перейти в эти единицы измерения при передаче платы в сапр. 5. высоту элементов нужно задавать в атрибутах в MIL. для лучшего результата применяю случайно найденую DXB утилиту IDF File creator, лежит в прицепе. IDF_CEATOR.zip

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

к великому сожалению ссылка на www.mcu.narod.ru уже умерла :( , это понятно уже прошёл почти год. может кто поделится свежей ссылкой.

кто нибудь применял для запитки ядра ПЛИС MAX 1831? выходной ток до 3 А, раб. част 1 МГц. синхронное выпрямление.

Вопрос для знающих. Сам я схемотехник, механическими САПРам владею на уровне открытия чертежа, но обратиься насущным с вопросом потребовали коллеги конструкторы. каким образом необходимо правильно задать атрибуты высоты элементов в PCAD 200х, что бы передать проект печатной платы в механический сапр типа Механикал десктоп 6 через IDF. если не трудно пдскажите по шагам. Пожалуйста.

Уважаемый Esquire про перспективы всё понятно ;) . драфты разработчиков - Т11, проглядывались очень внимательно, все лаконично и по делу, хотя трудно разобраться когда смотришь разные редакции, наверное потому что всё по английски. Есть ли у кого подробности применения CYP15G0101DXB-BBI. Вот ещё вопросик по импульсному трансформатору: если длина линии связи не более 15 м, то возможно использовать ТМ266HSCT от PulsSpeciality для скорости 250, как такое решение? не очень ясен вопрос по соеденителям: хотелось использовать соеденитель на плату АMPHINOL 21-33837-2, для оценки прикладываю доку. если не трудно поясните правила разделки кабеля Tensolite 28473/02006-4. Суть вопроса в следующем: у начальства есть желание поставить блочный разъем серии D38999 размера 9 и уже от него кабелем сделать прокладку на печатную плату под запайку, отросток будет короткий, не более 30 мм. Меня беспокоит целесообразность подобного решения, мои ссылки на стандарты приводят только к ответам типа "а в чем разница? провода точно такие же", "установка соеденителя на печатную плату приведет к отрыву соеденителя и растрескиванию печатной платы в процессе эксплуатации" :( 21_33837_21_C.pdf

Недавно проявилась тема: прием и передача видеоданных через канал Fibre Channel, для упрощения предложено пользоваться протоколом по сервису 3, это означает что данные передаются без установления логического соеденения и подтверждения приема. предожено использовать скорость 250 Мб/с с перспективой наращивания до 1 ГБ/с. среда распостранения витая пара, не более 15 м. предлагается использовать микруху CYP15G0101DXB-BBI или CYV15G0101DXB-BBI в качестве линка, контроллер верхнего уровня на ПЛИС. Кто нибудь использовал то нибудь подобное? если не трудно раскажите про грабли :rolleyes: , пожалуста.

Спасибо. NIOS есть в наличии, только старенький. Проблема освоения стоит в особеностях использования GNU-шного софта. Пытался разабраться с инструментарием под LINUX, как отмороженый, уже сформировалась привычка к графическим средам WIN. Раньше у нас на работе был паренёк - знаток LINUX, мог грамотно что то пояснить, уволился. Проведите ликбез если не трудно о запуске софта под NIOS с испоользованием CYGWIN и BASH.

По длинне проводов связи последовательного интерфейса в описаной ранее работе было великое множество глюков, правда речь идет не о индикаторах а о сборе информации. В общем задача зеркальная - параллельно защелкнуть данные в регистр и передать по последовательному каналу. Глюки на длинне провода - 1.5 м в условиях промышленых помех, включение/выключение: эл.дв 18 КВт и эл.дв 2 КВт с редуктором. Лечение которое помогло - токовая петля, гальваническая развязка, но есть ограничение по скорости: быстродействие опторонов. еще помогло накопление нескольких запросов(повтор приема)- с целью выявления сбоя. правда это уже не по теме. для 60 метров линии связи и раздельных источников для каждой платы на мой взгляд дорого и сердито -только оптроны и как экзотика импульсные трансформаторы, можно обратиь внимание на драйверы LVDS, правда на большие длины практически не проверял.

в начале моей деятельности разработчиком 1999г. была следующая задача, микроконтроллер, клавиатура, четыре семисегментных индикатора, буфрные регистры на устройства управления. Управление индикацией по последовательному каналу, из за скудности ресурсов пришлось гродить канал программно. в итоге скорость передачи 250 КГц. Частота обновления 1 сек. одновременно управлялись по 2 индикатора одной тактовой частотой, через дешифраторы. в целом конечно заметно на индикаторе как передаются данные, но есть одна особенность, при использовании супер ярких светодиодов изменение яркости менее заметно чем при испоьзовании обычных, обяснение простое - скорость нарастания тока постоянна, яркость пропорциональна току, чтобы получить одинаковую яркость, для суперярких светодиодов нужно меньше времени. в общем чтобы на глаз не было видно особенных глюков нужно держать частоту смены индикации для 1 светодиода порядка 25 Гц минимум а лучше 50-60 Гц. в общем всю цепочку нужно забить за 20 мс (50 Гц). при скорости передачи 3МГц можно заполнить 60000 светодиодов, правда нужно помнить, что следующие данные посылать нужно через как минимум 20 мс, а лучше еще и попозже - светодиоды могут просто не успеть загореться, если светодиод не специальный ИК то мне не удавалось поучить модуляцию светодиода свыше 1 КГц. удобно поставить промежуточную защелку между светодиодами и последовательным каналом, и завести сигналь разрешения смены состояния индикаторов после того как заполниш всю цепочку. для восприятия глазом важно отношение времени на передачу информации на светодиоды и время высвечивания этой информации - соответственно обшая яркость свечения.

АУ ну кто нибудь вообще занимается NIOS? Прошу квалифицировоного ответа. Можно слить ядро Z-80 с описанием на общее обозрение, если кого заинтересовало.

В работе над одним из проектов один из наших сотрудников запарившись отлаживат сложный конечный автомат взял и изобразил за два месяца урезаное ядро Z-80. заняло оно порядка 600 ячеек. Ядро стабильноработает на EP1F50-100 уже в двух, трех проектах. Причина выбора этого ядра- у него осталось о нем (Z-80) хорошое впечатление и освоеная система команд. Aльтера широко двигает свое ядро NIOS, прошу откликнуться знатоков, как к этому зверю правильно подехать, с чего начать. Просто пробывал заняться NIOS с наскока да не очень разобрася с последовательностью написания и отладки программы для ядра.