Всем доброго. В связи с тем, что нынче процы LPC17xx могут иметь частоту периферии до 100МГц, появилось желание избавиться от генератора тактов RMII с частотой 50МГц. Ну т.е. при PCLK=100МГц нет проблем использовать один из таймеров для генерации на какой-либо подходящей ножке (MATчего-нибудь) меандра с частотой 50МГц. Минус таймер, конечно, но и минус генератор на плате.

Ну вопрос собственно стандартный - кто пробовал? Или мне попробовать и доложиться?

Думали как-то сделать подобный финт (не на LPC, да не важно), но не понравились возникающие ограничения на частоту процессорного кварца - с "левой" частотой не получалось уложиться в требуемые 30ppm для REF_CLK. Попробуйте.

Зачем минус таймер? У LPC17xx есть выход CLKOUT - туда можно подать PClk поделенное на желаемый коэффициент. Сами так не делаем (есть причина, нужен независимый генератор, а не четко настроенный на 100 МГц), используем KSZ8031 - тоже минус 50МГц генератор на плате, а просто дополнительный кварц на 25МГц дешевый. Если соберетесь с силами и проверите насколько стабильны 100МГц выдаваемые PLL - будет здорово.

Возможно, лучше будет воспользоваться лапой "CLKOUT" (см. стр. 66 в Юзверь мануле UM10360.pdf)

Да, спасибо, как-то не приметил.

В общем, попробую, о результатах расскажу.



Ну дрожание фазы на глаз незаметно. Это я еще по результатам экспериментов на LPC23xx знаю.

Теоретически это возможно. А практически сейчас все новые PHY делают с RMII и внутренним PLL, генерирующим 50 МГц. Так что сделать то вы может и сделаете, но проект ждёт та же судьба, что и видеокамера на AVR.

Генерирующим из чего? Обычно REFCLK - это входной сигнал, и для MAC, и для PHY.



Смысл этого изречения мне не ясен совсем.

генерирующими из 25MHz. В современных чипах PHY REFCLK это выходной сигнал. Он генерится встроенной в PHY схемой PLL от кварца 25МГц. Конечно если вам надо то вы можете сконфигурировать PHY на работу от входных 50МГц.


Вы историю про Неуловимого Джо слышали ?

А чем тогда объяснить кол-во скачиваний этого "Неуловимого Джо"?

Аж один KSZ8031(51) в малоустраивающем меня корпусе (на данный момент) и, что более важно, на данный момент сей чип труднодоступен для меня. Задача у меня сейчас стоит сделать быстро первую итерацию, но с минимумом соплей на плате. Так что я, конечно, сделал место под запайку генератора 50МГц.

PS А вот с тем проектом корреляции этой темы совершенно не вижу. Странно, что ее увидели Вы.

Справедливости ради, надо заметить, что тот проект шаблончиков немало надорвал, не все "ымбеддеры" адекватно восприняли, некоторые испытали butthurt

BTW, нам тоже только новый 8031 подошел, остальные - то прерывание совмещается, то не автоконфигурируется, то еще чего.
А корпус - КуЭфЭн обычный, чего там - долго ли умеючи

Нажмите для просмотра прикрепленного файла


Ага. Жалко для моих задач практической ценности никакой, но сама идея очень прикольная.

Кроме KSZ, есть ещё LAN8720. У него, правда, корпус еще более дикий. Тем не менее, тенденция налицо, а использовать сигнал с PLL на входе PHY строго не рекомендуется.

Знаю я про этот чип. У него REFCLKO совмещен с выходом запроса на прерывание. Мой код прерывания от PHY использует - жалко время на периодическое сканирование по MDI тратить. Вывод - 8720 "в топку". А корпус не более дикий чем у 8031.


Пруфлинк можете дать? Или из общих соображений? (типа этот сигнал будет опорным для внутренней PLL-ки)

Не могу никак найти пруфлинк, но уверен, что где-то встречал разговор насчёт экономии на генераторе.

А вам прерывание для каких-то особых нужд нужно? Какой-нибудь Wake on LAN? Или что вам сканировать надо так активно?

Да в-общем-то ничего особого сканировать не нужно - просто не люблю когда TCP-сокет полчаса выясняет что у него локальный линк отвалился, поэтому так MAC-драйвер и писался, чтобы сразу оповещать все верхние уровни о своем состоянии (плюс фильтр для кратковременных пропаданий линка) - там сразу IP сбрасывается, DHCP-клиент заново взводится, TCP сокеты уведомляются что данных больше не будет, и т.д. А то большинство реализаций стеков привыкло валить все в кучу - "TCP крут - он там сам наверху разберется", а мне такое не очень нравиться. TCP-то разберется, но "по дороге" код точной ошибки потеряет и думать долго будет. Поскольку модель стека полностью асинхронная, то ессно была вовлечена обработка прерываний и генерация событий от PHY. Конечно, можно прерывание заменить на поллинг с каким-нить подходящим периодом - но это уже код переделывать нужно (и отнюдь не один MAC-драйвер и не для одного типа PHY), так что пусть уже будет. Wake on LAN пока нету, но очень даже может быть (есть аппаратура с батарейным питанием, прикладной софт скоро дорастет до обработки сетевых событий по запросу).

Чем кончились эксперименты? Сейчас посетила та же мысль, покопался в поиске - нашел эту ветку. Но результат не озвучен. Итого - работает али нет?

Если интересно, случайно наткнулся на атмеловский ответ. Нельзя, ибо джиттер.
Подозреваю, что и здесь картина не сильно лучше.

Они пока не начались.



Ну на LPC2364 было явно лучше заявленных Atmel'ом 5%. Я на осциллографе никакого дрожания не видел.

Ну так и 5% вроде не совсем приговор. Например у cp2201 требования к кварцу +-50ppm и Duty Cycle от 45 до 55%.
Для LAN8700 вообще +-10% на коэффицент заполнения.

Для помянутого LAN8700: CLKIN Jitter MAX 150 psec p-p

В общем, докладываю первые результаты. Линк есть, пакетики принимаются. Подробности поведения при высокой загрузке (много больших пакетов) - это завтра/послезавтра, когда TCP-стек подниму.

Интересно, каковы результаты на больших пакетах и большой загрузке? И ещё вопрос - какая скорость потока номинальная получена? А пиковая?

Все работает, замечаний нет.



Ну это от стека зависит. У меня TCP обеспечивает стопроцентную утилизацию 100М. Если покопаетесь - я свой стек выкладывал в этом разделе форума.

Сегодня почитывал errata на STM32F217, там есть такой любопытный пункт:

MCO PLL clock pins not compatible with Ethernet IEEE802.3 long term jitter specifications
Description
When the clock source output by the microcontroller on the MCO pin is issued from the PLL, the MCO pin cannot be used to deliver a 50 MHz RMII clock input or a 25 MHz MII clock input to the ethernet PHY compliant with the long term jitter maximum value for 1.4 ns specified in the IEEE802.3 standard.
This limitation applies both to MCO1 and MCO2 pins and PLLs.
Workaround
● In MII mode
Use a 25 MHz external crystal to generate the HSE clock and output the clock signal on the MCO pin to clock the PHY
● In RMII mode
Either use an external 50 MHz oscillator to clock the PHY or select a PHY with an internal PLL that is able to generate the 50 MHz RMII clock.

STM32 это, конечно, не LPC17, но примечание, ИМХО, интересное.

Спасибо за информацию. А теперь вопрос к форумчанам: у кого есть возможность измерить джиттер на выходе LPC17xx? Я смогу только через пару месяцев, когда появится соответствующий инструмент

Помнится, в целом ряде плат "Стартеркит" примерно так и поступил, в результате Ethernet то работал, то не работал... Ну а в даташите на PHY было английским по белому написано: тактировать только от кварца, а не от внешнего генератора. Правда, голову на отсечение не дам, давно смотрел, но... В общем, надо внимательно изучать документацию на используемые микросхемы, прежде чем пытаться упростить/сэкономить.

Посмотрел даташит на LAN8720a. Параметр "CLKIN Jitter (max)" равен 150 psec p-p (not RMS). Осталось определить характеристики выходного клока с LPC17xx при 12МГц кварце, чтобы добить тему