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

[SergeyPro]

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

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

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

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

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

[a123-flex]

Да, пожалуй вы правы. Сейчас изучаю 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 стека в проект несколькими кнопочками, все бесплатно.

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

[Alex11]

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

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

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

[a123-flex]

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

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

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

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

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

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

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

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

[_pv]

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

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

[Alex11]

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

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

[a123-flex]

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

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

[_pv]

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

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

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

[Kluwert]

Клоки на выходе 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". По-моему, прямо протеворечит тому, что вы написали.

[a123-flex]

Чего-то вы странное что-то пишите. Вот кусок описания ноги 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 ценник такой, что она стала непопулярна. Мы ее больше не ставим

[Kluwert]

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

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

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

[a123-flex]

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

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

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

[dxp]

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

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

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

[_Anatoliy]

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

KSZ - отстой,тоже забыл как страшный сон.
55 рублей за штуку - вот это цена.
AR8035

[_pv]

Чего-то вы странное что-то пишите. Вот кусок описания ноги 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 или по физической линии?

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