Harbour

знатный срач. задача легко решается за каких-то $250k при стоимости железа в <$10k. стучи в личку если сможешь показать деньги ;)

в случае реальной ошибки фитера всегда можно на evaluation license запулить bug-report, типа ты не причем. Q15 еще божеская тема, я начинал с Q10 - вот это пестня... в любом случае синтезатор в квартусе - это все еще посредственный кусок гавна - синтезить нужно хотя бы в менторе, а в квартусе только place & route.

broadcom - просто кусок prorprietor гавна, из которого многоие пытаются лепить пули. любое их решение при довольно неплохом инженерном бонусе тупо отваливается по причине маркетинговых фэйлов. если ты не крупный кетайский завод - то broadcom не для тебя

Linux юзайте в продакшене, а не пасьянс-гонялку. Или шлем на голову, забрало вниз, шпоры в клячу от m$ и вперед - на ветряные мельницы.

Так причем тут ПЛИС ? Изначально вопрос стоял - а можно ли сделать все на Linux. Ответ - да. Так получилось что сейчас 1GHz ARM стоит < $1. В 90-ых может и был короткий период, когда MCU имели смысл - но сейчас 20xx. Плата NanoPi Neo стоит (в розницу !) $5, 4 ядра 1.2Ghz, 512Mb RAM, ethernet, etc. Железо, которым бьют себя пяткой в грудь адепты ucos больше не играет никакой роли. И дальше будет еще для них хуже. Каличные доморощенные псевдо-оси, дефективные windoze-based компиляторы (Keil привет) и их натужные бородатые писатели тупо идут лесом, так как они не только не в состоянии обеспечить конкурентно-способный цикл разработки, но и даже более или менее стабильный продукт из-за хронической деревенской безграмотности, т.е. грубо говоря - ничего кроме своей оси и ее устаревших технологий (на устаревшем же и железе) они асилилить не смогли, а время и задачи на месте как-бэ не стоят. Приходит на ум только одна пословица - "она наморщила свой узкий лобок". Про обычные ситуевины, когда, к примеру, на следующем этапе стоит задача поднять производительность в 10 раз (или, скажем в 100) речь вообще не идет, так как вдруг оказывается что a) "ннуу ... это же все переделывать надо"; B) "это будет очень дорого и долго"; c) "это невозможно". Поэтому рынок этих грустных и бесполезных товарищей выкидывает в мусорку, меняя на других. Можно отметить их ключевые признаки: категорическое отрицание всего, что не попадает под узкий луч приобретенного ими опыта, полное неумение учиться новому, скудоумие, отсутствие взгляда на перспективу, острая и никому нахер не нужная заточка под одну задачу (например вымершую ось), бесполезная трата бабла на их разработки, дикие сроки - и в конце, как следствие - жопа по жизни. Также обычно такие товарищи любят тусоваться на форумах, периодически доказывая свою крутизну печатая разные слова ;) Мое резюме простое: учите Linux и возможно будет вам счастье. Правда не всем, и не в этой жизни ;))

фото платы - x86 мамка. время реакции на что ? прерывание ? готового ответа системы по ТЗ ? Тупые interrupt latency/scheduling latency величиной в 2 мкс - это какой-то отстой в наши дни, для x86 Linux уже давно пробита планка в 1мкс для RT apps на стоковом ядре. А Xenomai еще быстрее. Но вопрос не в том как быстро среагировать на прерывание, получить данные, распарсить, посчитать и отослать в сеть. Вопрос в том как быстро это можно сделать пока не сделали конкуренты. И начем уже не важно. А вариант на uCOS/FreeRTOS будет делаться годами, обрастая Linux'ом все равно, так как голая железяка никому нафиг не нужна. Сейчас битва идет за наносекунды, но это уже спец железо. Вот фото спец-платы с которой я лично работал: http://www.colfaxdirect.com/store/pc/viewP...?idproduct=2865 сток ядро с PREEMPT_RT, сетевуха - 2 канала по 40Gbit, время реакции всей системы от прихода пакета до ответа в сеть (на границе сетевого интерфейса) - ~250 ns. Ядру приложения надо всего один такт на выдачу результата, это 5ns Какие микросекунды ? Забудьте...

