// Обязательная "задержка между командами", пока АЦП восстановится после только что принятой команды delay_us(ADS1256_DELAY_T11_US);
// Datasheet: "After a reset, the ADS1255/6 performs self-calibration... " // Синхронная задержка до готовности АЦП (пока завершится автокалибровка) while(ADS1256_DRDY_BUSY()); }
В строке uint8_t TxBuffer = ADS1256_COMMAND_RESET; возникает warning ../Drivers/ADS1256_Driver/ads1256.c:330:11: warning: unused variable 'TxBuffer' [-Wunused-variable] Но ведь она же используется в следующей же строке! Что же я делаю не так? IDE: STM32CubeIDE Version: 1.7.0 Build: 10852_20210715_0634 (UTC) Компилятор GCC
assert_param - это не макрос случаем, который при "чистовой сборке" выбрасывается? Как обычно, советую выкинуть калокуб куда подальше!
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Если TxBuffer упоминается в коде один раз усего, компилятор не считает TxBuffer переменной, поскольку TxBuffer не меняется (похожа на константу (адрес константы)). Будете дальше писать текст, упомяните TxBuffer на запись и, Warning уйдет не переживайте это не Error.
P.S. Чего Вы тушуетесь от недоверия? Компилятор же сказал Вам, что TxBuffer не меняется у Вас. Это намек, что Вы что то не дописали в тексте кода, например, забыли добавить то что запланировали.
P.P.S. Поэтому я противник "инициализации" буферов, иначе важный намек (Warning) не будет "озвучен". Еще, здорово иметь статистику, где и сколько раз переменная упоминается на запись в явном и особенно неявном виде.
P.P.S. У меня бывало, отлично работающий код изобиловал Warning-ми, поскольку не желая явно переходить на ассемблер я писал на Си в стиле ассемблера (неявное приведение типов). Я знал эти места, поэтому на Warning ноль внимания (зато не было ошибок времени выполнения, даже удавалось их, таким образом, обойти), кроме Вашего случая, когда "прозрачный намек", что код неполный забыли дописать.
_________________ "Every profession is a conspiracy against the uninitiated" (B. Shaw) "A textbook can be defined as a book unsuitable for reading" (B. Shaw) Tautology is humor in "this" place (Vigo Carpathian)
К конденсаторам источников питания высокой мощности предъявляются высокие требования по качеству и надежности. Пленочные – единственный тип конденсаторов, который может справиться с такой задачей. Компания Hongfa предлагает продукцию, которая подходит для применения практически во всех функциональных узлах типовых AC/DC- или DC/AC-преобразователей. Рассмотрим характеристики и применения плёночных конденсаторов Hongfa для различных решений.
Большое спасибо всем за ответы! Последний вариант с промежуточной переменной - к нему и склонялся, попробую. А вообще, если не включен FULL_ASSERT, то корректно ли писать assert_param()? Нужен ли он?
Вслед за сериями на DIN-рейку DDRH-60/120/240 и на шасси RSDH-150/300 компания MEAN WELL выпустила новые маломощные DC/DC-преобразователи DDRH-15/30/45 со сверхшироким входным напряжением 150…1500 В, и монтажом не только на DIN-рейку, но и печатную плату или винтовым соединением. Все преобразователи семейства DDRH и RSDH работают при температурах -40…80°C и обладают высокой изоляцией 4000 В AC между входом и выходом, что обеспечивает надежную защиту. Они подходят для использования на высоте до 5000 м и сертифицированы по стандарту IEC62109-1 для фотоэлектрических систем. Преобразователи DDRH/RSDH есть в наличии и под заказ.
А вообще, если не включен FULL_ASSERT, то корректно ли писать assert_param()?
Что значит "корректно"? Очевидно, что при компиляции в режиме DEBUG, этот макрос должен порождать какой-то проверочный код; при компиляции в RELEASE - не должен порождать кода. Так как эти проверки нужны только для отладки и в уже отлаженном коде содают только лишний вес.
Нужна или нет проверка чего-либо assert-ом в коде - определяет программист, пишущий этот код. А ему это диктует его профессионализм и требования следования какому-то стилю построения кода.
Нужна или нет проверка чего-либо assert-ом в коде - определяет программист, пишущий этот код. А ему это диктует его профессионализм и требования следования какому-то стилю построения кода.
Совершенно согласен. Правильно ли я понимаю, что в функции должны были быть директивы предпроцессору вида:
#ifndef FULL_ASSERT... <код RELEASE> #else <DEBUG>// где и используется assert_param() #endif
и аффтар просто так не сделал?
PS С промежуточной переменной тоже не прокатило, появился warning про эту переменную. Вообще убрал присвоения, просто вызвал функцию HAL_SPI_Transmit() и компилятор успокоился. Но для чего то был же написан вызов assert_param?
Правильно ли я понимаю, что в функции должны были быть директивы предпроцессору вида: #ifndef FULL_ASSERT... <код RELEASE> #else <DEBUG>// где и используется assert_param() #endif
и аффтар просто так не сделал?
Нет. Как правило, где-то в заголовочных файлах должно быть определение assert_param() подобное:
Код:
#ifdef FULL_ASSERT... #define assert_param(условное_выражение) (какое-то действие если (условное_выражение) == истинно) #else #define assert_param(условное_выражение) #endif
Или типа того. Поэтому в коде программы достаточно писать просто: assert_param(условное_выражение)
PS С промежуточной переменной тоже не прокатило, появился warning про эту переменную.
Это странно... Какой-то странный у Вас компилятор. Например IAR (ARM) вполне корректно обрабатывает: 1) на простое объявление переменной с инициализацией без последующего использования (uint8_t TxBuffer = ADS1256_COMMAND_RESET;) - выдаёт варнинг; 2) на int r = HAL_SPI_Transmit(...); без последующего использования r - проглатывает молча. Что и правильно.
PS: Попробуйте после int r = HAL_SPI_Transmit(...); добавить фиктивное чтение: r; Хотя IAR как раз на такое вполне логично выдаёт варнинг: "Warning[Pe174]: expression has no effect"
PPS: Ну или ещё как-то нужно сказать компилятору, что r - используется. Сказать нужно в той ветке определения assert_param(), которая сейчас пустая. Может у него какая-нить pragma для этого есть? Не знаю - не пользуюсь GCC. Поищите в хидерах вашего компилятора определение какого-нить assert-подобного макроса, посмотрите как он реализован.
Последний раз редактировалось jcxz Вт мар 15, 2022 19:57:47, всего редактировалось 1 раз.
#ifdef USE_FULL_ASSERT /** * @brief The assert_param macro is used for function's parameters check. * @param expr If expr is false, it calls assert_failed function * which reports the name of the source file and the source * line number of the call that failed. * If expr is true, it returns no value. * @retval None */ #define assert_param(expr) ((expr) ? (void)0U : assert_failed((uint8_t *)__FILE__, __LINE__)) /* Exported functions ---------- */ void assert_failed(uint8_t* file, uint32_t line); #else #define assert_param(expr) ((void)0U) #endif /* USE_FULL_ASSERT */
Ну, ессно, есть и определение USE_FULL_ASSERT, закомментированное. Т.е. если не определен USE_FULL_ASSERT, то выражение выполняется, и всё?
Вести с полей: Попробовал разные варианты: 1.
Код:
HAL_OK==HAL_SPI_Transmit(...)
На это получил логичный warning "Результат выражения не используется" 2.
Код:
zzz=(HAL_OK==HAL_SPI_Transmit(...))
На это получил не менее логичный warning "variable 'zzz' set but not used" Меня то напрягло в первоначальной ситуации то, что неиспользуемой обзывалась переменная, используемая в передаче по SPI. Вот эту логику я и не понял. До сих пор.
Меня то напрягло в первоначальной ситуации то, что неиспользуемой обзывалась переменная, используемая в передаче по SPI. Вот эту логику я и не понял. До сих пор.
Т.е. - Вы так ничего и не поняли из моих объяснений? В "первоначальной ситуации" у Вас переменная не использовалась. Так как и самой передачи по SPI не было.
PS: Перечитайте внимательнее моё предыдущее сообщение. А особенно - предполагаемое определение макроса assert_param(). Там всё видно - что и почему.
Очевидно, что при компиляции в режиме DEBUG, этот макрос должен порождать какой-то проверочный код; при компиляции в RELEASE - не должен порождать кода.
tonyk, jcxz, Спасибо! Чет ступил, действительно, в ветке описания макро для не определенного USE_FULL_ASSERT в расширении (expr) даже не упоминается, а значит, код не генерится. Всем добра и здоровья!
Добрый всем день! Новая бредятина. Со вправленными Вами (спасибо) мозгами нарисовал таки программу. Но вот что происходит: - При прошивке из CubeIDE через ST-Link работает как надо. - При прошивке сгенеренного кубом образа, пробовал .elf,.bin,.hex через CubeProgrammer (пробовал также FlashLoaderDemonstrator) - НЕТ! Пробовал и через UART и через ST-Link!
Что это могут быть за грабли? Да, да, знаю, что куб - это отстой, но все-же! Как так-то?
Michael_Sch, ну выкинь ты уже калокуб и напиши простейшую мигалку светодиодом по-человечески! Потому что то, как ты сейчас это делаешь, напоминает попытку методом тыка кисточки вслепую нарисовать "Джоконду"!
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Michael_Sch, ну выкинь ты уже калокуб и напиши простейшую мигалку светодиодом по-человечески!
Да нет, диодом то я мигал давно уже, здесь связка 24-битный АЦП+103камень. viewtopic.php?f=2&t=178350 Когда начинал знакомство, очень нравился CooCox, но он приказал нам всем долго жить. А вот как по-вашему мнению, если пользовать CubeIDE но без HAL?
Michael_Sch, любым инструментом надо уметь пользоваться. Умеете делать на HAL и результат вас устраивает? Делайте и не слушайте мнение всяких пикселей в интернете.
Michael_Sch, Да, ваши доделки видел изначально, может быть позже дойду до них ). У меня пока не получается - идут нули. Может я что-то не так по пинам настроил? Только вот отладку настроил, не работала никак в Cube IDE. Ещё попробовал один из источников вдохновения этой библиотеки https://www.cyberforum.ru/arm/thread2226883.html - тоже не получилось сначала, потом вроде пошло дело, но значения как-будто случайные идут. Может конечно шум, но не должен, я нулевой канал замеряю с потенциметром которорый, джампер подключен.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
