Как бороться с шумами и всплесками в схемах?
Что нужно прочитать чтобы понять куда надо ставить резисторы, конденсаторы, диоды, дроссели?
Желательно не 1000+ страниц.
Собираю схему на микроконтроллере и при включении то пины ломаются переставая шим правильно выдавать, то контроллер дисплея сгорит.
Всем привет. Буду хвастаться.
Я смотрю некоторым зашли мои рукоблудия а посему поделюсь ещё..
Кратко в статье будет:
Что же не так в первой же картинке: хоть и выглядит вполне аккуратно, или сказ о наводках и СВЧ чёрной цифровой магии и почему так делать нельзя.
Немного об отладочной плате FPGA и особенностях разработки.
О модуле камеры, её сенсоре, MIPI интерфейсе и как его испортить.Как сделать связь с ПК в сотни мегабит, менее 100мбит/сек, и как в том числе и тут словить кару.
Внимание: в статье несколько хайрез фоток и видео, много тех терминов и лютого DIY, возможен взрыв мозга!
Начнём с пациента:
Что это на фото?
1. Белая плата - мозги: FPGA плата на базе Artix-7 от Xilinx, подключена к ПК по micro USB для прошивки и отладочных логов
2. Мини плата слева сверху - FTDI, обещала "скоростную" связь с компом...
3. Синяя плата справа сверху - сам модуль скоростной камеры с пимпкой "объектива" (извиняюсь за ругательство).
4. Куча проводков от ардуины.
Требовалось:
Захватить видеопоток с камеры и послать на ПК как есть, без сжатия, при этом достичь максимального количества кадров в секунду.
Что за зверь, FPGA плата?
Это процессор или миникомп как "малинка"?
Нет, но она как процессор может исполнять алгоритм, считать и управлять чем-нибудь.
По сути FPGA это набор блоков памяти, отдельных битов памяти и простых, проще сложения, логических элементов с управляемыми связями. А связями всего этого набора можно произвольно управлять софтом по своему желанию.
Стоп, а как оно считает, исполняет алгоритм и управляет?
А тем что специальный софт разбивает алгоритм, написанный на си подобном языке, на отдельные блоки:
массивы размещает в большие блоки памяти,
переменные разбивает на биты и размещает в отдельные аппаратные биты,
вычисления, даже такие простые как инкремент разбивает на сотни и тысячи логических функций, для сложных использует готовые аппаратные блоки.
И потом всё это соединяет вполне реальными физическими связями. И работает всё это на частотах в несколько сотен мегагерц.
По сути алгоритм превращается в реальную и очень комплексную электрическую схему. Это настолько низкоуровневое программирование, что даже "ниже" не только ассемблера, но и машинных кодов и чёрт побери перфокарт!
100-200 Мгц медленно? и зачем такой дрочь нужен если есть обычная малинка или одноплатные ПК х86 на которых винда крутится?
Нет, это не медленно и есть задачи, где не возможно обойтись без FPGA физически.
Первая фишка: в том что это не проц, который исполняет алгоритм шаг за шагом. Это куча связанного "железа" которая исполняет весь алгоритм одновременно! Тотальное 100% распараллеливание алгоритма, даже если в нём несколько сотен тысяч строк кода!
Это даёт возможность такой магии, как сортировка массива за ноль тактов (например, в фильтре шума).
А ещё даёт возможность самому проектировать эмуляторы старых консолей и они будут работать в точности, нет, ТАК В ТАК, так-же как и их аппаратные дедушки, даже даёт возможность сэмулировать баги, и разные аппаратные нестабильности например в звуке чип-тюна ZX-Spectrum.
А ещё это и чудовищное быстродействие: делать расчёты на 66 Мгц быстрее чем Core i7 на 3700 МГц? запросто! Именно поэтому ASIC (FPGA с предзаказанными, не изменяемыми связями) так полюбились всеми майнерами.
Вторая принципиально непобедимая фишка: время реакции - раз всё работает параллельно и можно реагировать с нереальной скоростью, в десятки а порой единицы наносекунд. Робототехника, автопрома и оружейка - без FPGA и ASIC (захардкоженный FPGA) никак.
Третья фишка: можно реализовать любую переферию, любой интерфейс самому при помощи исходного кода, и если ты написал сам всё с нуля, включая интерфейсы, то это 100% переносимо, ну не мечта ли? Но с большими оговорками, и можно "отстрелить себе ногу", что я и сделал в интерфейсе камеры.
Модуль камеры:
Это плата модуля камеры: сверху чёрный цилиндр объектива, под ним чип сенсора который собственно и видит со всей логикой, который установлен на плате, два стабилизатора питания и разъём 40 контактный.
Камера:
5 мегапикселей.
"Объектив" полное гавно: мылит даже на VGA разрешении, света собирает мало, не настраивается фокус. Но для отладки пойдёт.
Чип сенсора выдаёт RAW формат как в профессиональных фотокамерах,
Интерфейс параллельный MIPI, он примитивный: каждый такт синхросигнала выдаёт 12 бит данных пикселя, с парой статусных сигналов "конец строки" и "конец кадра".
Для настройки юзает двух проводной I2C.
Коннектор - 40 пиновый, двухрядный с шагом 2.56мм, как в старых жестяках.
Казалось бы всё просто особенно для FPGA...
"Отстрел ноги"
Но чтоб достичь максимальной скорости надо выдать камере максимальную частоту в ~100Мгц (а с гармониками до гигагерца), от которой камера и тактируется, которая в свою очередь даёт обратно FPGA с сырыми данными изображения.
А это очень быстро, даже слишком быстро и было наивно с моей стороны надеется, что можно отдельными проводками соединить и ничего за это не будет...
Будет!
Во первых: в стародавние времена, когда у жестяков был широченный ParallelATA 40 пиновый коннектор и такой же шлейф, то этот 40 жильный шлейф работал только до частот 30-60МГц, а далее уже нужно было использовать особый магический 80 жильный шлейф. И это не спроста: на таких частотах взаимные наводки очень сильно влияют и портят сигнал. Но в этой связке его использовать нельзя т.к. на основной FPGA плате нет такого же 40пинового разъёма, а мудаки из Xilinx ради маркетинга (ну и чтоб продавать только их доп платки по конской наценке) и несовместимости запилили 4 группы по 12 контактов в два ряда.
Во вторых: длинна ардуино-проводов разная да и на самой плате очень сильно различается длинна дорожек, а это критично на таких скорстях и если даже не из за скорости света то из за разной индуктивности - которая усиливает взимные наводки, разносит их по разным фазам ещё сильнее и превращает сигнал в "кашу".
В третьих: маркетологи посчитали что при помощи платы "всего" за 100 баксов нельзя давать заниматься серьёзными вещами. И поэтому два из четырёх 12 контактных коннекторов GPIO подключили через много килоомные резисторы тем самым зарезав частоту и "завалив форнты" (когда тактовая нарастает не слишком быстро чип камеры, из за шумов может не понять время переключение, это было одно или несколько).
Не делайте так! Не надо пытаться ардуино-проводками подключать такие быстрые (свыше 30 МГц и многобитные интерфейсы)
Попытки профиксить и прочие бесполезные трепыхания
1. Тактовая пикселей MIPI что выходит из камеры оказалась в разы шумнее: это тактовая из FPGA которая набрала по пути до камеры шумы, а потом вернулась из камеры в FPGA набрав ещё шумов на обратном пути. Пришлось затактироваться внутренней частотой внутри FPGA что генерится и выдаётся наружу.
Фейл: чип камеры при каждом старте настраивается чуток поразному и поэтому выходящяя из него тактовая тоже на пару наносекунд то отстаёт то опережает.
Адский Костыль: Нужно вручную подстраивать каждый раз при каждом включении задержку.
2. Фейл: Взаимные шумы: так как лежит на первой картинке (плата связи рядом с платой камеры) не работает! В линке с ПК проскакивают лишние байты или он теряет байты.
Адский Костыль:
приходится буквально на пару сантиметров отгибать в сторону камеру вот так:
3. Мини Фейл: Ардуино проводки - они норовят отскачить при любом неосторожном движении любой платы! Это, просто, очень и очень не удобно, надо ОЧЕНЬ аккуратно всё двигать.
Костыль: расковырял иголкой разъём чтоб лучше держалось ... помогло мало но вроде помогло.
4. Связь с ПК при помощи модуля FTDI2232H оказалось не настолько крутой как её рекламировала фирма.
Фейл: скорость вместо 480 мегабит оказалась всего в 100 мегабит, т.к. внутри ФТДИхи два канала и они прибиты гвоздями, уже 240мегабит, USB не умеет в 100% пропускной, уже 200Мегабит, а чип не сразу видит такт записи а через пол дополнительного такта: вот тебе и 100 мегабит. Дрочиться собирать из двух каналов один не стал - драйвер фтди перемашивает рандомно. Дрочь.
5. так же производитель камеры обманул: вместо 150 фпс оказалось 128 фпс, сам сенсор оказался очень тёмным на такой скорости.
Дополнительно было сделано
Т.к. камера выдаёт сырой рав-поток как в проф камерах, то его надо обрабатывать как это делают тулзы цифровой проявки такие как Adobe Light room.
Для этого запилил на верилоге свой видеопроц:
в нём и MIPI приёмник, и свой i2c контроллер и такие страшные слова как баланс белого, гамма-коррекция, коррекция дин. диапазона, шумодав (где сортируется за 0 тактов в медианном фильтре), ресайз, усиление и коррекция цветов.
схемка для пущего устрашения (to NN это выход в фтди, и спойлер темы будущей статьи ;):
Итог и что получилось сделать:
Оно заработало:
слева рендеринг на ПК при помощи OpenCV,
справа отладочная консоль в формате VT100 с цветами и свистелко-перделками (реализованный аппаратно на FPGA при помощи той же логики и такой-то матери), да я люблю красиво, дорого и богато.
В первую секунду видна первичная инициализация и пуск камеры с логом адресов и значений команд записи.
Далее я ручками, посылаю текстовые команды в FPGA (лексический интерпретатор команд тоже сам сделал, тоже на логике) и настраиваю яркость и чёртову фазу сигналов, видно что после подстройки фазы обильный "розовый снег" исчезает.
После я машу перед камерой древним смартом с настроечной таблицей цветов.
косяки:
1. т.к. по скорости FTDI подвела то только 64 кадра в сек, в среднем каждый второй пропускается.
2. есть местами мусор в виде снега и цветных кластеров (показаны красными стрелочками)
3. сам модуль камеры на такой скорости оказалось лютым гавном, мутная, и шумов много т.к. ISO задран к небесам.
Использованные ресурсы чипа:
Вывод:
Не делайте так! Не надо пытаться ардуино-проводками подключать такие быстрые (свыше 30 МГц и многобитные интерфейсы). Именно поэтому профессионалы порой недолюбливают ардуинщиков за такие дикие сопли с ардуино-проводками.
А отладить камеру и ip-корку (аппаратная либа) видеопроца я всё-таки смог. Благо сам алгоритм разработал и верифицировал формально и математически, а на FPGA только проверил, что оно в принципе работает и понял что надо копать в сторону само синхронных синфазных LVDS гигабитных интерфейсов без тактовой и всего этого дроча с шумами.
На этом всё, вот в завершение фотка с топологией чипа (светлосиним заюзанные аппаратные ячейки), зачем? незнай, просто красивый город как из сим-сити вышел.
Вот такой девайс отрыл в ящике. Был скрафчен мною ещё в бытность школотой. Плата сделана даже не из стеклотекстолита, а из гетинакса, найденного в какой-то масляной луже гаража. А чтобы плата не была такой скучной, была покрашена аэрозольной краской. Плата перетравлена, было решено напаять куски медной проволоки. Самое интересное, что это дерьмо работает. Ну, работало, по крайней мере.
В прошлом посте один человек спросил детали проекта, так что я решил запилить небольшую статейку о том как я делал JoyReBadge v1.0 мало ли кому захочется повторить поделку.
Немного истории:(кому не интересно можете мотать вниз и переходить по ссылке на гитхаб)
После того как я определился с внешним видом и рисунком который будет на плате, нужно было прикинуть какие элементы и в каком кол-ве использовать - микроконтроллер я заочно хотел использовать STM32F103С8T6, дальше я быстро прикинул оптимальное количество светодиодов которое должно идти по кромке эмблемы и сколько оптимально будет расположить в лице. Вышло 108 светодиодов по кромке и 8 RGB в лице. Получается туева хуча пинов, но как знает большинство любителей электроники есть 2 бомжатских вида управления большим количеством светодиодов: матрица или чарлиплексинг (спецмикрухи я не рассматривал т.к. ценник хотелось ужать по минимуму). В общем прикинув это все используем матрицу для кромочных светодиодов 16х7=112 и 8х3=24 для RGB светодиодов с общим анодом.
Итого 16+7+8+3=34 пина, многовато, да и тока будет порядком если все зажечь, значит берем пару сдвиговых регистров для 16 линий анодов и одну сборку транзисторов для 8 линий катодов, это управление 108 светодиодами на кромке (+4 допонительных которые я не использую), а RGB будем просто транзисторами щелкать.
С мигалками определились, дальше питание тут также все просто, берем обычный LDO и так как питание от 1S Li-Po то берем самую простую микруху для заряда Li-Po. Ну и для управления берем микрухи емкостных датчиков.
Все дальше разводка, я делал в Eagle и пришлось запариться с переносом туда эмблемы, а потом еще и с равномерным расположением светодиодов, а после попытки развести все ручками, я психанул и включил автороутер и с 5й попытки мне понравилось как он развел месево из дорожек и переходных и я наведя красоту запульнул герберы к Китайцам и был таков.
Прошивка писалась в CooCox (эклипсоподобная IDE для STM32), пришлось запариться с кодом т.к. схематически я немного накосячил и неудобно соединил матрицу светодиодов и не повесил управление сдвиговыми регистрами на SPI, так было бы и код проще писать и проц поменьше нагружать, но итак работает и все хорошо. На данный момент реализовано несколько режимов мигания, переключения между режимами и регулировка скорости их отображения, все это можно наблюдать на видео в прошлом посте, также сделал возможность отображать примерный уровень заряда аккумулятора с помощью пропорционального заполнения оранжевых светодиодов.
На GitHub можно найти, мой быдлокод и последнюю версию схемы и печатки (на момент написания v1.1 я там поправил косяк с расположением USB разъема), от туда и сформировать BOM на элементы и Gerber’ы для заказа платы.
П.С. если кто-то всерьез хочет делать этот бэйдж то можете писать в личку, я там накидаю полезных ссылок или еще чего :)
 | misideПодписчиков: +189 |
 | серый волчеПодписчиков: +46 |
 | ХаляваПодписчиков: +41 |
 | WapaperПодписчиков: +31 |
 | EGS халяваПодписчиков: +19 |
 | AwariaПодписчиков: +133 |
 | KimoriiiiПодписчиков: +129 |
 | Mia CollinsПодписчиков: +83 |
 | AromaSenseiПодписчиков: +64 |
 | TastyNovaПодписчиков: +59 |
