Шлюз в телефонную линию на Cortex-е, Сможет ли это сделать LM3S8970? Опции

[evg123]

Подбираем информацию для разработки след. устройства: С одной стороны ethernet, желательно 100-мегабитный, с другой стороны - телефонная линия. Со стороны ethernet-а бегают звуковые пакеты в прикладном протоколе, надстроенном над TCP/IP. Звук сжат вокодером (соответственно звуковой трафик на устройство - небольшой). Далее, прикладной протокол оговарвает пакеты управления, которыми можно управлять устройством. Например, выдать приказ набрать какой-либо номер телефона. Устройство (или несколько устройств, или даже много устройств, например 30-100 шт.) взаимодействует с хостом - компьютером. Хост может выдать приказ устройству набрать, например номер телефона. Когда устройство наберет этот, указанный в управляющем пакете, номер телефона, и со стороны абонентской линии кто-то возьмёт трубку, то устройство рапортует соему хосту, что оно дозвонилось, и тот, в свою очередь, начинает посылать звуковые пакеты в формате вокодера на устройство (и далее к человеку с той стороны телефонной линии) и, соответственно, принимать от устройства звуковые пакеты - речь человека.

Предполагается использовать Cortex-M3 от Luminary Micro (LM3S8970 и 50 МГц тактовая) в качестве контроллера и какой-нибудь SLIC со встроенным кодеком (например Si3216 от SiLabs) для сопряжения с телефонной линией.
1) Вопрос в том, потянет ли этот контроллер вокодирование и девокодирование и 100-Мбитный ethernet. Вокодирование включает в себя всякие там функции типа преобразования фурье. Или надо брать что-нибудь помощнее, например 9-ый ARM или каклй-нибудь TMS типа С6424
2) Какой SLIC более подходящий для наших линий? Их делают, как выразился один мой друг, все кому не лень, а проблема эха остаётся.

[zltigo]

а проблема эха остаётся.

Вот с этой проблемы и начните свои рассуждения о необходимой мощности процессора, ибо ни один SLIC не будет заниматься компенсацией эха возникшего из-за ЗАДЕРЖКИ В ВАШЕМ IP. Его дело обеспечить переход на двухпроводку при задержке практически стремящейся к 0 (несколько раз, ну десятков раз по 125us). Ну а мегабитность Ethernet и нагрузка от него вообще никакого значения не имеет при Ваших потоках. Все остальное пишите и моделируете.

[evg123]

Мы уходим немного в сторону.

... Его дело обеспечить переход на двухпроводку при задержке практически стремящейся к 0 (несколько раз, ну десятков раз по 125us)...

С этим я совершенно согласен. Судя по структурной схеме "слика" Si3216 в ней после кодека стоит аналоговый циркулятор (да и, по-моему, иначе быть не может), который развязывает двухпроводку на четырехпроводку.
Т.е. вы хотите сказать, что можно брать любой SLIC и он обеспечит функции циркулятора (т.е. не пропустит голос компьютера с выхода кодека на вход кодека, а подавит его на много децибелл). Но показатели у разных сликов разные, значит что-то из них лучше, а что-то хуже, опять же играет роль импеданс линии (выходное сопротивление слика должно уметь согласовываться с импедансом линии (иначе будут шумы)).

ибо ни один SLIC не будет заниматься компенсацией эха возникшего из-за ЗАДЕРЖКИ В ВАШЕМ IP

Здесь под эхом мы понимаем, наверное, разные вещи. Если нет, то поясните. Я имею в виду чисто аналоговое эхо из-за плохих характеристик циркулятора и шумов из-за несогласованности с линией. Вы, по-видимому, имеете в виду эхо, когда, кто-то, говоря по телефону по через IP, произносит слово "алё" и через секунду слышит сам себя.

Специфика нашей связи в том, что она, во-первых, смплексная (а это значит, что когда говорит компьютер, то человек сказать уже ничего не может, т.е. его разговор заканчивается на выходе кодека, данные которого игнорируются. Когда компьютер перестаёт говорить, то голос человека начинает восприниматься из кодека, преобразовываться в звуковые пакеты и отправляться в хост. По-этому проблема эха, как таковая, не существует. Я спросил только затем, что может, кто-то имеет опыт и скажет, что для наших линий более походящие такие-то слики, т.к. подстраиваются под наш импеданс и сами по себе имеют хорошие характеристики). Во-вторых путь голосового пакета - очень короткий, этот голосовой пакет выйдет из хоста, попадёт в другой, рядом стоящий эфирный компьютер и уйдёт в радиоэфир, либо из хоста в маршрутизатор, далее в выделенную E0, далее в маршрутизатор, далее в эфирный компьютер и в эфир. Предполагаем, что задержка не большая.

У меня простой вопрос - Кортекс сможет сжать/разжать MP3

Все остальное пишите и моделируете.

Как мне это дело промоделировать? Посчитать в Keil-е такты сколько уйдёт на вокодирование? Мне кажется это будет слишком приблизительно. Всё равно так или иначе надо покупать kit. А хотелось бы узнать принципиально - верное это решение или нет.

А зачем выдумывать новый стандарт VoIP?

Мы его не выдумываем. Он есть. Это стандартный вокодер, стандартные пакеты. Для достаточно специфичеких целей. Мы их только "сами" укладываем на TCP/IP, чтобы состыковать их передачу между компьютерами.

[zltigo]

Я спросил только затем, что может, кто-то имеет опыт и скажет, что для наших линий более походящие такие-то слики, т.к. подстраиваются под наш импеданс и сами по себе имеют хорошие характеристики).

Любой SLIC может и должен быть подстроен под линию, в том числе и под "вашу" российскую Характеристики заложены издревле MKKT они все "хорошие" и никто их по понятным причинам "лучше", чем требуется не делает. А "хуже" сертифицирующие органы не пропустят на телефонные сети общего пользования.

Т.е. вы хотите сказать, что можно брать любой SLIC и

Расшифруйте аббревиатуру SLIC и сами ответьте на свой вопрос.

Здесь под эхом мы понимаем, наверное, разные вещи.

Я - одинаковые, ибо наличие эха определяется работой эхокомпенсатора в вашей голове. Компенсатор "настроен" на определенный диапазон как уровней, так и задержек. Выход за эти пределы - эхо.