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

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

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

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

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

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

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

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

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

@chegleeff

3 күн бұрын

В итоге, в 1991 году случился break 😁

@AK-ji3qv

2 күн бұрын

​@@chegleeff abnormal program termination 😂

Спасибо за информацию. Пример с 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 раза. А это очень заметно пользователю. Спасибо, что вы показываете проблемы с разных сторон и предлагаете способы решения.

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

@VladimirMedintsev

3 күн бұрын

@@fizarum Это не метод, а функция. Потоки и Cortex M3? Как программист может заботиться о таймауте, если в функции бесконечный цикл? Если предполагалось что это сделает программист то цикл там не нужен.

@fizarum

2 күн бұрын

​@@VladimirMedintsevнаписал в телеграмме, тут Ютуб блочит мои сообщения

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

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

@VladimirMedintsev

3 күн бұрын

@@DrOlegLebedev Да, про goto абсолютно верно. Но для некоторых этот оператор как красная тряпка и люди считают, что его необходимо избегать. Хотя и реальных причин объяснить не могут.

@DrOlegLebedev

3 күн бұрын

Если представить код с кучей проверок в виде графа, то конструкция goto error очевидно является оптимизицией этого графа.

@VladimirMedintsev

3 күн бұрын

@@DrOlegLebedev Согласен. Программисты делятся на две группы. Те, кто использует goto и те, кто стесняется а этом признаться. Согласен. Это решение

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

@VladimirMedintsev

3 күн бұрын

Ну видео же не про SPI. Ну посмотрите как написаны в той же библиотеке функции работы с USART. Там та же картина. Видео немного о другом.

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

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

@VladimirMedintsev

3 күн бұрын

Эта конструкция не избавляет нас от выполнения if которые по причине ранее найденной ошибки можно уже не выполнять. Так что...

@andrewandroid8785

3 күн бұрын

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

@andrewandroid8785

3 күн бұрын

​@@VladimirMedintsev Сейчас проверил подобный код для десктопного компилятора (visual studio 2022, ver.17.7.3). Как я и предполагал, после первого же "сбоя" проверка остальных if-ов не производится. Т.е. никаких дополнительных расходов нет. К сожалению, не знаю, как сгенерировать ассемблерный код для МК-компилятора, поэтому проверить не могу. Если сможете проверить - буду признателен.

@alexandrdeveloper1242

3 күн бұрын

Если компилятор "не вывозит", всегда можно писать так: ок = ок && (...) Логическое " И" гарантировано будет оптимизировано даже в самых простых компилятора, т к это очевидно. Впрочем и в случае if оптимизация очевидная.

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

ещё.)

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

@VladimirMedintsev

3 күн бұрын

О, интересно, расскажите пожалуйста, как вы обошли необходимость вложенных условий?

@johnkoffee

3 күн бұрын

а каким образом вы теперь избегаете кучу вложенных условий?

@user-ul5ds9uv8u

3 күн бұрын

@@VladimirMedintsev вы накидываете в тело цикла условия. Если хоть одно не сработает - вышли из этого цикла, и далее функция вернула какой-то результат. Это очень удобно. Но со временем я стал замечать, что эта конструкция слишком часто стала встречаться в коде. Для кого-то она совершенно не очевидная. Возьмёт мой код какой-нибудь студент, и везде эти циклы. Мне и самому стало не по себе от этих фейковых циклов. По итогу оказалось, что в большинстве случаев они просто не нужны, т.к. из такого цикла все эти условия перетаскиваются в тело функции, в которой был этот цикл, и все работает аналогичным образом: одно из условий не сработало - вышел из функции с кодом ошибки или без него. И цикл этот уже и не нужен. Так же можно написать длинный if...else if...else... так, чтобы не вкладывать дополнительные условия. Логика та же самая. Сначала взвели ret в ошибку, а потом побежали по if...else if... else. И все эти условия от обратного, т.е. никогда все хорошо и можно что-то делать, а когда одно из условий не выполняется и нужно прекратить все это безобразие. Лайфхак с циклом встречается очень редко, я практически никогда его нигде и не видел.

@user-ul5ds9uv8u

3 күн бұрын

@@VladimirMedintsev аналогичным образом, но без циклов. Здесь ключевая вещь - это условное ветвление, в котором проверки выполняются "от обратного". Предположим, вы создаёте функцию и помещаете в нее такой цикл с набором условий. Зачастую, если приглядеться, то в этом цикле нет никакой необходимости, т.к. этот набор условий может находиться в теле самой функции. Если одна из последовательных проверок не проходит, происходит выход из функции (с кодом ошибки или без в зависимости от логики программы).

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

@VladimirMedintsev

3 күн бұрын

Функция это также дополнительные "расходы" в виде стека. Цикл, это всего лишь конструкция языка. Он не может быть странным и если вы не способны признать что эта конструкция выглядит изящнее и легче читается, то ваши лучшие годы в программировании уже позади.

@oabdn8282

3 күн бұрын

