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

http://www.rad-direct.com/Product-rad-bridge-tinybridge.htm

на самом деле нужно именно разработать данный девайс

А щто точно надо
1) V.35 -> Ethernet .... Ethernet -> V.35 (V.35 over Ethernet)
2) Ethernet -> V.35 .... V.35 -> Ethernet ( Ethernet bridge over V.35 )




Посмотри сюда:
http://electronix.ru/forum/index.php?showt...=16146&st=0
http://electronix.ru/forum/index.php?showtopic=480

Спасибо за ссылки, необходимо что бы одна сеть Ethernet видела другую сеть Ethernet, между сетями канал построеный на модемах с V.35.
Сейчас в качестве конвертера используется Cisco с портами Ethernet и V.35, что несколько дороговато, да и не совсем удобно

ну с Ethernet частью понятно, но как реализовать стык MII с V.35?
Или я чего то не понимаю

Использовать чип с HDLC интерфейсом или на внешней FPGA.

Подскажите где можно найти информацию по v.35 я уже испробовал все поисковики...
Если можете подскажите конкретные компоненты для данного девайса

http://www.interfacebus.com/Design_Connect..._Interface.html
http://www.linear.com/pc/viewCategory.do?n...,C1,C1007,C1018
http://www.linear.com/pc/downloadDocument....018,P1077,D4292
http://www.linear.com/pc/productDetail.do?...007,C1018,P1077
http://www.exar.com/product.php?ProdNumber=XRT3589
http://www.advice1.com/v35.htm

Скорее уж http://www.sipex.com/Files/DataSheets/SP3508.pdf

Запутался я с этим конвертером
drevesina, как данный компонент получает данные от Ethernet контролера?
я не понял, если мне надо организовать и прием и передачу как это сделать?
мне нужно спроектировать именно такую вещь http://www.rad-direct.com/Product-rad-bridge-tinybridge.htm (которую посоветовал Dainis), т.к. необходимо подключить сеть к модему у которого один интерфейс idsl, а второй V.35...

Эти компоненты - только порты. Преобразователи уровней. Получить и передать данные от контроллера Ethernet при помощи их одних невозможно. Такое устройство, вообще говоря, должно содержать процессор, который создает функциональность как минимум пакетного бриджа, причем с приличной памятью фреймов и управлением потоком. Потому что V.35 - это просто синхронный поток бит, а Ethernet - это пакеты, причем с гораздо более другой скоростью. То есть пакеты надо складывать в буфер, обрамлять заполнением и вставлять в поток бит.
Имхо самое простое и вменяемое решение - это взять $30 плату китайского SOHO раутера, какой-нибудь Edimax. Там на ней полнофункциональный свич Fast Ethernet и ARM или MIPS с сериальными портами и USB. На нем линукс. Прошивки на сто раз расковыряны энтузазистами. Только сериальные порты не запаяны. Так вот я бы на них насадил преобразователи уровней в V.35 и потом попросил бы какого-нибудь линуксоида приспособить к ним драйвер синхронного последовательного порта.
Только у меня может быть склероз, и надо уточнить, может ли тот же сериальный порт в том процессоре быть синхронным. А то там могут быть отдельные порты для высокоскоростной синхры.
Совсем минимальный вариант - это что-то вроде Microchip ENC28J60. У него торчит SPI, который надо прикрутить к какому-нибудь быстрому восьмиразрядному процессору с синхронным портом. А на тот синхронный порт и вешать преобразователи уровня V.35.

Даже в допотопных железках типа Cisco 1005 в середине 90x годов использовали вот такие "восьмибитные" контролеры.

Что характерно уже с HDLC и Ethernet на борту.
К нему 8MB RAM, Flash пару-тройку мегабайт....

Ну. А в начале девяностых лично имел таких уродов, как шестипроцессорные 680х0 PABX на полторы тыщи абонентов. И чего?
Человек же явно пишет, что циска, равно как и ейная начинка, ему не по карману. Да и вообще, это не место для коммуникационного процессора. Циска - штука с операционкой и заточена под чертову уйму протоколов. Данному же товарищу ничего этого нафиг не надо, ему только принимать raw ethernet frames. и организовывать соединение точка-точка. Ему даже HDLC контроллер не нужен.

Да смысл не в кармане, просто сейчас все работает именно при помощи циски, но это несколько не целесообразно
По теме: задумался о atmega32 к которому подцепить все как вы сказали

