[syoma 1]

@AlexandrY, вы же были ярым противником автоматической генерации кода, помните как мы спорили?

Что же поменялось?

Для примера, как программировать по новому. Вот этот проект для домашней автоматизации я наваял за пару вечеров, промоделировал в симулинке и запустил в реальном времени на codesys+Raspberry Pi. Уже крутится 2 года. Ввод/вывод через EtherCAT. Там код был в IEC61131-3, но Си или HDL получился бы на ура. В итоге ни одной строчки кода.

Сам контроллер:

Модель для его проверки:

Блок, импортированный в Codesys:

[AlexandrY 2]

1 hour ago, syoma said:

@AlexandrY, вы же были ярым противником автоматической генерации кода, помните как мы спорили?

Что же поменялось?

Для примера, как программировать по новому. Вот этот проект для домашней автоматизации я наваял за пару вечеров, промоделировал в симулинке и запустил в реальном времени на codesys+Raspberry Pi. Уже крутится 2 года. Ввод/вывод через EtherCAT. Там код был в IEC61131-3, но Си или HDL получился бы на ура. В итоге ни одной строчки кода.

Я бы и сейчас поспорил с вашим способом программировать в Simulink.
Codesys я не рассматриваю как серьезную среду для хостинга сложных программ.
Когда же вы говорите, что спокойно бы ее портировали без строчки кода на С, то лукавите.   

А я говорю именно за сложные программы написать и поддерживать которые на C или C++ просто нереально трудно. 
Такие в Simulink-е невозможно изобразить поскольку в его моделях не видно состояний. 
Состояния видны в StateFlow, но вы предпочли в Stateflow рисовать состояния светодиода, а не системы целиком. Вот в чем юмор. 

Т.е .на самом деле  вы не готовы именно программировать в новом стиле. 

[syoma 1]

46 minutes ago, AlexandrY said:

Я бы и сейчас поспорил с вашим способом программировать в Simulink.

Это всего лишь пример решения конкретной задачи, а не весь способ программирования в Simulink. Ессно есть и другие варианты работы с Simulink

Я уже писал в других темах, что у нас есть проекты, занимающие по 30% от Virtex-6 целиком сделанные на Simulinke и HDL Coder. И там сложные ЦОС, защита и управление силовой электроникой. Есть и System Generator - где DMA драйвер для PCIе нарисован.

Quote

Когда же вы говорите, что спокойно бы ее портировали без строчки кода на С, то лукавите.

