#ошибки_проектирования — Public Fediverse posts

Отверстия в печатных платах: 8 ошибок, которые делают плату более дорогой и менее надежной

Каждый день я открываю десятки проектов, и первое, на что смотрю это файл сверловки. Можно сразу сказать, где разработчик понимал, что делает, а где просто "нарисовал как в прошлый раз". Самое обидное, когда ошибки в проектировании отверстий всплывают уже на производстве: плату приходится переделывать, сроки горят, бюджет летит в трубу. Давайте на пальцах разберем, какие ошибки в проектировании отверстий встречаются чаще всего и как их избежать, чтобы не переплачивать и получать надежные платы с первого раза. Прежде чем начнем: какие вообще бывают отверстия? Для начала договоримся о терминах. Отверстия в печатных платах бывают:

https://habr.com/ru/companies/electroconnect/articles/1002830/

#печатная_плата #проектирование #электроника #переходное_отверстие #минимальное_отверстие #ошибки_проектирования #глухое_отверстие #слепое_отверстие #сквозное_отверстие #топология

Отверстия в печатных платах: 8 ошибок, которые делают плату более дорогой и менее надежной

Каждый день я открываю десятки проектов, и первое, на что смотрю это файл сверловки. Можно сразу сказать, где разработчик понимал, что делает, а где просто "нарисовал как в прошлый раз". Самое обидное, когда ошибки в проектировании отверстий всплывают уже на производстве: плату приходится переделывать, сроки горят, бюджет летит в трубу. Давайте на пальцах разберем, какие ошибки в проектировании отверстий встречаются чаще всего и как их избежать, чтобы не переплачивать и получать надежные платы с первого раза. Прежде чем начнем: какие вообще бывают отверстия? Для начала договоримся о терминах. Отверстия в печатных платах бывают:

https://habr.com/ru/companies/electroconnect/articles/1002830/

#печатная_плата #проектирование #электроника #переходное_отверстие #минимальное_отверстие #ошибки_проектирования #глухое_отверстие #слепое_отверстие #сквозное_отверстие #топология

Отверстия в печатных платах: 8 ошибок, которые делают плату более дорогой и менее надежной

Каждый день я открываю десятки проектов, и первое, на что смотрю это файл сверловки. Можно сразу сказать, где разработчик понимал, что делает, а где просто "нарисовал как в прошлый раз". Самое обидное, когда ошибки в проектировании отверстий всплывают уже на производстве: плату приходится переделывать, сроки горят, бюджет летит в трубу. Давайте на пальцах разберем, какие ошибки в проектировании отверстий встречаются чаще всего и как их избежать, чтобы не переплачивать и получать надежные платы с первого раза. Прежде чем начнем: какие вообще бывают отверстия? Для начала договоримся о терминах. Отверстия в печатных платах бывают:

https://habr.com/ru/companies/electroconnect/articles/1002830/

#печатная_плата #проектирование #электроника #переходное_отверстие #минимальное_отверстие #ошибки_проектирования #глухое_отверстие #слепое_отверстие #сквозное_отверстие #топология

Отверстия в печатных платах: 8 ошибок, которые делают плату более дорогой и менее надежной

Каждый день я открываю десятки проектов, и первое, на что смотрю это файл сверловки. Можно сразу сказать, где разработчик понимал, что делает, а где просто "нарисовал как в прошлый раз". Самое обидное, когда ошибки в проектировании отверстий всплывают уже на производстве: плату приходится переделывать, сроки горят, бюджет летит в трубу. Давайте на пальцах разберем, какие ошибки в проектировании отверстий встречаются чаще всего и как их избежать, чтобы не переплачивать и получать надежные платы с первого раза. Прежде чем начнем: какие вообще бывают отверстия? Для начала договоримся о терминах. Отверстия в печатных платах бывают:

https://habr.com/ru/companies/electroconnect/articles/1002830/

