Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Помогите с HDLC
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > ISDN/G.703/E1
klaks
Знающие люди, подскажите, пожалуйста, по HDLC.

Ситуация такая. Устройство работает по USB, два FALCа на борту. Работаю с E1.
Наш драйвер поддерживает всего один поток Bulk, по нему и нужно организовать всю передачу данных. Все бы хорошо, если бы все передаваемые данные были бы синхронные - отсчеты голосовых каналов. Но к этим данным добавляются HDLC, скорость передачи которых отличается от скорости передачи голосовых данных. Чтобы быть точным, она может быть равна этой скорости (для E1 это 8 кГц), либо быть меньшей (поскольку фреймер добавляет сам контрольную сумму и делает битстаффинг). Данные нужно подсовывать фреймеру непрерывно иначе он оборвет передачу.

Есть идея рассмотреть ситуацию как коммутацию двух разноскоростных каналов. В случае переполнения буфера просто забить на потерявшиеся пакеты. Но в HDLC кажется нет органичения по размеру кадра, я не знаю какой буфер делать, чтобы гарантированно уметь передавать самый большой пакет.
Либо если есть возможность фрагментировать пакеты, то может просто их еще в компе разделять допустим на 1кбайтные части.

Это решение вообще корректно? Или может есть более рациональные решения?
tolik1
Цитата(klaks @ Mar 30 2011, 14:26) *
Знающие люди, подскажите, пожалуйста, по HDLC.

Ситуация такая. Устройство работает по USB, два FALCа на борту. Работаю с E1.
Наш драйвер поддерживает всего один поток Bulk, по нему и нужно организовать всю передачу данных. Все бы хорошо, если бы все передаваемые данные были бы синхронные - отсчеты голосовых каналов. Но к этим данным добавляются HDLC, скорость передачи которых отличается от скорости передачи голосовых данных. Чтобы быть точным, она может быть равна этой скорости (для E1 это 8 кГц), либо быть меньшей (поскольку фреймер добавляет сам контрольную сумму и делает битстаффинг). Данные нужно подсовывать фреймеру непрерывно иначе он оборвет передачу.

Есть идея рассмотреть ситуацию как коммутацию двух разноскоростных каналов. В случае переполнения буфера просто забить на потерявшиеся пакеты. Но в HDLC кажется нет органичения по размеру кадра, я не знаю какой буфер делать, чтобы гарантированно уметь передавать самый большой пакет.
Либо если есть возможность фрагментировать пакеты, то может просто их еще в компе разделять допустим на 1кбайтные части.

Это решение вообще корректно? Или может есть более рациональные решения?

Вариант первый. Вы транслируете весь канал в котором лежит HDLC на комп (как речевой) и там разбираете его и выделяете пакет.
Вариант второй . Вы на устройстве реализуете HDLC контроллер.
Вариант третий(не знаю какой у Вас FALC). Вы используете внутренний HDLC контроллер(который внутри FALCa).

По размеру кадра.... HDLC определен как Х.25 layer2. Там размер пакета до 4096. Однако интерфейс стал популярным и я встречал пакеты по 8К и более.
klaks
Цитата(tolik1 @ Apr 9 2011, 09:49) *
Вариант первый. Вы транслируете весь канал в котором лежит HDLC на комп (как речевой) и там разбираете его и выделяете пакет.
Вариант второй . Вы на устройстве реализуете HDLC контроллер.
Вариант третий(не знаю какой у Вас FALC). Вы используете внутренний HDLC контроллер(который внутри FALCa).

По размеру кадра.... HDLC определен как Х.25 layer2. Там размер пакета до 4096. Однако интерфейс стал популярным и я встречал пакеты по 8К и более.


Спасибо за ответ.
Использую PEF2256, там три канала HDLC.
Была мысль, соответствующая первому варианту. В принципе это можно реализовать, хотя и придется делать бит-стаффинг тоже на уровне ПК. Поскольку с HDLC раньше не работал, боюсь подводных камней. Поэтому решил поручить это дело фалку, а в него передавать сами данные.
В итоге пока сделал так: в дсп сделал буферы для HDLC, такие чтобы при максимальной разнице скоростей записи в буфер и считывания можно было передать один пакет на 8к. Если буфер переполнился, то удаляем из буфера переполнивший буфер пакет, либо если он занимает весь буфер, то останавливаем передачу и очищаем буфер.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.