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 ...

то же но по-русски http://www.linux.org.ru/news/hardware/10111346

Ну как и предполагалось : http://www.anandtech.com/show/7724/it-begi...e-opteron-a1100 Так есть, что ответить Чемберлену ? ;)

Однобок не мой взгляд - а зашореный взгляд интел и его покупателей. Кто сказал, что сервера/десктопы/ноутбуки должны быть обязятельно на x86 ? Вот он их северный зверек, во всей своей красе. А cтатистика неумолима - самый распространенный в мире процессор - ARM, и это прямой и красноречивый результат для обос#авшихся менегров от интел - никто не станет отрицать, что все это произошло на их глазах за всего за несколько лет, и они так и не смогли оторвать свою задницу от мягких стульев, чтобы что-то предпринять. И теперь интелю приходится платить деньги своим же конкурентам за право пользоваться технологиями x86_64, ARM и т.д. Т.е. их провал просто капитален .... P.S. Забыл сказать - не стоит думать, что 64-битный АРМ вышел только как передовая хрень для айфончиков. Его задача как-раз и занять определенную долю серверного рынка. поживем - увидим ;)

Дык, а кому ж сейчас нужны эти допотопные десктопы и сервера ? Самое прикольное, что конкуренцию даже на этом жестоко падающем рынке составляет с успехом все тот же ARM - выпускаются очень даже ничего себе ARM десктопы, сервера и даже ноутбуки (хромобуки). Игры в основном играют на приставках, мобильниках и планшетах - там давно правит бал AMD и Nvidia. В авто, телевизорах, холодильниках и прочем умном доме - стоят в 99% ARM'ы. Сейчас время не десктопов и серверов, а больше "интернет-вещей" - собственно и топик-то об этом - время часов, браслетов, гугель-гласов и прочее. Даже не вижу даже места куда бы можно было воткнуть в эти девайсы печальный Интель. Можно еще попытаться спросить тут на форуме - вдруг, кто согласен сразу перепрыгнуть с Atmel/PIC/STM/PPC на x86 - но думаю покрутят пальцем у виска, и будут правы ;)

Наверное потому, что авалон для многих уже давно медленный отстой, как его ни накручивай. Тут же народу - все еще интересна перспектива ;)

Какая нафиг емкость, когда полностью отдали embedded область ARM'у. Уже обсуждалось не раз - поезд интел ушел, прос#али все что имели (мобильный рынок, разработку новых x64 процов, 3D карты и т.д.), и не от хорошей жизни они сейчас свои заводы в аренду сдают

Ну да, раньше они прессовали вендоров кнутом и давали взятки и откаты пряником, чтобы их процы хоть кто-то покупал, теперь конкурсы пытаются устраивать, только от прошлого не отмыться. Поезд ушел еще 10 лет назад и придется им до конца дней своих платить отчисления AMD и ARM за использование их технологий ;)

Неадвекатные выводы о моих тапочках сможете сделать только после успешного завершения своего прожекта. Пока я вижу, что побеждают тапочки с явным преимуществом ;) Так о том и речь, 40nm это уже моветон ...

Насчет FPGA я бы, конечно, поспорил - грамотная FPGA-for-ASIC-prototype платформа может легко выдавать на гора новые версии ASIC'ов в течении довольно длительного времени, причем с гуманными промежутками между итерациями. А так, да - все немного изменилось, и данная тема скорей всего ушла в законодательную плоскость. Чем больше стран примет необходимость обращения криптовалют - тем более данная тема будет востребована. Пока только Германия слегка раздуплилась : http://kiberpank.info/page/no-title-152

Sorry, если я не понял ТС, в том плане, что он не собирается делать свой ASIC, а просто лепит очередную продвинутую mining-борду, но посыл для подобных проектов остается неизменен и звучит он как "show me the money", т.е. деньги - вперед ;)