любое x86 железо не на интел чипсете ;))

Точно равна нулю только глупость человеческая, даже заточенные под RT железки ломаются. Linux, в подходе Xenomai, вообще ни на что не влияет - он может даже зависнуть или находится в tripple-fault (oops) состоянии - RT как работало так и будет продолжать работать, проверено не раз. Если хочется гарантий "5 девяток" - делается резервирование. т.е. ставится 2-3 устройства как принято везде в авиа и военке.

Зачем изобретать, то что придумано более 20 лет назад ? Сегодня один проц (без всяких каличных Cortex-M гибридов) легко тянет обе задачи. RT супервизор счедулит RT-прерывания и RT-задачи, запуская основную ОС как самую низкоприоритетную non-RT задачу, включая все ее non-RT драйвера, в том числе и графические. Вопрос в нужном времени отклика и джиттере. Для Linux один из таких супервизоров реализован в проекте Xenomai. В комплекте идет RT drivers framework где есть и CAN. Пашет на ARM, AARCH64, NIOS, x86, PPC. Поддерживается SMP, в том числе и в RT пространстве, с разными affinity извращениями. Данный подход позволяет реализовывать hard RT не парясь о жопообразности разработки под уникальные RTOS и наличии поддержки/драйверов под свое железо. Как известно - Linux работает везде и писать под него умеют теперь даже обезьяны, которые случайно засматривались в окна индусских программистов.

Hello, Нужно переделать опенсорсный LPC10 вокодер для работы в несовсем обычном режиме. Бюджет $1000, все вопросы в личку, только Украина.

2Stepanov: сроки мной указаны четко, работы тут для спеца на 1-2 дня. не смешите мои тапочки - какие месяцы ... ? А "динамическая модель тракта" тут, мягко говоря, не нужна. 2Elsystems: Совершенно c Вами согласен, но походу таковых не наблюдается. 2D-35: Если это ко мне, то Вы не правы, перечитайте исходный пост. Ok, тему закрываю, так как почти все сделал сам за сегодня, осталась кое-какая оптимизация ...

коррелятор практически бесполезен при искажениях частоты, да еще на таких коротких сэмплах. да, согласен HMM это не выход, особенно учитывая затраты на поиск в таком массиве моделей. лепить два набора баз - это грустно, в лоб и не имеет практического смысла, так как никто не гарантирует, что созданная модель сферического канала в вакууме будет соответствовать реальному положению вещей. так как никто не откликнулся - попытаюсь на выходных сделать сам через MFCC+DWT. Что-то DSP'шники повывелись ;)

Угм, АФХ и ФЧХ мангл имеет место быть ;)

Hello, Нужен DSP'шник для реализации надежного и не шибко затратного алгоритма распознавания/идентификации (HMM ?) коротких (до 5 ms) сэмплов из заданного набора (не более 1000, вполне допустима генерация своего набора, если так будет удобней реализовать задачу) в _сильно_ искаженном audio потоке. Target platform - Linux ARM, но тупой ANSI-C или C++ подойдет вполне. Оплата: в районе $1000, предпочтительно Украина Все предложения просьба отправлять на rus (at) sfinxsoft (dot) com P.S. Убедительная просьба - людям, которые этим никогда не занимались - не писать, потому как время реализации проекта - 1 неделя max.

Вообще-то майндспидовские SoC'и в сервера никто и никогда не ставит, разве что в экзотическое коммуникационное оборудование ;) Нет уних там никаких серверных линеек и быть не может. А ниша эта называется серверный рынок, теперь ее потихоньку занимает ARM ...