Комментарии 29
Умоляю, не надо миллиамперы делить на часы.
Доработать:
1) Перевести все на питание 3.3 вольта. STM32 в тему.
2) Переделать печатку. Как вариант — сделать на 4 слоя и отдать слой целиком под землю. Либо более грамотно перерисовать 2-х слойку. Разделить грамотно земли цифры и высоковольтной части. По возможности ВВ часть закрыть экраном. А то там сейчас полный треш творится.
3) Переработать цепь формирования импульсов счета. Возможно имеет смысл поставить формирователь с хорошим гистерезисом.
Спасибо за ваш ответ. Я уже начал приблизительно подбирать компоненты для версии на stm. Пока что определился только с дисплеем и процессором. С трансформатором нужно экспериментировать. Думал поставить на какой нибудь драйвер его, или если драйвер подобрать не получится, сделать с управлением от процессора. Насчёт формирования импульсов тоже есть пара вариантов, буду смотреть, что будет работать лучше.
Пульсации ШИМ-преобразователя нужно измерять, используя пружинку, надеваемую на земляной щуп осциллографа, вы так и делаете?
Если вы увидели на осциллографе импульсы по питанию, то первым делом измеряйте их ширину. Короткие «иглы» помогает побороть только керамика небольшой емкости, широкие — электролит. Емкость должна быть как можно ближе к потребителю (рядом с ключом импульсника).
Да, на осциллографе были короткие иглы, точную ширину не помню, т.к. мерил уже давно, а своего осциллографа не имею. Я думаю проще уже всю схему переделывать, чем пытаться бороться с этим. По питанию я в основном ставил керамику на 0.1 мкФ, возможно нужно было ставить на меньшие номиналы, потому что 100 пФ, на сколько я помню, довольно хорошо сглаживали эти иглы, но ложные срабатывания не исчезали, потому-что скачки были всё ещё в пределах одного вольта.
АВР с буквой Р в конце названия работает от 1,8 до 5,5 В. Повышайка не нужна, только если хочется разогнать выше 10 МГц.
А возможно ли сделать единый преобразователь для питания всех компонентов, на одном трансформаторе?
На входе напряжение с аккумулятора (3.0 — 4.2), на выходе — 3.3 или 5 В для логики, и высокое для трубки (возможно, с умножением). При необходимости можно добавить и другое напряжение, например 12 В для питания усилителя.
Это не совет, а вопрос к гуру.
На входе напряжение с аккумулятора (3.0 — 4.2), на выходе — 3.3 или 5 В для логики, и высокое для трубки (возможно, с умножением). При необходимости можно добавить и другое напряжение, например 12 В для питания усилителя.
Это не совет, а вопрос к гуру.
Можно конечно. Но нужно ли?
Вот на этот вопрос я и хочу знать ответ.
Плюсы вижу такие:
— полное использование заряда аккумулятора (дольше работаем на одном заряде)
— высокий КПД (еще дольше работаем на одном заряде)
— упрощение схемы: один преобразователь вместо одного
Вообще, у меня есть небольшой опыт проектирования импульсника, но очень давно, на дискретных элементах. Сейчас наверняка есть небольшие чипы, в которых уже есть все готовое. Получается довольно простая схема — небольшой чип, немного обвязки, ключ (если его нет в чипе), и трансформатор. Ну и выходные цепи — выпрямитель, умножитель.
Основную проблему вижу только одну — как сделать трансформатор. Но, возможно, я не знаю какие-то нюансы.
Если бы были только низковольтные цепи, трансформатор очень просто сделать на ферритовом колечке, число витков в обмотках там не велико. Но тут есть высоковольтная обмотка. На маленьком кольце сделать, например, тысячу витков довольно трудоемко. Но вот на Ш-образном феррите это вполне реально.
В общем, самому интересно узнать плюсы и минусы такого варианта от более опытных людей…
Плюсы вижу такие:
— полное использование заряда аккумулятора (дольше работаем на одном заряде)
— высокий КПД (еще дольше работаем на одном заряде)
— упрощение схемы: один преобразователь вместо одного
Вообще, у меня есть небольшой опыт проектирования импульсника, но очень давно, на дискретных элементах. Сейчас наверняка есть небольшие чипы, в которых уже есть все готовое. Получается довольно простая схема — небольшой чип, немного обвязки, ключ (если его нет в чипе), и трансформатор. Ну и выходные цепи — выпрямитель, умножитель.
Основную проблему вижу только одну — как сделать трансформатор. Но, возможно, я не знаю какие-то нюансы.
Если бы были только низковольтные цепи, трансформатор очень просто сделать на ферритовом колечке, число витков в обмотках там не велико. Но тут есть высоковольтная обмотка. На маленьком кольце сделать, например, тысячу витков довольно трудоемко. Но вот на Ш-образном феррите это вполне реально.
В общем, самому интересно узнать плюсы и минусы такого варианта от более опытных людей…
Так же, использование C++ вместо C в программировании микроконтроллеров это не лучшая практика
Почему вы так думаете?
Знакомые работают в DSR. Говорят, что под МК принято писать на C. При этом С++ использовать можно, но только если без него не обойтись.
Принято потому что 1-под многие МК исторически приемлемый компилятор C++ появлялся гораздо позже чем С. 2- по этой же причине С-шники старой школы в нормальный С++ просто не могут и пишут на нём как на С.Пишите на чем удобно, а не "правильно". Советчики не будут для вас код писать.
Скорее наоборот. В серьезных системах все больше применяется С++, а С остается из-за легаси, привязок к библиотекам вендоров и прочему.
Только вот не надо писать на древних стандартах, новые разработки лучше сразу на С++17 или даже 20. Там очень много полезного и приятного.
А «принято» — это наследие тяжелого прошлого.
PS Ардуиновский язык — это С++11 с препроцессингом.
Только вот не надо писать на древних стандартах, новые разработки лучше сразу на С++17 или даже 20. Там очень много полезного и приятного.
А «принято» — это наследие тяжелого прошлого.
PS Ардуиновский язык — это С++11 с препроцессингом.
Не совсем все так просто.
Оптимизировать по размеру или по скорости код, написанный на Си проще — потому что сам язык гораздо проще — логика оптимизации, соответственно, такая-же.
Если писать на C++, но не использовать ничего из его функционала (наследование, указатели т.д.) — то от Си не будет отличаться, а вот если использовать — из-за того, что оптимизация становится куда более сложной, она будет хуже.
Попытаюсь на примере объяснить — если сделать на C функцию, которая возвращает сложение параметров и просто ее вызывать и сделать статический класс на C++, и вызвать оттуда эту функцию — результат работы программы будет одинков, а вот оптимизация по размеру (например) даст разный результат — например второй результат может быть больше. Это синтетический, надуманный пример, но он объяснят что к чему.
Конечно, это зависит как от компилятора, так и от самого кода. Но использовать C++ ИМХО правильно только тогда, когда Вы точно понимаете, зачем Вы это делаете и его «плюсы» играют вам на руку.
Оптимизировать по размеру или по скорости код, написанный на Си проще — потому что сам язык гораздо проще — логика оптимизации, соответственно, такая-же.
Если писать на C++, но не использовать ничего из его функционала (наследование, указатели т.д.) — то от Си не будет отличаться, а вот если использовать — из-за того, что оптимизация становится куда более сложной, она будет хуже.
Попытаюсь на примере объяснить — если сделать на C функцию, которая возвращает сложение параметров и просто ее вызывать и сделать статический класс на C++, и вызвать оттуда эту функцию — результат работы программы будет одинков, а вот оптимизация по размеру (например) даст разный результат — например второй результат может быть больше. Это синтетический, надуманный пример, но он объяснят что к чему.
Конечно, это зависит как от компилятора, так и от самого кода. Но использовать C++ ИМХО правильно только тогда, когда Вы точно понимаете, зачем Вы это делаете и его «плюсы» играют вам на руку.
Попытаюсь на примере объяснить — если сделать на C функцию, которая возвращает сложение параметров и просто ее вызывать и сделать статический класс на C++, и вызвать оттуда эту функцию — результат работы программы будет одинков, а вот оптимизация по размеру (например) даст разный результат — например второй результат может быть больше. Это синтетический, надуманный пример, но он объяснят что к чему.
Подобные утверждения не соответствует действительности уже много лет как. А ваш конкретный пример скорее всего не соответствовал действительности никогда. Компиляторы не стоят на месте со времен книжки Страуструпа.
ничего из его функционала (наследование, указатели т.д.
Я не зря упомянул новые стандврты С++. Наследование в современном С++ используется довольно редко, а в указателях нет ничего плохого.
В то же время, даже пишучи в С-стиле на С++ вы получите гораздо более строгий контроль типов, и как следствие, уйдет куча мелких, но крайне неприятных для встроенной разработки ошибок.
А потом сами собой придут автопеременные, новый формат цикла for, tuple и еще много приятных и полезных плюшек…
Вы можете попробовать :) А получал отличия более чем в 20%, когда ставил эксперименты. Не скажу, что это прям свежее — было около 2 лет назад.
Экспериментировал с GCC и ATMEGA.
Экспериментировал с GCC и ATMEGA.
В то же время, даже пишучи в С-стиле на С++ вы получите гораздо более строгий контроль типовХм, интересно. Там базовые типы, в основном, только и используются, ну struct еще иногда, что дают новые стандарты по контролю за ними? Можно пример?
например, запрет на неявное преобразование на этапе компиляции.
Будь любезен использовать cast для этого.
поддерживаю за использование С++ в МК. Проблем с переходом не возникло, зато несколько мелких ошибок, как с приведением типов, были найдены.
Будь любезен использовать cast для этого.
поддерживаю за использование С++ в МК. Проблем с переходом не возникло, зато несколько мелких ошибок, как с приведением типов, были найдены.
Сравнил :)
Результаты компиляции с точностью до инструкции
godbolt.org/z/9n3z5G
GCC 8.2 для ARM
Вот этот код даст 5 ошибок в С++ и ни одной ошибки в С.
GCC даст 5 предупреждений, но код откомпилит. Т.е. очень легко все эти ошибки пропустить.
Причем какие компиляторы будут давать предупреждения — не специфицировано.
Результаты компиляции с точностью до инструкции
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 предупреждений, но код откомпилит. Т.е. очень легко все эти ошибки пропустить.
Причем какие компиляторы будут давать предупреждения — не специфицировано.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История разработки одного дозиметра (Часть 2)