[twix 0]

6 hours ago, petrov said:

Удачная визуализация всегда сильно продвигает вперёд.

Это заблуждение.

Изменено 28 февраля, 2019 пользователем twix

[petrov 6]

twix

Например в образовании была попытка перехода в геометрии от графики и треугольников к чисто алгебраическому подходу, как результат дети перестали что-либо понимать. Посмотрите те же диаграммы Фейнмана в квантовой физике. Да миллион примеров можно привести. Заметьте как тяжело выучить новый язык и свободно писать на нём. А визуальная информация доступна сразу без знания чужого языка. Всё более очевиден кризис классического программирования, в исходниках такая тарабарщина, что понять ничего невозможно.

[Arlleex 131]

Только что, SVNKz сказал:

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

Диалог заказчика и исполнителя по алгоритму работы программы должен происходить по наглядно изложенному функциональному алгоритму, в котором ВСЕ требования заказчика изложены понятным и удобным для договаривающихся сторон виде. Это классика методики разработки программ подробно и грамотно изложена в учебниках. Умные и одарённые самоучки-энтузиасты пренебрегают изучением основ программирования и часто даже не знают о существовании такого рода области знаний и литературы.

Красиво и складно пишете.

Вы в идеальном мире заказчиков и разработчиков живете? Тогда да, верю, что заказчик должен выдвинуть сразу ВСЕ требования.

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

Уровень функциональности современных девайсов зависит на 90% от их ПО. Не в 70-х же все-таки живем, где логику работы забивали жестко рассыпухой и ставили шкафами мертвым грузом в подвалах лаборатории.

[warrior-2001 0]

Доброго времени суток!

Любое новшество всегда критикуется, причем обычно теми, кто с новшеством этим не знаком.

Единственное, что сдерживает бурный рост объектно-ориентированной разработки - это стоимость продукта.

Насколько помню - цена полного пакета далеко за 20 млн. рублей на одно рабочее место!

Зато скорость разработки и модификации алгоритма, верификации и выхода готового продукта на рынок увеличивается в разы!

Один минус - если на предприятии схемотехник не готов к тому, что разработчик ПО для ПЛИС начинает работать в 2-3 раза быстрее - готовый продукт не выйдет раньше, чем до этого! И если конструктор, схемотехник и программист не связаны единым сквозным маршрутом проектирования, то смысла покупать САПР для одного звена из всей цепочки нет - это деньги на ветер!

Для не особо верующих - в марте будет мероприятие по матлабу, симулинку и прочим прелестям. В прошлом году я на нем был, может и в этом смогу заскочить. Там не мало, как сейчас говорят, удачных примеров применения новых способов разработки в реальных проектах. И далеко не все примеры - разработка в интересах МО с неограниченными бюджетами ;)

В 2014 году я сам скептически относился к автоматической генерации кода. Сейчас - активно её пользуюсь в части ПЛИС и весьма доволен результатами.

[_pv 52]

45 minutes ago, petrov said:

twix

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

для обучения детей - пожалуйста, есть тот же scratch. ну или для hello world / моргания светодиодом от кнопки.

но вот по мере роста сложности пользы от этот никакой кроме вреда,

пока микросхемы были маленькие (ну или наоборот большие с точки зрения тех. процессов) их рисовали руками, а как оно начало расти, причём по экспоненте, пришлось придумывать языки описания.

[SVNKz 1]

1 hour ago, Arlleex said:

Красиво и складно пишете.

Сказанное "красиво и складно" описано в учебниках по дискретной математике...

[petrov 6]

_pv

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

 

[AlexandrY 3]

10 hours ago, Arlleex said:

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

1. Как встроить ее в проект, который крутится, например, под RTOS с LwIP и прочим middleware? Как подружить ее с уже написанным и отлаженным софтом (например, после определения команды с кнопки дать семафор планировщику, т.е. банально вызвать OS_SemGive())?

2. Если выхлоп из StateFlow получается модуль из двух файлов .h и .c, то, подключая их к своему проекту на злом уровне оптимизации, каков шанс, что оптимизатор не выкинет половину сгенерированного кода? А если выкинет, то как разобраться, почему он это выкинул, если код из матлаба читать не возможно (и, якобы, не надо)?