Уже не помню, сколько RAM в меге32, но мало. Изернетовский фрейм - полтора кила, так что меньше меги256 брать не стоит. Или цеплять срам. Без буфера фреймов, хотя бы совсем маленького, это будет работать плохо. А за деньги меги256 лучше уж тогда ставить тоже атмеловский ARM7. Там и синхронный порт, поди, будет.
Имхо также при некотором программистском искусстве это можно вылепить на МС-чего-то-там-S12NE64. Пристроив к нему с одной стороны RJ-45 с трансформатором, а с другой - преобразователь RS-422. Только синхронный порт придется изготавливать ручками, что на 25-МГц камне может потребовать неких извращений.

Сколько раз можно повторится?
http://electronix.ru/forum/index.php?showtopic=480
>Этим я занимаюс последние 5 лет, решение:
>1) RAD ChipBridge ( only 10Mbit, obsolute)
>2) RAD ChipRouter( only 10Mbit)
>3) Redux RS-120 & RS-125
>4) ADMtek AT8993
>5) ADMtek ADM6996F
>6) nSYStech's Xbridge2.0
7) FPGA

На севодня самый простой вариант ADMtek ADM6996F + V.35 interface chip.

А не могли бы Вы пояснить?

1)..3) приносят деньги RADу или Вам, а цель у вопрошающего вроде бы диаметрально противоположная. Принести деньги себе. Насколько, конечно, я его интерпретирую.

4) это же какая-то очень старая микросхема, да? Она есть в производстве?

5) Да, вроде есть слухи, что один из МАСов этого свича якобы переключается в HDLC моду, и это якобы не описано в даташите, но знают посвященные. И на кой черт закладываться на недокументированную фичу? Я уж не говорю о том, что нет уже никакого ADMtek, а есть Infineon, и емнис даже актуальный даташит на 699х парню, поди, выдадут только под NDA, что есть ненужный геморрой.

6) Посмотрел. Ничего не понял. Какая-то неизвестная корейская компания, у которой полтора продукта, на сайте написано "old", последние новости датируются 2003 годом. Ни списка дистрибуторов, ни онлайн магазина. Плохо смотрел? И, это, есть гарантии, что эта компания будет жива через полгода?

7) так вообще выглядит несуразно. Зачем там FPGA? Там нужен процессор и память, а не гейты. Гейты там совсем не нужны.

Но самы вопрос в другом. То, что Вы предлагаете, это камень из пп. 4-7, плюс интерфейс RS422, плюс все равно мелкий процессор. Потому что девайс все равно надо хоть минимально конфигурить и мониторить. И софт для этого надо написать.
То, о чем я говорю, то же самое, но без большого, 100+ ног и $10, камня. Фишка-то в том, что _сейчас_, а не пять лет назад, самый дешевый uP, который все равно там надо ставить, вполне осилит еще и синхронную передачу. И написать ее - малая толика от всего остального. Все это разумеется имхо.
Ваш же подход сейчас уехал в другую нишу, в полосы пропускания много выше наших 1-2 Mbps. И камни под него - это всевозможные SoC с изернетовским свичом и армом или мипсом на борту. Но имхо тут это оверкилл.

Похоже "до бесконечности" всегда кто-нибудь ввиду полного непонимания пожелает что-нибудь
"просто соединить" и заявлять а то, что там еще кто-то наворотил, то "не надо", особенно мне понравилось "Ему даже HDLC контроллер не нужен" - предполагается, что летит, понимаешь, битовый поток без начала и без конца и "восьмибитовым контролером" все в Ethernet фреймы пакуется???
to drevesina
Тут еще одна веточка была - почитайте:
http://electronix.ru/forum/index.php?showt...amp;hl=ethernet
Ну а самый простой работоспособный вариант, как на этом форуме уже писалось, на инфинеоновских
ADMtek-ах. Dainis на них, правда, "зуб имеет", но по крайней мере с 2-мя двухмегабитными синхронными потоками они у меня работают без проблем.

Не осилит. Осилит, как и десять лет назад заточенный под это дело коммуникационный контроллер или
DSP. Ничего не изменилось, только появились более узкоспециализированные чипы с готовым отлаженным софтом.

Ну скорось передачи автор топика вообще не назвал, но думаю речь шла не не о сотне-бругой Бод

HDLC не то что "не нужен", а совершенно необязателен. Потому что в указанном применении можно придумать и использовать любой фрейминг, какой захочется. И, да, "битовый поток без начала и без конца восьмибитовым контролером в Ethernet фреймы пакуется". При достаточной производительности такового и достаточно малой скорости потока. Зуб даю. Личный опыт.

