Перейти к содержанию
    

Как оборудование, электронику на взрывозащиту испытывают я видел, а как ПО испытывают?

 

согласно ГОСТ Р 8.654-2015 и Р 50.2.077-2014

 

ссылки на ваши средства измерений в Госреестр СИ, в студию!

 

например, 66314-16

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

согласно ГОСТ Р 8.654-2015 и Р 50.2.077-2014

 

Там ничего необычного нет, простые вещи которые соблюдают нормальные программисты. Вы еще про стандарты оформления ПО вспомните.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Там ничего необычного нет, простые вещи которые соблюдают нормальные программисты. Вы еще про стандарты оформления ПО вспомните.

 

Видимо, вы не совсем в теме, бывает. Рекомендую еще взглянуть на ГОСТ Р МЭК 61508-6-2012, но он к метрологии не имеет отношения.

Изменено пользователем 0men

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При чем тут метрология, идет разговор о надежности применения CubeMX и HAL в своих изделиях и методов испытания надежности ПО.

Разрабатываю средства измерений, в том числе взрывозащищенные. Сертифицируется и взрывозащита и метрология и встроенное ПО и автономное (внешнее)

Как оборудование, электронику на взрывозащиту испытывают я видел, а как ПО испытывают?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При чем тут метрология, идет разговор о надежности применения CubeMX и HAL в своих изделиях и методов испытания надежности ПО.

 

про надежность смотрите ГОСТ Р МЭК 61508 и гост р мэк 61511. У импортных он упоминается как SIL

Изменено пользователем 0men

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

По теме вопроса - личное мнение я уже озвучивал.

Считаю, что тема не особенно актуальна. Если рассматривать чисто обработку железа - то бишь драйвера - то это несколько процентов от общего объёма проекта. Если рассматривать всякие там GUI, OS и прочие входящие компоненты, то надо понимать, что это совершенно независимые разработки. Применение каждой из них должно рассматриваться в отрыве.

Как правило драйвера, в том виде, в котором они написаны - просто не нужны. Я бы сказал бессмысленны и явно избыточны.

Например, мне трудно представить проект, где органично бы вписался драйвер USART от ST. Возможно у меня фантазия слабая.

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

 

Есть проблемы и со своими.

Я не заморачивась. Как правило пишу всётаки драйвера под конкретную задачу/ проект. А универсальность чуть повыше обеспечиваю. Правильно тут отмечали - часы должны идти независимо от того, откуда ты получаешь данные. Это же касается и всего прочего. Например, при изменении типа флэши, не должно быть существенного изменения проекта. Добавление нового протокола, не должно менять логику работы устройства и так далее..

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Для I2C по атмелу весь код - сплошные прерывания, зачем ? Эти функции например нельзя использовать в контексте другого прерывания ! Система API таймеров для ATMEL оперирует 4 байтными значениями задержек в микросекундах, при использовании подсчета не атомарных величин - запрещают прерывания, длительность расчета превышает десятки микросекунд, при использовании например UART на скорости выше или равно 115200 - задержка для вычисления времени API TIMER калбэков по таймерам превышает время трансляции байта, а так как у atmel нет FIFO - данные просто теряются. При задержке в калбек функции по премени вычисления больше чем запрограммировано время следующего калбека - вылет и неопределенное значение внутреннего программного состояния Timer API - ну и т.д.

И это что считается нормальным поиск багов ? Такие API не годятся вообще никуда, они только показательны и только когда работают одни в системе, или таймера или UART или I2C. А вот в связке функционирования - полная Ж... . Вообще халява она для особенных людей, когда ее кто-то ищет - это очень яркий ярлык отсутствия шишек.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ни один HAL не может использовать 100% все возможности периферии.

Мое впечатление от HAL в этой цитате.

 

Стандартные решения средствами HAL вполне интересны, но не стандартные варианты увы не подъемны. SPL может помочь для отважных фантазеров. Когда HAL будет способен на ЛЮБУЮ импровизацию, тогда свершится ожидаемый скачок.

 

Пример. SDIO заточен на обмен с SD. Это значит, что в перечне команд заложены стандартные наборы с соответствующими ответами. Архитектура(CRC7, CRC16, стартовые\завершающие коды, файловая система и т.п.) присутствует явно в HAL. .....Жизнь диктует свои законы и стык SDIO можно использовать для многих применений(подразумевается гибкость ПЛИС).

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

И вся эта красота моментально рушится.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кроме банальных и грубых ошибок в API поддержек микроконтроллеров, существует еще и простые политики - зарабатывание денег.

 

 

