Перейти к содержанию
    

Соединение LVDS на 10 метров по витой паре

а разнодлинность пар вас не смущает ?

 

Имхо решение сильно оптимистичное. Вы какбы считаете, что канал ничего не будет вам стоить. А это не так.

 

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

30 Мбит Arm должен прососать, при аккуратном программировании.

 

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

 

Да, пожалуй вы правы. Сейчас изучаю ATSAME70Q21. Он 300 МГц, DMA многоканальное, два I2S. Думаю, что для моих целей должно хватить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да, пожалуй вы правы. Сейчас изучаю ATSAME70Q21. Он 300 МГц, DMA многоканальное, два I2S. Думаю, что для моих целей должно хватить.

Я бы смотрел STM или Philips бывший. Мне нра STM, у него ИМХО более качественная периферия и лучшая поддержка.

Это мейнстрим, у них есть камни под 200 Мгц - этого точно должно вам хватить.

Atmel аутсайдер.

 

Проще всего убедиться в успехе, купив пару макеток с Eth, и написав тестовый обмен.

Я бы купил чтото такое:

https://www.terraelectronica.ru/product/1204298

 

считаю 7 тыр за твердую уверенность в результате вашей разработки совсем недорого.

 

Дешево и вкусно, + будет возможность отлаживать софтину, пока спокойно выпиливаете железо, по образу и подобию.

 

Про philips не знаю, у STM есть чудесные STM32 Сube MX, Atollic, STM Studio, System Workbench for STM32 - полное конфигурирование кристалла и интеграция lwip tcp/ip стека в проект несколькими кнопочками, все бесплатно.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Про philips не знаю, у STM есть божественный STM32 Сube MX, Atollic, STM Studio, System Workbench for STM32 - полное конфигурирование кристалла и интеграция lwip tcp/ip стека в проект несколькими кнопочками, все бесплатно.

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

 

И еще вопрос по ранее обсуждавшемуся - задавить TX_ENA в 0 и гнать данные - это кто-нибудь реально делал? Мне кажется, что PHY в таком режиме жить не будет - у него очень скоро развалится синхронизация и пойдут сбои.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При том, что железу у них изумительное, и я его очень люблю, то, что они наворотили в софте - ужос.

мы делаем довольно много проектов, на текущий момент идут одновременно 4, все контроллеры разные, и у нас штук пять разных отладок, со всеми работали (0xx,1xx,2xx,4xx серий).

 

Еще не разу критических проблем с софтом не было. Глюки в cube я видел и сам, и довольно много, но они не смертельны - ну упала система при фильтрации тысячи параметров - ткнуть 2 галки в матрице выбора заново недолго. Я никогда в жизни не видел настолько удобного и с огромным функционалом софта по параметрическому подбору контроллера и поиску совместимых аналогов, а впервые собирал систему на арме лет 12 назад)

 

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

 

Их периферия, в которой фактически реализована плисовая матрица для вывода чего угодно куда угодно, и средства конфигурации - ИМХО венец творения.

Я не могу представить себе ничего более удобного.

В софте для конфигурации IO я не видел глюков, правда я им пользуюсь мало, в основном мои инженеры. Я никогда не слышал от них жалоб по поводу этого ПО.

 

Бесплатный сыр бывает только в мышеловке.

Я бы не сказал, что этот сыр такой уж бесплатный.

Есть мнение, что рядом с Alwinner-ом и другими большими армами по цене маленьких от STM цена на продукты STM сильно завышена.

STM пытается остаться в рынке, и делает это качеством сервиса - стандартная стратегия Запада.

 

