Jump to content

    

dspman

Свой
  • Content Count

    35
  • Joined

  • Last visited

Community Reputation

0 Обычный

About dspman

  • Rank
    Участник
  1. crypto voice over gsm

    Обратитесь в Филком. Грамотные товарищи..
  2. Прошу прощения за консерватизм, но реализацию проекта нужно начинать с постановки реальных сроков. Если вы своих инвесторов не убедили увеличить сроки раз в пять, то вы обрекаете свою затею на медленную, но неминуемую гибель. Побегаете, согреетесь (что само по себе неплохо), но продукт не сделаете. Он архи/немеряно/охрененно и т.д. сложный. Денег вы просите очень мало (понятно, скока денег дали и под это дело и сроки подтянули соответственно). Без опытной команды, работающей лет 10 с похожими технологиями - это epic fail.... Но, тем не менее, вы молодец, удачи!
  3. >>Aston Martin One 77 С Германией все понятно, а тачка где?
  4. В библиотеках Ардуино (Atmega) есть реализация программного UART. Называется SoftwareSerial, но ее используют на скоростях до 9600. Выше работа нестабильная, думаю, в первую очередь из-за плохого кварца от которого тактируется процессор. Разве для STM такого готового нет?
  5. Вот еще ребята толковые http://www.bisant.ru/
  6. Цитата(MADMAX @ Sep 26 2016, 11:05) Крупной московской компании , требуется программист для ADSP-SC589 , а именно для ядра ARM Cortex A5 под Linux. Необходимо написать VoIP приложение для системы голосовой связи , по протоколу RTP, SIP используя в качестве транспорта голоса два Ethernet интерфейса объединенных в боундинг. Подробности на почту v.max@mail.ru. Вам нужен человек, способный выполнять интеграционную работу, а VoIP движок он сам не напишет, это отдельная научно-техническая задача для группы инженеров-программистов, требующая нескольких лет кропотливой работы. Там же у вас должен быть компенсатор акустического эха, шумоподавитель и прочее...Все должно быть оптимизировано под архитектуру процессора. Пишу, так как мы этим и занимаемся. Есть готовый SDK, работает много где, в том числе в VVoIP сервисах Ростелекома. Пишите/звоните. info @ integrit.ru PS: Либо опенсорс, как советуют коллеги, но с эхоподавлением и совместимостью будут проблемы.
  7. Как говориться: "Кто о чем, а вшивый все о бане!" , но я бы вам посоветовал переквалифицироваться в DSP программиста. С вашим багажом знаний и возрастом это будет относительно просто. Знания схемотехники вам однозначно пригодятся. Все DSPшники, кого я знаю, без работы не сидели, не сидят и сидеть не будут....
  8. Цитата(a-p @ Jun 7 2016, 19:20) Добрый день! А платы KONA от AJA Вас не устраивают? Эти карточки умеют работать напрямую с видеокартами AMD, что сильно снижает нагрузку на систему в определённых случаях. Они исходники драйверов не дают..... Нам это надо в AstraLinux встраивать, сами понимаете..... А в одной работе, возможно, надо весь дизайн интегрировать в общую материнскую плату...
  9. Здравствуйте! Нужна помощь в разработке и изготовлении 2х канальной платы видеозахвата с интерфейсами DVI-I, HDMI, HD-SDI. С драйверами под Линукс и Винду. Должна поддерживать разрешения до 1080р@60fps, работать навстречу с бытовой электроникой а-ля ноутбуки и вставляться в PCI-E слот. Если можете что-то предложить - пишите на info @ integrit.ru Спасибо.
  10. Простите за оффтоп, слышал, что в Гонконге люди работают чистого времени по 51 час в неделю, против наших 40 часов... А у вас сколько часов в неделю?
  11. Все, что вам нужно по программной части у нас есть. Если разговор серьезный - напишите на info @ integrit.ru, обсудим Делали много чего и для наших и для не наших. По части VoIP посмотрите на наш сайт integrit.ru По видео делаем вот такие терминалы: VitaHD.com. Весь софт - наш. Дмитрий
  12. Ищем DSP программистов для разработки библиотек под современные вычислительные ядра Tensilica. Работы много, зашиваемся! Готовы рассмотреть удаленку, но присутствие в офисе предпочтительнее. Офис в г. Мытищи, Московская область. Немного информации о библиотеках здесь: http://integrit.ru/index.php/products/dsp-libraries Для успешной работы надо более-менее знать и любить математику, представлять, как работает процессор на низком уровне и уметь программировать на "С". Пишите на info@integrit.ru или через форму запроса на страничке контактов http://integrit.ru/index.php/contacts Дмитрий
  13. Цитата(Plain @ Feb 12 2015, 06:50) Но если важен процесс, то из готовых, например, такое: http://www.amazon.com/Blue-Microphones-Ici...p/dp/B001EW5YQS Внутри — контроллер USB, регулируемый усилитель, АЦП и преобразователь в 48 вольт. Штатная звуковая плата и какие-либо драйверы не требуются — система подмонтирует конкретный микрофон со всеми рюшками и звуковые программы его однозначно увидят. Да, XLR to USB переходники, похоже, являются компромиссным решением по цене/качеству.
  14. Коллеги, Есть необходимость подключить конденсаторный микрофон с фантомным питанием и с балансным выходом к линейному (или микрофонному) входу звуковой карты. Подскажите, как лучше это сделать и, может быть, уже есть готовые решения? Кто-то может мне в этом помочь? Пример микрофона: http://www.aliexpress.com/item/Takstar-BM-...2054077013.html
  15. Цитата(Xenia @ Jan 22 2015, 15:11) Женщина на корабле – к несчастью . Но у меня и вопрос был поставлен в самом общем виде, не требущий раскрытия нау-хау. У нас представители этого прекрасного вида на корабле уже давно, плаваем Цитата(Xenia)Это-то я понимаю, однако одна лишь проверка чисел на больше-меньше перед операцией способна сильно замедлить алгоритм в целом. Например, при суммировании ряда (оно как раз в векторных умножения используется) идеальным для точности вариантом было бы сперва отсортировать тот ряд в порядке возрастания его членов, а потом суммировать, начиная от малых к большим. Но так только чистые математики думают, а инженер должен понимать, что такая сортировка обошлась бы очень дорого по времени, а потому неприемлема. Я, честно говоря, не являюсь специалистом в вопросе фикспоинта, но в рантайме проверять числа, конечно, вредно. Речь идет о том, что разные части сложных алгоритмов по разному чувствительны к ошибкам округления и о том, что для разных операций нужны разные разрядности регистров (переменных). Это все зависит от конкретного алгоритма и типа данных, обусловленности матриц и т.д. Цитата(Xenia)Конечно же float-арифметика сводится в своей реализации к арифметике целочисленной, это понятно. Однако float-арифметика популярна именно потому, что она реализована аппаратно! Именно поэтому конвейерные/векторные DSP-операции столь эффективны. Но как только я стану реализовывать такую арифметике программно на целых числах, то у меня получится банальная эмуляция . Та самая эмуляция, которая обычно бывает заложена в библиотеках тех МК, которые float-арифметику аппаратно не поддерживают. Считать на эмуляции можно, но ведь медленно же! Все верно, но энергопотребление процессоров с плавучкой и фиксированной точкой не в пользу первого. Много задач, в которых энергопотребление не важно, там где рядом есть мощный источник питания и хороший теплоотвод. Но в системах с батарейкой надо экономить на всем, поэтому там применяются процессоры целочисленные. У Тенсилики есть контроллер, который обрабатывает клавиатуру, так он умудряется поспать, пока пользователь палец переносит от одной кнопки к другой.... Цитата(Xenia)Именно из-за того, что программная эмуляция бывает чуть ли не на порядок медленее, чем аппаратная, у меня и возник к вам вопрос о побуждениях использовать целочисленную арифметику в алгоритмах, которые традиционно работают на арифметике плавающей, вследствие слишком большого разброса в порядках чисел. Для алгоритмов, типа FFT, целочисленная арифметика подходит хорошо, т.к. в этом алгоритме деления нет, а sin и cos могут быть загодя масштабированы в разрядной сетке целых чисел. Да и сами массивы данных, требующие FFT-преобразования, чаще всего являются целыми числами, покольку их обычно получают от АЦП. Но когда объект матрица, а задача на сингулярное разложение, то тут и целочисленность исходной матрицы уже не в помощь, а опасность потерять значимость малых элементов встает в полный рост. Вот поэтому мне так интересна причина, побудившая вас отказаться от float-арифметики в пользу целочисленной, тем более что в задачах линейной алгебры это порождает массу нетривиальных проблем с реализацией. Грубо говоря, почему бы вам не бросить маяту с целочисленностью, требующую для реализации такого рода алгоритмов очень высокой квалификации инженеров и программистов, и не выбрать для этих задач процессор с шустрой float-арифметикой, позволяющий использовать стандартные/типичные алгоритмы. Мы говорим не об эмуляции арифметики с плавающей точкой, а замене операций с плавающей точкой на операции с фиксированной. Т.е., очень грубо говоря, количество умножений и сложений остается в обоих случаях одинаково. А по поводу причины все просто - наш заказчик идет за рынком, делает для него ядра, а мы идем за ним и подгоняем математику