Я ничего не имею против инфинеоновских свичей. Покажите мне только в даташите, как его мак переключить в HDLC.

PS. Вспомнил еще. У RADа есть ведь еще MIRIC-530, да? Уж это-то проще всего. Деньги, конечно, надо отдать раду, но за изящество решения ничего не жалко.

Но, наверно, и не о десяти мегабодах? Давайте его спросим.

Придумать и реализовать.... Придумать планируется проще? Так он и так МАКСИМАЛЬНО простой для
битовых потоков. Что упрощать? контроль выкинуть - типа пусть там потом TCP/IP раcхлебывает?
Битстаффинг для удобства "восьмибитового контроллера" заменить байтстаффингом и потом "придумывать и реализовывать" поиск начала байта при первом-же сбое на линии?


Извращаться можно по разному. Вопрос ЗАЧЕМ! Результат таких извращений почти по Вашему рецепту ( только фреймер железный, а дальше Atmega и Ethernet ) запущенный в разработку приказом свыше мимо меня с напутственными словами "просто соединить" имею перед глазами. Могу выложить фото и даже подарить в железе. 64Kbit (говорят) в благоприятных услових жует, нагрузку не держит категорически, для поддержки штанов снаружи switch стоит....

Максимальная скорость передачи по ТЗ должна быть 2 мбит/с

Контроль выкинуть. Потому что во всех мыслимых приложениях это уйдет в порт свича, а тот дропнет битый пакет, не напрягаясь. На вход битый пакет так же без нагрузки на CPU дропнет изернетовский контроллер. Байтстаффинг... ну зачем так сразу бить по яйцам, можно еще 8B/11B, сделанное из набортового уарта. Если на целевом камне найдется уарт с поддержкой быстрого клока.
И, да, не об атмеге же речь для скоростей ~1 Mbps. Тут надо ядро с 50+ МГц.

А зачем - ну так из-за доступности и меньшей площади платы. Я же говорю, ничего против ADMtek. Только почему у него НDLC мода недокументированная? Или документированная?


Кстати, это просто херовые программисты. Эн лет назад мы выпускали серийно бридж на атмеге 128, cs8900, а фреймер тоже был железный. Устройство было для другого, а бридж - довесок к функциональности.
Получалось 1.5..2 Mbps, плюс там же крутился очень простенький вебсервер, телнет, и до предела кастрированный SNMP. Стояло как врытое. Совершенно неубиваемая вещь.



Спасибо, конечно, только ведь в ваши края визу надо . Приглашение, очереди и геморрои в консульстве.

Ну насчет наших программистов и железячников которые взялись "это" делать у меня никаких иллюзий нет .
Давайте поговорим о в Вашем девайсе.
Atmega128 16Mhz и 2Mbit синхронный поток передача и 2Mbit синхронный поток прием 10Mbit Ethernet. Получаем, что за 64 такта вышеупомянутая Atmega должна вытащить из железного фреймера байтик, положить через порты sc8900 в его память и периодически толкнуть передачу. Ну и в обратную сторону - выяснив наличие фрейма в cs8900 и его целостность вычитывать его по байтику и запихивать во фреймер. "Мелочи" типа наличия промежуточной буферизации опускаем. С обработкой ошибок Вы еще раньше "покончили" - тоже опускаем. Там еще что-то было на счет того, что это был всего довесок к чему-то? Ну бог с основным назначением тоже....
Не знаю, какие у Вас на фирме "программисты", но "сказочники" просто отличные!
А в реальности оно конечно "работало", но 2Mbit там и рядом не лежало, даже если угробленные этим девайсом пакеты считать.

Во-первых, не 2 Mbps передача и 2 Mbps прием, а около 1.5-2 Mbps FTP. Один поток в одну сторону. Так что не 64 такта, а скорее сто. Промежуточный буфер был во фреймере. Обработка ошибок - так Вы готовы объяснить, зачем она в устройстве, зажатом между двумя свичами?
Ну и самое существенное. Давайте поступим просто. Поставим на кон разумную сумму, ну, скажем, тысяч пять-десять. Я подлечу в Москву или в Ригу, откуда Вы там, захватив два устройства. Мы тут же подключим два ноута, запустим какой-нибудь iperf, и померим полосу. Среднее гармоническое между 64к и 2М - где-то 384 к. Если любые мыслимые измерения покажут больше, деньги заберу я, если меньше - Вы. Идет?
Я, конечно, могу проделать то же самое у себя под вебкамерой, но было бы очень приятно наказать Вас на деньги.

При этом, заметьте, Вы так и не ответили ни на один из моих вопросов.