Я не лукавлю, а говорю, что нажав другую кнопочку в контектсном меню я могу сгенерить те же Cи функции init() и step(), как и у вас, для почти любого любого МК и без переделки модели вообще и они будут делать то же самое, что и  в Codesys. Только пины надо будет расключить на входы/выходы контроллера и написать оболочку while(1) {....

 

 

[SVNKz 1]

 

25 minutes ago, AlexandrY said:

Я бы и сейчас поспорил с вашим способом программировать в Simulink.

  Разработанные таким "способом" программы не для серьёзных задач. 

[AlexandrY 2]

53 minutes ago, syoma said:

И там сложные ЦОС, защита и управление силовой электроникой. Есть и System Generator - где DMA драйвер для PCIе нарисован.

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

53 minutes ago, syoma said:

Я не лукавлю, а говорю, что нажав другую кнопочку в контектсном меню я могу сгенерить те же Cи функции init() и step(), как и у вас, для почти любого любого МК и без переделки модели вообще и они будут делать то же самое, что и  в Codesys.

Не будут, ну что вы сочиняете. Где у вас на bareboard возьмется EtherCAT, да хотя бы CAN? 
 

[syoma 1]

1 hour ago, AlexandrY said:

Кем нарисован?  Если это была толпа программеров и года работы, то такое не интересно.

Человеком, который не знает ни VHDL ни Verilog, но понимает, как работает FPGA. А сделано гораздо быстрее, чем года работы трушных ПЛИСоводов. Заценено, кстати, ими самими.

Quote

А ЦОС сложные пока их не понимают, а так ЦОС алгоритмы - мелочь по физическим размерам. 

Смешно, но понимание ЦОС часто приходит только после того, как эти алгоритмы хорошенько промоделируешь в том же Симулинке. И потом возникает логичный вопрос - ну и как это запустить на реальном железе, не переписывая все на Си с нуля? Вот так и появилась автоматическая генерация кода.

1 hour ago, AlexandrY said:

Т.е. меня это все не впечатляет, я речь веду о быстрой технологии программирования, а не о том что в чем в принципе можно сделать.  Вы хоть понимаете, что в этом суть нашего спора?

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

1 hour ago, AlexandrY said:

Не будут, ну что вы сочиняете. Где у вас на bareboard возьмется EtherCAT, да хотя бы CAN? 

Мы же говорим об управляющем алгоритме, или о чем? Вы ждете каких-то чудес от матлаба? Конечно, там нет ни драйверов, ни интерфейсных блоков. А еще в моей программе, чтобы ее запустить на МК, надо еще бы драйвер АЦП прикрутить, чтобы получать измерения температуры каждый цикл.

И, кстати, в некоторых моих пректах тратится примерно по полгода человековремени, чтобы как раз написать все эти драйвера для bareboard, но чтобы потом можно было запускать сгененрированный из Симулинковской модели код за пару минут после перекомпиляции. И это все потом работает на реальном железе у клиентов и управляет очень критичными вещами.

Я вот сейчас занимаюсь почти тем же самым для нового проекта  - делаю Simulink Runtime для STM32F4XX на RTOS, с драйвером нескольких CANopen, SPI и еще некоторыми плюшками. А сам алгоритм у меня уже давно в Симулинке промоделирован и работает. Причем с красивым GUI - моторчики крутятся, лампочки загораются, модель объекта управления со всевозможными неисправностями, можно самому на кнопочки понажимать и посмотреть, что произойдет - клиент просто тащится.

 

[AlexandrY 2]

1 hour ago, syoma said:

Я вот сейчас занимаюсь почти тем же самым для нового проекта  - делаю Simulink Runtime для STM32F4XX на RTOS, с драйвером нескольких CANopen, SPI и еще некоторыми плюшками. А сам алгоритм у меня уже давно в Симулинке промоделирован и работает. Причем с красивым GUI - моторчики крутятся, лампочки загораются, модель объекта управления со всевозможными неисправностями, можно самому на кнопочки понажимать и посмотреть, что произойдет - клиент просто тащится.

Ладно, убедили. Тогда дружим. 

Пора сделать раздел по новому способу программирования. 

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

[syoma 1]

37 minutes ago, AlexandrY said:

Пора сделать раздел по новому способу программирования. 

Я предлагал уже.

Не заценили, наверное не дошли еще. 

[syoma 1]

17 hours ago, AlexandrY said:

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

Лично мне не приходилось сталкиваться, так как я не сторонник распределенных систем управления. CAN для меня - это чисто I/O, моделируемый какой-то задержкой, а весь алгоритм исполняется на центральном процессоре.

Но народ с аналогичной задачей сталкивался и там все атоматы забивались в отдельные subsystem, которые размножались програмно исходя из параметра. Т.е связь была через Simulink, а не прямо в Stateflow.

[des00 25]

Интересная тема, в свое время забросил, надо снова заняться)

[AlexandrY 2]

On 3/6/2019 at 11:25 AM, syoma said:

Лично мне не приходилось сталкиваться, так как я не сторонник распределенных систем управления. CAN для меня - это чисто I/O, моделируемый какой-то задержкой, а весь алгоритм исполняется на центральном процессоре.

Но народ с аналогичной задачей сталкивался и там все атоматы забивались в отдельные subsystem, которые размножались програмно исходя из параметра. Т.е связь была через Simulink, а не прямо в Stateflow.

Мысль понял. 
Про CAN спросил коряво, я тож еще  не создаю в одном проекте программу для всех микроконтроллеров в системе за раз. Хотя мысль интересная.  
Я скорее имел в виду аналоги подпрограмм в диаграммах.
Если создавать диаграммы по каждой на свою назовем задачу (задача здесь -  некий  обособленный автомат состояний) то matlab нагенерит кучу повторяющихся кусков кода. 
В Simulink есть штатные блоки, которые автоматом определяют сколько переменных во входном потоке и размножают соответственно свой выход.
Это будет выглядеть в коде как превращение переменных в массивы.  
И тут подумалось, может и диаграммы StateFlow так могут. Подал им вектор вместо скаляра и они превратят все переменные в массивы и состояния также станут массивами состояний.     Но наверно размечтался.    
Подход видимо в том что надо делать шаблонные диаграммы, а потом их копировать столько раз сколько максимально будет переменных во входном векторе событий. 
А затем делать диспетчеры событий для рассылки по шаблонным диаграммам и собирания с них обратной реакции.    
Шаблонные диаграммы не хотелось бы использовать так как при отладке шаблонов трудно понять с каким конкретно экземпляром имеешь дело.
Тут надо копать отладочные возможности matlab-а    
  

