Quasar

Хорошо, но где-то требования к надежности-то есть? В вашем документе я этого не нашел (при первом взгляде). Ширина импульсов, модуляция/демодуляция это все требования назначения, а какие-то требования к надежности предъявляются? Вы по теме, не написали вообще ничего, при этом, постите сюда какие-то идиотские цитаты, которые считаете уместными в технической дискуссии. Попутно, как я понимаю, пытаетесь обозвать собеседника "Идиотом", "Мартышкой" или еще кем-то. Вы думаете вас воспринимают серьезно? Вы никто, и звать вас никак, ничего из себя не представляете, и ваши цитаты интересны только вам, и возможно вашему врачу.

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

Хорошо, а тогда прокомментируйте пожалуйста факт существования DO-178, EUROCAE ED-12, IEC 61508? Зачем они нужны? Ведь требования, например, к самолету можно сформулировать кратко и ясно: 1.0 Самолет должен взлетать; 1.1 Самолет должен лететь; 1.2 Самолет должен приземляться; 1.3 Самолет не должен падать. Ну а дальше, хоть на лампах, хоть на ПЛИС...

Ада это конечно жесть. Я тут почитал сайт VxWorks, их ОС якобы используется в авиа. Вот чем они хвастаются в плане Critical Safety: https://www.windriver.com/products/product-...ct-Overview.pdf Ну то есть, когда речь идет действительно о Safety-critical, а не о каких-то фантазиях, местных "гениев", всплывает сразу много красивых аббревиатур, которым надо соответствовать.

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

HAL это вообще первое, что увидит начинающий в теме. Поэтому по нему и дофига вопросов на форумах, типа "НИ ЧЕГО НЕ РАБОТАЕТ ПАМАГИТЕ". У не окрепших умов создается впечатление, что это неработающее "Г...", вон же сколько тем по нему! Я сколько использую HAL, ни разу не сталкивался с чем-то, для чего нужна была бы помощь зала. Linux тоже не эффективен, память жрет, мипсы тратит, четырехслойку с BGA требует, но его популярность на планете порой пугает.

Видите ли, то, какие IDE используются для разработки критически-важных приложений, не является предметом данного обсуждения. Повторим еще раз: - Был высказан тезис, что HAL, SPL, Cube, Linux это все для мигания лампочкой, в сложных приложениях надо писать все самому, потому что не известно, чего там индусы "накодили". Далее, мною и еще рядом участников был задан вопрос: "а с чего вы взяли, что ваш быдло код, лучше индусского в перечисленных выше фреймворках? Вы его как-то сертифицируете или просто "зуб даете"?"; - Судя по написанному в дальнейшем в этой ветке, никто ничего не сертифицируют, а просто уверен, что он пишет код лучше индусов из СТ; - В добавок ко всему, у меня возник уточняющий вопрос, а почему в домашних/офисных роутерах чаще всего крутится Линуксе, а на Боинг 737 линукс можно встретить разве что в развлекательной системе для пассажиров? Решать навигационные задачи и управлять элеронами с тягой куда как проще какой-нибудь rasberry pi было )). Я предполагаю, что для важных приложений, нужна сертификация, принятая в соответствующей отрасли. Написав код в соответствии со стандартом, легче потом будет его сертифицировать, линукс никогда не подразумевал какой-либо сертификации, поэтому его и не используют в важных приложениях, и это никак не связано со сложностью проекта (лампочкой там мигают или двумя). В одних проектах достаточно с представителем заказчика проверить, работает ли устройство или нет, не зависает ли со временем или под влиянием очевидных факторов, а в других, надо доказывать надежность, проходя соответствующую сертификацию. Разговор о ВЕЛИКОЙ надежности своего кода, всех, кто его никак не сертифицирует это просто шум, сказка детям на ночь. Поэтому там, где поставленной задачей заранее, никак не ограничивается использование HAL, SPL, Cube, Linux (сертификация, или ограничения по производительности/быстродействию, или потреблению) - их вполне можно использовать.

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

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

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

Какие у вас прекрасные познания. Да, весь протокол это примитивная 4FSK... Пять минут в гугле и все готово. Заслугами дети в ясельках меряются. А именно в этом треде, взрослые (как я полагаю) люди, обсуждают оптимальные пути решения технических задач. По поводу плотности использования периферии, я выше написал. Учить вас читать я не собираюсь. Упомянутому мною выше D-Link'у все коммутаторы и роутеры, видимо, достаются в виде работающей демки linux'а.