#печатная_плата #проектирование #электроника #переходное_отверстие #минимальное_отверстие #ошибки_проектирования #глухое_отверстие #слепое_отверстие #сквозное_отверстие #топология

ТОП-10 ошибок проектирования печатных плат

Работая в «ЭЛЕКТРОконнект» более 30 лет , я ежедневно вижу десятки самых разных проектов и успел заметить, что многие ошибки у начинающих (и не только!) инженеров — одни и те же. Поэтому решил собрать свой личный Топ-10 ошибок при проектировании печатных плат, с которыми мы сталкиваемся чаще всего. Надеюсь, мой опыт поможет вам сэкономить нервы, время и бюджет. 1. «Волосок» вместо надежного соединения Я постоянно вижу, как проводник еле-еле «царапает» контактную площадку. DRC такую ошибку не найдет — контакт-то есть! Но на деле это мина замедленного действия: дорожка может перегореть от тока, для которого не рассчитана, или испортить целостность сигнала. Мой совет: в том же Altium Designer настройте правило Unrouted Net → Check for incomplete connections. Оно отловит эти «волоски».

https://habr.com/ru/companies/electroconnect/articles/973522/

#печатная_плата #проектирование_платы #схема_печатной_платы #трассировка #ЭЛЕКТРОконнект #проводник_печатной_платы #отверстие_печатной_платы #ошибки_проектирования #дорожки_печатной_платы

ТОП-10 ошибок проектирования печатных плат

Работая в «ЭЛЕКТРОконнект» более 30 лет , я ежедневно вижу десятки самых разных проектов и успел заметить, что многие ошибки у начинающих (и не только!) инженеров — одни и те же. Поэтому решил собрать свой личный Топ-10 ошибок при проектировании печатных плат, с которыми мы сталкиваемся чаще всего. Надеюсь, мой опыт поможет вам сэкономить нервы, время и бюджет. 1. «Волосок» вместо надежного соединения Я постоянно вижу, как проводник еле-еле «царапает» контактную площадку. DRC такую ошибку не найдет — контакт-то есть! Но на деле это мина замедленного действия: дорожка может перегореть от тока, для которого не рассчитана, или испортить целостность сигнала. Мой совет: в том же Altium Designer настройте правило Unrouted Net → Check for incomplete connections. Оно отловит эти «волоски».

https://habr.com/ru/companies/electroconnect/articles/973522/

#печатная_плата #проектирование_платы #схема_печатной_платы #трассировка #ЭЛЕКТРОконнект #проводник_печатной_платы #отверстие_печатной_платы #ошибки_проектирования #дорожки_печатной_платы

ТОП-10 ошибок проектирования печатных плат

Работая в «ЭЛЕКТРОконнект» более 30 лет , я ежедневно вижу десятки самых разных проектов и успел заметить, что многие ошибки у начинающих (и не только!) инженеров — одни и те же. Поэтому решил собрать свой личный Топ-10 ошибок при проектировании печатных плат, с которыми мы сталкиваемся чаще всего. Надеюсь, мой опыт поможет вам сэкономить нервы, время и бюджет. 1. «Волосок» вместо надежного соединения Я постоянно вижу, как проводник еле-еле «царапает» контактную площадку. DRC такую ошибку не найдет — контакт-то есть! Но на деле это мина замедленного действия: дорожка может перегореть от тока, для которого не рассчитана, или испортить целостность сигнала. Мой совет: в том же Altium Designer настройте правило Unrouted Net → Check for incomplete connections. Оно отловит эти «волоски».

https://habr.com/ru/companies/electroconnect/articles/973522/

#печатная_плата #проектирование_платы #схема_печатной_платы #трассировка #ЭЛЕКТРОконнект #проводник_печатной_платы #отверстие_печатной_платы #ошибки_проектирования #дорожки_печатной_платы

ТОП-10 ошибок проектирования печатных плат

