реклама на сайте
подробности

 
 
2 страниц V   1 2 >  
Reply to this topicStart new topic
> xenomai (linux) + ARM9, сбор информации о сабже
mdmitry
сообщение Apr 4 2008, 09:29
Сообщение #1


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
Harbour
сообщение Apr 5 2008, 06:00
Сообщение #2


Местами Гуру
*****

Группа: Validating
Сообщений: 1 103
Регистрация: 5-12-04
Пользователь №: 1 323



пару лет юзаю, правда под x86 - стабильно, быстро, весьма продуманный API, классная поддержка - понравилась скорость разработки прог - всю муторную логику спокойно можно перенести в user-space - получается типа демон с hard-rt приоритетом и тоненькая прослойка с драйвером железяки. на сайте в разделе weblinks найдете ссылки на стеки rt-ethernet (держит с десяток сетевых карт, ARM/x86) / rt-usb / rt-firewire и т.д.
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 5 2008, 17:49
Сообщение #3


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
Harbour
сообщение Apr 6 2008, 06:25
Сообщение #4


Местами Гуру
*****

Группа: Validating
Сообщений: 1 103
Регистрация: 5-12-04
Пользователь №: 1 323



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

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

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

- Возьмем к примеру N танков ... нет N слишком мало, возьмем M танков !
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 6 2008, 17:36
Сообщение #5


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Цитата(Harbour @ Apr 6 2008, 10:25) *
Ну, все зависит от значения N wink.gif
- Возьмем к примеру N танков ... нет N слишком мало, возьмем M танков !

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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Apr 6 2008, 18:23
Сообщение #6


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



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

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

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


Цитата(mdmitry @ Apr 6 2008, 21:06) *
N максимально 15, то есть до 1 Мбит. При этом на приемним устройстве требуется восстановить тактовую частоту.
И еще вопрос на эту же тему: можно ли принять последовательный поток со скоростью 6-7 Мбит и преобразование его в Ethernet? Хватит ли скорости работы ARM9? Насколько я понимаю CRC32 надо считать программно на ARM9, что и определит предельную скорость.
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 6 2008, 19:23
Сообщение #7


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Цитата(AlexandrY @ Apr 6 2008, 22:23) *
Эт где там CRC32 то надо?

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

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

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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
vshemm
сообщение Apr 6 2008, 19:44
Сообщение #8


Частый гость
**

Группа: Участник
Сообщений: 167
Регистрация: 15-08-07
Пользователь №: 29 803



В Е* битовое кодирование, насколько я помню... Других проблем не должно быть smile.gif Хотя, если случай симметричный, то это не требуется (раскодирование-кодирование).
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 6 2008, 20:14
Сообщение #9


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Цитата(vshemm @ Apr 6 2008, 23:44) *
В Е* битовое кодирование, насколько я помню... Других проблем не должно быть smile.gif Хотя, если случай симметричный, то это не требуется (раскодирование-кодирование).

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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
vshemm
сообщение Apr 6 2008, 21:14
Сообщение #10


Частый гость
**

Группа: Участник
Сообщений: 167
Регистрация: 15-08-07
Пользователь №: 29 803



Если схема такая: "N*E1(64kb)-> ethernet->N*E1", и данные можно не менять, то проблем почти нет; мой пост можно проигнорировать smile.gif
Go to the top of the page
 
+Quote Post
Harbour
сообщение Apr 7 2008, 05:52
Сообщение #11


Местами Гуру
*****

Группа: Validating
Сообщений: 1 103
Регистрация: 5-12-04
Пользователь №: 1 323



восстанавливать клок - весьма хитрая задача, обычно передают погрешности jitter буфера на ту сторону. max скорость потока зависит от скорости DMA проца, соответственно от его частоты, arm9 - значит > 200MHz, должно хватить, просто будет задержка (еще накладные расходы на tcp/ip стек, сетевой драйвер и сам канал передачи), для TDMoE есть нормируемые задержки, кажись до 100ms считается нормально
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 7 2008, 08:36
Сообщение #12


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



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

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

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

Как я понимаю: восстановление тактовой частоты - наиболее сложная задача
Что понимается под
Цитата
обычно передают погрешности jitter буфера на ту сторону.
?
Спасибо a14.gif


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
Harbour
сообщение Apr 8 2008, 07:50
Сообщение #13


Местами Гуру
*****

