Harbour

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

Цитата(Dima_G @ Jan 22 2018, 05:24) Неоднократно нарывался на падения фиттера (Q15..Q16 под Linux). Помогали только шаманские танцы с бубном - максимальное упрощение проекта и постепенное включение его частей до начала падения при сборке. Результирующие причины были разные - сложные для него конструкции на SV, пины без Location Assigment, либо с неправильным Location Assigment. в случае реальной ошибки фитера всегда можно на 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) "ннуу ... это же все переделывать надо"; "это будет очень дорого и долго"; c) "это невозможно". Поэтому рынок этих грустных и бесполезных товарищей выкидывает в мусорку, меняя на других. Можно отметить их ключевые признаки: категорическое отрицание всего, что не попадает под узкий луч приобретенного ими опыта, полное неумение учиться новому, скудоумие, отсутствие взгляда на перспективу, острая и никому нахер не нужная заточка под одну задачу (например вымершую ось), бесполезная трата бабла на их разработки, дикие сроки - и в конце, как следствие - жопа по жизни. Также обычно такие товарищи любят тусоваться на форумах, периодически доказывая свою крутизну печатая разные слова Мое резюме простое: учите Linux и возможно будет вам счастье. Правда не всем, и не в этой жизни )

Цитата(AlexandrY @ Nov 11 2017, 21:34) Нет, это не пример. Покажите фото платы дивайса чтобы мы убедились что все действительно работает на одном ядре, одной шине и одном чипе памяти и без полуавтономных хардварных ускорителей протоколов. И с временем реакции не больше 2 мкс. Сейчас такой стандарт для жесткого риалтайма в ARM Cortex фото платы - 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 Какие микросекунды ? Забудьте...

Цитата(syoma @ Nov 10 2017, 20:38) На чем проверено? Примеры рабочих железяк можно? любое x86 железо не на интел чипсете )

Цитата(Студент заборстроительного @ Nov 9 2017, 05:49) Линукс это классно. Линукс - это модно Только никто не гарантирует, что данный дистрибутив гарантирует отсутствие дедлоков, пропусков прерываний, инверсий приоритетов и пропуска дедлайнов. Скажут только "вероятность этого мала" А если у Вас приложения, где вероятность всего перечисленного должна быть не "мала", а "ТОЧНО равна нулю"? Точно равна нулю только глупость человеческая, даже заточенные под RT железки ломаются. Linux, в подходе Xenomai, вообще ни на что не влияет - он может даже зависнуть или находится в tripple-fault (oops) состоянии - RT как работало так и будет продолжать работать, проверено не раз. Если хочется гарантий "5 девяток" - делается резервирование. т.е. ставится 2-3 устройства как принято везде в авиа и военке.

Цитата(syoma @ Oct 26 2017, 11:41) Привет. Собственно вопрос из области начинающих по архитектуре процессорной системы. Делаем новый проект и возник вопрос. С одной стороны есть программа, работающая в жестком реальном времени с коммуникацией, через CAN, SPI и RS485. Это основная функция системы. С другой стороны есть куча других интерфейсов - SD card, Ethernet, USB и прочих, которые служат для вспомогательных функций - записи логов, параметрирования, обновления ПО, удаленного доступа через WEB и bluetooth, терминалки и т.д. Если все это реализовывать на одном процессоре, то получается, что надо использовать RTOS, что требует определенных программистских навыков и не нравится то, что это уменьшает защиту системы от внешних хакерских атак. Если из-за Ethernetа зависнет основная программа - это будет очень-очень плохо. Т.е. в результате увеличиваем затраты на разработку, делаем сложную программу, но уменьшаем стоимость железа. Поэтому у меня настрой такой, что основной процессор должен выполнять только основную real-time программу и все. При этом ему не нужна операционная система вообще, так как нужные интерфейсы реализуются как функции ввода/вывода - это уже реализовано и проверено. А для всего остального поставить отдельный процессор или даже платку, на которой будет крутиться обыкновенный Linux со всеми нужными драйверами. И с основным процессором эта плата будет общаться только через CAN. В этом случае практически все функции будут уже реализованы в самом ядре и программисту надо будет сделать очень мало и хоть на питоне или джаве. То есть затраты на разработку будут гораздо меньше, имеем барьер от хакерских атак - если этот процессор зависнет, система будет прекрасно работать дальше, но увеличиваем стоимость железа. Как думаете это нормальный подход сегодня? Зачем изобретать, то что придумано более 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'шники повывелись

Цитата(Stepanov @ Nov 27 2014, 22:39) Думаете о HMM? Значит ваши искажения имеют нелинейную АФХ, и вероятно ФЧХ тоже, и просто коррелятор тут не эффективен. Угм, АФХ и ФЧХ мангл имеет место быть

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

Цитата(Mihail Gluhowchenko @ Feb 1 2014, 11:51) И ? http://www.mindspeed.com/products/wireless...anscedereg-4000 Вообще-то майндспидовские SoC'и в сервера никто и никогда не ставит, разве что в экзотическое коммуникационное оборудование ЦитатаТам линеек достаточно много с большим количеством ядер. Есть ещё NPU. Есть у них ниша её и занимают. Нет уних там никаких серверных линеек и быть не может. А ниша эта называется серверный рынок, теперь ее потихоньку занимает ARM ...