Работая в «ЭЛЕКТРОконнект» более 30 лет , я ежедневно вижу десятки самых разных проектов и успел заметить, что многие ошибки у начинающих (и не только!) инженеров — одни и те же. Поэтому решил собрать свой личный Топ-10 ошибок при проектировании печатных плат, с которыми мы сталкиваемся чаще всего. Надеюсь, мой опыт поможет вам сэкономить нервы, время и бюджет. 1. «Волосок» вместо надежного соединения Я постоянно вижу, как проводник еле-еле «царапает» контактную площадку. DRC такую ошибку не найдет — контакт-то есть! Но на деле это мина замедленного действия: дорожка может перегореть от тока, для которого не рассчитана, или испортить целостность сигнала. Мой совет: в том же Altium Designer настройте правило Unrouted Net → Check for incomplete connections. Оно отловит эти «волоски».

https://habr.com/ru/companies/electroconnect/articles/973522/

#печатная_плата #проектирование_платы #схема_печатной_платы #трассировка #ЭЛЕКТРОконнект #проводник_печатной_платы #отверстие_печатной_платы #ошибки_проектирования #дорожки_печатной_платы

[Перевод] Как менеджеры становятся причиной ИТ-катастроф

«Зачем беспокоиться о том, чего не произойдёт?» Этот вопрос председателя КГБ Чаркова из сериала «Чернобыль» может стать хорошей эпитафией для сотен закончившихся катастрофами проектов по разработке, модернизации и эксплуатации ПО. Провалы в этой сфере происходят везде, они не зависят от страны и размеров компаний. Они случаются в коммерческих, некоммерческих и государственных организациях, вне зависимости от статуса и репутации. За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни. Не стоит и надеяться на то, что ИИ-помощники и кодинг-копилоты вскоре обеспечат успех крупномасштабных ИТ-проектов. В обозримом будущем возможности ИИ в контролировании миллиона аспектов и компромиссов системной разработки, управления проектами, финансами и бизнесом останутся сильно ограниченными. Лишь немногие ИТ-проекты демонстрируют примеры рационального принятия решений, на которых может учиться ИИ. Как знают люди, занимающиеся разработкой ПО, такие проекты и так страдают от галлюцинаций и иллюзий руководства, поэтому ИИ лишь усугубит ситуацию. Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.

https://habr.com/ru/companies/ruvds/articles/970836/

#управление_проектами #ошибки_управления #сложные_системы #ошибки_проектирования #ruvds_перевод

[Перевод] Как менеджеры становятся причиной ИТ-катастроф

«Зачем беспокоиться о том, чего не произойдёт?» Этот вопрос председателя КГБ Чаркова из сериала «Чернобыль» может стать хорошей эпитафией для сотен закончившихся катастрофами проектов по разработке, модернизации и эксплуатации ПО. Провалы в этой сфере происходят везде, они не зависят от страны и размеров компаний. Они случаются в коммерческих, некоммерческих и государственных организациях, вне зависимости от статуса и репутации. За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни. Не стоит и надеяться на то, что ИИ-помощники и кодинг-копилоты вскоре обеспечат успех крупномасштабных ИТ-проектов. В обозримом будущем возможности ИИ в контролировании миллиона аспектов и компромиссов системной разработки, управления проектами, финансами и бизнесом останутся сильно ограниченными. Лишь немногие ИТ-проекты демонстрируют примеры рационального принятия решений, на которых может учиться ИИ. Как знают люди, занимающиеся разработкой ПО, такие проекты и так страдают от галлюцинаций и иллюзий руководства, поэтому ИИ лишь усугубит ситуацию. Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.

https://habr.com/ru/companies/ruvds/articles/970836/

#управление_проектами #ошибки_управления #сложные_системы #ошибки_проектирования #ruvds_перевод

[Перевод] Как менеджеры становятся причиной ИТ-катастроф