Добавлю - которая последние 30 лет стандартно проигрывает Востоку, с его демпингом(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И еще вопрос по ранее обсуждавшемуся - задавить TX_ENA в 0 и гнать данные - это кто-нибудь реально делал? Мне кажется, что PHY в таком режиме жить не будет - у него очень скоро развалится синхронизация и пойдут сбои.

развалится синхронизация чего с чем?

у езернета на физическом уровне "побитовая" синхронизация, в не зависимости от передаваемых данных, за счёт избыточности 4b5b и 8b10b у гигабита.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

развалится синхронизация чего с чем?

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

разве нельзя принятые данные тактировать наружу восстановленным клоком ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

ну у mii, rgmii клоки на приём передачу отдельные, имхо было бы глупо вместо того чтобы на rxc просто вытащить восстановленный клок, городить ещё фифо.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации.

Нету никаких ограничений: забивали на пакетную передачу и гнали через гигабитные физики непрерывный поток - всё работает отлично.

 

ну у mii, rgmii клоки на приём передачу отдельные, имхо было бы глупо вместо того чтобы на rxc просто вытащить восстановленный клок, городить ещё фифо.

 

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

Чего-то вы странное что-то пишите. Вот кусок описания ноги RX_CLK популярной 88e1111: "Receive Clock provides a 125 MHz ref-

erence clock with ± 50 ppm tolerance derived from the received data stream". По-моему, прямо протеворечит тому, что вы написали.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чего-то вы странное что-то пишите. Вот кусок описания ноги RX_CLK популярной 88e1111: "Receive Clock provides a 125 MHz ref-erence clock with ± 50 ppm tolerance derived from the received data stream". По-моему, прямо протеворечит тому, что вы написали.

на самом деле 88e1111 имеет если не ошибаюсь 4 режима тактирования выходных данных: как с derived clock, так и с независимым и elastic буфером. Соответственно в разных режимах работает по разному.

 

Последнее время на 88e1111 ценник такой, что она стала непопулярна. Мы ее больше не ставим

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

на самом деле 88e1111 имеет если не ошибаюсь 4 режима тактирования выходных данных: как с derived clock, так и с независимым и elastic буфером. Соответственно в разных режимах работает по разному.

 

Последнее время на 88e1111 ценник такой, что она стала непопулярна. Мы ее больше не ставим

Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то :(

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то :(

м. Нам нужна индустриальная версия, и если первоначальная цена была 30$, то после переворота в Украине и с началом войны когда последний раз я смотрел в efind она была доступна по 200$, и вообще industrial было очень мало. Я испугался, что мы не сможем укомплектоваться и мы сменили ее.

 

На замену мы взяли именно KSZ9031, но еще ее не пробовали, что с ней не так ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

за счёт избыточности 4b5b и 8b10b у гигабита.

В каком месте у гигабитного изернета кодирование 8b10b? GMII, RGMII или по физической линии? Если только SGMII.

 

По клокам у гигабитного изернета. Насколько помню, оба чипа физического уровня работают на одной тактовой - они договариваются, кто мастер, и второй чип извлекает тактовую из входного потока. Это очень важное условие - чёткий захват клока входного потока необходим для качественного извлечения данных из суперпозиции сигналов - там ведь сигналы обоих направлений одновременно присутствуют в линии. RxClk соответственно всегда равен тактовой в линии. Elastic buffer тут не нужен, да и протокол не предусматривает посылку IDLE/SKIP символов в линию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то :(

KSZ - отстой,тоже забыл как страшный сон.

55 рублей за штуку - вот это цена.

AR8035

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чего-то вы странное что-то пишите. Вот кусок описания ноги RX_CLK популярной 88e1111: "Receive Clock provides a 125 MHz ref-erence clock with ± 50 ppm tolerance derived from the received data stream". По-моему, прямо протеворечит тому, что вы написали.

я про 100мбитный RMII, у которого один единственный клок в обе стороны и тот иногда бывает входом, а не выходом.

тогда скорость выдачи данных по rxd задаётся МАСом, а не из восстановленных клоков из приёмника. соответственно данные в приёмник приходят с другой скоростью.

 

В каком месте у гигабитного изернета кодирование 8b10b? GMII, RGMII или по физической линии?

физической, в том смысле что он самосинхронизирующийся и ему дополнительная "кадровая" синхронизация не нужна, как и ограничения на длину пакетов.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...