Уважаемые форумчане.
Поделитесь, пожалуйста, опытом применения собственно сабжа.
Анализируя свою задачу, склоняюсь к RTOS с поддержкой обмена по TCP/IP (стандартные протоколы).
Очень хочется передавать в реальном времени информацию по ethernet между платой и ПК/специализированным комьютером.
Спасибо.
xenomai

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

Спасибо за ответ.
Еще возникло несколько вопросов:
Насколько сложна разработка драйверов под устройства контроллера (SPI и другие)?
Возможна ли поддержка в реальном времени такого канала: N*E1(64kb)-> ethernet->N*E1?

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

выдержка из 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

Спасибо.

Хотя не совсем по теме.
В общем случае, как везде, восстановление частоты не сложная задача.
Все зависит от требуемых характеристик, в основном к блужданию фазы.
Обычно определяют 2 параметра МОВИ (максимальное отклонение временного интервала) и ДВИ (девиация временного интервала). В телекоме это рекомендации ITU-T G.811, G.812, G813, ETS 300 462-3 и аналогичные им российские нормы. Можно поискать по теме Тактовая сетевая синхронизация.
На ФТП есть Synchronization of Digital Telecammunication Networks Stefano Bregni
Задачка по теме интересная. Но без требований или хотя бы области применения трудно понять насколько.

Уточните, пожалуйста, где лежит, в каком разделе.

Задачка усложнилась: N*64кбит/с <= 1Мбит/с. В потоке скорее всего нет синхрослотов. Для меня просто битовый поток.

Передача N*64кбит/с-> ethernet->N*64кбит/с

Хватит ли производительности ARM9 на 200 МГц для приема и передачи данных в ethernet?
Хватит ли точности для восстановление тактовой частоты без анализа потока, а только по динамике наполнения буферов?

2 Harbour: Как блуждают задержки в xenomai при приеме данных с одного интерфейса, их паковки и отправки на другой? А то задумался: потянет ли такое Linux?

Задержки не могут "блуждать" - они просто есть, так как не могут не есть. xenomai же, в отличие от non-rt систем, гарантирует что они будут фиксированными. их длительность зависит от конкретного экземпляра железа и способа написания приложения. т.е. следует провести лабораторную работу и убедиться что платформа подходит для задачи.
в данном случае основная задержка и max jitter будет в передаче по tcp/ip + ethernet каналам - т.е. на несколько порядков больше чем остальные (e1/dma/rt)

Для простоты соединение точка-точка, без кокого-либо допоборудования (свич и др.)
Задержка для tcp/ip + ethernet будет стабильная или нет? Общее время задержки не критично, главное стабильность этой задержки.

тоды лучше tcp/ip исключить и использовать/написать RT драйвера сетевых карт

Harbour, спасибо.

Ну тогда дам вам еще более дельный совет.
Вообще надо LInux исключить, поскольку RT драйверам он будет сильно мешать.
Хотя вообще и драйвера я бы исключил. На кой они без Linux-а?
Надо идти в конфу по ARM-ам и просить народ присоветовать нормальную RTOS.
Обработка потока 1 Мбит на ARM-е без специальных ускорителей 3-го уровня это занятие довольно экстремальное и явно не для Линукса.

Что такое ускорители 3-го уровня? 1 Мбит/с ARM9 не примет? Ориентация на Linux была из-за поддердки стандартных протоколов, которые в минимальном виде, похоже, будут необходимы. Что-то типа отсылки команд по ethernet.

Ускорители нужны типа такого:
http://www.eeproductcenter.com/rss/showArt...ed_eepc_newsRSS

Если у вас идет битовый поток без разделения на байты, значит парсинг придется делать на каждом бите. Это просто не реально сделать на 200 МГц ARM-е.
Парсинг то довольно комплекный, его будет невозможно запихнуть в короткий блок кода как, например, цифровой фильтр чтоб он весь поместился в кэш. И значит начнутся простои на выборку кэша. Выборка битов из какого-нибудь периферийного порта тоже даст большие тормоза, поскольку шина APB у ARM-ов довольно медленная.
Если у вас сильные надежды на DMA, то сначала изучите шинную структуру вашего чипа.
Есть ли у него коммутационная матрица на шинах. Если нет, то положение еще хуже становится.
Вообщем без FPGA тут делать нечего. Либо жесткая RTOS.

Битовый поток нарезается на байты как есть и отправляется в ethernet. Анализ данных не требуется. Надежда именно на DMA.
1Мбит/с -> 250кбайт/с -> 6,25 двойных слов/с в буфер, по заполению подсовывание другого указателя, заполеннный буфер на DMA для ehternet. Всего 3 (4) буфера по кольцу. Такое не пройдет?