Я когда то писал так же чтобы избавиться от вложенности, но благодаря тому что пишу активно и на ЯП высокого уровня, ну например с#, я понабрал от туда множество правил и приёмов. Один из таких - как можно быстрее выходить из функций. Например инверсия условий и по условию return. Такой приём позволяет писать более читабельный код, вложенность сводится к минимуму. В общем код из трёх строчек который у вас в итоге получился (с break) можно вынести в небольшую static функцию, вместо break - return. Это избавляет от костыльной записи while (0). Можно не заботиться о доп расходах на вызов, компилятор с удовольствием инлайнит такие функции без каких либо прагм.

О, а я во всех своих библиотеках как раз подход Хала взял, по возврату статусов И там тоже сразу отворот-поворот из функции происходит, если что-то не так пошло, с возвратом уже своих статусов

Спасибо за идею! Теперь буду зацикливать функцию обработки ошибок, которая за проход будет вылетать на первом сбое. Делал нечто подобное уже, но в другой реализации. Теперь просто вызывать циклично до тех пор, пока устранится ошибка, либо таймер не сработает.

Я например, использую конструкцию switch, строю на ней конечный автомат, завожу переменную состояние, и уже по значению этой переменной можно спокойно мониторить в каком стояния находится твой автомат. Как по мне намного читабельнее. Но вариант do/while, тоже возьму на заметку

Спасибо ! Полезная информация.

Первая часть видео - очень красивое решение, спасибо! Ну а вторая часть - это да, само собой. Периферия она такая.

Я пишу вызов глобального error_handler со своим кодом вызова. Это здорово помогает при отладке , сразу видно что отвалилось в переферии (имеется ввиду конечно же внешняя)

Здесь есть 2 минуса: 1. Когда определённый иф нужно снабдить элсом - такая возможность уже теряется. 2. Когда окажемся за пределами секции ду-вайл, мы не узнаем, по какому мы там оказались: по хорошему или по плохому. Пожалуй гото с меткой в конце и фалсом - оптимальный вариант.

Обработка ошибок - самая сложная тема. В бывшем СССР как-то собрали всесоюзный съезд наладчиков, но и он не смог "придти к общему знаменателю".😕

Спасибо за информацию. Пример с SPI не очень показателен. Смотрел как в разных библиотеках сделан например I2C везде поголовно ждутся флаги без всякого таймаута. В основном все ЭТО работает, но зависы случаются. Не все микроконтроллеры имеют такую библиотеку HAL. Писал программу для контроллера gd32f130c8. Обмен по I2C писал сам. Заморочился с отработкой ошибок и таймаутами. Вчера сравнил свой код и получилось практически 1 в 1 как в HAL STM. Еще про вопрос нужно понимать как передавать ошибки по уровням абстракции в программе. На верхнем уровне даем команду сохранить настройки прибора в энергонезависимой. Программа должна анализировать статус, что произошло. И на каком этапе это можно исправить. Например не совпадает контрольная сумма после записи. На уровне записи блока можно попробовать записать еще раз или выбрать другую страницу. Если сработает сторожевая собака нам сложно разобрать, что случилось с системой. Что касаемо spi hal катастрофично режет производительность своими проверками. при тактовой частоте spi в 18-36 Мhz и тут даже готовность проверять не нужно(на это тратится много времени). И даже вызов функции передачи байта занимает намного больше времени. Лучше в одной функции в цикле пихать данные в SPI. Но если снизить частоту до 1-2-4Мhz все работать перестанет. Часто работа дисплея по spi c hal очень медленна. И проверки неоправданны. Переход на регистры ускоряет отрисовку в 2-4 раза. А это очень заметно пользователю. Спасибо, что вы показываете проблемы с разных сторон и предлагаете способы решения.

Думаю, по стилистике кода break из фиктианого цикла примерно тож самое, что и goto. Тут надо просто решить для себя, что ты готов осознанно разрушить "школьные догматы стиля ради реально читабельного кода.

