[AlexandrY 2]

Проекты бывают разные, со своими тонкостями, но почему-то многие здесь, наплевав на тонкости, раздают идиотские советы типа "Cube и HAL" это для мигания лампочкой. Это просто признак низкого профессионализма, я так считаю.

Да ладно то к мелочам придираться, я ж искал по "DMR stack" . Примитивная 4-FSK модуляция. Там демодулятор не больше сотни строк.

lwIP конечно можно использовать, но достался он вам в виде рабочей демки. Сомнительная заслуга что он у вас работает на STM32.

Где собственно приложение плотно работающее с периферией?

 

 

 

 

[Quasar 18]

Да ладно то к мелочам придираться, я ж искал по "DMR stack" . Примитивная 4-FSK модуляция. Там демодулятор не больше сотни строк.

 

Какие у вас прекрасные познания. Да, весь протокол это примитивная 4FSK... Пять минут в гугле и все готово.

 

lwIP конечно можно использовать, но достался он вам в виде рабочей демки. Сомнительная заслуга что он у вас работает на STM32.

 

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

 

Упомянутому мною выше D-Link'у все коммутаторы и роутеры, видимо, достаются в виде работающей демки linux'а.

 

 

[let's see 0]

А лампочкой поморгать это safety critical? Как вообще лампочка связана с safety critical? Вообще удивительно какой бардак у многих в голове.

 

Ok, зайдем с другой стороны, как вы подтверждаете safety critical? Ваш софт проходит сертификацию на DO-178B, например, или вы просто по "пацанский зуб даете"?

 

Какой-нибудь управляемый L2 коммутатор D-link или soho роутер от них же, ни разу не лампочкой поморгать, но в нем скорее всего обычный линукс. И там это решение вполне оправдано, так как там не стоит задачи в спец. сертификации. А вот на бортовом вычислителе боинга 737 вы линукс не встретите, и не потому, что он сильно сложнее, а потому, что сделав вычислитель на линукс вы упашетесь его сертифицировать и доказывать что оно надежно. Потому что в настоящем safety critical надо доказывать, а не просто трындеть.

 

Если проект подразумевает safety critical с соответствующей сертификацией, то он подразумевает и соответствующее количество трудочасов и денег на него. В рамках этого проекта, естественно, разумно выделить группу для написания надежной замены ST'шному HAL'у. С которой потом, можно будет пройти все сертификации. А когда у вас задача спроектировать железку без доп. требований по надежности, а вы все равно тратите время на перепись HAL'а, полагая (почему-то?), что ваш быдло код лучше "индусского", вы просто разбазариваете время и деньги, отвлекаясь от основной задачи.

Следую мудрым советам:

“Never argue with an idiot. They will drag you down to their level and beat you with experience.”

― Mark Twain

[Quasar 18]

Следую мудрым советам:

“Never argue with an idiot. They will drag you down to their level and beat you with experience.”

― Mark Twain

 

Да-да. При этом, судя по вашим последним сообщениям на форуме, вы считаете нужным влезать в обсуждения с одним единственным советом "не использовать Cube, HAL, SPL". Какие еще цитаты приведете по этому поводу?

 

 

[Darth Vader 0]

По поводу быстродействия кода, написанного с помощью CubeMX, HAL, SPL, а также применения ОС в микроконтроллерах - хороший пример - управление электродвигателями. Вот интересная статья про это. Вот вторая - про отечественный микроконтроллер К1921ВК01Т от НИИЭТ и про решение задачи управления двигателем на нём.

Если коротко, то

В-четвертых, никаких операционных систем! Можно предвидеть, как у некоторых в голове крутится мысль «ну раз у вас такая сложная задача, поставьте нормальный микроконтроллер с Linux и пишите под него обычные приложения, обновляя ПО с флешки». Системы управления силовым оборудованием – системы очень жесткого реального времени. Не то что Linux, даже не все специализированные ОС реального времени подходят для таких задач. Например, прерывание АЦП по считыванию и усреднению аналоговых данных может вызываться с частотой до 100кГц. При этом оно будет содержать всего десяток-другой строк кода – сбор данных аналоговых каналов, пара проверок быстродействующих защит и выход – всё, больше ничего не успеть. Если поручить такое прерывание какому-нибудь планировщику задач ОС, то просто его собственное выполнение будет занимать больше ресурсов. Не говоря уже о том, что, в частности, для Linux вместо одной микросхемы МК на плату надо поставить еще две – внешнюю оперативную и флеш-память, отведя на них кучу драгоценных ножек кристалла, использовать шестислойную плату для правильной разводки, получить огромное время загрузки МК (иногда при сбое питания или срабатывании сторожевого таймера надо начать работу раньше, чем двигатель успел остановиться!), иметь проблемы с целостностью файловой системы и прочее.

Также есть ряд продуктов, позволяющих «рисовать» программы непосредственно для микроконтроллеров. В том числе тот же Matlab умеет генерировать Си-код для МК именитых брендов на основе модели в Simulink. Якобы можно нарисовать и отладить нарисованную структуру системы управления на компьютере в модели, а потом загрузить в МК – и готово, поехали! И даже такие среды позволяют отлаживать нарисованные структуры управления прямо внутри МК, смотреть переменные и т.п., а на сайтах таких продуктов есть куча демо-проектов для самых сложных систем, «запрограммированных» таким образом. Но так как все реальные проекты до сих пор почему-то программируют «руками», то можно догадаться, что с «рисованием» что-то не так. Но тут даже сложно описать, что именно, когда не так – всё. Главный аргумент против – это отсутствие полного контроля над происходящим внутри МК. Вы нажимаете кнопку в такой среде «сделать хорошо» и надеетесь, что генератор кода сделает за вас всё остальное. Для каких-то простых систем, где производительности МК «за глаза», сроки разработки очень поджимают, а программировать на фирме, которая взялась за проект, никто не умеет… то да, наверное, можно попробовать «нарисовать» программу. Но если она не заработает как надо, или будет иметь какой-то очень специфический глюк, то отладить её уже не будет никакой возможности. А для сложной задачи, где даже при программировании руками с производительностью МК всегда проблемы, рисование не подходит просто по причине нехватки ресурсов – любой язык программирования, чем он более высокоуровневый (куда уж выше рисования), генерирует менее оптимальный машинный код. А низкоуровневые оптимизации, которые сделал бы программист на Си, такая система сделать не сможет (расчет блоков одной структуры с разным тактированием, использование закешированных значений синуса и косинуса, замена функций деления на умножение на заранее подготовленную величину, или совсем уж хитрые вещи типа таких и т.п.).

...

Таким образом, приходится писать свой софт, и писать на Си. И отлаживать свой софт так или иначе надо, и надо на объекте. Наверное, к этому месту статьи все уже поняли, что отладить структуру управления можно только просмотром осциллограмм внутренних переменных, т.е. просмотром графиков во времени, как меняется та или иная переменная на Си – скажем, «выход вот того блока, пятого слева, одновременно с входами третьего справа».

...

И сделать это можно только средствами самого микроконтроллера. Нельзя просто взять и поставить внешний быстрый интерфейс связи и посылать «наверх» значение какой-то переменной, так быстро, как только можно, а уже в системе верхнего уровня строить график. Потому что ни один интерфейс связи МК не успеет сделать это с той частотой, с которой протекают регулируемые переходные процессы. А если успеет, то все ресурсы МК уйдут на обслуживание этого интерфейса связи. Поэтому делают так – записывают осциллограмму в оперативную память МК, просто в массив.

Понятно, что не всегда и не везде так жёстко со временем, но, просто, как один из реальных примеров. Причём не из области военной техники, управления оружием, типа маневрирующей гиперзвуковой боеголовки Ю-71 ракетного комплекса "Сармат" в атмосфере на скоростях 5-7 км/с, или случаев, подлежащих обязательной сертификации. Это обычная промышленная задача, решаемая для управления лифтом, троллейбусом, трамваем, электровозом, карьерным самосвалом или тепловозом с электрической передачей.

[AlexandrY 2]

... - хороший пример - управление электродвигателями.

вторая - про отечественный микроконтроллер К1921ВК01Т от НИИЭТ и про решение задачи управления двигателем на нём...

У меня приличных слов нет про эту статью..

Сплошное нагромождение мифов.

 

[Quasar 18]

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

 

А вы уверены, что это «обычное» ПО, и не подлежит сертификации?

 

 

 

[Aleksandr Baranov 1]

 

В-четвертых, никаких операционных систем! Можно предвидеть, как у некоторых в голове крутится мысль «ну раз у вас такая сложная задача, поставьте нормальный микроконтроллер с Linux и пишите под него обычные приложения, обновляя ПО с флешки». Системы управления силовым оборудованием – системы очень жесткого реального времени. Не то что Linux, даже не все специализированные ОС реального времени подходят для таких задач. Например, прерывание АЦП по считыванию и усреднению аналоговых данных может вызываться с частотой до 100кГц. При этом оно будет содержать всего десяток-другой строк кода – сбор данных аналоговых каналов, пара проверок быстродействующих защит и выход – всё, больше ничего не успеть. Если поручить такое прерывание какому-нибудь планировщику задач ОС, то просто его собственное выполнение будет занимать больше ресурсов. Не говоря уже о том, что, в частности, для Linux вместо одной микросхемы МК на плату надо поставить еще две – внешнюю оперативную и флеш-память, отведя на них кучу драгоценных ножек кристалла, использовать шестислойную плату для правильной разводки, получить огромное время загрузки МК (иногда при сбое питания или срабатывании сторожевого таймера надо начать работу раньше, чем двигатель успел остановиться!), иметь проблемы с целостностью файловой системы и прочее.

 

 

Off topic: https://pikabu.ru/story/sovetskie_inzhenery...ezhdali_2414570

Изменено 25 февраля, 2018 пользователем Aleksandr Baranov

[Darth Vader 0]

Как-то делал проект в фирме, занимающейся театральным оборудованием. Я там был в качестве схемотехника. Были ещё трое технарей - два конструктора и программист. Там решались задачи сценической механики - подъём сцены, её поворот, движение лебёдки, движение софитов и т.п. По разговорам с ними я понял, что никакой сертификации КД и ПО там нет и в помине. Более того, сертифицировать, по-сути там нечего. Т.к. на сертификацию направляется полный комплект КД, включая ЭД, ПД, если она есть. Ничего такого там просто нет. Нет учтённого комплекта КД. Требования ЕСКД и ЕСПД там игнорируются, нормоконтроль отсутствует. ГОСТы по разработке, регламентирующие этапы разработки, количество партий приборов и объёмы испытаний - нет, не слышали. Вернее слышали и знаем, но сознательно игнорируем - это слишком долго и дорого. Т.е. случись чего - концов не найдёшь. Ни программ, ни схем. Они где-то у кого-то на компьютерах и неизвестно насколько соответствуют реальному железу. А если увольняется ключевой разработчик - то и этого может не остаться.

[let's see 0]

Да-да. При этом, судя по вашим последним сообщениям на форуме, вы считаете нужным влезать в обсуждения с одним единственным советом "не использовать Cube, HAL, SPL". Какие еще цитаты приведете по этому поводу?

Я считаю полезным высказывать свое мнение. Прислушиваться к нему или нет личное дело каждого. А вот и подходящая цитата:"You can lead a horse to water, but you can't make it drink".

[Quasar 18]

Как-то делал проект в фирме, занимающейся театральным оборудованием.

 

 

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

 

 

 

 

 

 

Я считаю полезным высказывать свое мнение.

 

А любого, кто аргументировано возражает вашему мнению, вы считаете нужным назвать идиотом. Лечитесь, мой вам совет.

[let's see 0]

А любого, кто аргументировано возражает вашему мнению, вы считаете нужным назвать идиотом. Лечитесь, мой вам совет.

Аргументы у каждого свои. А далее, см. приведенную выше цитату Марка Твена.

[Darth Vader 0]

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

Но технические стороны вопроса от этого не меняются. В любом случае, это задача управления электродвигателем. Что для электромобиля, что для лифта, что для сцены.

[AlexandrY 2]

Но технические стороны вопроса от этого не меняются. В любом случае, это задача управления электродвигателем. Что для электромобиля, что для лифта, что для сцены.

Но вы хоть различаете BLDC двигатель от скажем AC или шаговика и в курсе что у них могут быть принципиально разные алгоритмы управления?

И задачи там могут на порядок отличаться по сложности.

Давайте ближе к конкретике если есть что сказать.

[juvf 10]

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

Абсолютно одинакового. Что ПО для авиации (как для гражданской, так и для военной), что ПО для автоматической поливки комнатных цветов - пишется абсолютно одинакового. Или кто-то для военной авиации использует годный софт, а для гражданской глючный? Кто-то для кухонных весов использует заведомо глючный компилятор? Или в коде для гражданской авиации можно на ноль делить?