В сгенерированном исходнике можете увидеть две функции:
- ButtonService_initialize
- ButtonService_step

Обе помещаются в любую уже созданную или новую задачу.
Первая вызывается на старте задачи.
Вторая вызывается в цикле задачи.

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

После вызова ButtonService_step нужно собрать опять же из ее глобальных переменных все выходные данные и рассовать по остальным задачам. 
Т.е. непосредственно мой сниппет или в более общем виде модель в матлаб никак не связана с железом или архитектурой остального софта на микроконтроллере. 
Да, надо создать функции адаптеры для компоновки и передачи аргументов, а потом обратного приема результатов.
В таком маленьком сниппете, который показал это может быть не оправдано, но он на самом деле у меня часть гораздо большей модели. 
Из нее генерится около 200 кБ исходников. Адаптер для такой махины - мелочь. 

Исходник адаптера я не показал, он не важен. Кроме этого матлаб генерит еще пачку заголовочных файлов и свой файл адаптер под платформу.
Но адаптер матлаба я не использую. Он делается под конкретную плату, в данном случае был под плату с K64 и без RTOS.

Я же вставляю сорсы сгенерированные в Matlab в проект с RTOS c тысячами уже готовых файлов. Какая RTOS  - неважно, сколько уже там есть задач - не важно.
Важно часто бывает сделать профайлинг, но тогда помещаю фиксаторы меток времени перед и после вызова ButtonService_step и все. Дальше рулю в матлабе чтобы модель сгенерилась максимально быстрая. 

Сомнений в надежности и синтаксисе исходников из Matlab у меня нет никаких. Я всегда компилю с -O3, и проблем не фиксировал. Там еще можно сгенерить подробнейший отчет по исходникам в HTML формате, чтобы сдать его сертифицирующим органам. Т.е. кто хочет сертифицировать на критичные приложения тот просто вынужден использовать Matlab. 

Мой метод - это не уход в графическое программирование , как тут некоторые хотят представить.
На самом деле это гибридный текстово-графический фреймворк .
Без текстов и маленьких текстовых подпрограмм всей этой графике была бы грош цена. 
Самое ценное в StateFlow это его возможность рефакторить текст на диаграммах и искать места использования переменных и функций.
Визуальная пошаговая отладка с точками останова на ветвях и проч. фичами тоже очень мощный инструмент.

 

[_pv 52]

4 minutes ago, petrov said:

_pv

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

ага, ну то есть какое-нибудь арм ядро кортекс, например, надо понимать распространяется в таких вот "картинках" для желающих производить МК на его основе.

[RobFPGA 27]

Приветствую!

35 minutes ago, petrov said:

_pv

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

Попробуйте на досуге реализовать на Симулинке  например 10G PCS-PMA, MAC и TCP/IP стек в связке с scatter/gather DMA и PCIe контроллером - И так чтобы было ВСЕ на красивых stateflow диаграммах .  И на этих же диаграммах нарисуйте верификацию  всей этой красоты.  Думаю это будет покруче уровня картин писанных в Excel  

Средств автоматической генераций кода существует огромное множество - но каждый инструмент чаще всего заточен (оптимален) под определенный круг задач. И увы - нет идеального и универсального. Окромя грамотного разработчика который может выбрать каким инструментом наиболее оптимально решить ту или иную задачу. 

Удачи! Rob.

[petrov 6]

RobFPGA

Средств автоматической генераций кода существует огромное множество - но каждый инструмент чаще всего заточен (оптимален) под определенный круг задач. И увы - нет идеального и универсального.

Никто и не утверждает, что simulink для всех задач хорошо подходит.

[AlexandrY 3]

4 minutes ago, RobFPGA said:

Приветствую!

Попробуйте на досуге реализовать на Симулинке  например 10G PCS-PMA, MAC и TCP/IP стек в связке с scatter/gather DMA и PCIe контроллером - И так чтобы было ВСЕ на красивых state-flow диаграммах .  И на этих же диаграммах нарисуйте верификацию  всей этой красоты.  Думаю это будет покруче уровня картин писанных в Excel  

