Форум РадиоКот

ARV писал(а): Пт июн 05, 2026 09:02:19 Увижу - заткнусь навсегда.

Не нужно столь радикально.
Но посмотреть - пожалуйста:



Красным помечены интересующие вас цепи.

Не вопрос, сказал навсегда, значит, навсегда. Естественно, задавать вопросы я не прекращаю, а вот давать ответы - не буду.

Если следует уменьшить количество корпусов компонентов на печатной плате - есть Resistor‑Equipped Transistor, RET (BJT/FET транзистор + 2 резистора).
Но для схемы с индикацией можно напрямую к МК. На раб. столе работают уже много лет (+AVR/PIC/STM32/CH32 ...), ничего не происходит с МК, ни с LED.
Только LED должны светиться ярко, а китайские именно такие (напр. красные).

Спойлер

Насколько я знаю, но сопротивление в затворной цепи полевика это про сглаживание тока на заряд/разряд ёмкости затвора, которая у полевика (особенно мощного) достаточно велика и с ростом частоты управления может уже быть решающим фактором. Однако, это не мешает в некоторых схемах использовать диод для ускорения фронта или спада - зависит от направления диода (а иногда даже встречно-параллельно ставят, потому что диод это нелинейное, но всё же сопротивление). А ведь есть ещё и т.н. "цифровые" полевики (впрочем, как и биполярники).

Я полагал, что в цепи биполярных в случаях, изображённых на картинке, ускорение запирания всего лишь побочный эффект (основное назначение - защита от всплесков обратного напряжения, и, возможно, дополнительная гарантия запирания), а в случае полевых - защита затвора.
Именно ускоряющие цепочки - последовательно к цепи управления. Диод притом позволяет разделить режимы.

ARV писал(а): Пт июн 05, 2026 10:38:51 а вот давать ответы - не буду.

Ой блин, напугал ежа голой жопой Какая польза в ответах от начинающего?

Какие соппсна проблемы то с индикатором? Индикаторы типа xxxxSRWA уже при среднем токе сегмента в 2-3 мА светят уже так, что в помещении будет более чем достаточно видно. Если этого мало и хочется глазовыдерательной яркости - я выше давал модель драйвера в корпусе размером 17 х 7 мм. При этом индикатор будет хорошо виден на улице, либо через зачерненное стекло.
Сами себе придумали проблему, когда она решается "на раз".

ARV писал(а): Пт июн 05, 2026 08:18:37 Если я правильно понимаю, то технологически невозможно изготовить кристалл, в котором бы соседние транзисторные структуры отличались друг от друга сколько-нибудь существенно, если эти структуры "по схеме" одинаковы. На том стоит вся промышленность интегральных микросхем. Два пина одного порта по параметрам переключения, сопротивления каналов в открытом состоянии и утечке в закрытом, а так же по емкостям затворов и другим (паразитным) будут отличаться не более, чем никак, тысячные доли процента.

Это так, но управление ассинхронное.

ARV писал(а): Пт июн 05, 2026 08:18:37 И параллельное соединение выходов, управляемых одновременно - официально оговариваемая возможность всех логических схем, к которым, безусловно, и МК относится.

Управлять одновременно всеми внутренними входами порта внутри МК невозможно, синхронности нет и не будет(и ненужна она там), скорее ассинхронная подача сигнала на входы блоков порта, отсюда сквозной ток и неравенство токов. Одновременное объединение входов и выходов логических элементов позволительно, но есть оговорки.

В вашем случае, если так сильно хочется объединить двухтактные выходы, воспользуйтесь обычными диодами с малым падением напряжения на переходе.

Вообще-то, все сигналы внутри синхронизированы тактовым сигналом. Кто не верит - посмотрите, как работают дискретные D-триггеры.
Хотя и существуют небольшие задержки, называемые задержкой распространения, а так же переходные процессы, но в данном случае это наносекунды и менее.

Но всё равно, объединять выходы микроконтроллера напрямую - есть дурной тон. Ибо случайная программная ошибка на этапе отладки - и КЗ обеспечено. Поэтому, вместо объединения выходов ставят транзистор, как наиболее правильный и безопасный вариант. Есть "цифровые" транзисторы с внутренними резисторами.

Вообще, рассматриваемая проблема не стоит и выеденного яйца, а тут уже исписали три страницы темы. Решение было предложено уже несколько раз и в разных вариантах.

Rapra писал(а): Пт июн 05, 2026 17:19:30 Ибо случайная программная ошибка на этапе отладки - и КЗ обеспечено.

Я выше показал, что КЗ - это совсем не КЗ, а 130 Ом. И ток всего чуть выше 25 мА.
И это при том, что практически невозможно допустить ошибку приводящую к КЗ, если объединены пины одного порта.
Ибо вывод в порт - это атомарная процедура.
С другой стороны, есть огромное множество проектов с управлением силовыми цепями, где реально остановка в отладчике - это пожар.
Значит ли это, что проектирование таких устройств - это дурной тон?
Никаких проблем (СОВСЕМ НИКАКИХ) объединение пинов порта не создает. Проблема надумана от начала до конца.
Другое дело, что объединение двух пинов не удваивает ток. Некоторый небольшой разброс Rdson имеется. По опыту и на вскидку нужно отдавать на перекос процентов 10...20 тока. Для простых устройств с копеечной ценой, а значит и себестоимостью, экономия резисторов и ключей бывает обоснована. Напомню, что к стоимости элементной базы добавляется стоимость монтажа. И традиционно такие изделия имеют крошечную маржинальность и миллионные тиражи.

Transformer-V писал(а): Пт июн 05, 2026 16:53:48 Это так, но управление ассинхронное.