API периферии, а ТАКЖЕ ПЕРИФЕРИЙНЫЕ УЗЛЫ между производителями - ранее, ныне и всегда будут уникальными, это способ затормозить юзеров на переход или смену "периферийного железа" на другого производителя, это по крайней мере должны понимать не наивные люди. И как вследствие этого НИКОГДА НЕ БУДЕТ безболезненного перехода. Время чтения документации + поиск багов + нереальные трудности по изменению "специально написанного" кода - делают своё дело, причём это делается скорее всего целенаправленно, чем случайно.

 

Сколько продержалась STM_SPL уступив STM_HAL, кому мешала быстро переносимая API архитектура ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При принятии данных заставить прочитать регистр статуса перед регистром данных - ни в какую не хочет. На STM UARTe ....
А в каком конкретно месте этот баг? Глянул на вскидку хал для stm32l0 функцию HAL_UART_Receive(), сначало читается ISR, потом RDR.

 

при использовании например UART на скорости выше или равно 115200 - задержка для вычисления времени API TIMER калбэков по таймерам превышает время трансляции байта
довод ни о чем. все ваши высказывания в двух словах - "хал грамоздкий". А то что там по времени что-то у вас не пролезло, хал тут не причем. Он грамоздкий - со всеми вытекающими, этим всё сказано. Запустите хал на 150 МГц и пролезут ваши 115200. С другой стороны.... вы свой код соптимизируте на 48МГц, ваши 115200 с запасом будут работать.... в другом проекте нужно будет проц на 1 МГц запустить.... и те же грабли, что вы описали.

 

а так как у atmel нет FIFO - данные просто теряются.
дма нет?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А в каком конкретно месте этот баг? Глянул на вскидку хал для stm32l0 функцию HAL_UART_Receive(), сначало читается ISR, потом RDR.

 

В части где нелинейно укрюченый код отловил FE или NOISE Interrupt - ТАМ. Возможно и подправили со временем, но когда обычно такой код пишут , он много говорит о том кто его писал.

 

дма нет?

 

Это не XMEGA и не STM, не MSP и не LPC. Это класика AVR ;) .

 

довод ни о чем. все ваши высказывания в двух словах - "хал грамоздкий". вы свой код соптимизируте на 48МГц

 

Интересно, а к чему тогда мануалы: ну например что такое 240 mka / 1 Mhz. Сейчас полно автономных устройств на своем питании, где время выполнения кода играет первостепенную роль.

Дык, волшебство превращения контроллера в кирпичеподобную субстанцию за день работы - вот, это точно не выход.

Надо вообще разбить ветку форума на две, в одной высказывания программистов "которым еще кажется" в другой "которые уже открестились" ;)

Изменено пользователем картошка

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пример. SDIO заточен на обмен с SD. Это значит, что в перечне команд заложены стандартные наборы с соответствующими ответами. Архитектура(CRC7, CRC16, стартовые\завершающие коды, файловая система и т.п.) присутствует явно в HAL. .....Жизнь диктует свои законы и стык SDIO можно использовать для многих применений(подразумевается гибкость ПЛИС).

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

И вся эта красота моментально рушится.

В этом случае без SPL не обойтись.... Какие рекомендации от корифеев?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Возможно и подправили со временем, но когда обычно такой код пишут , он много говорит о том кто его писал.
А был ли мальчик? Так и не нашел я ни какого бага, о котором вы говорите. Из гита качнул самую первую версию

* @file stm32f1xx_hal_uart.c

* @author MCD Application Team

* @version V1.0.0

* @date 15-December-2014

При приеме вычитывается статусный регистр в течении таймаута, если пришел RXNE, то читаем RDR. По другому - даже кривыми руками не написать. Вы говорите

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

Почему я за это зацепился? Я использую хал, и не хочу наступить на эту граблю если она есть. Вы можете показать эту граблю? Если не можете, то с вашими выводами всё понятно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В этом случае без SPL не обойтись...

Уже 15 страниц толкуют, что HAL===SPL (только с бóльшими извращениями), и опять начинай сначала…

Только внимательное чтение даташита поможет правильно реализовать требуемый алгоритм. И никакие SPL/HAL/opencm3/что-то-еще не помогут.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Уже 15 страниц толкуют, что HAL===SPL (только с бульшими извращениями), и опять начинай сначала…

Только внимательное чтение даташита поможет правильно реализовать требуемый алгоритм. И никакие SPL/HAL/opencm3/что-то-еще не помогут.

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

Вы не поняли... Когда от SDIO не требуется обмен с SD, а требуется клон, который резко отличается от SD-спецификации,-HAL- беспомощен, потому как в нем прописан промышленный стандарт. Выход Только в прямом управлении регистрами!..

HAL хорош для стандартных решений. ЛЕГО!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...