«Зачем беспокоиться о том, чего не произойдёт?» Этот вопрос председателя КГБ Чаркова из сериала «Чернобыль» может стать хорошей эпитафией для сотен закончившихся катастрофами проектов по разработке, модернизации и эксплуатации ПО. Провалы в этой сфере происходят везде, они не зависят от страны и размеров компаний. Они случаются в коммерческих, некоммерческих и государственных организациях, вне зависимости от статуса и репутации. За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни. Не стоит и надеяться на то, что ИИ-помощники и кодинг-копилоты вскоре обеспечат успех крупномасштабных ИТ-проектов. В обозримом будущем возможности ИИ в контролировании миллиона аспектов и компромиссов системной разработки, управления проектами, финансами и бизнесом останутся сильно ограниченными. Лишь немногие ИТ-проекты демонстрируют примеры рационального принятия решений, на которых может учиться ИИ. Как знают люди, занимающиеся разработкой ПО, такие проекты и так страдают от галлюцинаций и иллюзий руководства, поэтому ИИ лишь усугубит ситуацию. Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.

https://habr.com/ru/companies/ruvds/articles/970836/

#управление_проектами #ошибки_управления #сложные_системы #ошибки_проектирования #ruvds_перевод

[Перевод] Как менеджеры становятся причиной ИТ-катастроф

«Зачем беспокоиться о том, чего не произойдёт?» Этот вопрос председателя КГБ Чаркова из сериала «Чернобыль» может стать хорошей эпитафией для сотен закончившихся катастрофами проектов по разработке, модернизации и эксплуатации ПО. Провалы в этой сфере происходят везде, они не зависят от страны и размеров компаний. Они случаются в коммерческих, некоммерческих и государственных организациях, вне зависимости от статуса и репутации. За двадцать лет мировые траты на ИТ в расчёте на доллары 2025 года увеличились втрое, с 1,7 триллиона до 5,6 триллиона, и продолжают расти. Несмотря на дополнительные траты, показатели успеха за эти годы повысились незначительно. Из-за этого потери бизнесов и общества становятся всё серьёзнее, ведь ПО проникает во всё большее количество аспектов нашей жизни. Не стоит и надеяться на то, что ИИ-помощники и кодинг-копилоты вскоре обеспечат успех крупномасштабных ИТ-проектов. В обозримом будущем возможности ИИ в контролировании миллиона аспектов и компромиссов системной разработки, управления проектами, финансами и бизнесом останутся сильно ограниченными. Лишь немногие ИТ-проекты демонстрируют примеры рационального принятия решений, на которых может учиться ИИ. Как знают люди, занимающиеся разработкой ПО, такие проекты и так страдают от галлюцинаций и иллюзий руководства, поэтому ИИ лишь усугубит ситуацию. Как я говорил двадцать лет назад, причинами краха проектов часто становятся крах человеческого воображения, нереалистичные или несформулированные цели проектов, неспособность справиться со сложностью проекта или неучтённые риски. Всё это регулярно приводит к ИТ-катастрофам и сегодня. Существует и множество других причин, часть которых выявил глава кафедры бизнес-технологий Школы бизнеса Университета Виллановы Стефен Андриоле; его диаграмма, показанная ниже, впервые была опубликована в Forbes в 2021 году. Было бы крайне удивительно обнаружить проект, потерпевший крах каким-то уникальным, незадокументированным ранее образом, потому что подавляющее большинство таких неудач вызваны вполне преодолимыми факторами, за десятки лет изложенными в сотнях отчётов, научных исследований, технических книг и учебников по управлению. Читая литературу о таких катастрофах, часто испытываешь дежавю.

https://habr.com/ru/companies/ruvds/articles/970836/

#управление_проектами #ошибки_управления #сложные_системы #ошибки_проектирования #ruvds_перевод

Мой опыт over-engineering: как 4 микросервиса на Spring Boot убили pet-проект

История о том, как попытка построить «идеальную» архитектуру для простой задачи обернулась системой из 4 сервисов, потребляющей 8 ГБ ОЗУ и 15 ГБ диска. Разбираю свои ошибки и выводы, которые помогут не повторять их другим разработчикам.

https://habr.com/ru/articles/950768/

#java #spring #микросервисы #архитектура_приложений #ошибки_проектирования

Мой опыт over-engineering: как 4 микросервиса на Spring Boot убили pet-проект

История о том, как попытка построить «идеальную» архитектуру для простой задачи обернулась системой из 4 сервисов, потребляющей 8 ГБ ОЗУ и 15 ГБ диска. Разбираю свои ошибки и выводы, которые помогут не повторять их другим разработчикам.

https://habr.com/ru/articles/950768/

#java #spring #микросервисы #архитектура_приложений #ошибки_проектирования

Мой опыт over-engineering: как 4 микросервиса на Spring Boot убили pet-проект

История о том, как попытка построить «идеальную» архитектуру для простой задачи обернулась системой из 4 сервисов, потребляющей 8 ГБ ОЗУ и 15 ГБ диска. Разбираю свои ошибки и выводы, которые помогут не повторять их другим разработчикам.

https://habr.com/ru/articles/950768/

#java #spring #микросервисы #архитектура_приложений #ошибки_проектирования

Мой опыт over-engineering: как 4 микросервиса на Spring Boot убили pet-проект

История о том, как попытка построить «идеальную» архитектуру для простой задачи обернулась системой из 4 сервисов, потребляющей 8 ГБ ОЗУ и 15 ГБ диска. Разбираю свои ошибки и выводы, которые помогут не повторять их другим разработчикам.

https://habr.com/ru/articles/950768/

#java #spring #микросервисы #архитектура_приложений #ошибки_проектирования

Почему не стоит бездумно использовать SSO

Приветствую! Меня зовут Артём. Я без малого четверть века работаю в IT. За это время у меня как-то сама собой сформировалась так называемая «аура тестировщика». Зачастую мне не приходится прилагать каких бы то ни было усилий, чтобы натыкаться на недоработки, ошибки проектирования и вполне себе конкретные баги в различных продуктах. Это касается не только IT но и повседневных вещей. Сегодня я хочу рассказать о своём видении причин недопустимости повсеместного SSO с завязкой на номер телефона. Рассказать я хочу не с точки зрения безопасности (атаки с угоном номера и т. д.), а на пример банальной ситуации с которой я столкнулся лично и которую из-за ошибки проектирования невозможно решить никаким приемлемым способом.

https://habr.com/ru/articles/863454/

#SSO #ошибки_проектирования #нестандартные_ситуации

Почему не стоит бездумно использовать SSO

Приветствую! Меня зовут Артём. Я без малого четверть века работаю в IT. За это время у меня как-то сама собой сформировалась так называемая «аура тестировщика». Зачастую мне не приходится прилагать каких бы то ни было усилий, чтобы натыкаться на недоработки, ошибки проектирования и вполне себе конкретные баги в различных продуктах. Это касается не только IT но и повседневных вещей. Сегодня я хочу рассказать о своём видении причин недопустимости повсеместного SSO с завязкой на номер телефона. Рассказать я хочу не с точки зрения безопасности (атаки с угоном номера и т. д.), а на пример банальной ситуации с которой я столкнулся лично и которую из-за ошибки проектирования невозможно решить никаким приемлемым способом.

https://habr.com/ru/articles/863454/

#SSO #ошибки_проектирования #нестандартные_ситуации

Почему не стоит бездумно использовать SSO

Приветствую! Меня зовут Артём. Я без малого четверть века работаю в IT. За это время у меня как-то сама собой сформировалась так называемая «аура тестировщика». Зачастую мне не приходится прилагать каких бы то ни было усилий, чтобы натыкаться на недоработки, ошибки проектирования и вполне себе конкретные баги в различных продуктах. Это касается не только IT но и повседневных вещей. Сегодня я хочу рассказать о своём видении причин недопустимости повсеместного SSO с завязкой на номер телефона. Рассказать я хочу не с точки зрения безопасности (атаки с угоном номера и т. д.), а на пример банальной ситуации с которой я столкнулся лично и которую из-за ошибки проектирования невозможно решить никаким приемлемым способом.