Лютая чушь безграмотного дилетанта.
Асинхронность в МК в принципе невозможна при передаче внутренних сигналов, а внешние сигналы и сигналы от асинхронной периферии (бывают асинхронные таймеры) синхронизируются при взаимодействии с шинами и ядром.

Rapra писал(а): Пт июн 05, 2026 17:19:30 Но всё равно, объединять выходы микроконтроллера напрямую - есть дурной тон. Ибо случайная программная ошибка на этапе отладки - и КЗ обеспечено.

Это так, но существует достаточно большая масса МК, у которых есть порты только с ОК/ОС. И при использовании таких МК в массовой продукции часто просто объединяют такие порты для управления, например, светодиодами.

помните, как все меня хаяли, что я не изучаю доки, и поэтому мой код будет ужасным, жрущим ресурсы МК и т.п.? это было, когда я сказал, что на второй день знакомства с STM32 реализовал полноценный MODBUS на чужой либе?
вот вчера я поднялся на новую вершину для себя - реализовал MODBUS не на прерываниях UART, а через DMA, и, как тут советовали, по паузе в активности UART. то есть теперь мой код намного меньше грузит МК обменом - так же?
а знаете, как я этого достиг? путем замены 0 на 1 одном из дефайнов библиотеки
вот такое программирование мне нравится. вчера код был ужасным, а сегодня стал красивым и правильным, и никто не сможет сказать, что нерационально используются ресурсы МК.

а вот доставшийся мне в наследство код был написан "настоящим" программистом, который игнорил CubeMX, и в итоге реализовал SPI-обмен чистым дрыгоногом на HAL-функциях. а я теперь должен с этим что-то делать... пока переписал дрыгоног на прямой работе с регистрами портов и уложил его в FreeRTOS-задачу, чтобы не париться лишний раз. с верхнего уровня практически имитация аппаратной работы: указал на данные, установил флаг и жди события о завершении передачи.

Да ну на? Ну за это надо выпить! Я щас как раз на даче, ща за это дело пивка бахну.
Так то я тоже умею 0 на 1 заменять. Это безусловно прорыв и подъем на новый уровень. Я когда впервые заменил 0 на 1 тоже ощутил прилив гордости за себя. Ну, за замену! Ура!
(главное, теперь понять, что это был за "один из дефайнов бибилиотеки")

я тоже вечером бахну

не очень, правда, мне понятен ваш сарказм: какою-нибудь memcpy использовать вам не зазорно, а, условно говоря, ModbusReadRegister - уже дурной тон. и та и другая функция написана не вами - так где та грань между кошерным и некошерным программированием?!

Rapra писал(а): Пт июн 26, 2026 15:45:06 главное, теперь понять, что это был за "один из дефайнов бибилиотеки"

#define ENABLE_USART_DMA 1

define ENABLE_USART_DMA 1
Уйёмаё, я тоже так умею!

ARV писал(а): Пт июн 26, 2026 15:49:03 так где та грань между кошерным и некошерным программированием?!

Разница - в понимании. Я знаю, как сделана memcpy и знаю, что она может делать, а чего не может.
Есть 10 видов программистов - первые просто составляют библиотечные функции и при первой же проблеме впадают в ступор, и вторые - используют библиотеки потому что знают, как они работают.

ARV писал(а): Пт июн 26, 2026 15:50:52 #define ENABLE_USART_DMA 1

А может memcpy копировать данные между RAM и встроенной EEPROM, знаете?

Мне кажется, уверенность "я знаю" это из разряда самообмана. Чем сильнее такая уверенность, тем громче звук разрываемых шаблонов в момент осознания истинного положения вещей. Вовремя смириться куда правильнее, чем упорствовать до конца.

Я вот проследил по коду, какие куски кода активируются по этой директиве, увидел там обращения к HAL с "говорящими" идентификаторами, и мне этого достаточно для понимания, что я все сделал правильно. Копать глубже можно, но к моей цели это не приблизит. Так и зачем тогда копать? Чтобы устать сильнее?

ARV писал(а): Пт июн 26, 2026 22:15:43 Мне кажется, уверенность "я знаю" это из разряда самообмана. Чем сильнее такая уверенность, тем громче звук разрываемых шаблонов в момент осознания истинного положения вещей.

Разрыв шаблона может случиться только у вас, поскольку чем меньше знаний, тем больше для вас чудес открывается
А если мне известно, как сделана и как работает та же memcpy, то что неожиданного может случиться и какой там самообман? Неожиданности будут только для вас, когда в очередной раз вы наступите на грабли - для вас это и будет самообман. Примером такого самообмана в данном контексте является встроенная ЕЕПРОМ - поскольку вы не читали документацию и не знаете, как она работает Вы в любом случае устанете, пока будете прыгать по граблям. Вы с этим поиском дефайна от ДМА целый месяц прыгали.

Вы так и не сказали, будет memcpy работать с erprom или нет...

Не нужно меня убеждать, что я не прав. Я выдаю качественный результат в заданный срок, значит, работу делаю хорошо, и этого достаточно.

Вы не можете знать, как работает каждая функция либси, максимум - вы имеете об этом представление. Ровно как и я.

И, как любой начинающий, я уровень своего понимания постоянно повышаю. Разница лишь в том, что делаю это не тем способом, как делали вы: я начал сразу с готового полезного и сложного проекта и постепенно его улучшаю. Если бы я начал с изучения основ, я до сих пор был бы где-то между миганием светодиодом и прерываниями от таймера. А сейчас я работаю с с printf, выводящим в usart через DMA, и сделал это самостоятельно, без чужих либ и, тем более, без вашей помощи.