Information
- Rating
- 358-th
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
Инженер встраиваемых систем, DevOps-инженер
Старший
Git
Bash
CI/CD
C
Встраиваемая система
Программирование микроконтроллеров
Разработка программного обеспечения
Алгоритмы и структуры данных
Системное программирование
Разработка драйверов
Пополнил коллекцию референс дизайнов
https://docs.google.com/spreadsheets/d/1qN1byQ0WxMioVbxBkGvKu5PQMvwMiCRe_2rgx16G3Gw/edit?gid=0#gid=0
У меня есть Malahiteam DSP4.
Ставлю на подоконник - уверенный сигнал.
Ставлю на комп. стол в кабинете - нет сигнала.
Был бы пульт можно было бы оставить приемник на подоконнике и переключать каналы пультом.
Может ещё добавить ИК приемник, чтобы переключать станции ТВ пультом?
Я так и делал. Пробовал просто численно просуммировать range profiles, но получилось какое-то каля-маля.
Интересно как это технически сделать?
Я так и делаю.
Cвертку считаю при помощи алгоритма FFT iFFT.
Это вычисляется быстрее FIR.
Вот по этой формулу.
iFFT{ FFT( принятый сигнал) * [комплексное сопряжение(FFT(импульсный ЛЧМ-сигнал))] }
В результате программа вычисляет свёртку для файла длинно 0,7 секунд в 13 раз быстрее по сравнению с FIR фильтром, и в 3421 раз быстрее, если сравнивать с DFT!
Как быть если надо реализовать два экземпляра программного uart?
Can без протокола - ничто.
А can протоколы(uds, j1939, xcp и прочее) это много кода.
У начальства в планах было продавать эту умную розетку в каждом хозяйственном магазине.
В этом
Glyndwr University или еще одна статья об образовании за границей / Хабр https://share.google/fKqsP0LJcD3mln2Me
У меня есть сонар. https://habr.com/ru/articles/1050166/
Я записал эхо сигнал в известных местах вдоль прямой с известным шагом.
Все измерения были неподвижные.
Вычислил свертки при помощи коррелятора.
После согласованной фильтрации (корреляции с зондирующим сигналом) получил коррелограмму.
Формально у меня есть набор радиальных профилей (range profiles) вдоль окружностей радиуса r вокруг каждой позиции .
Это и есть исходные данные .
Получил коррелограммы, которые показывают расстояния до каждой цели из заданной точки. По сути это одномерные графики.
Хочу построить акустический аналог SAR / aperture synthesis. Или томографию окружающего пространства. Как мне теперь на основе этих N коррелограмм построить 2D карту окружающих предметов вокруг?
Пробовал просто численно просуммировать range profiles, но получилось какое-то каля-маля.
пробовал вычитать range profiles
пробовал брать среднее range profiles
Но пока картинка не проясняется.
Если у Вас в прошивке нет отладочной CLI, то Вам, конечно же, не нужны функции из файлов xxx_diag.c и xxx_commands.c.
Вот как раз поэтому сериализаторы структур, команды shell и выделены в отдельные файлы исходников.
Чтобы не захламлять код ядра самого условного драйвера.
Тогда просто берете файл xxx_drv.c xxx_drv.h , xxx_const.h, xxx_type.h, xxx_config.c xxx_config.h. остальное просто не подключаете к сборке.
Вас может испугать большой набор файлов: 21 штука. Однако в коде и репозитории гранулярность как раз к месту. Так как не все файлы надо собрать в той или иной сборке. В одних платах есть UART-CLI в других нет. Там где CLI есть сразу надо подключать diag и commands. Где-то нужны модульные тесты, где-то нет. В одних проектах много flash памяти, а в других надо утрамбовывать код. В одних проектах одна кнопка в других 88 кнопок, то есть надо подключать конфиг отдельным файлом. В одних проектах есть NVRAM, в других нет. В одних проектах используют GNU Make, в других Cmake. В одних проектах нужна документация, в других нет. Всё это надо учитывать при проектировании программного компонента. Поэтому и получается что для одного модуля надо множество файлов. Это нормально.
сегодня внезапно выяснилось, что он оказывается еще хочет, чтобы порядок ответов на вопросы соответствовал порядку в котором вопросы задавались в сообщении.
Человек не умеет пользоваться Crtl+F по pdf-ке.
Такое себе решение, нанимать отдельного человека, чтобы тот начал писать модульные тесты под legacy.
Даже ИИ говорит, что модульные тесты должен писать сам автор тестируемого кода.
Модульные тесты должен писать сам автор модуля. По крайней мере первый набор модульных тестов. Дело в том, что написание модульных тестов требует глубокого понимания предметной области. У разработчика модуля это понимание уже так или иначе накоплено по мере разработки самого модуля. Если вы будете привлекать к написанию тестов сторонних людей, то вы потратите существенно много времени пока новые люди освоят предметную область, вникнут в код и придумают тесты для него.
Как вам? @LeraKholod
Насколько я помню в MDR не было PDM и I2S интерфейсов для микрофона.
Тов. майор бы не смог работать.
Это прям яндекс драйв чистой воды.
Есть такое.
Когда я написал текст про модельное тестирование статься даже в плюс не вышла.
Модульное Тестирование в Embedded
https://habr.com/ru/articles/698092/
Аналитимка показывает, что большинство минусов за
"Ничего не понял после прочтения "