Группа: Validating
Сообщений: 1 103
Регистрация: 5-12-04
Пользователь №: 1 323



выдержка из 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
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 8 2008, 14:27
Сообщение #14


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Спасибо.


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
maegg
сообщение Apr 9 2008, 05:34
Сообщение #15


Частый гость
**

Группа: Свой
Сообщений: 129
Регистрация: 22-06-04
Из: S. Peterburg
Пользователь №: 103



Хотя не совсем по теме.
В общем случае, как везде, восстановление частоты не сложная задача.
Все зависит от требуемых характеристик, в основном к блужданию фазы.
Обычно определяют 2 параметра МОВИ (максимальное отклонение временного интервала) и ДВИ (девиация временного интервала). В телекоме это рекомендации ITU-T G.811, G.812, G813, ETS 300 462-3 и аналогичные им российские нормы. Можно поискать по теме Тактовая сетевая синхронизация.
На ФТП есть Synchronization of Digital Telecammunication Networks Stefano Bregni
Задачка по теме интересная. Но без требований или хотя бы области применения трудно понять насколько.
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 9 2008, 20:01
Сообщение #16


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Цитата(maegg @ Apr 9 2008, 09:34) *
На ФТП есть Synchronization of Digital Telecammunication Networks Stefano Bregni

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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 10 2008, 17:06
Сообщение #17


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



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

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

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

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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
Harbour
сообщение Apr 11 2008, 05:15
Сообщение #18


Местами Гуру
*****

Группа: Validating
Сообщений: 1 103
Регистрация: 5-12-04
Пользователь №: 1 323



Задержки не могут "блуждать" wink.gif - они просто есть, так как не могут не есть. xenomai же, в отличие от non-rt систем, гарантирует что они будут фиксированными. их длительность зависит от конкретного экземпляра железа и способа написания приложения. т.е. следует провести лабораторную работу и убедиться что платформа подходит для задачи.
в данном случае основная задержка и max jitter будет в передаче по tcp/ip + ethernet каналам - т.е. на несколько порядков больше чем остальные (e1/dma/rt)
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 11 2008, 08:18
Сообщение #19


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Цитата(Harbour @ Apr 11 2008, 09:15) *
в данном случае основная задержка и max jitter будет в передаче по tcp/ip + ethernet каналам - т.е. на несколько порядков больше чем остальные (e1/dma/rt)

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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
Harbour
сообщение Apr 12 2008, 06:09
Сообщение #20


Местами Гуру
*****

Группа: Validating
Сообщений: 1 103
Регистрация: 5-12-04
Пользователь №: 1 323



тоды лучше tcp/ip исключить и использовать/написать RT драйвера сетевых карт
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 12 2008, 21:22
Сообщение #21


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Harbour, спасибо.


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Apr 13 2008, 09:42
Сообщение #22


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



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

Цитата(mdmitry @ Apr 13 2008, 00:52) *
Harbour, спасибо.
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 13 2008, 18:16
Сообщение #23


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Цитата(AlexandrY @ Apr 13 2008, 13:42) *
Вообще надо LInux исключить, поскольку RT драйверам он будет сильно мешать.
Надо идти в конфу по ARM-ам и просить народ присоветовать нормальную RTOS.
Обработка потока 1 Мбит на ARM-е без специальных ускорителей 3-го уровня это занятие довольно экстремальное и явно не для Линукса.

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


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Apr 13 2008, 19:07
Сообщение #24


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



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

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

Цитата(mdmitry @ Apr 13 2008, 21:46) *
Что такое ускорители 3-го уровня? 1 Мбит/с ARM9 не примет? Ориентация на Linux была из-за поддердки стандартных протоколов, которые в минимальном виде, похоже, будут необходимы. Что-то типа отсылки команд по ethernet.
Go to the top of the page
 
+Quote Post
mdmitry
сообщение Apr 13 2008, 21:35
Сообщение #25


Начинающий профессионал
*****

Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648



Цитата(AlexandrY @ Apr 13 2008, 23:07) *
Ускорители нужны типа такого:
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) буфера по кольцу. Такое не пройдет?


--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
Go to the top of the page
 
+Quote Post

2 страниц V   1 2 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st August 2025 - 19:26
Рейтинг@Mail.ru


Страница сгенерированна за 0.02298 секунд с 7
ELECTRONIX ©2004-2016