Ага, начинаем накладывать дополнительные ограничения. А что симметричных протоколов не бывает?
И нескольких соединений через Ethernet низяяя

Кто-то совсем недавно проедлагал вопрошающему делать сие без дополнительной железной поддержки.

Вот еще и свичи появились, мелочь, но приятно.
Ну а коррекция ошибок, а что, по Вашему Ethernet ничего типа TCP/IP ходить не имеет права?

Канал передачи будет мой? Или Вы рассчитываете, что меня устроит демонстрация в "паркетных" условиях соединением метровым куском кабеля? Я ведь иммитатор канала поставлю.

Два ноута установившие между собой только одно FTP соединение не хочу - хочу соединение двух реальных сегментов сетей c их разными протоколами.

Так, уже скатились на 384k, вместо 2M
Некоторые замечания по поводу методики изложил выше.
Я кажется не многого хочу?
Согласитесь, соединение точка-точка двух комьютеров на расстоянии несколько метров (ну ладно, по идеальному каналу) и только одна сессия FTP с использованием 384k из 2M канала мало кого устроит в реальной жизни....
Для реальной жизни надо делать НОРМАЛЬНЫЕ девайсы на нормальном железе.
Продолжаем разговор?

Извините, пропустил видимо Один вопрос вижу:

Документированная. Политика раздачи документов под NDA это дело каждой фирмы. Альтернативы
этому чипу тоже есть - ссылку на ветку форума я давал.
Какие еще вопросы были?

Симметричные протоколы бывают. Просто скорость будет ниже. У того конкретного устройства.
Несколько соединений тоже можно, пожалуйста. Оно же вообще имело дело с raw Ethernet, ему пофиг вообще все детали IP, кроме длины пакетов. Сколько и каких сессий - без разницы. Канал в моем случае был оптоволокно. А какая, собственно, разница, что за канал? Или Вы имеете в виду каналы с BER типа 10-3...10-4 и заставить делать форвардную коррекцию? Так это не наш метод.
Канал лежит за пределами обсуждения. У инициатора темы канальные устройства уже есть. То, о чем мы говорим, по понятиям не каналообразующее устройство, а конвертор интерфейсов и не более того.

Свичи не "появились", а не могут не быть. Ну куда еще в принципе могут быть воткнуты эти железки?

До 384к, конечно, скатился. Все же даже пять штук - деньги для меня заметные. Но ведь и Вы стартовали с "64к и то не работало". На мелких пакетах, натурально, 2М из того устройства было не выжать. Но тем не менее это было вполне реальное устройство для совершенно реальной жизни. Хотя объемы продаж его не дошли даже до миллиона денежек, вины инженеров в этом не было.

И самое существенное - нынче есть камни заметно быстрее атмеги128. Если уж разрядность так важна. Каковые вполне можно применять в данном поделии. Вплоть до самого дешевого блэкфина.

А вопросы, они были где-то выше по ветке. В сообщении от 14:51. И сразу возник еще один вопрос - а почему я не вижу ни слова про HDLC в даташите v1.03 на упомянутый ADMtek?

Это Вы не подумали . В вашем FTP случае имеют место быть паркетные условия "запрос пауза ответ"
Буфер на один Ethernet фрейм решает все проблемы с буферизацией, допустимые огромные паузы позволяют организовывать межпакетные разборки, железка "фреймера" сама обслуживает синхронный поток. Просто курорт какой-то. При нескольких сессиях все становится совершенно асинхронным бегает кто когда и куда хочет совсем тогда когда его не ждут.
Буфера начинают требоваться совсем других размеров, ну и время на их обслуживание тоже.
Раздумья об управлении потоком начинают одолевать...

Если этот конвертер начинает резко хуже (вываливая кучу дерьма наверх) работать на каналах находящихся на грани допустимого понятия "нормального канала", то использовать или нет такой конвертер уже надо крепко думать.

В Hub, прямо в Notebook Вы-же и предлагали....

Стартовал с 64K не лично я. Ну а весь прикол в том, что "не работало" это чудо ровно так-же как у Вас считается "работало" . Посему я и счел необходимым высказать замечания по применимости девайсов построенных по такой схеме в реальной жизни.

Для реального, но абсолютно конкретного нишевого применения такие вещи можно и
нужно делать только не надо рекламировать такой подход в хоть какой-то замены хотя-бы профессионально сделанных железок 90x годов прошлого века. Не тянет.

