Теоретически есть возможность подключения. Надо использовать внешний преобразователь из 4x3.125 Гбит/с в 10 Гбит/с. Но для 10G Ethernet своих сложностей хватает. У меня вот сейчас есть устойчивое соединение с 10G коммутатором, а вот с сетевой платой Intel — не получается. И не хватает времени разобраться.
Это очень хорошо, то вот что делать когда matlab поменяет API, будет очень неприятно остаться без поддержки
Это общая проблема работы с Open Source — всё на свой страх и риск.
Интересное мнение. А какие вы нашли у него преимущества по сравнению с другими фреймворками для тестирования? Хотя бы по сравнению с Google Test и Ctest+Cmake…
Если сравнивать с Google Test и другими системами unit тестирования то Simulink конечно другой. В более общем смысле — это система тестирования и разработки чего-то. Например алгоритмов, или других вещей. И да, возможность создать тесты и провести регрессионное тестирование там тоже есть.
А вы не могли бы показать код S-Function. Кстати, статье как раз кода оч не хватает…
Плата с PCI Express не обязательно должна стоять в компьютере, мы активно используем внешние модули на PCI Express. Есть стандарт для медного кабеля, есть и оптические удлинители.
Для ускорения обработки данных в компьютере есть различные способы, включая видеокарты, ПЛИС, сигнальные процессоры. Ну и от самого алгоритма обработки тоже зависит. Например я умею проверять 64-х битный счётчик на скорости 11 Гбайт/с.
Решение с вводом данных в Simulink через Ethernet является альтернативным подходом. Оно вас устраивает — и это хорошо. В статье приведён другой, более мощный подход. Вот он устраивает меня.
Ethernet сразу ограничивает скорость обмена. А главное — накладывает ограничения на выбор аппаратуры. Предложенный подход не накладывает ограничений на интерфейс связи. USB взят исключительно для примера, что бы удобнее было подключиться к ноутбуку. А так конечно напрашивается применение модулей на основе PCI Express.
По поводу синхронизации — в данном примере АЦП стартует по фронту сигнала «START», этот сигнал формируется генератором. Но разумеется вместо генератора может быть и другой источник.
С точки зрения Simulink непредвиденные задержки на ПК совершенно не мешают. Он просто ждёт когда сигнал старта пройдёт через sm_adc и вернётся обратно. Это будет всё тот же момент модельного времени.
Ну если проект достиг совершенства, то зачем коммиты :-)
1. Симулинк как раз и является тестовым фреймворком. И мне нужен полный контроль за моим кодом. Как за тем что есть в схеме симулинка, так и за тем что в DLL и программах управления аппаратурой. Я этого достиг.
2. Про тестовый вывод — printf() как раз и является системой логирования. Простой и очень эффективной. И легко переносимой между разными программами. Ну вот я его и использую. Причём везде, в том числе и в программах с GUI.
3. Может. Вот только я не вижу места где бы я мог его вызвать. У меня есть код DLL на С++, есть S-Function которая вставляется в схему Simulink. А вот отдельного m-файла нет. И вроде бы он не предполагается. Я не прав?
Здесь главный вопрос — режим захвата однократный или непрерывный?
Если однократный — то определяется только возможностями аппаратуры по скорости регистрации сигнала. Если регистрировать в память при ПЛИС — 8-12 Гбайт/с. Если регистрировать в память компьютера, то зависит от интерфейса связи. Для USB 3.0 это 300 Мбайт/с. На PCI-Express до 13 Гбайт/с.
А если интересует непрерывный режим — то тогда уже надо учитывать скорость обработки в Matlab. Надо что он успел обработать блок данных до прихода следующего.
По такой технологии можно обеспечить скорость передачи в Matlab до 13 Гбайт/с.
У нас сейчас нет готового решения для захвата видеопотока, но я готов обсудить такую задачу. Сделать можно.
А будет подобная статья про менеджеров?
Например взгляд на менеджера со стороны разработчика?
Например лично я считаю что менеджеры только мешаются в разработке.
Есть замечательные специалист которые на своем опыте могут вам рассказать что такое проектный подход и как его внедрять
Конечно есть специалисты, расскажут, покажут и возьмут деньги. Собственно это их работа, они как раз прекрасно зарабатывают деньги на теме проектного подхода. И это не единственный пример. Можно ещё вспомнить МММ. На этом тоже многие заработали.
Вообще, если у вас такой негативный опыт с проектным управлением, то может, что-то в консерватории подправить?
Может быть что то не так именно с проектным управлением?
Второй график можно интерпретировать так что половине компаний это оказалось совершенно не нужным. Но они не смогли отбиться от внедрения.
Самое интересное в нашей дискуссии это найти границы применения этого самого проектного подхода. Он не может охватить всё и везде быть эффективным. Так просто не бывает. Поэтому я считаю ложными утверждения о том что проектный подход (и в частности PMBoK) это наше всё и по другому нельзя работать.
Одно ограничение мы уже выяснили — это разделение операционной и проектной деятельности. Но оно тоже достаточно условно. В рамках операционной деятельности тоже могут выполняться проекты и достаточно сложные.
График показывает что предпочтительная область проектного подхода — это разработка с нуля. Но это достаточно редко. По сути — это создание новой компании для новой деятельности. В реальности все разработки идут на основе предыдущего опыта. У нас норма это 80-90% задела. Если меньше — скорее всего не заработает.
А про ЗП программистов я просто не понял ваш вопрос.
Тут тоже всё просто — если вы собираетесь платить за отработанное время, то люди будут вырабатывать время. Если за результат — будут вырабатывать результат. Если результат будет представлен в виде KPI — будут вырабатывать KPI.
Причём здесь есть обратная зависимость. Идеальное состояние это когда люди не работают а результат есть. Классический пример — это ремонтная бригада на заводе Форда. Они получали деньги когда сидели в комнате отдыха. Также и с программистами. Надо что бы они минимальными усилиями получи максимальный результат. Оплата за отработанные часы в проекте это самый худший вариант из всех.
Проект направлен на создание УНИКАЛЬНОГО продукта или услуги. Поддержка проекта после сдачи — задача важная, но относится к операционной деятельности. Частично относится к проекту, а в остальном — к портфельному уровню управления.
Что такое уникальный? Если в проекте задействовано 10% наработок от предыдущих это уникальный проект? А если 90%? А можно сказать что операционной деятельностью компании является разработка новых проектов?
В примере компании действительно выполняются проекты но нет места проектному подходу. К обсуждению нового проекта и выработке плана реализации привлекаются наиболее квалифицированные разработчики. Они принимают решения о модификации исходной библиотеки (если необходимо). Далее оперативное руководство выполняют руководители подразделений.
Платить программистам по часам это ПРИНЦИПИАЛЬНО не правильно. В долгосрочной перспективе это приведёт к тому, что программисты будут вырабатывать человеко часы а не программы. И вместо оптимальных решений будут искать решения которые позволят им заполнить человеко часы на проекте. Про единую библиотеку можно забыть. Так что в долгосрочной перспективе (десятки лет) проектный подход вреден.
Как ни странно, но наиболее неблагоприятной структурой для проектной деятельности является проектная команда. Это сразу ограничивает кругозор рамками данного проекта. Это задаёт методику поведения — после нас хоть потоп. Т.е. сейчас сдадим и всё. Следующий проект с чистого листа.
Признаю, я достаточно поверхностно знаю PMBoK, но я не вижу причин туда углубляться. Только потому что это модно?
Вопрос сложный, вполне может быть что я не прав. Но именно для этого и ведётся дискуссия. Мне по крайней мере интересно. Если вам тоже интересно — то можно продолжить. Пока что я не увидел хороших аргументов в защиту проектного подхода. Как только доходит до конкретных вопросов сразу идёт уход в сторону от ответа.
Давайте ещё раз рассмотрим гипотетическую ситуацию. Компания в течении долгого времени разрабатывает библиотеку. На основе этой библиотеки выполняются различные проекты для совершенно разных заказчиков. Где в этой структуре место для проектного подхода? Где место руководителя, где место программистов и главное — как и за что платить деньги программистам.
Наверное при цифре 0.6 будет сложно сказать что всё Ок. Но я боюсь что сотрудники очень быстро научатся делать нужные цифры. И очень скоро будет показатель 0.99 но при этом до полной готовности будет очень далеко.
Совершенно верно. Это средняя температура по больнице. Опытный главврач может по увеличению температуры определить что началась эпидемия.
Но я подвергаю сомнению самые основы — откуда взялись эти цифры. Например с трудоёмкостями. Например можно посчитать поставленные задачи и выполненные. Получаем процент. Вот только чего? Задачи равнозначные? Или есть какая-то сложная задача и много мелких.
Но перед самой сдачей проекта средняя температура не имеет никакого смысла. Имеет значение только список не сделанных задач. Причём каждая задача требует индивидуальной оценки. А здесь мы опять возвращаемся к вопросу о квалификации руководителя проекта.
Хороший обзор. Спасибо.
Это общая проблема работы с Open Source — всё на свой страх и риск.
Если сравнивать с Google Test и другими системами unit тестирования то Simulink конечно другой. В более общем смысле — это система тестирования и разработки чего-то. Например алгоритмов, или других вещей. И да, возможность создать тесты и провести регрессионное тестирование там тоже есть.
Так его то и нет. Есть код DLL: https://github.com/dsmv/simulink_sm/blob/master/simulink_sm/src/mex/sm_adc.cpp
Для ускорения обработки данных в компьютере есть различные способы, включая видеокарты, ПЛИС, сигнальные процессоры. Ну и от самого алгоритма обработки тоже зависит. Например я умею проверять 64-х битный счётчик на скорости 11 Гбайт/с.
Решение с вводом данных в Simulink через Ethernet является альтернативным подходом. Оно вас устраивает — и это хорошо. В статье приведён другой, более мощный подход. Вот он устраивает меня.
По поводу синхронизации — в данном примере АЦП стартует по фронту сигнала «START», этот сигнал формируется генератором. Но разумеется вместо генератора может быть и другой источник.
С точки зрения Simulink непредвиденные задержки на ПК совершенно не мешают. Он просто ждёт когда сигнал старта пройдёт через sm_adc и вернётся обратно. Это будет всё тот же момент модельного времени.
Ну если проект достиг совершенства, то зачем коммиты :-)
1. Симулинк как раз и является тестовым фреймворком. И мне нужен полный контроль за моим кодом. Как за тем что есть в схеме симулинка, так и за тем что в DLL и программах управления аппаратурой. Я этого достиг.
2. Про тестовый вывод — printf() как раз и является системой логирования. Простой и очень эффективной. И легко переносимой между разными программами. Ну вот я его и использую. Причём везде, в том числе и в программах с GUI.
3. Может. Вот только я не вижу места где бы я мог его вызвать. У меня есть код DLL на С++, есть S-Function которая вставляется в схему Simulink. А вот отдельного m-файла нет. И вроде бы он не предполагается. Я не прав?
Если однократный — то определяется только возможностями аппаратуры по скорости регистрации сигнала. Если регистрировать в память при ПЛИС — 8-12 Гбайт/с. Если регистрировать в память компьютера, то зависит от интерфейса связи. Для USB 3.0 это 300 Мбайт/с. На PCI-Express до 13 Гбайт/с.
А если интересует непрерывный режим — то тогда уже надо учитывать скорость обработки в Matlab. Надо что он успел обработать блок данных до прихода следующего.
По такой технологии можно обеспечить скорость передачи в Matlab до 13 Гбайт/с.
У нас сейчас нет готового решения для захвата видеопотока, но я готов обсудить такую задачу. Сделать можно.
Сразу возникает вопрос — в каких условиях НЕ эффективно использовать проектное управление?
Например взгляд на менеджера со стороны разработчика?
Например лично я считаю что менеджеры только мешаются в разработке.
Не надо говорить за весь мир, это не так.
Конечно есть специалисты, расскажут, покажут и возьмут деньги. Собственно это их работа, они как раз прекрасно зарабатывают деньги на теме проектного подхода. И это не единственный пример. Можно ещё вспомнить МММ. На этом тоже многие заработали.
Тоже хорошая мысль. Обсудим.
Рад стараться :-)
Может быть что то не так именно с проектным управлением?
Второй график можно интерпретировать так что половине компаний это оказалось совершенно не нужным. Но они не смогли отбиться от внедрения.
Самое интересное в нашей дискуссии это найти границы применения этого самого проектного подхода. Он не может охватить всё и везде быть эффективным. Так просто не бывает. Поэтому я считаю ложными утверждения о том что проектный подход (и в частности PMBoK) это наше всё и по другому нельзя работать.
Одно ограничение мы уже выяснили — это разделение операционной и проектной деятельности. Но оно тоже достаточно условно. В рамках операционной деятельности тоже могут выполняться проекты и достаточно сложные.
График показывает что предпочтительная область проектного подхода — это разработка с нуля. Но это достаточно редко. По сути — это создание новой компании для новой деятельности. В реальности все разработки идут на основе предыдущего опыта. У нас норма это 80-90% задела. Если меньше — скорее всего не заработает.
Тут тоже всё просто — если вы собираетесь платить за отработанное время, то люди будут вырабатывать время. Если за результат — будут вырабатывать результат. Если результат будет представлен в виде KPI — будут вырабатывать KPI.
Причём здесь есть обратная зависимость. Идеальное состояние это когда люди не работают а результат есть. Классический пример — это ремонтная бригада на заводе Форда. Они получали деньги когда сидели в комнате отдыха. Также и с программистами. Надо что бы они минимальными усилиями получи максимальный результат. Оплата за отработанные часы в проекте это самый худший вариант из всех.
Что такое уникальный? Если в проекте задействовано 10% наработок от предыдущих это уникальный проект? А если 90%? А можно сказать что операционной деятельностью компании является разработка новых проектов?
В примере компании действительно выполняются проекты но нет места проектному подходу. К обсуждению нового проекта и выработке плана реализации привлекаются наиболее квалифицированные разработчики. Они принимают решения о модификации исходной библиотеки (если необходимо). Далее оперативное руководство выполняют руководители подразделений.
Платить программистам по часам это ПРИНЦИПИАЛЬНО не правильно. В долгосрочной перспективе это приведёт к тому, что программисты будут вырабатывать человеко часы а не программы. И вместо оптимальных решений будут искать решения которые позволят им заполнить человеко часы на проекте. Про единую библиотеку можно забыть. Так что в долгосрочной перспективе (десятки лет) проектный подход вреден.
Признаю, я достаточно поверхностно знаю PMBoK, но я не вижу причин туда углубляться. Только потому что это модно?
Вопрос сложный, вполне может быть что я не прав. Но именно для этого и ведётся дискуссия. Мне по крайней мере интересно. Если вам тоже интересно — то можно продолжить. Пока что я не увидел хороших аргументов в защиту проектного подхода. Как только доходит до конкретных вопросов сразу идёт уход в сторону от ответа.
Давайте ещё раз рассмотрим гипотетическую ситуацию. Компания в течении долгого времени разрабатывает библиотеку. На основе этой библиотеки выполняются различные проекты для совершенно разных заказчиков. Где в этой структуре место для проектного подхода? Где место руководителя, где место программистов и главное — как и за что платить деньги программистам.
Но я подвергаю сомнению самые основы — откуда взялись эти цифры. Например с трудоёмкостями. Например можно посчитать поставленные задачи и выполненные. Получаем процент. Вот только чего? Задачи равнозначные? Или есть какая-то сложная задача и много мелких.
Но перед самой сдачей проекта средняя температура не имеет никакого смысла. Имеет значение только список не сделанных задач. Причём каждая задача требует индивидуальной оценки. А здесь мы опять возвращаемся к вопросу о квалификации руководителя проекта.