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

В статье пойдёт речь про ГИП-10000. Это газоразрядная матрица постоянного тока с внешней адресацией разрешением 100х100 точек. Применялась она в таких изделиях как Электроника МС6205 и ИМГ-1. Я расскажу про то, как запустил на ней Bad Apple!! и Doom.

У любителей электроники, разобравшихся в общих чертах в процессах отражения сигнала от концов линии передачи, неизбежно возникает ряд вопросов, связанных с выбором номиналов согласующих резисторов. При согласовании на стороне источника, выбор резисторов порождает две задачи: определение волнового сопротивления линии и определение внутреннего сопротивления источника сигнала. Обе задачи решаются с помощью симуляторов. Об особенностях их применения и пойдёт речь в данных статьях.

Рано или поздно в руки любителей, начинавших с Ардуино, попадают куда более быстрые устройства. Накинув щупы осциллографа на навесные провода, они обнаруживают, что сигнал, который задумывался, как голубая линия на заглавной картинке на деле выглядит, как жёлтая. В поисках решения проблемы они приходят к весьма многогранной области знаний под названием «Целостность сигналов». И если такие её аспекты, как питание и возвратные токи относительно просты для понимания, то согласование импедансов содержит ряд контринтуитивных положений. В процессе освоения данной темы мне показалось, что материалы по ней разделены на три не слишком хорошо связанных блока:
1) теория с формулами и отсылками к 2 курсу ВУЗа
2) гипертрофированные примеры на симуляторах
3) применение на практике (с эмпирическими суевериями)

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

Всем привет! В процессе работы над гексаподом AIWM я все чаще задумывался о каком-нибудь удобном интерфейсе для общения с ним. В результате тесной работы с Linux через терминал я подумал, а почему бы не использовать такой же интерфейс и в гексаподе? Я был очень удивлен, что по запросу "STM32 terminal" я не нашел готовых реализаций. Ну раз нет готовых, то напишем свою реализацию терминального сервера, которую можно использовать в микроконтроллерах. Сделаем это без использования динамической памяти и прочих опасных радостей.

Задача состояла в подключении файлов: HTML, JS, CSS; без специальной подготовки. Так же неудобно подключать бинарные файлы (например картинки) конвертируя их в HEX. Так как не хотелось конвертировать в HEX или разделять на строки, искал способ подключения файла в адресное пространство программы.

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

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

Привет, Хабр!

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

Компоненты, схема, плата, производство в Китае и результаты, обо всём этом –– под катом.

Scanning.

Создание кастомного сервиса и тем более клиента Bluetooth Low Energy – прогулка по граблям с завязанными глазами. По крайне мере так было для меня 4 года назад, когда я только начинал работать с BLE-устройствами. Сейчас почти каждый мой проект предусматривает использование этого протокола, поэтому в свое время пришлось в нем долго и мучительно разбираться. 

Разложить все по полкам помогла книга Мохаммада Афане "Intro to Bluetooth Low Energy" и серия постов на Novel Bits. Лично для меня эта книга стала настоящим открытием. Изначально я делал ее перевод на русский для своих коллег, не имеющим опыт работы с BLE. С согласия автора (огромное ему спасибо) решил опубликовать свою работу здесь. Надеюсь, перевод окажется полезным.

Это первая часть перевода (всего их будет 5), которая рассказывает, что такое BLE, ее возможности и отличия от Bluetooth Classic и описывает архитектуру протокола.

Перевод статьи подготовлен в преддверии старта курса «Backend-разработчик на PHP»

(Читать первую часть)

После релиза PHP версии 7.3 я решил уделить больше внимания развитию PHP: что собственно развивается и в каком направлении искать понимание потенциала и оптимизации этого невероятно популярного языка программирования.

В результате поиска лаконичного списка функций, реализованных PHP за время разработки PHP v7.x, я решил составить список сам - приятное дополнение, которое, я думаю, кому-то тоже может пригодиться.

За основу мы возьмем PHP 5.6 и рассмотрим, что было добавлено и изменено. Я также добавил везде где смог ссылки на официальную документацию по каждой из упомянутых фич, поэтому, если вам вдруг понадобится получить более подробную информацию - пожалуйста.

• Гальваническая развязка входа и нагрузки
• Коммутация индуктивных нагрузок без выбросов тока и напряжения
• Отсутствие значимого тепловыделения даже на максимальной мощности

Никак не можете найти ту самую ссылку на цветовые профили для Wireshark? Забыли, на каком сайте видели удобную стойку для Site Survey? Какой адаптер подходит для Packet Capture на Windows? Закладка с таблицей модуляций осталась в другом браузере?

Мы тоже от этого устали.

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

Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?

Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".

Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.