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

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

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


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


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

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


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

Мелкие функций типа подавления дребезга я реализую в блоках S-function на C-и.
А использовать Stateflow для такой ерунды вас заставляет скорее всего корпоративные правила.
Но это неэффективная потеря времени.

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

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

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

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

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

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

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


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

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

Так Буратино правильно и сказал - "Сложные люди". В данной теме есть несколько людей которые пишут свои программы сами - от начала и до конца. И полностью отвечают за их разработку. Таким людям не нужны системы контроля версий и баг треккеры и вообще лучше, чтобы никто не мешал - это такие одиночки. У них есть свой определенный стиль и сложившиеся подходы к разработке своего ПО. Я знаю, я сам таким был.
Но проблема в том, что начиная с определенных размеров проекта в одиночку проект не поднять никак. Нужно разделять работу между разными людьми (и у каждого свой подход) и в конце концов их направлять в нужное русло, чтобы они там не напилили бог знает что.
И вот тут приходит понимание и SVN и баг-трекеров и самое главное, что начинаешь понимать и свои ошибки в прошлом, как одиночника. Вспоминаешь, как днями в одиночку крутил танцы с бубнами вокруг своего же софта, пытаясь заставить его работать, а теперь понимаешь, сколько времени терял впустую - сейчас я ни одному своему программисту такого просто не позволяю. Также начинаешь понимать, что есть продукты, которые действительно значительно повышают производительность труда и уменьшают вероятность ошибок, а есть и такие, что нет. В одиночку такие вещи даже и не узнать, так как времени на обучение попросту нет, ведь "Индивидуальные разработчики работают гораздо быстрее", а заставить кого-либо позаниматься и поизучать продукт - индивидуальному разработчику попросту некого.
Вот сидит мне AlexandrY и доказывает, что Матлаб/Симулинк - это фигня для эмбеддера, а я прихожу на совещания MAAB и общаюсь там с чуваком, который говорит, что у БМВ что-то вроде 150 лицензий на Embedded Coder, и думаю WTF? И думаете они там на 8-и битных контроллерах не программируют?

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

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

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

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


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

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

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

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


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