Какие типы переменных? Float или Double среди них есть? Результат первой и второй конструкции идентичен или отличается? Оптимизация по скорости включена?
Какие типы переменных? Float или Double среди них есть? Результат первой и второй конструкции идентичен или отличается? Оптимизация по скорости включена?
C8T6 не имеет FPU, в первом посте указал что только CMSIS без всяких надстроек т.е. никаких извращений с float на цельночисленном камне, тип данных uint16_t или 32_t - ситуация одинаковая, оптимизации пробовал разных уровней - результат малоотличим
Данные снимал анализатором, в прерывании ->ODR ^= и смотрел на интервалы прерывания
И еще, для понимания - калькуляция там не одна, их с десяток наберется, за пределы результирующей длины слова - не вылезает, по отладчику перепроверено несколько раз
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
ну а если записать "естественно", без лишних скобок:a = (b*10 + c/60 - 1) * 5;? что будет?
А есть варианты? Твоя программа разбора выражений со скобками и без могла выдавать разные результаты?
V2oD2o, такое выражение целиком за пол мкс должно считаться, даже без оптимизации будет не на много больше, причем в таком случае медленнее должен быть вариант с промежуточными переменными, так что весьма вероятно баг где-то в другом месте.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
ну а если записать "естественно", без лишних скобок:a = (b*10 + c/60 - 1) * 5;? что будет?
А есть варианты? Твоя программа разбора выражений со скобками и без могла выдавать разные результаты?
V2oD2o, такое выражение целиком за пол мкс должно считаться, даже без оптимизации будет не на много больше, причем в таком случае медленнее должен быть вариант с промежуточными переменными, так что весьма вероятно баг где-то в другом месте.
выражение условное, там несколько десятков расчётов завязанные на разные временные события и внешние прерывания, основная масса расчетов ведётся по данным ADC через DMA - 4 канала
попробую сформировать вечером реальный пример, на котором можно увидеть "у себя" описанную проблему
результат - всегда одинаковый, просто разбивание строки со скобками убирает проблему полностью, таймер начинает считать нормально
тип данных uint16_t или 32_t - ситуация одинаковая
В многострочном варианте промежуточный результат явно приводится к типу присваиваемых переменных, в однострочном - нет. Проверьте, интересу ради, вариант a = (uint_16t)(((uint_16t)(b * 10) + (uint_16t)(c / 60)) - 1) * 5; Кроме того, теоретически, операции "перемножение" и "домножение" имеют разное количество аргументов - и компилятор вполне может решить пользоваться разными инструкциями буде такие в его распоряжении на рассматриваемой платформе. А сгенерированный ASM код наверняка неидентичен - может туда глянуть?
_________________ Одновременным нажатием LIGHT и POWER, РП Sangean ATS-909X (ver 1.29) превращается в ATS-909XR!
тип данных uint16_t или 32_t - ситуация одинаковая
В многострочном варианте промежуточный результат явно приводится к типу присваиваемых переменных, в однострочном - нет. Проверьте, интересу ради, вариант a = (uint_16t)(((uint_16t)(b * 10) + (uint_16t)(c / 60)) - 1) * 5; Кроме того, теоретически, операции "перемножение" и "домножение" имеют разное количество аргументов - и компилятор вполне может решить пользоваться разными инструкциями буде такие в его распоряжении на рассматриваемой платформе. А сгенерированный ASM код наверняка неидентичен - может туда глянуть?
На работе к сожалению нет возможности objdump сделать, дома по-любому буду построчно разбирать и бряки делать на каждом шагу, вчера ночью только наткнулся на этупроблему, особо времени не было разбираться
Насчет приведения к типам - хорошая идея, попробую вечером
Современные компиляторы очень умные, в данном случае он раскрыл скобки(b * 50 + c / 12 - 5), заменил деление умножением, умножение заменил сдвигами и сложением, более того т.к. из-за целочисленного деления результат упрощенного выражения может быть другим, то было предусмотрено и это. Так что не нужно искать баги у компилятора, ищи баги у себя
Там все в порядке, проект рабочий, после доработок, не сразу, но было замечено увеличение времени отсчета по таймеру примерно х1.8 - х2, т.е. событие по 10мс, выполнялось в 18.5064мс
тип данных uint16_t или 32_t - ситуация одинаковая
В многострочном варианте промежуточный результат явно приводится к типу присваиваемых переменных, в однострочном - нет. Проверьте, интересу ради, вариант a = (uint_16t)(((uint_16t)(b * 10) + (uint_16t)(c / 60)) - 1) * 5; Кроме того, теоретически, операции "перемножение" и "домножение" имеют разное количество аргументов - и компилятор вполне может решить пользоваться разными инструкциями буде такие в его распоряжении на рассматриваемой платформе. А сгенерированный ASM код наверняка неидентичен - может туда глянуть?
"Дело было не в бобине" - и действительно, приведение к типам дало прирост, очень ощутимый, было 18мс вместо 10мс, перевёл все расчеты на u32_t (в 16 не влезу) - стало 13.3мс, добавил -O3 - и увидел заветные 10мс, пробовал нагрузить еще всякими вычислениями, даже гораздо более сложными и считать их каждый тик, а не по событию - проблема решилась, каждый тик ровно 5.000 мкс, спасибо за наводку!
Что интересно -Ох без использования однотипных данных - почти ничего не давало
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 30
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения