[syoma 1]

Stateflow не часть Simulink-а, а только один из его тулбоксов.

Все тулбоксы имеют в себе блоки с оригинальными алгоритмами, потому они и ценны, вне связи с матлабом. А вот Stateflow пустышка.

Ну вот установили Вы Simulink Real-Time на свою target машину или робота. А дальше что? Как вы собираетесь для нее алгоритмы программировать?

Вот картинка тулбокса Simulink Real-time. Вы видите в нем "оригинальные алгоритмы", чтобы чем-то управлять?

По поводу пустышки советую заглянуть в Examples. Различные Automotive и Redundancy примеры там не просто так, а скопированы из живых реализаций.

У нас в проекте в Stateflow крутится наверное под сотню автоматов состояний, начиная от простой логики для устранения дребезга контактов и всяких Do Not Beleive It обработок, до менеджмента аварийных ситуаций и выбора режимов работы. Stateflow как раз задает состояние контроллера в той или иной ситуации и подает сигналы на Симулинковские модели, активируя и деактивируя нужные подсистемы.

 

 

 

[haker_fox 61]

Ну, я просто не представляю себе, как это будет работать. malloc/free на статическом массиве?

Да без проблем! Гляньте исходный код этих функций :rolleyes:

 

Ну как без mmu каждой задаче выделить свой блок памяти, чтобы не было конфликтов?

Батенька, да вы всё перемешали в кучу :rolleyes: Что делает malloc? Предоставляет вам указатель на память запрошенного размера. Ну, как вы эту память получите (выделите) дело десятое. Алгоритмов выделения - море. MMU вам только поможет склеить память в одно линейное пространство из разбросанных кусков, да сгенерит исключение, если кто-то захочет попортить её.

Ещё раз: посмотрите исходники аллокаторов. Их море. Хотябы в тойже "недоси" FreeRTOS. Их там 4 штуки (всего 5, но одна просто обёртка над "стандартными").

 

А под фигней я понимаю всяких кастратов вроде микрортосей и uClinux'ов.

Вы такую фигню сначала создайте сами. Или даже попроще, что-то на подобии scmRTOS, FreeRTOS, us/OS. А потом посмотрим, сможете ли назвать это "фигней", т.к. поймёте, что там не два пальца об... а вполне себе теория, по которой книжки написаны :rolleyes:

 

[AlexandrY 3]

Вот картинка тулбокса Simulink Real-time. Вы видите в нем "оригинальные алгоритмы", чтобы чем-то управлять?

 

У нас в проекте в Stateflow крутится наверное под сотню автоматов состояний,

Вот алгоритмы -

 

Собственно из-за них matlab и нужен.

 

Мелкие функций типа подавления дребезга я реализую в блоках S-function на C-и.

А использовать Stateflow для такой ерунды вас заставляет скорее всего корпоративные правила.

Но это неэффективная потеря времени.

[Eddy_Em 2]

Вы такую фигню сначала создайте сами.

Мне и так нужно за год столько понаписать, что думаю — на что бы такое забить!

А уж нафиг не нужную неведомую фигню писать — так вообще смысла нет! Мне ртось не нужна.

[syoma 1]

А использовать Stateflow для такой ерунды вас заставляет скорее всего корпоративные правила.

Но это неэффективная потеря времени.

Ну знаете :rolleyes: я был у истоков запуска матлаба/симулинка/стейтфлоу в нашей далеко не самой мелкой фирме, которая является номером 3 на рынке HVDC/FACTS, если это что-то говорит вам о сложности программ.

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

Мелкие функций типа подавления дребезга я реализую в блоках S-function на C-и.

Ну а у меня для этого вообще не нужен Си-программист.

 

[AlexandrY 3]

Ну знаете :rolleyes: я был у истоков запуска матлаба/симулинка/стейтфлоу в нашей далеко не самой мелкой фирме, которая является номером 3 на рынке HVDC/FACTS, если это что-то говорит вам о сложности программ.

 

О трудоемкости говорит, а о сложности ничего не говорит.

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

Ну по крайней мере пока их не стал писать ИИ.

 

Род ваших занятий серьезен и важен для человесчества, но...

Вы работаете в крупной компании где понятия не имеют что значит работать быстро.

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

Настолько интенсивно там просиживают штаны.

 

Потому рекомендации с вашей позиции выглядят наивно.

Индивидуальные разработчики работают гораздо быстрее и корпоративные подходы им не годятся, типа "у меня нет даже программиста на C-и"

 

[zltigo 2]

Потому рекомендации с вашей позиции выглядят наивно.

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

 

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

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

[slavka012 0]

Ну как без mmu каждой задаче выделить свой блок памяти, чтобы не было конфликтов?

По моему вы просто не понимаете, что такое mmu и как работает malloc.

[syoma 1]

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

Так Буратино правильно и сказал - "Сложные люди". В данной теме есть несколько людей которые пишут свои программы сами - от начала и до конца. И полностью отвечают за их разработку. Таким людям не нужны системы контроля версий и баг треккеры и вообще лучше, чтобы никто не мешал - это такие одиночки. У них есть свой определенный стиль и сложившиеся подходы к разработке своего ПО. Я знаю, я сам таким был.

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

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

Вот сидит мне AlexandrY и доказывает, что Матлаб/Симулинк - это фигня для эмбеддера, а я прихожу на совещания MAAB и общаюсь там с чуваком, который говорит, что у БМВ что-то вроде 150 лицензий на Embedded Coder, и думаю WTF? И думаете они там на 8-и битных контроллерах не программируют?

[haker_fox 61]

А уж нафиг не нужную неведомую фигню писать — так вообще смысла нет! Мне ртось не нужна.

Ну чтож, выбор за вами. Словам "нафиг" и "фигня" говорят сами за себя: Пастернака не читал, но осуждаю)

[slavka012 0]

Так Буратино правильно и сказал - "Сложные люди". В данной теме есть несколько людей которые пишут свои программы сами - от начала и до конца. И полностью отвечают за их разработку. Таким людям не нужны системы контроля версий и баг треккеры и вообще лучше, чтобы никто не мешал - это такие одиночки. У них есть свой определенный стиль и сложившиеся подходы к разработке своего ПО. Я знаю, я сам таким был.

Даже работая в одиночку нужна система контроля версий и желательно багтрекер тоже :)

 

[syoma 1]

Даже работая в одиночку нужна система контроля версий и желательно багтрекер тоже :)

Я о том и говорю, что понимание этого приходит только с развитием. А ко многим одиночкам не приходит вообще. Такое же принятие/отторжение происходит и со многими другими подходами и технологиями, типа использование/неиспользования РТОС, ММU, Матлаба, или 8-и/32-х битных контроллеров, что и видно из данной темы.

[Grizzly 0]

Даже работая в одиночку нужна система контроля версий и желательно багтрекер тоже :)

+1. Только в России никто переучиваться не хочет. Как привыкли 30 лет назад работать, так и будут до конца дней :) Пример syoma очень показателен. Заграницей просто выгонят с работы, а у нас, если чудом такое случится, найдут еще более дурного работодателя, у которого можно продолжать работать своими древними методами.

 

Мне и так нужно за год столько понаписать, что думаю — на что бы такое забить!

А уж нафиг не нужную неведомую фигню писать — так вообще смысла нет! Мне ртось не нужна.

Жалко, что никто не сказал, что RTOS дисциплинирует. Когда тебе достается проект в несколько десятков тысяч строк (на самом деле это не показатель) совершенно без документации, в котором реализованы свои конечные автоматы, очереди FIFO/LIFO, тратится безумное количество времени, чтобы понять, как это работает. Если вообще возможно понять это полностью.

[slavka012 0]

+1. Только в России никто переучиваться не хочет. Как привыкли 30 лет назад работать, так и будут до конца дней :) Пример syoma очень показателен. Заграницей просто выгонят с работы, а у нас, если чудом такое случится, найдут еще более дурного работодателя, у которого можно продолжать работать своими древними методами.

Та не только...

 

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

[Grizzly 0]

Та не только...

Мне казалось, что это у нас так плохо. Самое обидное, что не только в НИИ и прочих гос. предприятиях, но и во многих частных компаниях, выполняющих гос. заказы. Казалось бы, все карты в руки. Ан нет...

 

Потом обанкротились, конечно )

Естественный отбор :)