Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: стек TCP/IP и IEEE1588
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Интерфейсы
Д.К.
Для реализации TCP стека решено использовать аппаратные решения (типа WizNet), но задумался, когда появилась необходимость в синхронизации времени по IEEE1588.
Не хочется переходить к "программным" реализациям и ковырять пакеты руками. Есть ли аппаратные решения?
Нашёл такое
http://www.ti.com/product/DP83640#description

но как скрестить с модулем Wiznet - ума не приложу...
_pv
для ieee1588 вроде как хотя бы на MAC уровне надо время засекать (причем аппаратно) когда пакет прилетел/улетел, а тут всё внутри даже включая PHY. Tак что если уж не умеет, то научить пожалуй не получится.
Д.К.
Цитата(_pv @ Sep 13 2012, 17:53) *
для ieee1588 вроде как хотя бы на MAC уровне надо время засекать (причем аппаратно) когда пакет прилетел/улетел, а тут всё внутри даже включая PHY. Tак что если уж не умеет, то научить пожалуй не получится.

хорошо, а если есть DP83640, то что выбрать для аппаратной TCP реализации.
_pv
Цитата(_pv @ Sep 13 2012, 19:53) *
а тут всё внутри даже включая PHY.

виноват, погорячился, из w5300 наружу доп MAC торчит, и в w3150 phy внешний.
Д.К.
Цитата(_pv @ Sep 13 2012, 19:28) *
виноват, погорячился, из w5300 наружу доп MAC торчит, и в w3150 phy внешний.

но всёравно пока непонятно, можно ли все хотелки(TCP+IEEE1588) аппаратно сделать?
_pv
Цитата(Д.К. @ Sep 13 2012, 21:37) *
но всёравно пока непонятно, можно ли все хотелки(TCP+IEEE1588) аппаратно сделать?

по диагонали глянул даташит на DP83640, всё что касается PTP управляется регистрами через MII интрфейс, который, кстати, к wiznetу вообще вроде бы не подключается, то есть им всё равно придётся рулить самому. так что на превый взгляд проблем не видно.
Д.К.
Цитата(_pv @ Sep 13 2012, 20:32) *
по диагонали глянул даташит на DP83640, всё что касается PTP управляется регистрами через MII интрфейс, который, кстати, к wiznetу вообще вроде бы не подключается, то есть им всё равно придётся рулить самому. так что на превый взгляд проблем не видно.

Тогда получается две эти микрухи на один эзернет порт не повесить для реализации стека tcp и IEEE1588
_pv
Цитата(_pv @ Sep 13 2012, 22:32) *
по диагонали глянул даташит на DP83640, всё что касается PTP управляется регистрами через MII интрфейс, который, кстати, к wiznetу вообще вроде бы не подключается, то есть им всё равно придётся рулить самому. так что на превый взгляд проблем не видно.

блин, совсем плохой стал, не через mii, конечно, через mdio.
strannyi
Цитата(_pv @ Sep 14 2012, 01:21) *
DP83640


Эта штука настраивается через mdio. При прохождении через нее ptp message она генерирует timestamp аппаратно (внутри этой микрухи есть таймер с величиной шага порядка наносекунды).
Этот timestamp можно прочитать по тому же mdio из регистров, либо настроить микруху чтоб она генерировала timestamp пакеты (Layer 2 уровня либо UDP). Эти пакеты идут только от phy к MAC процессора,
во внешку они не идут. Таким образом можно посчитать time offset между хостами и подкоректировать эти внутренние часы в phy. Сама микруха время не корректирует, нужно писать верхее приложение (демон).
TigerSHARC
Я видел проект PTP для Linux.
Написано, что к примеру для SAM9-серии есть софтовая поддержка протокола. Это как? Насколько я полнял, PTP должен поддерживаться либо на MAC уровне самого процессора(если есть MAC), либо на внешнем MAC через RMII.
получается в контексте SAM9-серии нужно искать MAC внешний с поддержкой IEE1588 ?
strannyi
Цитата(TigerSHARC @ Nov 7 2012, 11:26) *
Я видел проект PTP для Linux.
Написано, что к примеру для SAM9-серии есть софтовая поддержка протокола. Это как? Насколько я полнял, PTP должен поддерживаться либо на MAC уровне самого процессора(если есть MAC), либо на внешнем MAC через RMII.
получается в контексте SAM9-серии нужно искать MAC внешний с поддержкой IEE1588 ?


Т.е. генерирует и разбирает PTP пакеты некоторое приложение. Сам PTP имеет несколько вариаций. Если посмотреть стандарт, то можно увидеть что,
их можно инкапсулировать их в UDP пакеты с определенным мультикаст адресом либо в ethernet layer 2 пакеты.
Сама микросхема эти пакеты не генерит у нее нет протокола общение она генерит только временные метки!!!

Что касается linux, там есть такой ptpd
ничего не могу про него сказать.

У нас на работе есть девайс LANTIME так вот там стоит linux и этот демон.

----------------------------------------------------------------------------------------

Я ставил DP83640 и AT91RM9200 вместе. В качестве источника PTP брал этот LANTIME.
Моя железка принимала эти сообщения, генерила timestamp, корректировала время.
Но заявленных наносекундных точностей у меня не получилось. Десятки микросекунд.

----------------------------------------------------------------------------------------

Спрашивайте, только по конкретней что вам не понятно.
TigerSHARC
Цитата(strannyi @ Nov 7 2012, 11:35) *
У нас на работе есть девайс LANTIME так вот там стоит linux и этот демон.

интересно, получается демон позволяет раздавать время, а не только принимать данные для синхронизации?
strannyi
Цитата(TigerSHARC @ Nov 7 2012, 11:58) *
интересно, получается демон позволяет раздавать время, а не только принимать данные для синхронизации?


Просто в пакетах которые передает также есть timestamp (время отправки).
Ты принимаешь пакет засекаешь время приема.
Если глянуть стандарт все понятно становится. Если нужен могувыслать.

DP83640 аппаратно втыкает эти timestamp в пакеты PTP при выходе.
TigerSHARC
если я вас правильно понял демон аналогичен серверу времени NTP на виндоус(я имею ввиду возможность его работы как сервера)
да, если несложно выложите стандарт на zalil.ru
strannyi
Цитата(TigerSHARC @ Nov 7 2012, 12:07) *
если я вас правильно понял демон аналогичен серверу времени NTP на виндоус(я имею ввиду возможность его работы как сервера)
да, если несложно выложите стандарт на zalil.ru


похож на NTP
только в NTP если глянуть исходники (под linux) timestamp берется софтварно и втыкается в пакет "ручками"
а тут это делает за нас PHY

http://zalil.ru/33934891
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.