Ошибочное предположение здесь в том что исходник будет огромен. Нет, он будет компактней чисто текстового представления.
Ибо главный принцип - иерархичность и параллельность.
В тексте вы не видите иерархичности  поэтому текст воспринимается тяжелее.
Текст обрастает дополнительными артефактами, как то: структуры, классы, делегаты, модули... чтоб хоть как-то структурировать его в мозгу. 
Диаграммы же позволяют скрыть огромное количество мелочей отвлекающих внимание в чистом тексте. 
 

[RobFPGA 27]

Приветствую!

1 hour ago, AlexandrY said:

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

Увы - графическое представление не уменьшает количество сущностей в дизайне. Да - чуть нагляднее представить связи,  скрыть некоторые второстепенные. Но при этом привносит дополнительные так как навязывает вам некоторые шаблоны применения.  И если этих шаблонов не достаточно - то увы:   

1 hour ago, AlexandrY said:

На самом деле это гибридный текстово-графический фреймворк .
Без текстов и маленьких текстовых подпрограмм всей этой графике была бы грош цена

1 hour ago, AlexandrY said:

Текст обрастает дополнительными артефактами, как то: структуры, классы, делегаты, модули... чтоб хоть как-то структурировать его в мозгу. 
Диаграммы же позволяют скрыть огромное количество мелочей отвлекающих внимание в чистом тексте. 

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

 

Я в свое время много что делал только в графике. Но с ростом проектов как раз иерархичности в графике стало не хватать. То что можно было сделать в тексте парой строк  требовало в графике/диаграмме длительного тупого клацанья мышкой.

 

Но еще раз повторюсь  - хорошо когда есть возможность выбрать каким инструментом упростить себе жизни при разработке.  Хотя иногда это принимает забавные формы - видел большой проект в Matlab в котором скриптами в .m файлах генерировали кучу simulink диаграмм (в основном на примитивах!) чтобы потом HDL генератором перевести это в RTL.  

 

Удачи! Rob.

[warrior-2001 0]

1 час назад, RobFPGA сказал:

Приветствую!

Попробуйте на досуге реализовать на Симулинке  например 10G PCS-PMA, MAC и TCP/IP стек в связке с scatter/gather DMA и PCIe контроллером - И так чтобы было ВСЕ на красивых stateflow диаграммах .  И на этих же диаграммах нарисуйте верификацию  всей этой красоты.  Думаю это будет покруче уровня картин писанных в Excel  

Средств автоматической генераций кода существует огромное множество - но каждый инструмент чаще всего заточен (оптимален) под определенный круг задач. И увы - нет идеального и универсального. Окромя грамотного разработчика который может выбрать каким инструментом наиболее оптимально решить ту или иную задачу. 

Удачи! Rob.

Тут так скажу - использую симулинк пока только для задач ЦОС. И пока сажаю это дело либо на фифо, либо через ту же  AMBA AXI. А контроллер PCIe - это HARD IP блок у Интела, и занимает он всего навсего 1 блок в Симулинке, который интерпретируется в это самое ядро. Однако от необходимости настройки данного ядра ручками в Квартусе Симулинк никак не избавляет. Именно потому я и говорю о маршруте проектирования, а не об одном продукте.

[AlexandrY 3]

6 minutes ago, RobFPGA said:

Я в свое время много что делал только в графике. Но с ростом проектов как раз иерархичности в графике стало не хватать. То что можно было сделать в тексте парой строк  требовало в графике/диаграмме длительного тупого клацанья мышкой.

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

В чем еще помогает StateFlow так это избежать потерю контроля в многопоточности. 
Скажем обрабатываю я эту кнопку, а неподалеку есть еще группа кнопок управляющая другими режимами в той же системе. 
Работая в многозадачной среде я для всякой периферии выделяю отдельные задачи, если надо передаю туда через события или очереди.
Это такая редукция комплексности управления.
В этом случае легко забыть что-то передать в другую задачу чтобы не было конфликта режимов. 

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