Иногда лучше жевать, а не раздавать советы по проектированию... Во-первых, речь шла о DMR, а не о DRM; Во-вторых, если вам человек пишет о том, что на процессоре "крутится DMR стек", это значит, что он там крутится (на процессоре), а не на каком-то специализированном ASIC'е, общающемся по UART'у c хостом. Реализованы там уровни начиная от phy. В сам процессор вводятся либо квадратуры с бэйсбенда, либо сигнал после ЧМ (зависит от версии железки); В-третьих, по поводу стеков USB и lwIP, да, они есть в любой демке, но это не означает, что их нельзя использовать в проектах (стек USB и стек lwIP). Я работал когда-то в одной конторе, в которой зачем-то писали свой стек. Устройства, которые выпускала контора были мягко говоря так себе, потому что все были заняты изучением RFC и бдениями за Wireshark'ом, отлаживая стек, а об оконечном функционале (за который клиенты и платили деньги) вспоминали редко. Проекты бывают разные, со своими тонкостями, но почему-то многие здесь, наплевав на тонкости, раздают идиотские советы типа "Cube и HAL" это для мигания лампочкой. Это просто признак низкого профессионализма, я так считаю.

А лампочкой поморгать это safety critical? Как вообще лампочка связана с safety critical? Вообще удивительно какой бардак у многих в голове. Ok, зайдем с другой стороны, как вы подтверждаете safety critical? Ваш софт проходит сертификацию на DO-178B, например, или вы просто по "пацанский зуб даете"? Какой-нибудь управляемый L2 коммутатор D-link или soho роутер от них же, ни разу не лампочкой поморгать, но в нем скорее всего обычный линукс. И там это решение вполне оправдано, так как там не стоит задачи в спец. сертификации. А вот на бортовом вычислителе боинга 737 вы линукс не встретите, и не потому, что он сильно сложнее, а потому, что сделав вычислитель на линукс вы упашетесь его сертифицировать и доказывать что оно надежно. Потому что в настоящем safety critical надо доказывать, а не просто трындеть. Если проект подразумевает safety critical с соответствующей сертификацией, то он подразумевает и соответствующее количество трудочасов и денег на него. В рамках этого проекта, естественно, разумно выделить группу для написания надежной замены ST'шному HAL'у. С которой потом, можно будет пройти все сертификации. А когда у вас задача спроектировать железку без доп. требований по надежности, а вы все равно тратите время на перепись HAL'а, полагая (почему-то?), что ваш быдло код лучше "индусского", вы просто разбазариваете время и деньги, отвлекаясь от основной задачи.

Иногда, комментарии на русском языке могут быть обязательным требованием заказчика/работодателя. Поэтому я всегда стараюсь писать комменты на инглише. Эта путаница с кодировками сильно утомляет. Особенно когда одни и те же исходники редактируются в разных операционках (Win <-> macOS/Linux). [off] Вы уж как-нибудь определитесь, люди используют в работе HAL потому что у них совести нет, или потому что "ничего сложнее примеров от ST не делали". А то выглядит это все как какой-то подростковый максимализм. Вы наверное еще винду не любите, потому чтА "маздай"? [/off]

Есть мнение, что те, кто отрицательно пишет про HAL не умеют работать с чужым кодом или очень любят охотится на блох там, где нужно охотиться на медведя. Например, у меня есть ряд проектов, в которых на STM32F4 крутится DMR стек (стек цифровой радиосвязи) с вокодером, TCP/IP стек и USB в режиме виртуального COM порта. Все это крутится на одной из популярных легковесных ОС. DMR стек реализовывал я, совместно с еще одним разработчиком - специалистом по ЦОС и помехоустойчивому кодированию. От процессора необходима реализация базовых функция, типа принять поток по SPI/I2S/I2C, встроенный EMAC, таймеры, USB phy. СТшный HAL с вышеописанными функциями вполне справляется. Основная сложность таких проектов - в прикладной логике (стеки протоколов, обработка сигналов и т.п.), и деньги платятся за это. Если не стоит задачи жесткой оптимизации (на диком масс-продашене такое вполне возможно), колупаться с изучением конкретного камня не имеет никакого смысла, ну будет софтовый оверхед, ну выберете камень посильнее и все. Словить какие-то тяжелые баги, например в HAL'овском драйвере SPI или I2C достаточно тяжело, оно либо работает, либо нет. Намного важнее, сосредоточиться на тех задачах, которые собственно и требуют решения в ходе разработки. А судя по тому, как все тут переживают за код в HAL'е, который, как и любой другой код, естественно имеет ряд недостатков, создается впечатление, что люди дальше дерганья GPIO и работе с SPI не уходят в своих трудах. От HAL очевидно придется уйти только тем, у кого: 1) Дикая серия и камень взят впритык, ибо на больших сериях каждый доллар на счету; 2) Если у вас жесткие требования по потреблению.

Не совсем понял, а что значит не содержать свой штат, но искать кого-то на постоянной основе? В смысле стороннего исполнителя на постоянной основе?

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

Припомнил у себя в проекте такой же код, правда только после того, как вы на русском дали разъяснение по своему примеру. Там все было сделано через typedef и по сути даже более сложная структура была. Мое мнение, подобная бадяга (указатель, на указатель на функцию возвращающую массив указателей тра-ля-ля...) может применятся очень часто, вопрос только в том, как оно оформлено. typedef int32_t /*successful = 0*/ ( *callback_func_t ) ( uint32_t /*protocol status*/ ); typedef callback_func_t callback_tbl_t[LAST_CALLBACK_ID]; typedef struct { uint32_t id; callback_tbl_t cl_tbl; } proto_impl_t; static proto_impl_t impl[MAX_NOF_IMPLS] = { 0 }; callback_tbl_t *impl_get_callbacks ( uint32_t impl_id ) { for ( uint32_t i = 0; i < MAX_NOF_IMPLS; i++ ) { if ( impl[i].id == impl_id ) { return &impl[i].cl_tbl; } } int32_t ( *(*f)[32] ) (uint32_t) = NULL; /* Это я уже сейчас добавил, проверить ругнется ли компилятор. Не ругается. */ return f; }

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

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

sizeof ( ptr ) != sizeof ( arr )

Да, часто встречаю мнение, что инженеры в руководстве это зло, мол ничего в жизни не понимают. Зато руководители "технологических" компаний выросшие из торгашей трусами, это нормально и круто.

Поведение volatile описано, поведение const тоже. Дерзайте, соединяйте вместе. Участок одного из заголовочных файлов к STM32. Определение для __I и для __IO найдете сами. Хотя естественно можно с const не заморачиваться, также, как и с осмысленными именами функций, например. Можно развить ваш вопрос: "приведите пример, когда const необходим и без него никак"? typedef struct { __IO uint32_t POWER; /*!< SDIO power control register, Address offset: 0x00 */ __IO uint32_t CLKCR; /*!< SDI clock control register, Address offset: 0x04 */ __IO uint32_t ARG; /*!< SDIO argument register, Address offset: 0x08 */ __IO uint32_t CMD; /*!< SDIO command register, Address offset: 0x0C */ __I uint32_t RESPCMD; /*!< SDIO command response register, Address offset: 0x10 */ __I uint32_t RESP1; /*!< SDIO response 1 register, Address offset: 0x14 */ __I uint32_t RESP2; /*!< SDIO response 2 register, Address offset: 0x18 */ __I uint32_t RESP3; /*!< SDIO response 3 register, Address offset: 0x1C */ ... etc } SDIO_TypeDef; А какие вопросы вы считаете не притянутыми за уши для программиста встроенных систем с опытом хотя бы более 5 лет? Мне всегда интересно понять, как человек думает. Даже если умный человек столкнулся первый раз с такой конструкцией (а это вполне возможно), он задумается, постарается понять, о чем речь. Неумный начнет доказывать, разбрасывая слюни в разные стороны, что оно не надо, вы все тут идиоты, так никто не программирует! Но этот человек пришел к нам, решать наши задачи за деньги. Сейчас задача понять, что значит volatile const, вот и все. Бывают и совсем волшебные кандидаты, которые даже вопрос не понимают, а пишут опыт 100500 лет и более. В C++ крайне нужная весчЬ. Хотя в C++ я не использую это слово по старой привычке, и опираясь на логику некоторых местных товарищей, могу утверждать, что оно не нужно :-)

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

Раз уж в этой теме обсуждали DMR и 4-FSK, задам вопрос здесь. Сейчас читаю инструкцию на DMR тестер Aeroflex 3920b. Там среди прочих, понятных мне параметров измеряются Magnitude Error и Magnitude Peak. Я не понимаю что это и зачем оно нужно? Вот что написано про Symbol Magnitude Error: Я что-то не совсем понимаю, зачем в этом виде модуляции измерять магнитуду символа? В моем понимание, исчерповающую информацию о качестве модуляции несут следующие тесты: Полный документ во вложении. 3920B_DMR_option.pdf