SergeyPro 0 4 мая, 2018 Опубликовано 4 мая, 2018 · Жалоба а разнодлинность пар вас не смущает ? Имхо решение сильно оптимистичное. Вы какбы считаете, что канал ничего не будет вам стоить. А это не так. Я бы в такой ситуации делал Arm - Eth - Arm - получилось бы по деньгам дешевле, результат проще, надежнее, разработка быстрее, и без странных велосипедов. 30 Мбит Arm должен прососать, при аккуратном программировании. На вашем месте промакетировал бы ваше решение как следует, прежде чем на релиз идти, и попробовал бы менять пары местами в кабеле и посмотрел, как система будет себя при этом вести. Да, пожалуй вы правы. Сейчас изучаю ATSAME70Q21. Он 300 МГц, DMA многоканальное, два I2S. Думаю, что для моих целей должно хватить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a123-flex 0 4 мая, 2018 Опубликовано 4 мая, 2018 · Жалоба Да, пожалуй вы правы. Сейчас изучаю 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 6 4 мая, 2018 Опубликовано 4 мая, 2018 · Жалоба Про philips не знаю, у STM есть божественный STM32 Сube MX, Atollic, STM Studio, System Workbench for STM32 - полное конфигурирование кристалла и интеграция lwip tcp/ip стека в проект несколькими кнопочками, все бесплатно. Бесплатный сыр бывает только в мышеловке. При том, что железу у них изумительное, и я его очень люблю, то, что они наворотили в софте - ужос. И еще вопрос по ранее обсуждавшемуся - задавить TX_ENA в 0 и гнать данные - это кто-нибудь реально делал? Мне кажется, что PHY в таком режиме жить не будет - у него очень скоро развалится синхронизация и пойдут сбои. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a123-flex 0 4 мая, 2018 Опубликовано 4 мая, 2018 · Жалоба При том, что железу у них изумительное, и я его очень люблю, то, что они наворотили в софте - ужос. мы делаем довольно много проектов, на текущий момент идут одновременно 4, все контроллеры разные, и у нас штук пять разных отладок, со всеми работали (0xx,1xx,2xx,4xx серий). Еще не разу критических проблем с софтом не было. Глюки в cube я видел и сам, и довольно много, но они не смертельны - ну упала система при фильтрации тысячи параметров - ткнуть 2 галки в матрице выбора заново недолго. Я никогда в жизни не видел настолько удобного и с огромным функционалом софта по параметрическому подбору контроллера и поиску совместимых аналогов, а впервые собирал систему на арме лет 12 назад) Без этой софтины в море продуктов STM можно было бы провести месяцы в поиске оптимального контроллера, а с ней даже 2 поиска займут не больше получаса. Их периферия, в которой фактически реализована плисовая матрица для вывода чего угодно куда угодно, и средства конфигурации - ИМХО венец творения. Я не могу представить себе ничего более удобного. В софте для конфигурации IO я не видел глюков, правда я им пользуюсь мало, в основном мои инженеры. Я никогда не слышал от них жалоб по поводу этого ПО. Бесплатный сыр бывает только в мышеловке. Я бы не сказал, что этот сыр такой уж бесплатный. Есть мнение, что рядом с Alwinner-ом и другими большими армами по цене маленьких от STM цена на продукты STM сильно завышена. STM пытается остаться в рынке, и делает это качеством сервиса - стандартная стратегия Запада. Добавлю - которая последние 30 лет стандартно проигрывает Востоку, с его демпингом( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 79 4 мая, 2018 Опубликовано 4 мая, 2018 · Жалоба И еще вопрос по ранее обсуждавшемуся - задавить TX_ENA в 0 и гнать данные - это кто-нибудь реально делал? Мне кажется, что PHY в таком режиме жить не будет - у него очень скоро развалится синхронизация и пойдут сбои. развалится синхронизация чего с чем? у езернета на физическом уровне "побитовая" синхронизация, в не зависимости от передаваемых данных, за счёт избыточности 4b5b и 8b10b у гигабита. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex11 6 4 мая, 2018 Опубликовано 4 мая, 2018 · Жалоба развалится синхронизация чего с чем? Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a123-flex 0 4 мая, 2018 Опубликовано 4 мая, 2018 · Жалоба Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации. разве нельзя принятые данные тактировать наружу восстановленным клоком ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 79 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба Клоки на выходе PHY - это не востановленные клоки из потока, а свои внутренние от кварца. И дальше elastic buffer между принятыми данными и выдаваемыми наружу (по крайней мере, как пишут в подробных описаниях работы). В результате есть ограничения на бесконечный поток. Отсюда, как я понимаю, и ограничения на jumbo-frame в PHY - то 2, то 8 кб в зависимости от реализации. ну у mii, rgmii клоки на приём передачу отдельные, имхо было бы глупо вместо того чтобы на rxc просто вытащить восстановленный клок, городить ещё фифо. хотя вот у rmii клок общий, и иногда только на вход, там проблема синхронизации должна быть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kluwer 0 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба Клоки на выходе 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 0 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба Чего-то вы странное что-то пишите. Вот кусок описания ноги 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 ценник такой, что она стала непопулярна. Мы ее больше не ставим Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kluwer 0 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба на самом деле 88e1111 имеет если не ошибаюсь 4 режима тактирования выходных данных: как с derived clock, так и с независимым и elastic буфером. Соответственно в разных режимах работает по разному. Последнее время на 88e1111 ценник такой, что она стала непопулярна. Мы ее больше не ставим Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
a123-flex 0 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то :( м. Нам нужна индустриальная версия, и если первоначальная цена была 30$, то после переворота в Украине и с началом войны когда последний раз я смотрел в efind она была доступна по 200$, и вообще industrial было очень мало. Я испугался, что мы не сможем укомплектоваться и мы сменили ее. На замену мы взяли именно KSZ9031, но еще ее не пробовали, что с ней не так ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 67 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба за счёт избыточности 4b5b и 8b10b у гигабита. В каком месте у гигабитного изернета кодирование 8b10b? GMII, RGMII или по физической линии? Если только SGMII. По клокам у гигабитного изернета. Насколько помню, оба чипа физического уровня работают на одной тактовой - они договариваются, кто мастер, и второй чип извлекает тактовую из входного потока. Это очень важное условие - чёткий захват клока входного потока необходим для качественного извлечения данных из суперпозиции сигналов - там ведь сигналы обоих направлений одновременно присутствуют в линии. RxClk соответственно всегда равен тактовой в линии. Elastic buffer тут не нужен, да и протокол не предусматривает посылку IDLE/SKIP символов в линию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_sda 0 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба Да а что такого нехорошего с ценником? По-моему, вменяемая цена вполне. И она проверенная и надёжная как автомат Калашникова. А что взамен-то? Мы пробовали KSZ9031, но это кошмар какой-то :( KSZ - отстой,тоже забыл как страшный сон. 55 рублей за штуку - вот это цена. AR8035 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 79 5 мая, 2018 Опубликовано 5 мая, 2018 · Жалоба Чего-то вы странное что-то пишите. Вот кусок описания ноги 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 или по физической линии? физической, в том смысле что он самосинхронизирующийся и ему дополнительная "кадровая" синхронизация не нужна, как и ограничения на длину пакетов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
