Відео

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

Ох как жалко дроселя😊

В результате появился неоден ))

Стопудово работает и проработает лет 50 если его подключить

Ардуино - это инструмент для каждого. Инструменты бывают разные. С разными достоинствами и недостатками. Во многом результат применения того или другого инструмента зависит от кривизны рук кодера и места их произрастания. В Ардуино есть библиотеки разного качества. Нужно уметь выбрать из многих одну хорошую. Для этого нужны знания и опыт. Совсем не факт, что говнокодеры (гордо именующими себя "профи") напишут лучше. (Из личных наблюдений. В электронике 50 лет, в программировании - 40). С Ардуино знаком, но проекты на Ардуино не делаю, иногда использую библиотеки для ESP32 от Espressif.

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

брейк плохой

лет 20 назад, если не больше начинал с PIC

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

Эта "древность ещё 100 лет отработает.

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

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

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

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

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

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

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

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

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

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

ещё.)

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

Юзаю FreeRTOS для ESP8266/ESP32, там применение do/while c брейком в проверках это обычное явление. И даже goto label; . Я думал, так все нормальные люди делают.

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

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

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

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

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

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

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

На мой взгляд всё верно, но с одним НО. Не знаю как у вас, но в моих проектах очень часто, главный функционал завязан на переферию. Причём если эта переферия отказывает, то продолжение "работы" всего устройства теряет смысл. И зачастую нет никакого резона отслеживать все эти возможные проблеммы, так как по любому выход один: прекращение работы + перезагрузка + лог/оповещение пользователю. И вот в таких задачах лично у меня нет никаких "лишних" проверок, но всегда есть сторожевой таймер. Вот личный пример недельной давности, делал сушильную камеру для пластика. Главный сенсор меряет температуру и влажность (не помню точную маркировку). Главная задача ПИД, второстепенная экранчик. И вот этот сенсор любит зависать собака. Ну вот скажите, какой смысл отслеживать всю эту скатерть проверок? Он завис, всё... Но тут есть вторая сторона медали: мы "самодельщики", натягивать супер пупер сложный алгоритм в МК за 1 рубль не нужно. Зачастую, если не хватает процессорного времени, то нужно просто менять МК на чуть более быстрый.

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

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

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

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

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

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

👍эхо мощной цевилизациии!

Судя по дате меньше 30-ти лет

Ну так а это стране даже гвоздей своих не делают

Зачем искать ключ если у вас есть контрольная сумма? Сразу проверяйте целостность и если содержимое развалено восстанавливайте заводские значения.

Подскажите, описание на английском сами переводили или наши китайские друзья подготовили английскую версию?

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

А всё это время американский космический аппарат Вояджер летит в космосе и до сих пор работает.

Нет моделек держателей сменных сопел? ЗЫ нашел у Эдуарда, отбой )

Спасибо

Instead of a long talk that is of little use, you should write and show a specific program that could run DFU and that would be great.

У радиолюбителей рф и не такие наворованные из мусорников СССР штучки лежат!😂😂😂 Причём чем старее, тем выше ценятся!!!😂😂😂 И называется у них весь этот хлам - ВИНТАЖ😂😂😂😂😂😂

реклама aliexpress, ничего дельного, на практике такай лабуда не нужна, или будет использоваться на 1% от возможностей. главное знать теорию и определятся по месту, для чего и зачем, а остальное уже ручками делается.

Друг мой не продаш их?