https://habr.com/ru/articles/863454/

#SSO #ошибки_проектирования #нестандартные_ситуации

Почему не стоит бездумно использовать SSO

Приветствую! Меня зовут Артём. Я без малого четверть века работаю в IT. За это время у меня как-то сама собой сформировалась так называемая «аура тестировщика». Зачастую мне не приходится прилагать каких бы то ни было усилий, чтобы натыкаться на недоработки, ошибки проектирования и вполне себе конкретные баги в различных продуктах. Это касается не только IT но и повседневных вещей. Сегодня я хочу рассказать о своём видении причин недопустимости повсеместного SSO с завязкой на номер телефона. Рассказать я хочу не с точки зрения безопасности (атаки с угоном номера и т. д.), а на пример банальной ситуации с которой я столкнулся лично и которую из-за ошибки проектирования невозможно решить никаким приемлемым способом.

https://habr.com/ru/articles/863454/

#SSO #ошибки_проектирования #нестандартные_ситуации

STM32 — грамотно включаемся от кнопки

Наличие у контроллеров STM32, да и практически любых других, режима энергосбережения STANDBY, который фактически представляет собой полное отключение (работает только RTC и сторожевой таймер, потребление составляет первые микроамперы, а состояние не сохраняется), дает возможность простейшим способом сделать включение и выключение устройства на таком МК нажатием кнопки, в том числе и задействованной под другие функции, без каких-либо дополнительных элементов. Есть, однако, несколько подводных камней, и в этой статье я расскажу, как на них не попасть.

https://habr.com/ru/articles/690376/

#stm #stm32 #кнопка #энергосберегающий_режим #ошибки_проектирования

STM32 — грамотно включаемся от кнопки

Наличие у контроллеров STM32, да и практически любых других, режима энергосбережения STANDBY, который фактически представляет собой полное отключение (работает только RTC и сторожевой таймер, потребление составляет первые микроамперы, а состояние не сохраняется), дает возможность простейшим способом сделать включение и выключение устройства на таком МК нажатием кнопки, в том числе и задействованной под другие функции, без каких-либо дополнительных элементов. Есть, однако, несколько подводных камней, и в этой статье я расскажу, как на них не попасть.

https://habr.com/ru/articles/690376/

#stm #stm32 #кнопка #энергосберегающий_режим #ошибки_проектирования

STM32 — грамотно включаемся от кнопки

Наличие у контроллеров STM32, да и практически любых других, режима энергосбережения STANDBY, который фактически представляет собой полное отключение (работает только RTC и сторожевой таймер, потребление составляет первые микроамперы, а состояние не сохраняется), дает возможность простейшим способом сделать включение и выключение устройства на таком МК нажатием кнопки, в том числе и задействованной под другие функции, без каких-либо дополнительных элементов. Есть, однако, несколько подводных камней, и в этой статье я расскажу, как на них не попасть.

https://habr.com/ru/articles/690376/

#stm #stm32 #кнопка #энергосберегающий_режим #ошибки_проектирования

STM32 — грамотно включаемся от кнопки

Наличие у контроллеров STM32, да и практически любых других, режима энергосбережения STANDBY, который фактически представляет собой полное отключение (работает только RTC и сторожевой таймер, потребление составляет первые микроамперы, а состояние не сохраняется), дает возможность простейшим способом сделать включение и выключение устройства на таком МК нажатием кнопки, в том числе и задействованной под другие функции, без каких-либо дополнительных элементов. Есть, однако, несколько подводных камней, и в этой статье я расскажу, как на них не попасть.

https://habr.com/ru/articles/690376/

#stm #stm32 #кнопка #энергосберегающий_режим #ошибки_проектирования