Если сочтете за труд перечитать, то я говорил ровно о том-же самом поминая комуникационные контроллеры и DSP. Поминанаемый моторолловский контроллер тоже был коммуникационным контроллером. Ничего не изменилось Насколько я понимаю Dainis сейчас с успехом использует самсунговсие ARM. Я как побочную (примерно Ваши частные условия использования) работу на BF537 пробовал. Но в любом случае для добротного устройства сил придется на разные "мелочи" потратить очень много. На сегодняшний день если речь идет о функционально законченном девайсе использование специализированных чипов, тем более не специалистами, МНОГО предпочтительнее.

Нету в этой ветке сообщений в 14:51....

Отчего же. Количество сессий и все такое влияют только на требования к объему памяти буфера, но практически не влияют на ее полосу пропускания. И соответственно на скорость нужного процессорного ядра. Грубо говоря, полоса памяти хоть так, хоть эдак нужна примерно с ушестеренную скорость модема.

Имхо без управления потоком затевать этого вообще не стоит.

Это вряд ли. Хабов уж сколько лет в природе не бывает, как и полудуплекса. Ноутбуки на обоих концах... ну, возможно, конечно.

Дак они массово строятся именно по такой схеме. Весь вопрос в объеме буфера, ширине полосы к нему, скорости ядра процессора. А тут в последние годы выбор есть, в том числе и в категории ~$10 камней.

С оценкой трудоемкости согласен. Но имхо бОльшая часть сил уйдет на реализацию хотя бы минимального OAM. Расходы времени на собственно L2 протокол имхо примерно того же порядка, что и ждать подписания NDA с доброжелательным вендором и самплов. Плюс потом зависеть от поставок из одной дырки.
В то время как камни общего применения предлагают весьма настойчиво, только что что в ж$%& не засовывают. И по BOM price оно может оказаться лучше.

Ага, работаем так себе в установившемся режиме перекладывая 2Mbit в допустим 10Mbit (рассматриваем
Ваш вариант) и тут по 10Mbit прилетают несколько 1500 байтовых фреймов других сессий. Буфер у
используемого Вами NIC даже поменее 16K классического 8390. Для переложить пик 10Mbit потока в промежуточный буфер дополнительные ресурсы процессорного ядра значит не нужны???
В случае одной FTP сесии один фрейм полностью спокойно буферился в NIC и совершенно не ограниченно по времени (FTP/TCP таймауты огромадны) из него перекладывался во "фреймер".
Про "полосу пропускания" имеете ввиду разрядность? буферной памяти я ничего не говорил, говорил только про 32bit-ность используемого уже 1995 году в Cisco 1005 коммуникационного контроллера.

И наличия синхронного порта способного работать на мегабитных скоростях с поддержкой HDLC.
[ТРЕТИЙ РАЗ] говорю и строились и строятся. Только "камни" использовалитсь и используются соответствующие а не предложенный Вами:



a}? У меня время совсем другое - Сегодня, 10:51
b}Это были вопросы не ко мне.
c}
На 5) повторенный мне я ответил. На 7) могу походя заметить, что на FPGA это отлично ложится, благо FPGA давно уже из "просто гейтов" выросли и блоки памяти там имеют быть в больших количествах. советую поинтересоваться. Можете и поближе на эту тему пообщаться с iosifk, как с одним из специалистов имевших к подобному отношение.

Например какие соответствующие, если можно поподробнее о том как включать?

Имеющие на борту синхроный порт с HDLC и Ethernet. Те, которые такое будут иметь уже сразу попадают в категорию пригодных - все остальное почти наверняка будет достаточным.

Типа пришлите схему, разводку и исходники?
Каков вообще Ваш уровень, как разработчика? Что приходилось делать по жизни?
Самый простой вариант сделать подобную вещь называл Dainis и я к нему присоединяюсь - сам использую ADMtec - 4 Etherhet порта и два 2/8Mbit TDM.

Как я уже написал, то я сильно новичек, это первая разработка, конкретных схем мне не надо, мне нужно просто объяснение, как и что состыковать, например, к чему у ADM6996f прикрутить sipex sp320 (как я понял это V.35 interface chip)

Смотрым станици 8 или 9 http://www.sipex.com/Files/DataSheets/sp320.pdf


ADM6996F

HDLC
P4TXCLK pin 115 (input)
P4TXD0 pin 106 (output)

P4RXCLK pin 117 (input)
P4RXD0 pin 74 (input)

Config P4 to HDLC CFG = 0 (pin 86)
P4TYPE1 = 1 (pin 105)

p.s.
8) появился ещо новый чип от Dallas:
Ethernet mapper DS33Z11