Перейти к содержанию
Поиск
    

lex4ern

Участник
 Профиль  Обзор контента

  • Постов

    7

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные lex4ern

  2. Опубликовано · Пожаловаться

    Приветствую присутствующих!

    Есть сдельная задача, суть в следующем. В готовом изделии, представляющем собой некий шлюз-разборщик потоков E1, реализована в виде готового программного модуля разборка сигнализации ОКС7. Все это работает и успешно взаимодействует с другими программными и плисовыми компонентами. Необходимо разработать другую версию этого же программного компонента, работающую с сигнализацией dss1, сохранив его программные интерфейсы.

    Комментарий от разработчика:

    "Для того чтобы сделать подходящий для нас разборщик Dss1 необходимо

    реализовать его аналогично классу CSigProc, у которого есть основной

    метод process_block, выполняющий обработку буфера со входными данными.

    CSigProc в итоге вызыает CISUPParcer::process, который и выполняет обработку событий сигнализации.

    Итого: передать в качестве образца, для реализации парсера Dss1нужно

    файлы: isup.* sig_proc.* из указанной папки."

    По срокам оцениваю эту задачу как небольшую, порядка двух недель. Мое предпочтение кандидатам, имевшим опыт работы с этими сигнализациями, возможно, имеющими наработки. По вознаграждению обсуждается, условно на уровне нормальной з/п программиста соответствующей квалификации, в пересчете на фактические трудозатраты.

    Форма работ - мы даем все исходники, автор пишет компонент, далее предоставляем возможность отладки у нас на приборе, или удаленно (такие инструменты есть).

    Упомянутые выше файлы вышлю заинтересовавшимся.

    Пишите, постараюсь ответить на вопросы. [email protected]

    Причина обращения - мы малое предприятие, люди ушли в отпуск, надо делать срочно.

     

    С Уважением,

    Алексей

  3. Опубликовано · Пожаловаться

    Автоматические тесты на матлабе подняты?

    Сколько килобайт исходного кода?

    С++14 допустим?

    OpenCV, Intel MKL допустим?

    Контроль версий git/hg?

    Визуализация нужна, или файл на вхоже, файл на выходе, или REST API?

    Если нужна простая визуализация:

    Достаточно средств OpenCv (без менюшек и прочих GUI)?

    Визуализация Windows или Linux?

     

    Попытаюсь ответить, на которые не смог - переадресовал разработчику.

    70К исходников (*.m)

    OpenCv, насколько знаю, использовали, но неудачно.

    Контроль версий есть.

    Визуализация есть (внешняя утилитка кроссплатформенная с gui), но в данный момент она не нужна - нужно добиться идентичного (более-менее) потока выходных данных.

    Автоматическая генерация не получилась. «Что-то» собирается, но с массой варнингов, в итоге собранный код неработоспособен.

     

  4. Опубликовано · Пожаловаться

    Коллеги, приветствую.

    Задача в следующем.

    Есть разработанный алгоритм на Matlab-е. Назначение – выделение из видеопотока движущихся объектов и выдача наружу их координат.

    Входными данными являются видео-файлы (их набор ограничен), выходом – координаты рамки, окружающей объект.

    Для модели сделана простая визуализация, отображающая в плеере рамку.

    «Закрытые мегафункции» (затрудняюсь с точным термином) матлаба не используются.

    Модель в матлабе полностью работоспособна и была сдана заказчику.

    Есть документация на алгоритм. В исходниках приличные комментарии.

    Есть, кто проконсультирует по математике.

    Необходимо сделать: транслировать матлабовскую модель в с-код. Можно в с++.

    В силу крайне жестких сроков предпочтительно использовать автоматический метод трансляции, подправляя его вручную. Но в конечном счете это на усмотрение разработчика.

    Критичен срок. Я ориентируюсь на 2-4 недели, можно больше, но в пределах этих сроков должно быть что-то работоспособное.

    В целях контроля результата нужно будет ввести «точку контроля», утрируя – сравнивать выходные данные, то есть координаты, генерируемые исходной моделью и с-шной моделью. Допускаются отклонения, в пределах срока решения задачи допускается результат категории «почти совпадает».

    Ориентировочный размер оплаты (на руки) – 150 т.р., это обсуждаемо.

    Это основные моменты, исполнителю, который выразит предварительное согласие – все подробности и исходные данные вышлю.

    Мы в Питере, возможна удаленная работа по этой задаче.

    [email protected]

  5. Опубликовано · Пожаловаться

    Интересно, был ли сделан прогноз по достижимому на выбранной FPGA + QDR хешрейту и энергоэффективности проекта?

     

    По-моему, начинать такие проекты "от платы" довольно рискованно.

    Правильнее было бы приступать (или не делать этого) к разработке платы имея на руках отлаженный на готовых платах алгоритм с понятной производительностью.

     

    Да, расчеты были сделаны предварительно.

    Правильнее, согласен. Но имеем то, что имеем.

    Производительность завязана на аппаратурные характеристики.

     

  6. Опубликовано · Пожаловаться

    Алексей,

    какие критерии приёмки?

     

    Требуется переложить с Си на Верилог или всёже стоит задача выдачи не менее заданного хешрейна (хеш-на-лут, хеш-на-память)?

     

     

    Здравствуйте! Да, все правильно. К началу июня - просто переложить и показать первичную работоспособность алгоритма на этом железе. Далее будет время на оптимизацию и выжимание хэшрэйта.

     

     

    Добрый день!

     

    Вот этот:

    https://github.com/wolf9466/cpuminer-multi

     

    Здравствуйте!

    Прошу прощения, не было возможности сразу ответить.

    Постараюсь ответить всем одним сообщением.

    Сроки действительно жесткие.

    Сформулирую критерий первичного успеха простыми словами: в начале июня изделие должно первично заработать. Без оптимизации, с допустимыми недоработками и пр. Заказчик поедет с платой к инвестору, положит ее на стол и скажет «во чо у меня есть») Если оно при этом будет еще как-то функционировать, то вообще шикарно.

    В планировании задачи изначально были допущены ошибки, плюс специфические орг.моменты – поэтому сроки остались вот такие.

    В худшем случае будем переносить – головной заказчик вполне вменяемый. Но это всегда нежелательно.

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

    По деньгам все обсуждаемо, здесь не будет крохоборства. Но естественно, в разумных пределах. Есть «первый этап» - как-то запустить к июню. Далее – доработки, они тоже оплачиваются. Обычно в таких ситуациях я договариваюсь с разработчиком на примерный срок и помесячную оплату.

    Готов рассматривать нескольких разработчиков (команду).

     

    С Уважением,

    Алексей

     

     

    Здравствуйте! Да, все правильно. К началу июня - просто переложить и показать первичную работоспособность алгоритма на этом железе. Далее будет время на оптимизацию и выжимание хэшрэйта.

     

     

     

    Добрый день!

     

    Вот этот:

    https://github.com/wolf9466/cpuminer-multi

     

    Здравствуйте!

    Прошу прощения, не было возможности сразу ответить.

    Постараюсь ответить всем одним сообщением.

    Сроки действительно жесткие.

    Сформулирую критерий первичного успеха простыми словами: в начале июня изделие должно первично заработать. Без оптимизации, с допустимыми недоработками и пр. Заказчик поедет с платой к инвестору, положит ее на стол и скажет «во чо у меня есть») Если оно при этом будет еще как-то функционировать, то вообще шикарно.

    В планировании задачи изначально были допущены ошибки, плюс специфические орг.моменты – поэтому сроки остались вот такие.

    В худшем случае будем переносить – головной заказчик вполне вменяемый. Но это всегда нежелательно.

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

    По деньгам все обсуждаемо, здесь не будет крохоборства. Но естественно, в разумных пределах. Есть «первый этап» - как-то запустить к июню. Далее – доработки, они тоже оплачиваются. Обычно в таких ситуациях я договариваюсь с разработчиком на примерный срок и помесячную оплату.

    Готов рассматривать нескольких разработчиков (команду).

     

    С Уважением,

    Алексей

     

    Где-то в интернете есть достоверное графическое представление алгоритма, что более наглядно, с ходу не смог найти.

     

    На первом этапе рассматривали использование vivado hls или чего-то аналогичного.

    Все сроки рассчитаны исходя из оптимистического прогноза по плате - если будут задержки из-за железа - это будет объективно восприниматься

  7. Опубликовано · Пожаловаться

    Приветствую всех присутствующих!

    Предлагаю рассмотреть задачу, которую планируем к выполнению в сдельно-удаленном режиме.

     

    Разработка ПЛИС-проекта майнера по алгоритму «Монеро». Исходный алгоритм – стандартный, написанный на C. Его необходимо портировать на плату с Kintex7. Память QDR GSI Technology, для нее будет применен ip-core производителя, реализующий доступ для Xilinx. Плата в стадии финальной разводки, до конца апреля будет отдана в производство. Детали задачи будут уточнены при общении с нашим специалистом. Схемная документация будет предоставлена. Железо для удаленной работы будет предоставлено.

    Сроки достаточно жесткие.

    Примерный план-график:

    20.04 – 20.05 – разработка модели ПЛИС-реализации алгоритма «Монеро» в САПР в режиме симуляции. Имитация (симуляция) памяти.

    20.05 – 20.06 – отладка на плате. Итог – первично работающая версия. При недостатке сил в усиление будет придан еще один разработчик.

    20.06 – (определяется по ходу работ) Финальная отладка.

    Ориентировочный уровень оплаты – выше среднего для специалистов соответствующей квалификации в СПБ. Заинтересовавшихся кандидатов просьба в личке озвучить желаемую стоимость работ.

     

    С Уважением,

    Алексей

     

×
×
  • Создать...