[mdmitry 0]

Уважаемые форумчане.

Поделитесь, пожалуйста, опытом применения собственно сабжа.

Анализируя свою задачу, склоняюсь к RTOS с поддержкой обмена по TCP/IP (стандартные протоколы).

Очень хочется передавать в реальном времени информацию по ethernet между платой и ПК/специализированным комьютером.

Спасибо.

xenomai

[Harbour 0]

пару лет юзаю, правда под x86 - стабильно, быстро, весьма продуманный API, классная поддержка - понравилась скорость разработки прог - всю муторную логику спокойно можно перенести в user-space - получается типа демон с hard-rt приоритетом и тоненькая прослойка с драйвером железяки. на сайте в разделе weblinks найдете ссылки на стеки rt-ethernet (держит с десяток сетевых карт, ARM/x86) / rt-usb / rt-firewire и т.д.

[mdmitry 0]

Спасибо за ответ.

Еще возникло несколько вопросов:

Насколько сложна разработка драйверов под устройства контроллера (SPI и другие)?

Возможна ли поддержка в реальном времени такого канала: N*E1(64kb)-> ethernet->N*E1?

[Harbour 0]

Для драйверов есть цельная инфраструктура - RTDM называется, там и примеров дофига и доки весьма clear.

Ну, все зависит от значения N ;)

 

P.S. Напомнило:

 

Препод на занятии по стратегии и тактике в военном училище:

 

- Возьмем к примеру N танков ... нет N слишком мало, возьмем M танков !

[mdmitry 0]

Ну, все зависит от значения N ;)

- Возьмем к примеру N танков ... нет N слишком мало, возьмем M танков !

N максимально 15, то есть до 1 Мбит. При этом на приемним устройстве требуется восстановить тактовую частоту.

И еще вопрос на эту же тему: можно ли принять последовательный поток со скоростью 6-7 Мбит и преобразование его в Ethernet? Хватит ли скорости работы ARM9? Насколько я понимаю CRC32 надо считать программно на ARM9, что и определит предельную скорость.

[AlexandrY 3]

Эт где там CRC32 то надо?

 

Там простое суммирование: http://www.faqs.org/rfcs/rfc1071.html

 

На парсинг входного потока гораздо больше времени уйдет.

 

 

N максимально 15, то есть до 1 Мбит. При этом на приемним устройстве требуется восстановить тактовую частоту.

И еще вопрос на эту же тему: можно ли принять последовательный поток со скоростью 6-7 Мбит и преобразование его в Ethernet? Хватит ли скорости работы ARM9? Насколько я понимаю CRC32 надо считать программно на ARM9, что и определит предельную скорость.

[mdmitry 0]

Эт где там CRC32 то надо?

 

Там простое суммирование: http://www.faqs.org/rfcs/rfc1071.html

 

На парсинг входного потока гораздо больше времени уйдет.

Спасибо, не разобрался :crying:

Входной поток только передать. В этом случае проблем быть не должно?

[vshemm 0]

В Е* битовое кодирование, насколько я помню... Других проблем не должно быть :) Хотя, если случай симметричный, то это не требуется (раскодирование-кодирование).

[mdmitry 0]

В Е* битовое кодирование, насколько я помню... Других проблем не должно быть :) Хотя, если случай симметричный, то это не требуется (раскодирование-кодирование).

Фактически односторонняя передача, передать данные. Ничего с данными делать не требуется, только восстановление тактовой чатоты по приему пакетов ethernet. Обратно только управление для платы не в формате E*

[vshemm 0]

Если схема такая: "N*E1(64kb)-> ethernet->N*E1", и данные можно не менять, то проблем почти нет; мой пост можно проигнорировать :)

[Harbour 0]

восстанавливать клок - весьма хитрая задача, обычно передают погрешности jitter буфера на ту сторону. max скорость потока зависит от скорости DMA проца, соответственно от его частоты, arm9 - значит > 200MHz, должно хватить, просто будет задержка (еще накладные расходы на tcp/ip стек, сетевой драйвер и сам канал передачи), для TDMoE есть нормируемые задержки, кажись до 100ms считается нормально

[mdmitry 0]

то проблем почти нет

ПОЧТИ - это какие?

 

восстанавливать клок - весьма хитрая задача

Как я понимаю: восстановление тактовой частоты - наиболее сложная задача

Что понимается под

обычно передают погрешности jitter буфера на ту сторону.

?

Спасибо :a14:

[Harbour 0]

выдержка из ietf драфта:

 

....

3. Clock Recovery

 

TDM networks are inherently synchronous. In the public switched

telephone network and in SONET / SDH networks one node, called the

clock master provides a time reference to the other, called the

slave. Somewhere in the network there will always be at least one

extremely accurate primary reference clock, with long-term accuracy

of one part in 1011. This node, whose accuracy is called stratum 1,

provides the reference clock to secondary nodes with lower stratum 2

accuracy, and these in turn provide reference clock to stratum 3

nodes. This hierarchy of time synchronization is essential for the

proper functioning of the network as a whole.

 

Packets in IP networks reach their destination with delay that has a

random component, known as jitter. When emulating TDM on an IP

network, it is possible to overcome this randomness by using a

"jitter buffer" on all incoming data, assuming the proper time

reference is available. The problem is that the original time

reference information is no longer available.

 

Anavi, Stein, Schwartz [PAGE 4]

 

TDM over IP February, 2001

 

 

In principle there are two different levels of integration of TDMoIP

into a T1/E1 network. In the "bypass" scenario a one party might

want to transport TDM T1/E1 traffic over another party's network. In

such applications both TDMoIP devices SHALL receive time reference

from the central offices to which they connect.

 

In the "whole network" scenario, major portions of the primary

infrastructure are replaced with TDMoIP networks, and a method of

time synchronization is required. IP networks also disseminate clock

information through NTP (RFC 1305), but unless the IP network is

completely private and dedicated to the TDMoIP link, there will be

no connection between the NTP clock and the desired TDM one. In such

cases independent time standards MAY be provided to all TDMoIP

devices, thus relieving the IP network of the need to send

synchronization information. The use of time standards less accurate

than stratum 3 is NOT RECOMMENDED since it may result in service

impairments.

 

When the provision of accurate local time references is not

practical then clock recovery SHOULD be performed based on the rate

of arrival of incoming packets using an appropriate `averaging'

process that negates the effect of the zero mean random jitter.

Conventionally a phase locked loop (PLL) is used for this purpose.

......

 

подробнее (даже с картинками) см. например :

 

http://pdfserv.maxim-ic.com/en/an/AN4115.pdf

 

или набор доков по теме:

 

http://www.dspcsp.com/tdmoip/index.html

[mdmitry 0]

Спасибо.

[maegg 0]

Хотя не совсем по теме.

В общем случае, как везде, восстановление частоты не сложная задача.

Все зависит от требуемых характеристик, в основном к блужданию фазы.

Обычно определяют 2 параметра МОВИ (максимальное отклонение временного интервала) и ДВИ (девиация временного интервала). В телекоме это рекомендации ITU-T G.811, G.812, G813, ETS 300 462-3 и аналогичные им российские нормы. Можно поискать по теме Тактовая сетевая синхронизация.

На ФТП есть Synchronization of Digital Telecammunication Networks Stefano Bregni

Задачка по теме интересная. Но без требований или хотя бы области применения трудно понять насколько.