Владимир, спасибо за видео, но позвольте с вами не согласиться по поводу SPI. Если этот флаг не поднимется то это говорит только об одном - внутренней проблеме камня. Ведь SPI это просто сдвиговый регистр. Флаг поднимается грубо говоря после определенного числи тактов. Если бы это был I2c то так делать преступно. Так как требуется ответ от устройства ACK. В SPI ну улетят данные в воздух и все...Что SPI что U(s)ART с точки зрения передачи не требуют подтверждения.

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

@VladimirMedintsev насчёт кода libopencm3, выше нарисано: "@brief SPI Data Write with Blocking": тоесть указано, что функция блокирующая и программист использующий этот метод должен сам позаботиться о таймауте, может она вообще будет работать в отдельном потоке. Скорее всего это было сделан так, чтобы миниизировать кодовую базу и не брать на себя всякие крайние случаи. Предположу, что расчёт был та какой-нить RTOS

Я бы использовал декоратор, если нет ооп. А если есть ооп использовал бы паттерн инициализация как объект

По поводу таймаутов и отказа периферии. Сразу выкину за скобки случай с отказом тактирования периферии, будем считать, что источник условно надёжный. Тут всё не так однозначно, периферию нужно делить на ту, которой можно доверять и на ту, которая может отказать из-за внешних факторов. Например spi, который в режиме мастера и тактируется например от внутреннего RC. Нет ни одной причины по которой мы отправили байт и не дождались завершения передачи. Ну вот ни одной. Это пример периферии при работе с которой нет смысла переусложнять код с таймаутами. Приведу второй пример i2c в режиме мастера. В зависимости от внешних факторов (может вообще eeprom не запаян или линии в нуле) мы можем передать с стартовый байт и не дождаться передачи потому что линия занята. Это пример с периферией с которой надо аккуратно. Или запуск кварца и ожидание стабилизации, понятное дело что он может не запуститься, заметьте - опять же это внешний фактор. Теперь расскажу что в принципе таймауты (без ос) моветон так как это забивает обработку главного цикла, такие вещи нужно реализовывать на прерываниях/опросах с использованием автоматов. Понятное дело, что это сильно усложняет код, и поэтому нужно несколько раз подумать, имеется ли внешнее влияние на используемую периферию и нет ли каких то приколов в эрате. Если проблем нет - лучше таймауты не использовать, это самообман в безопасности и не обусловленое усложнение.

можно обойтись и без цикла, но для С вполне нормальный подход.

ещё.)

Для избавления от вложенных if-ов использую такой подход: auto ok=Init(); if(ok) ok=Transmit(); if(ok) ok=Recieve(); Иногда бывает, что статусная переменная (ок) не подходит, например если функции возвращают разные типы. В таком случае создаем булеву переменную, которой присваиваем "успешность", вот так: bool ok = (Init()==...); if(ok) ok = (Transmit()==...); if(ok) ok = (Recieve()==...); ... Буду рад, если помог!

нууу... while до срабатывания watchdog не самое страшное, что бывает..... некоторые весёлые индусы перазагружают watchdog в прерывании от RTC и перезагружают его на 1,9сек, и вот тогда while становится вечным.....

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

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

Не понятно почему просто не вынести в функцию гарантированной отправки с if(...) return; Компилятор вероятнее всего ее заинлайнит даже без пинка... вместо do while

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

а решение с циклом не лучше сделать так: if (is1 || is2 || is3) { что то }

Главное правило программиста - никогда не делайте так, как сделано в HAL. Единственное достоинство этой библиотеки в том что она есть. Все остальное - недостатки.

Глючный зараза этот hal . Кроме библиотеки usb старался не пользовать.

брейк плохой

Инженеры продумывают систему прерываний делают отдельные шины для DMA. Но будем ставить while без tryout. Уххх говнина, впрочем и HAL тоже шлапя, когда дохрена всего и АЛУ рабоатет на симантику HAL. (HAL_LL это другое это уже годнота).

SPI - не устройство, а интерфейс.🙃