Как стать автором
Обновить

Комментарии 29

Умоляю, не надо миллиамперы делить на часы.

А можно делить ватты на часы?
Только для вычисления скорости изменения мощности.
А в чём измерять ёмкость батареи?
В ампер-часах. Амперы умножаем на часы.

Доработать:
1) Перевести все на питание 3.3 вольта. STM32 в тему.
2) Переделать печатку. Как вариант — сделать на 4 слоя и отдать слой целиком под землю. Либо более грамотно перерисовать 2-х слойку. Разделить грамотно земли цифры и высоковольтной части. По возможности ВВ часть закрыть экраном. А то там сейчас полный треш творится.
3) Переработать цепь формирования импульсов счета. Возможно имеет смысл поставить формирователь с хорошим гистерезисом.

Спасибо за ваш ответ. Я уже начал приблизительно подбирать компоненты для версии на stm. Пока что определился только с дисплеем и процессором. С трансформатором нужно экспериментировать. Думал поставить на какой нибудь драйвер его, или если драйвер подобрать не получится, сделать с управлением от процессора. Насчёт формирования импульсов тоже есть пара вариантов, буду смотреть, что будет работать лучше.
Пульсации ШИМ-преобразователя нужно измерять, используя пружинку, надеваемую на земляной щуп осциллографа, вы так и делаете?
Нет, не знал об этом. Замеры были не конкретно с шима, а по питанию 5 вольт, близ преобразователя.
Если вы увидели на осциллографе импульсы по питанию, то первым делом измеряйте их ширину. Короткие «иглы» помогает побороть только керамика небольшой емкости, широкие — электролит. Емкость должна быть как можно ближе к потребителю (рядом с ключом импульсника).
Да, на осциллографе были короткие иглы, точную ширину не помню, т.к. мерил уже давно, а своего осциллографа не имею. Я думаю проще уже всю схему переделывать, чем пытаться бороться с этим. По питанию я в основном ставил керамику на 0.1 мкФ, возможно нужно было ставить на меньшие номиналы, потому что 100 пФ, на сколько я помню, довольно хорошо сглаживали эти иглы, но ложные срабатывания не исчезали, потому-что скачки были всё ещё в пределах одного вольта.

Переделывать. Посмотри на печатку. Здоровые полигоны, соединенные с землей одним переходным отверстием. Или цепочка полигонов с тонкими дорожками между ними. Однозначно неудачный дизайн.

А возможно ли сделать единый преобразователь для питания всех компонентов, на одном трансформаторе?
На входе напряжение с аккумулятора (3.0 — 4.2), на выходе — 3.3 или 5 В для логики, и высокое для трубки (возможно, с умножением). При необходимости можно добавить и другое напряжение, например 12 В для питания усилителя.
Это не совет, а вопрос к гуру.
Можно конечно. Но нужно ли?
Вот на этот вопрос я и хочу знать ответ.

Плюсы вижу такие:
— полное использование заряда аккумулятора (дольше работаем на одном заряде)
— высокий КПД (еще дольше работаем на одном заряде)
— упрощение схемы: один преобразователь вместо одного

Вообще, у меня есть небольшой опыт проектирования импульсника, но очень давно, на дискретных элементах. Сейчас наверняка есть небольшие чипы, в которых уже есть все готовое. Получается довольно простая схема — небольшой чип, немного обвязки, ключ (если его нет в чипе), и трансформатор. Ну и выходные цепи — выпрямитель, умножитель.
Основную проблему вижу только одну — как сделать трансформатор. Но, возможно, я не знаю какие-то нюансы.
Если бы были только низковольтные цепи, трансформатор очень просто сделать на ферритовом колечке, число витков в обмотках там не велико. Но тут есть высоковольтная обмотка. На маленьком кольце сделать, например, тысячу витков довольно трудоемко. Но вот на Ш-образном феррите это вполне реально.
В общем, самому интересно узнать плюсы и минусы такого варианта от более опытных людей…
упрощение схемы: один преобразователь вместо одного
Вы не сможете при помощи одного преобразователя стабилизировать несколько напряжений.
Подумал. А ведь точно! Это уже аргумент.
Остается понять, насколько не стабильным может быть высокое…
В паспорте от счёткика ответ сей кроется...
Так же, использование C++ вместо C в программировании микроконтроллеров это не лучшая практика

Почему вы так думаете?
Знакомые работают в DSR. Говорят, что под МК принято писать на C. При этом С++ использовать можно, но только если без него не обойтись.

Принято потому что 1-под многие МК исторически приемлемый компилятор C++ появлялся гораздо позже чем С. 2- по этой же причине С-шники старой школы в нормальный С++ просто не могут и пишут на нём как на С.Пишите на чем удобно, а не "правильно". Советчики не будут для вас код писать.

Скорее наоборот. В серьезных системах все больше применяется С++, а С остается из-за легаси, привязок к библиотекам вендоров и прочему.

Только вот не надо писать на древних стандартах, новые разработки лучше сразу на С++17 или даже 20. Там очень много полезного и приятного.
А «принято» — это наследие тяжелого прошлого.

PS Ардуиновский язык — это С++11 с препроцессингом.
Не совсем все так просто.

Оптимизировать по размеру или по скорости код, написанный на Си проще — потому что сам язык гораздо проще — логика оптимизации, соответственно, такая-же.

Если писать на C++, но не использовать ничего из его функционала (наследование, указатели т.д.) — то от Си не будет отличаться, а вот если использовать — из-за того, что оптимизация становится куда более сложной, она будет хуже.

Попытаюсь на примере объяснить — если сделать на C функцию, которая возвращает сложение параметров и просто ее вызывать и сделать статический класс на C++, и вызвать оттуда эту функцию — результат работы программы будет одинков, а вот оптимизация по размеру (например) даст разный результат — например второй результат может быть больше. Это синтетический, надуманный пример, но он объяснят что к чему.

Конечно, это зависит как от компилятора, так и от самого кода. Но использовать C++ ИМХО правильно только тогда, когда Вы точно понимаете, зачем Вы это делаете и его «плюсы» играют вам на руку.
Попытаюсь на примере объяснить — если сделать на C функцию, которая возвращает сложение параметров и просто ее вызывать и сделать статический класс на C++, и вызвать оттуда эту функцию — результат работы программы будет одинков, а вот оптимизация по размеру (например) даст разный результат — например второй результат может быть больше. Это синтетический, надуманный пример, но он объяснят что к чему.

Подобные утверждения не соответствует действительности уже много лет как. А ваш конкретный пример скорее всего не соответствовал действительности никогда. Компиляторы не стоят на месте со времен книжки Страуструпа.

ничего из его функционала (наследование, указатели т.д.

Я не зря упомянул новые стандврты С++. Наследование в современном С++ используется довольно редко, а в указателях нет ничего плохого.
В то же время, даже пишучи в С-стиле на С++ вы получите гораздо более строгий контроль типов, и как следствие, уйдет куча мелких, но крайне неприятных для встроенной разработки ошибок.
А потом сами собой придут автопеременные, новый формат цикла for, tuple и еще много приятных и полезных плюшек…

Вы можете попробовать :) А получал отличия более чем в 20%, когда ставил эксперименты. Не скажу, что это прям свежее — было около 2 лет назад.
Экспериментировал с GCC и ATMEGA.
В то же время, даже пишучи в С-стиле на С++ вы получите гораздо более строгий контроль типов
Хм, интересно. Там базовые типы, в основном, только и используются, ну struct еще иногда, что дают новые стандарты по контролю за ними? Можно пример?
например, запрет на неявное преобразование на этапе компиляции.
Будь любезен использовать cast для этого.

поддерживаю за использование С++ в МК. Проблем с переходом не возникло, зато несколько мелких ошибок, как с приведением типов, были найдены.

Если про неявное типа long/float в int и т. д., то емнип варнинги всегда GCC кидает, только если не стоит спец. настроек.

Сравнил :)
Результаты компиляции с точностью до инструкции
godbolt.org/z/9n3z5G
GCC 8.2 для ARM

    int arr[3] = {0, 1, 3, 4};
    int b = 1;
    int * b_ptr = b;
    int * b_ptr_ptr = &b_ptr;
    short c = b;
    short *c_ptr = &b;
    struct STRUCT *a = b;


Вот этот код даст 5 ошибок в С++ и ни одной ошибки в С.
GCC даст 5 предупреждений, но код откомпилит. Т.е. очень легко все эти ошибки пропустить.
Причем какие компиляторы будут давать предупреждения — не специфицировано.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.