Ну собственно заголовок объясняет всё. И для инженеров связанных с цифровой электроникой здесь всё абсолютно понятно. Есть огромная сфера деятельности, востребованная в современном мире и которую надо объяснять детям.
Теоретически есть возможность подключения. Надо использовать внешний преобразователь из 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.
Причём здесь есть обратная зависимость. Идеальное состояние это когда люди не работают а результат есть. Классический пример — это ремонтная бригада на заводе Форда. Они получали деньги когда сидели в комнате отдыха. Также и с программистами. Надо что бы они минимальными усилиями получи максимальный результат. Оплата за отработанные часы в проекте это самый худший вариант из всех.
Ну собственно заголовок объясняет всё. И для инженеров связанных с цифровой электроникой здесь всё абсолютно понятно. Есть огромная сфера деятельности, востребованная в современном мире и которую надо объяснять детям.
Это просто недостаточно.
Вот поэтому и надо быть рядом. Что бы передать знания.
Ссылки в разделе "Готовое решение" - "вот" и "эта" - не работают. Поправьте пожалуйста, хотелось бы на них посмотреть.
Хороший обзор. Спасибо.
Это общая проблема работы с 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.
Причём здесь есть обратная зависимость. Идеальное состояние это когда люди не работают а результат есть. Классический пример — это ремонтная бригада на заводе Форда. Они получали деньги когда сидели в комнате отдыха. Также и с программистами. Надо что бы они минимальными усилиями получи максимальный результат. Оплата за отработанные часы в проекте это самый худший вариант из всех.