[syoma 1]

17 minutes ago, AlexandrY said:

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

Не всегда. Это зависит от оптимизаций. Может сделать кучу повторяющихся кусков, а может сделать многократно используемую функцию. Вроде для этого надо, чтобы автоматы были из библиотеки. https://www.mathworks.com/help/stateflow/ug/tutorial-reusing-a-state-multiple-times-in-a-chart.html

17 minutes ago, AlexandrY said:

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

Если вы говорите о мультиплексировании, то да, но это не делает их более эффективными. Просто один и тот же код прогоняется столько раз, сколько мультиплексированных потоков данных у вас есть. Но это в случае генерации Си-кода. В HDL интереснее - там можно выбирать между скоростью и площадью. Т.е. если нужна скорость, то симулинк сгенерит столько копий одной и той же логики, сколько потоков. А если экономить на площади, то тогда одна и та же логика будет мультиплексироваться, но она тогда должна работать в n-раз высокой частоте.

Quote

И тут подумалось, может и диаграммы StateFlow так могут. Подал им вектор вместо скаляра и они превратят все переменные в массивы и состояния также станут массивами состояний.     Но наверно размечтался.    

Может и могут, я не пробовал. Но для этого они также должны уметь мультиплексировать свое состояние. А об этом чего-то не написано в документации

[Kluwer 0]

Совершенно аналогичная штука - это DSPbuilder для Моделсима. И да, уже много лет её использую для разработки блоков обработки сигналов под ПЛИСины. Причём, это реально удобно, если, например, сравнивать с моделированием в том же Modelsime/Questasim'е.

Преимущества:

1) графическое представление для человека завсегда удобнее "сухого" кода;

2) нативная интеграция с Матлабом (тут же можно вручную или с помощью скриптов сопоставить результат моделирования с теоретическим, расчитать всякие хар-ки, типа, статистик, спектров и т.д.);

3) простота замены блоков/смены параметров, импорта внешнего кода, матлабовских скриптов, короче юзер-френдли среда.

Но есть и недостатки:

1) графика даже относительно небольших блоков может легко не вместиться даже в 2 экрана;

2) очень медленно (Матлаб всё-таки). У меня, например, сжатие на базе альтеровских БПФ на длине 3х-4х-зондирований - уснуть можно;

3) довольно неудобное отображением цифровых данных;

4) сложно документировать и передавать такой проект: DSPbuilder генерит громоздкий и слабочитаемый код. Руками этот код сопровождать сложно, а разрабов, владеющих Матлабом/Симулинком, мягко говоря, не много;

5) моделировать реально только куски (пусть и важные). Загнать туда реально большую систему (например, тракт радиолокатора от ацп до MTI-фильтров хотя бы - а это не так и много) - не реально. Если вы даже её и нарисуете и по-блочно отладите, то потом умрёте ждать рез-ов моделирования. Уже проще в живом железе собрать.

Вот какие-то такие у меня впечатления от подобных штучек.

[AlexandrY 2]

33 minutes ago, Kluwer said:

Совершенно аналогичная штука - это DSPbuilder для Моделсима.

Опять 25. 
Почему так сложно понять разницу между потоковой обработкой и диаграммами состояний? 

 DSPbuilder  - это потоковая обработка. Таким способом нельзя спроектировать логику верхнего уровня, на вашей диаграмме не видно состояний. Это не то.  

[Kluwer 0]

3 minutes ago, AlexandrY said:

Опять 25. 
Почему так сложно понять разницу между потоковой обработкой и диаграммами состояний? 

 DSPbuilder  - это потоковая обработка. Таким способом нельзя спроектировать логику верхнего уровня, на вашей диаграмме не видно состояний. Это не то.  

Вы просто не понимаете, что такое DSP builder.