@@VladimirMedintsev я, честно скажу, не являюсь профессиональным разработчиком для микроконтроллеров, однако являюсь профессиональным разработчиком «больших железок». Когда-то на заре развития ПК, когда ресурсов «железа» не хватало, то и мои профессиональные предки тоже экономили на таких мелочах. Время шло, железо становилось мощнее и дешевле, а программы сложнее и дороже. На сегодняшний день в первую очередь в мире «больших железок» важна модульность кода, его расширяемость, возможность адаптировать под меняющиеся требования. Хоть я и новичок в мире «маленьких железок» но мне почему-то кажется, что уже и здесь проблема нехватки ресурсов не так остро стоит, чтобы вкладываться в низкоуровневую оптимизацию с первых строк кода в ущерб структуре кода. Тем более что язык с/с++ сам по себе довольно опасный инструмент, так как человеческий фактор в ошибках довольно высок по сравнению с более современными языками, то как раз структура кода могла бы позволить снизить количество ошибок на этапе разработки и как следствие ускорить доставку проекта до заказчика. Могу ошибаться, но чувство что малые «железки» повторяют в значительной степени путь больших меня не покидает. Возможно, через пяток лет и с++ будет вытеснен какими-то новыми яп или даже уже существующими

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

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

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

@VladimirMedintsev

2 күн бұрын

Реальная разница видна когда пишешь реальный код. Три уровня показанные как пример это не более чем иллюстрация.

@pgrusha

2 күн бұрын

@@VladimirMedintsev вообще-то и в реальном коде надцать уровней вложенности - явление редкое и в реальном коде второй вариант тоже не будет таким красивым и понятным. Это вопрос больше религиозный, как война остроконечников с тупоконечниками.

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

@VladimirMedintsev

3 күн бұрын

Нет, не лучше.

@viv3000

3 күн бұрын

Можете объяснить почему?

@viv3000

3 күн бұрын

И я там ошибся не или а и

@VladimirMedintsev

3 күн бұрын

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

@viv3000

3 күн бұрын

@@VladimirMedintsev понял, спасибо за разъяснения, недавно начал заниматься периферией

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

@VladimirMedintsev

3 күн бұрын

@@ArtemKAD1 Разумеется пояснить что именно там не так вы не сможете.

@ArtemKAD1

3 күн бұрын

@@VladimirMedintsev Почему-же, к примеру в этом примере безусловная переиннициализация всего SPI-модуля с последующим таймаутом ожидания обязательно возникающего бита это тупая потеря времени в каждом цикле отправки. Причем если произойдет невероятное событие и таки бит повиснет, то весь контроллер все равно придется пересбросить для прохождение через аппаратный Reset, что в целом эквивалентно сбросу через WDT на вечном цикле. Аналогично с отправкой через ожидание вместо отправки в прерывании/DMA это тоже та часть которая уже должна заставить задуматься что где-то что-то не так.

@VladimirMedintsev

3 күн бұрын

Ну я не увидел там безусловной переинициализации всего модуля. Но то ладно, спорить не буду, вы правы. Лучше бесконечный цикл. Согласен. Просто устал от бесконечных споров с любителями писать "на регистрах". Мне так даже выгоднее. Перевожу очередной проект с регистров на HAL по простой причине, не работает и прочитать задуманное никто не может. Вот и переписываем.

@ArtemKAD1

3 күн бұрын

@@VladimirMedintsev Причем тут "на регистрах"? В HAL работа точно так-же на тех-же регистрах. Только он не имеет отправки 1 символа заставляя каждый символ передавать как единичную строку с настройкой всех параметров передачи в начале каждого символа или выделять временную буферную память под всю передаваемую строку. К примеру, тупой пример чтения куска из spi-flash выглядит так: /// Read flash memory void spiflashRead(U32 addr, U32 nbytes, U8 *data) { start_transmit(); TransmitByteSPI(SPIFLASH_CMD_READ); // Read TransmitByteSPI((U8)(addr>>16)); // Адрес страницы... TransmitByteSPI((U8)(addr>>8)); TransmitByteSPI((U8)(addr)); while(nbytes--) { *data++ = TransmitByteSPI(0); } stop_transmit(); } А теперь прикиньте чего из этого сделает HAL...

@ArtemKAD1

2 күн бұрын

@@VladimirMedintsev Ну вот давайте переведем с "регистров на HAL" обычное чтение из SPI-flash. void spiflashRead(U32 addr, U32 nbytes, U8 *data) { start_transmit(); TransmitByteSPI(SPIFLASH_CMD_READ); TransmitByteSPI((U8)(addr>>16)); TransmitByteSPI((U8)(addr>>8)); TransmitByteSPI((U8)(addr)); while(nbytes--) *data++ = TransmitByteSPI(0); stop_transmit(); } Только оперативку не надо разбазаривать - не резиновая.

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

брейк плохой

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

@VladimirMedintsev

3 күн бұрын

Так себе причина зацепиться.

@ievgenchesnokov1070

3 күн бұрын

@@VladimirMedintsev Тщательнее надо, тщательнее..🙂

@johnkoffee

3 күн бұрын

пойду открою форточку😁

@poludenny

3 күн бұрын

Мимо тёщиного дома я без шуток не пройду

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