Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
a = b; a = c; это не кривой код, но без явного указания что с этим делать оптимизатор испортит логику.
Это вообще не код. И единственное что с ним сделает компилятор/оптимизатор - выдаст сообщение об ошибке. Так как типы a,b,c - не определены. А без них невозможно понять что делает этот "код".
Если же предположить что: a,b,c имеют тип int (int a,b,c;), то этот код соответствует коду: a = c и компилятор его нормально скомпилит. Что такое "испортит логику" - не понимаю. Логика тут простая - "а присвоить с", какая же ещё?
Работа кода с оптимизатором и без всегда будет отличаться, притом в зависимости от настроек оптимизатора и код при этом не будет кривой. Отличия могут привести к неправильной работе.
Только скоростью. Как уже выше сказали. Если не только скоростью - код кривой. Или приведите реальный пример такого кода, работа которого будет отличаться в зависимости от оптимизации (на нормальном компиляторе, а не некоем почти никем не используемым и давно заброшенным).
Это вообще не код. И единственное что с ним сделает компилятор/оптимизатор - выдаст сообщение об ошибке. Так как типы a,b,c - не определены. А без них невозможно понять что делает этот "код".
В случае разных типов я бы указал приведение к типу. Его тут есть?
Цитата:
тот код соответствует коду: a = c и компилятор его нормально скомпилит. Что такое "испортит логику" - не понимаю. Логика тут простая - "а присвоить с", какая же ещё?
Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту. Неважно, зачем. Это может быть что-то параллельное: что-то где-то рядом читает a. Может быть требованием какой-либо периферии, например получение доступа к флэш у STM.
Цитата:
Только скоростью. Как уже выше сказали. Если не только скоростью - код кривой. Или приведите реальный пример такого кода, работа которого будет отличаться в зависимости от оптимизации (на нормальном компиляторе, а не некоем почти никем не используемым и давно заброшенным).
Сдаюсь. Тратить время на поиски глюков оптимизатора не хочу. Когда попадётся очередной, если не забуду - покажу Вам персонально. Новый и используемый всеми компилятор безгрешен. Логика его безупречна. В любом ином случае - кривой код или компилятор старый и никем не используется... Опции, отключающие или ограничивающие влияние оптимизатора на код придумали для таких неверующих в его святость, как я.
Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту. Неважно, зачем. Это может быть что-то параллельное: что-то где-то рядом читает a. Может быть требованием какой-либо периферии, например получение доступа к флэш у STM.
Откройте для себя такое ключевое слово: "volatile".
По поводу INT или FLOAT, в первой строчке программы, для первых трех переменных. Изначально было так: Потом у меня из - за отсутствия скобок, ничего не работало, и я для исключения кажущейся ( для меня ) причины просто изменил размерность первых трех переменных до FLOAT. В счетчик кол.ва циклов, в десятичную переменную со знаком ( -2 147 483 648,0 : 2 147 483 647,0 ) сохраняем значение переменной с такой же разрядностью + переменная, но со максимальным значением не более 300. Т.е. логично использовать для этих целей переменную размерности INT ( - 32 768 : 32 767 ). Всего получается 16 проходов цикла. Не увидел разницы в кол. ве проходов цикла, как от обозначения размерности INT так и от обозначения как FLOAT. jcxz, что вы имели в виду ? Спасибо.
Не учитесь быдлокодингу! Если на компе float выполняется быстро, то на STM8 будет очень медленно. Пишите так чтобы код был как можно оптимальнее, иначе потом придется переучиваться или будете писать медленный и ресурсоемкий былокод. Можете посмотреть сколько тактов нужно МК без без аппаратной поддержки float для вычислений с плавающей точкой. http://purebasic.mybb.ru/viewtopic.php?id=717
Использование float не делает из кода "быдло". Количество тактов не является приоритетом. Не учите тупым шаблонам. Приоритетным является алгоритм, а не высосанные из пальца какие-то догмы. Использование float чревато лишь из-за способа представления данных, в результате которого в отсутствие чёткого понимания механизма, может быть, например, неверное сравнение в условии. То, что числа с плавающей точкой обрабатываются дольше - всего лишь особенность, каковых куча.
Что-то он там не то для H750 намерял, как может получиться в полтора раза меньше F4... У меня для 480 MHz вышло 16 тактов вместо 26, а для 240 MHz, когда делитель AHB можно единичным сделать, вообще всего 11 тактов.
Вообще-то, есть ещё такое понятие как время. В одно время мне нужно, чтоб а равнялось б, а в другое время, чтоб с, даже если это время равно одному такту.
Для этого есть volatile. Если вам нужно именно это, то нужно описать: int volatile a, b, c; (это опять к слову о том - зачем описывать что такое a,b,c) И тогда будет работать именно так. Без volatile - как я описал выше. Если человек имел виду такой алгоритм, но написал как вы привели (без volatile) - код кривой, а написатель его - сам себе дурак. Как я уже говорил. И дело не в компиляторах/оптимизаторах, а в написателе сего недоразумения. Впрочем - у неумех всегда во всём инструмент виноват.
Опции, отключающие или ограничивающие влияние оптимизатора на код придумали для таких неверующих в его святость, как я.
Баги компиляторов есть, я же не отрицаю (и даже сам их находил и не один). Но в 99.99% случаев кривизна работы какого-то кода - заслуга не кривого компилятора, а прослойки между стулом и клавиатурой. А "опции отключающие" - придумали главным образом - для возможности отладки с привязкой к исходному коду. Так как - чем выше уровень оптимизации - тем труднее сопоставить исходный код, результирующей последовательности асм-команд. Если какие-то неумехи используют эти опции всегда (так как не умеют писать код, корректно работающий с любым уровнем оптимизации), то это говорит только об их уровне компетенции. А нормальный программист если видит, что при включении максимальной оптимизации, програмамма стала глючить, начинает искать ошибки в своём коде. А не заметает проблему под ковёр, отключая оптимизацию. Второе - признак быдлокодера, а не программиста.
Не увидел разницы в кол. ве проходов цикла, как от обозначения размерности INT так и от обозначения как FLOAT. jcxz, что вы имели в виду ?
Переменная счётчика цикла (fahr) у вас типа float. float - это значение с плавающей точкой. А значит операции с ним всегда имеют некую погрешность. А значит на 16-м шаге значение fahr будет: fahr = lower + step * 16 + delta * 16 delta будет зависеть от особенностей реализации операций FPU в данном конкретном компиляторе/МК, а также - от фазы Луны (delta может быть больше или меньше 0). А значит в каких-то случаях у вас будет 16 шагов, а в каких-то - 15 шагов.
Приоритетным является алгоритм, а не высосанные из пальца какие-то догмы.
А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего? Вот это и называется быдлокод - скомпилили одним компилятором - 16 проходов, другим - 15. Конечно виноват компилятор и не быдлокодер!
А то что число проходов приведённого цикла может зависеть от фазы Луны - ничего?
Читайте внимательно:
Цитата:
Использование float чревато лишь из-за способа представления данных, в результате которого в отсутствие чёткого понимания механизма, может быть, например, неверное сравнение в условии.
Это я написал. Поставить сюда ржущий смайлик, что ли...
Цитата:
А "опции отключающие" - придумали главным образом - для возможности отладки с привязкой к исходному коду.
Понятно. Но я уже говорил - спорить не буду. Не видите очевидного, сами себе противоречите (volatile - то же опция) - Ваше счастие. Да и куда мне, неумехе-то, у которого инструмент виноват. У меня даже понимание термина "алгоритм" другое. Неверное.
Не учитесь быдлокодингу! Если на компе float выполняется быстро, то на STM8 будет очень медленно.
С точки зрения скорости выполнения и громоздкости, float в том коде не самое страшное. Гораздо хуже то, что там ещё есть и double-операции. Их даже и не всякий ARM аппаратно осилит, а уж о STM8 - вообще молчу.
Понял, спасибо. Я пока что не гонюсь за точностью, ( кол. вом циклов ), но в будущем, при обработке ( пересчете ) данных какого то, к примеру 12 - 14 битного АЦП, учту. ---------- К стати, здесь кто то говорил, что нет какого то определенного языка С для STM8, а как же узко специализированные ( для STM8 ), команды для работы с внутренними модулями камня, команды (функции) для приема - передачи данных по различным встроенным в чип интерфейсам ?
Последний раз редактировалось sergey.UA Пт янв 08, 2021 17:36:29, всего редактировалось 1 раз.
Понял, спасибо. Я пока что не гонюсь за точностью, ( кол. вом циклов ), но в будущем, при обработке ( пересчете ) данных какого то, к примеру 12 - 14 битного АЦП, учту.
Тут дело не в точности. Корректно написанное ПО должно выполняться одинаково при работе в любом окружении и компиляции любым компилятором. А у вас будет зависеть от реализации FPU и от особенностей работы его режима округления. Поэтому типы с плавающей точкой используют только там, где это реально нужно. Для счётчика цикла они не нужны и даже вредны. И при операциях сравнения типов плавающей точки использовать операции ==, <=, >= следует осторожно, помня о погрешности и применяя вместо == проверку на диапазон. Также следует избегать алгоритмов с накоплением ошибки вычислений (как у вас, где на каждом шаге цикла ошибка вычислений delta суммируется).
К стати, здесь кто то говорил, что нет какого то определенного языка С для STM8, а как же узко специализированные ( для STM8 ), команды для работы с внутренними модулями камня, команды (функции) для приема - передачи данных по различным встроенным в чип интерфейсам ?
Нет таких команд в языке си. Как и функции - это не элементы языка.
PS: Вы бы лучше сперва учебник по си до конца дочитали, прежде чем что-то писать.
Переменная счётчика цикла (fahr) у вас типа float. float - это значение с плавающей точкой. А значит операции с ним всегда имеют некую погрешность.
Не всегда. Если число дробное, то зависит от числа, а целые числа float может хранить без погрешности вплоть до 24-х бит, так что при шаге 20 можно столкнуться с проблемами не раньше 838861 прохода
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 34
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения