Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
не очень понятно пока, зачем. Классы со сплошь public static inline void методами - имхо маленько не то, ради чего стоит использовать плюсы.
На самом деле все не так плохо, в эмбедде большинство методов и должны быть static и часто inline, хотя непонятно зачем автор при помощи #pragma явно заставляет компилятор инлайнить методы там, где они и так будут инлайниться согласно правилам языка. Вот если бы тут все методы были статические и не использовались шаблоны, тогда да, можно было бы спокойно заменить классы неймспейсами ничего особо не потеряв...
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
>> имхо маленько не то, ради чего стоит использовать плюсы К сожалению C++ для ПК и для микроконтроллеров отличается. Нельзя многое из ПК использовать в микроконтроллерах - микроконтроллер не справиться, ну и стиль программирования для микроконтроллера не имеет смысла для ПК. >> непонятно зачем автор при помощи #pragma явно заставляет компилятор инлайнить методы наличие ключевого слова inline не означает, что компилятор обязательно будет инлайнить метод (по крайней мере в IAR), для принудительного "инлайнинга" необходимо использовать #pragma. Во многих местах можно #pragma убрать и ничего не измениться, но не везде (можете по экспериментировать). Для себя решил, что если метод должен инлайнится, то наличие #pragma обязательно (в основном это касается прерываний).
наличие ключевого слова inline не означает, что компилятор обязательно будет инлайнить метод (по крайней мере в IAR), для принудительного "инлайнинга" необходимо использовать #pragma. Во многих местах можно #pragma убрать и ничего не измениться, но не везде (можете по экспериментировать). Для себя решил, что если метод должен инлайнится, то наличие #pragma обязательно (в основном это касается прерываний).
А речь не про наличие inline, а про случаи типа таких:
Тут не нужен ни inline, ни #pragma inline, в стандарте по этому поводу говорится следующее: A member function may be defined in its class definition, in which case it is an inline member function, or it may be defined outside of its class definition if it has already been declared but not defined in its class definition.
начну с "почему void". Для определения переменной Recount необходимо указать тип. Тип для Recount определяется на стадии компиляции в шаблоне в зависимости от значения (у меня это 1000, т.е тип будет uint16_t).
Код:
typedef STATIC_TYPE_UNSIGNED_VALUE(Value) T; static volatile T Recount;
Мне (по условию) не требовалось менять значение инициализации (Если алгоритм требует, то конечно можно и передать значение). Тогда будет так:
но тогда входное значение будет (должно) иметь тоже тип uint16_t. Если сразу задать тип для Recount, то придётся делать класс под каждый тип, что не целесообразно.
Ну и отсюда почему inline. Т.к. это шаблонный класс, и инициализация предполагалась только один раз поэтому код решил инлайнить, чтобы компилятор не оформил это в вызов метода.
Добавлено after 13 minutes 7 seconds: вообще всё что связано с inline появилось после того как начал заниматься прерываниями в C++.
Ты пишешь на С++, но местами как будто на С. Очень часто когда я вижу подобный код с ним в комплекте еще идут typedef struct и прочие пережитки чистого С.
Цитата:
Ну и отсюда почему inline. Т.к. это шаблонный класс, и инициализация предполагалась только один раз поэтому код решил инлайнить, чтобы компилятор не оформил это в вызов метода.
Еще раз повторяю, любой метод определенный в теле класса неявно является встроенным, т.е. инлайнится согласно правилам самого языка. Конечно можно явно прописать и inline со всякими прагмами, но это не имеет никакого значения.
>> В С++ стало так: я это знаю, это не нарушает синтаксис
>> struct в любом учебнике по C++ struct показан как public класс
по поводу inline, C++ не работает с прерываниями, это надстройка embedded. Поэтому корректной работы от компилятора ждать не приходится, надо ему помочь (ещё раз повторюсь, что сначала не было inline, он появился только после работы с прерываниями, когда результат был отрицательный)
Я ждал замечаний не по поводу синтаксиса (что пока достаточно спорно), а по организации программы, ошибкам, рекомендации
Добрый день, с С++ совсем не знаком по этому и пишу, подскажите в нем есть более удобные способы/методы распараллеливания задач(на конечных автоматах), ну скажем вот в функции инициализации LCD,
да ради бога, заходи по прерыванию таймера, а там уже свитч-кейсом выбирай какую часть кода выполнять.
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Что бы вместо DELAY_MS происходил выход в майн, и проход по всем остальным задачам
как велико ваше желание выстрелить себе в ногу? какие-такие задачи требуют от вас этого самого "распараллеливания"? вы на 100% уверены, что это необходимо?
самый лучший совет, который я могу вам дать, повторяет суть принципа бритвы Оккама: не делай то, без чего можно обойтись.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
DELAY_US нет смысла переделывать, а вот DELAY_MS особо если с большими цифрами, да работающий внутри прерывания вполне может придать контроллеру некоторую ... туповатовть. (динам. индикация может подвисать, нажатие кнопки (не на INTе) может оказаться пропущенным, "собака" не кормлена...
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Да на все 100% уверен что надо, даже функцию инициализацию надо так как, весь маин состоит из параллельных частей, а индикатор может повисать,из за внешних помех, так что приходится его передергивать(пере инициализировать).
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 36
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения