Quasar
-
Постов
344 -
Зарегистрирован
-
Посещение
-
Победитель дней
4
Сообщения, опубликованные Quasar
-
-
И что, красная кнопка программная?? Может еще и софт под винду
Не хотел бы я на таком станке работать... Там все железно отрубаться должно.Мне как-то девушка, которая делала МРТ рассказывала про кнопку экстренного отключения аппарата. И назвала её "кнопкой увольнения". Мол после нажатия этой кнопки, аппарат надо обслуживать. Скорее всего, это следствие того, что кнопка все-таки не программная, а резко-обрывающая какие-то критические цепи, и аппарат просто блокируется механически, без возможности штатного перезапуска.
-
Ни слова о программном обеспечении.
Хорошо, а тогда прокомментируйте пожалуйста факт существования DO-178, EUROCAE ED-12, IEC 61508?
Зачем они нужны? Ведь требования, например, к самолету можно сформулировать кратко и ясно:
1.0 Самолет должен взлетать;
1.1 Самолет должен лететь;
1.2 Самолет должен приземляться;
1.3 Самолет не должен падать.
Ну а дальше, хоть на лампах, хоть на ПЛИС...
-
ps стало интересно, что там в боингах.... погуглил.... Ada, ось для Ada, даже Windows есть, но винда там не в системах=жизнь.
Ада это конечно жесть.
Я тут почитал сайт VxWorks, их ОС якобы используется в авиа. Вот чем они хвастаются в плане Critical Safety:
Safety-critical certification support: Wind River VxWorks Cert Platform provides a COTSsolution for delivering safety-critical applications that must be certified to the stringent
requirements of RTCA DO-178, EUROCAE ED-12, or IEC 61508 certification evidence in
avionics, transportation, industrial automation, and medical device industries
https://www.windriver.com/products/product-...ct-Overview.pdf
Ну то есть, когда речь идет действительно о Safety-critical, а не о каких-то фантазиях, местных "гениев", всплывает сразу много красивых аббревиатур, которым надо соответствовать.
-
Только не надо уводить тему в сторону.
Линукс огромен. Взять и переписать его полностью с нуля, но чтобы сверху работали все сторонние приложения никто не может.
А c HAL-ом нормальная практика.
Каждый профессионал сталкивается рано или поздно с необходимостью выкинуть HAL и заменить на свой более эффективный код.
По поводу каждого, вспомнилось:
Второе по значимости событие в жизни каждого мужчины — это день, когда он покупает яхту, а самое великое событие в его жизни — тот день, когда он ее продает.Д. Трамп.
Я лишь столкнулся с необходимостью расширить HAL, дабы обеспечить поддержку нескольких плат (с разным набором микросхем) одной прошивкой.
-
Более того если вы неопытный разработчик, то HAL для вас единственный выход. Только с ним вы можете что-то быстро запустить.
А насчет надежности и безглючности согласен.
Не стоит приписывать HAL-у какую-то особенную глючность. Его все-таки солидная толпа проверяет.
HAL это вообще первое, что увидит начинающий в теме. Поэтому по нему и дофига вопросов на форумах, типа "НИ ЧЕГО НЕ РАБОТАЕТ ПАМАГИТЕ". У не окрепших умов создается впечатление, что это неработающее "Г...", вон же сколько тем по нему! Я сколько использую HAL, ни разу не сталкивался с чем-то, для чего нужна была бы помощь зала.
HAL просто неэффективен.Linux тоже не эффективен, память жрет, мипсы тратит, четырехслойку с BGA требует, но его популярность на планете порой пугает.
-
И ПО пишется, что для бытовухи, что для систем жизнеобеспечения одинакового, с применением одинаковых IDE, компиляторов, библиотек.... Если кто-то считает что иначе - я вас разочарую.
Видите ли, то, какие IDE используются для разработки критически-важных приложений, не является предметом данного обсуждения. Повторим еще раз:
- Был высказан тезис, что HAL, SPL, Cube, Linux это все для мигания лампочкой, в сложных приложениях надо писать все самому, потому что не известно, чего там индусы "накодили". Далее, мною и еще рядом участников был задан вопрос: "а с чего вы взяли, что ваш быдло код, лучше индусского в перечисленных выше фреймворках? Вы его как-то сертифицируете или просто "зуб даете"?";
- Судя по написанному в дальнейшем в этой ветке, никто ничего не сертифицируют, а просто уверен, что он пишет код лучше индусов из СТ;
- В добавок ко всему, у меня возник уточняющий вопрос, а почему в домашних/офисных роутерах чаще всего крутится Линуксе, а на Боинг 737 линукс можно встретить разве что в развлекательной системе для пассажиров? Решать навигационные задачи и управлять элеронами с тягой куда как проще какой-нибудь rasberry pi было )). Я предполагаю, что для важных приложений, нужна сертификация, принятая в соответствующей отрасли. Написав код в соответствии со стандартом, легче потом будет его сертифицировать, линукс никогда не подразумевал какой-либо сертификации, поэтому его и не используют в важных приложениях, и это никак не связано со сложностью проекта (лампочкой там мигают или двумя).
В одних проектах достаточно с представителем заказчика проверить, работает ли устройство или нет, не зависает ли со временем или под влиянием очевидных факторов, а в других, надо доказывать надежность, проходя соответствующую сертификацию. Разговор о ВЕЛИКОЙ надежности своего кода, всех, кто его никак не сертифицирует это просто шум, сказка детям на ночь. Поэтому там, где поставленной задачей заранее, никак не ограничивается использование HAL, SPL, Cube, Linux (сертификация, или ограничения по производительности/быстродействию, или потреблению) - их вполне можно использовать.
-
Как-то делал проект в фирме, занимающейся театральным оборудованием.
Как вы ловко привели сначала в аргументации "лифты, троллейбусы, трамваи, электровозы, самосвалы", а потом продолжили софитами... Я тут не являюсь экспертом, но мне кажется, что ПО для важных узлов подобного рода техники пишется несколько более серьезно, чем ПО к приводам софитов и поворотных сцен, и все-таки имеет какую-то сертификацию на надежность, принятую в соответствующей отрасли.
Я считаю полезным высказывать свое мнение.А любого, кто аргументировано возражает вашему мнению, вы считаете нужным назвать идиотом. Лечитесь, мой вам совет.
-
Это обычная промышленная задача, решаемая для управления лифтом, троллейбусом, трамваем, электровозом, карьерным самосвалом или тепловозом с электрической передачей.
А вы уверены, что это «обычное» ПО, и не подлежит сертификации?
-
Следую мудрым советам:
“Never argue with an idiot. They will drag you down to their level and beat you with experience.”
― Mark Twain
Да-да. При этом, судя по вашим последним сообщениям на форуме, вы считаете нужным влезать в обсуждения с одним единственным советом "не использовать Cube, HAL, SPL". Какие еще цитаты приведете по этому поводу?
-
Да ладно то к мелочам придираться, я ж искал по "DMR stack" . Примитивная 4-FSK модуляция. Там демодулятор не больше сотни строк.
Какие у вас прекрасные познания. Да, весь протокол это примитивная 4FSK... Пять минут в гугле и все готово.
lwIP конечно можно использовать, но достался он вам в виде рабочей демки. Сомнительная заслуга что он у вас работает на STM32.Заслугами дети в ясельках меряются. А именно в этом треде, взрослые (как я полагаю) люди, обсуждают оптимальные пути решения технических задач. По поводу плотности использования периферии, я выше написал. Учить вас читать я не собираюсь.
Упомянутому мною выше D-Link'у все коммутаторы и роутеры, видимо, достаются в виде работающей демки linux'а.
-
DRM довольно примитивный протокол. Гораздо проще того же Bluetooth или ZigBee. Работали небось по UART-у с чипом реализующем два первых уровня или вообще весь стек.
TCP стек и USB теперь есть в любой демке любого производителя микроконтроллеров.
Я даже не глядя скажу что это у вас был lwIP.
У вас и задач наверно было две три.
Вам на самом деле почти не нужна периферия. Поэтому извините, но мне кажется вы недостаточно в теме.
Иногда лучше жевать, а не раздавать советы по проектированию...
Во-первых, речь шла о DMR, а не о DRM;
Во-вторых, если вам человек пишет о том, что на процессоре "крутится DMR стек", это значит, что он там крутится (на процессоре), а не на каком-то специализированном ASIC'е, общающемся по UART'у c хостом. Реализованы там уровни начиная от phy. В сам процессор вводятся либо квадратуры с бэйсбенда, либо сигнал после ЧМ (зависит от версии железки);
В-третьих, по поводу стеков USB и lwIP, да, они есть в любой демке, но это не означает, что их нельзя использовать в проектах (стек USB и стек lwIP). Я работал когда-то в одной конторе, в которой зачем-то писали свой стек. Устройства, которые выпускала контора были мягко говоря так себе, потому что все были заняты изучением RFC и бдениями за Wireshark'ом, отлаживая стек, а об оконечном функционале (за который клиенты и платили деньги) вспоминали редко.
Далеко не всегда вопрос в сертификации. Например, делал в свое время вендинговую систему, требования - повышенная надежность, пришлось писать все с нуля, старался по минимуму использовать сторонние либы, особенно те, в которых плохо понимаю их принцип работы или они слишком замудрены, используют кучи всяких аллокаторов памяти и пр.Проекты бывают разные, со своими тонкостями, но почему-то многие здесь, наплевав на тонкости, раздают идиотские советы типа "Cube и HAL" это для мигания лампочкой. Это просто признак низкого профессионализма, я так считаю.
-
А еще тогда, когда надо чтобы работало всегда, например, safety critical. Так, к слову, некоторые очень любят исполхзовать Linux, чтобы, например, лампочкой поморгать... Выбор инструментария и ответственность эа результаты его применение целиком лежит на разработчике. Нельзя запретить желающим писать с кубическим акцентом...
А лампочкой поморгать это safety critical? Как вообще лампочка связана с safety critical? Вообще удивительно какой бардак у многих в голове.
Ok, зайдем с другой стороны, как вы подтверждаете safety critical? Ваш софт проходит сертификацию на DO-178B, например, или вы просто по "пацанский зуб даете"?
Какой-нибудь управляемый L2 коммутатор D-link или soho роутер от них же, ни разу не лампочкой поморгать, но в нем скорее всего обычный линукс. И там это решение вполне оправдано, так как там не стоит задачи в спец. сертификации. А вот на бортовом вычислителе боинга 737 вы линукс не встретите, и не потому, что он сильно сложнее, а потому, что сделав вычислитель на линукс вы упашетесь его сертифицировать и доказывать что оно надежно. Потому что в настоящем safety critical надо доказывать, а не просто трындеть.
Если проект подразумевает safety critical с соответствующей сертификацией, то он подразумевает и соответствующее количество трудочасов и денег на него. В рамках этого проекта, естественно, разумно выделить группу для написания надежной замены ST'шному HAL'у. С которой потом, можно будет пройти все сертификации. А когда у вас задача спроектировать железку без доп. требований по надежности, а вы все равно тратите время на перепись HAL'а, полагая (почему-то?), что ваш быдло код лучше "индусского", вы просто разбазариваете время и деньги, отвлекаясь от основной задачи.
-
И вам советую не симулировать в своих текстах английские комментарии, а нормально писать их на языке который лучше знаете.
Иногда, комментарии на русском языке могут быть обязательным требованием заказчика/работодателя.
...ANSI? UTF? Win1251? А на английском никаких проблем.Поэтому я всегда стараюсь писать комменты на инглише. Эта путаница с кодировками сильно утомляет. Особенно когда одни и те же исходники редактируются в разных операционках (Win <-> macOS/Linux).
[off]
3) если есть совесть.Вы уж как-нибудь определитесь, люди используют в работе HAL потому что у них совести нет, или потому что "ничего сложнее примеров от ST не делали". А то выглядит это все как какой-то подростковый максимализм. Вы наверное еще винду не любите, потому чтА "маздай"?
[/off]
-
// а отписывающиеся тут в пользу [censored], похоже, кроме мигания светодиодов и "примеров от ST" ничего не делали, иначе поняли бы, что быстрей написать "на голом CMSIS", чем ковыряться в кривом коде кала...
Есть мнение, что те, кто отрицательно пишет про HAL не умеют работать с чужым кодом или очень любят охотится на блох там, где нужно охотиться на медведя.
Например, у меня есть ряд проектов, в которых на STM32F4 крутится DMR стек (стек цифровой радиосвязи) с вокодером, TCP/IP стек и USB в режиме виртуального COM порта. Все это крутится на одной из популярных легковесных ОС. DMR стек реализовывал я, совместно с еще одним разработчиком - специалистом по ЦОС и помехоустойчивому кодированию. От процессора необходима реализация базовых функция, типа принять поток по SPI/I2S/I2C, встроенный EMAC, таймеры, USB phy. СТшный HAL с вышеописанными функциями вполне справляется. Основная сложность таких проектов - в прикладной логике (стеки протоколов, обработка сигналов и т.п.), и деньги платятся за это. Если не стоит задачи жесткой оптимизации (на диком масс-продашене такое вполне возможно), колупаться с изучением конкретного камня не имеет никакого смысла, ну будет софтовый оверхед, ну выберете камень посильнее и все. Словить какие-то тяжелые баги, например в HAL'овском драйвере SPI или I2C достаточно тяжело, оно либо работает, либо нет. Намного важнее, сосредоточиться на тех задачах, которые собственно и требуют решения в ходе разработки. А судя по тому, как все тут переживают за код в HAL'е, который, как и любой другой код, естественно имеет ряд недостатков, создается впечатление, что люди дальше дерганья GPIO и работе с SPI не уходят в своих трудах.
От HAL очевидно придется уйти только тем, у кого:
1) Дикая серия и камень взят впритык, ибо на больших сериях каждый доллар на счету;
2) Если у вас жесткие требования по потреблению.
-
Возможно не стоит содержать свой штат и писать драйвера которые кто то уже точно делал, а наверное под каждую задачу искать исполнителя на постоянной основе. Так будет ещё быстрее.
Не совсем понял, а что значит не содержать свой штат, но искать кого-то на постоянной основе? В смысле стороннего исполнителя на постоянной основе?
-
... не стоит рисковать с применением индусских библиотек.
Соответственно для увеличения скорости разработок необходимо увеличит штат программистов ...
И крайне желательно, нанять в этот штат программистов повыше квалификацией, чем упомянутые индусы. Если на все это есть деньги и время, то конечно лучше не использовать куб.
-
P.S. func - это функция, не принимающая аргументов и возвращающая указатель на массив указателей на функции, которые возвращают char и не принимают параметров.
Припомнил у себя в проекте такой же код, правда только после того, как вы на русском дали разъяснение по своему примеру. Там все было сделано через 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 )
-
СУПЕР!!! Торговые менеджеры залог процветания. Конкретно. Компания GG (скрываю), капитал американский (ну наплели одному американцу бред и тот бедняга поверил в супер рашиа мозги). Главные менеджеры .1 Непонятно кто совсем не понял. На любую фразу по делу смеется и что невнятно лапочит. Образование физтех. Нигде не работал по спец.
2. Торговец чаем сразу после вуза. Образование- физтех. Нигде не работал по спец. Прямо так и говорил мне-я ничего не понимаю в схемах, в рсв, в физике, но вот слышал, что эта схема и рсв (30 компонентов мс) делается за 1 день, заказ срочный рсв в резоните за 1 день, сборка и изготовление и запуск в работу за пол дня (не верите?, ну как было) а вот ты говоришь, что тебе надо 5 дней.
Как Вы думаете чем все закончилось?
Да, часто встречаю мнение, что инженеры в руководстве это зло, мол ничего в жизни не понимают. Зато руководители "технологических" компаний выросшие из торгашей трусами, это нормально и круто.
-
Привидите плиз пример когда volatile const необходим и заоодно выдержку из стандарта где поведение этой конструкции описывается.
Поведение 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, а в плюсах новый auto использую очень часто и нахожу очень удобным.В C++ крайне нужная весчЬ.
Хотя в C++ я не использую это слово по старой привычке, и опираясь на логику некоторых местных товарищей, могу утверждать, что оно не нужно :-)
-
Вероятно, под этим параметром подразумевается паразитная амплитудная модуляция. В случае демодуляции чм аналоговыми способами она сильно мешает и нужно применять дополнительные действия, типа амплитудного ограничения. А это все лишнее потребление, что для мобильных устройств критично.
Да, так оно и есть. Уже были подсказки из зала с таким же мнением по поводу паразитной АМ. Вопрос, а есть ли какие-либо документы указывающие на порядок допустимой паразитной АМ для данного вида модуляции?
-
Раз уж в этой теме обсуждали DMR и 4-FSK, задам вопрос здесь.
Сейчас читаю инструкцию на DMR тестер Aeroflex 3920b. Там среди прочих, понятных мне параметров измеряются Magnitude Error и Magnitude
Peak. Я не понимаю что это и зачем оно нужно?
Вот что написано про Symbol Magnitude Error:
Magnitude ErrorThe Magnitude Error Meter indicates the Root Mean Square (RMS) of the difference
between the expected and the received magnitude values. The Test Set measures
Magnitude Error in two steps. First the expected magnitude is calculated as the mean of
the received magnitudes. Then the Magnitude Error is computed by finding the RMS of
the differences between the received magnitudes and the previously calculated expected
magnitude.
Я что-то не совсем понимаю, зачем в этом виде модуляции измерять магнитуду символа?
В моем понимание, исчерповающую информацию о качестве модуляции несут следующие тесты:
Frequency ErrorThe Frequency Error Meter measures the frequency error of the incoming RF carrier
signal. Frequency Error is calculated as the difference between the frequency of the
received signal and the receive frequency defined on the RF Control Tile.
FSK Error
The FSK Error Meter measures RMS deviation error at the symbol deviation points of the
UUT signal. FSK Error is measured over one 30 ms slot and is expressed as the
percentage of the deviation.
Symbol Clock Error
The Symbol Clock Error Meter measures the symbol clock of the received DMR signal
over one 30 ms slot .
Полный документ во вложении.
STM32СubeMX и подобные
в STM
Опубликовано · Пожаловаться
Хорошо, но где-то требования к надежности-то есть? В вашем документе я этого не нашел (при первом взгляде). Ширина импульсов, модуляция/демодуляция это все требования назначения, а какие-то требования к надежности предъявляются?
Вы по теме, не написали вообще ничего, при этом, постите сюда какие-то идиотские цитаты, которые считаете уместными в технической дискуссии. Попутно, как я понимаю, пытаетесь обозвать собеседника "Идиотом", "Мартышкой" или еще кем-то. Вы думаете вас воспринимают серьезно? Вы никто, и звать вас никак, ничего из себя не представляете, и ваши цитаты интересны только вам, и возможно вашему врачу.