Обновить
64K+
192

Embedded SW/Firmware Engineer

54,2
Рейтинг
495
Подписчики
Отправить сообщение

Y -= 2048?

Сигнал c ADC может колебаться вокруг любого смещения.
Не обязательно вокруг (2^12)/2.
Зависит от освещения.

 буду рад оказать вашей группе любое техническое (экспертное на базе своего опыта)... любое содействие в этом направлении.

Самая первая проблема с которой я столкнулся оказалась такая:

ADC отсчёты всегда положительные 0.....4095.
Как на лету отсеивать постоянную составляющую сигнала для последующей ЦОС обработки?

Причем так, чтобы не сильно перегружать микропроцессор.

Как вариант , можете использовать для управления джойстик от PlayStation2.

Вот методичка
https://habr.com/ru/articles/959628/
Подключение PlayStation2 Джойстика к Микроконтроллеру (или Переходник между человеком и компьютером)


терминал легко пристегивается в роверы по SPI

Для радиоуправления и получения телеметрии использовался приемопередатчик NRF24L01

Не рассматривали LoRa трансиверы, например SX1262?

Именно на этом этапе поток бит, накопленных за 1 мс, превращается в пару int16_t значений I/Q.

Если на выходе I/Q после фильтра нижних частот получился комплексный ноль, то как определить ошибку по фазе? Ведь нулевой вектор I/Q может быть направлен в абсолютно любую сторону.

К стати, а STM32F407 может исполнять программу из SPI-NorFlash памяти  eXecute in Place (XiP) ?

DMA (по русски ПДП) копирует данные из одного места в другое, в пределах адресного пространства, без помощи CPU

И, к слову, в обход запретам MPU (Memory Рrotection Unit )...
https://habr.com/ru/articles/950298/

передача данных из одного аппаратного интерфейса в другой, в Ethernet

Вот бы STM добавили DMA режим peripheral to peripheral.

Как там у Микрона успехи с портированием прошивки квадрокоптера BettaFlight на K1948BK018?
https://github.com/betaflight/betaflight

Остается операция суммирования. Чтобы вычислить результат корреляции, нужно просуммировать все биты, которые получились в результате умножения. А их много - 16368.К сожалению, используемый MCU не имеет команд ядра, позволяющих посчитать сумму установленных бит (в x86 это popcount). Нужно реализовывать суммирование полностью программно. Я рассмотрел разные методы, и остановился на простой таблице поиска на 16 бит. Она хранится в ОЗУ (так быстрее) и занимает 64 Кбайт. Заполняется таблица во время инициализации. Так как суммирование 16-битное, то и операции умножения XOR сделаны 16-битными. Переход к 32-битным вычислениям не дает значительного прироста по скорости, так как именно операции суммирования требуют больше времени.Именно на этом этапе поток бит, накопленных за 1 мс, превращается в пару int16_t значений I/Q.В итоге получившаяся функция умножения и сложения для I/Q данных выполняется за 112 мкс.

Хорошо бы отметить в тексте, что суммирование - это по сути усиливающий фильтр нижних частот ФНЧ.
FIR фильтр, где все веса равны 1.


Почему PCB белая? Это довольно редкий цвет и он дорогой. Да и еще это ухудшает передачу тепла между PCBA и воздухом.

Какой цвет PCB лучше всего способствует улучшению теплоотвода и охлаждению электронной платы?

Дальше нужно определиться как Test Jig и PCBA будут обмениваться информацией. Почти всегда я использую самый простой способ. По фиксированному адресу в RAM микроконтроллера располагается структура, которая содержит информацию о проведенных тестах. Обязательно нужно использовать CRC, чтобы убедиться, что там содержится осмысленная информация, а не случайный мусор. У всех тестов всегда должен быть timeout. Если этого не будет и во время тестов, что‑то зависнет, то вы никогда не узнаете точно какие тесты проходят успешно, а какие валятся. Всегда должна быть информация о варианте и версии платы. Т.к. в разных версиях и вариантах могут быть разные наборы тестов и ваше ПО всегда однозначно должно знать, какие тесты проводятся.

Почему бы не использовать UART - CLI?

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

Не часто увидишь слова "разработка электроники" и "индустриальный дизайнер" в одном тексте.

Можно попробовать. Но мне кажется, что приложение будет так занято, что будет пропускать сигналы от DMA между итерациями.

Как вы без FIFO обеспечите гарантию, что внутри функции main() семплы будут обрабатываться в хронологическом порядке?

Почему в квадратурных смесителях используют для гетеродина не просто cos() и sin(), а cos() и -sin()?

При том, что ухо, прямо скажем, не ахти какой быстрый сенсор.

Ухо может определять частоты до 15kHz, а глаз только 28кадров в секунду улавливает (28Hz). Ухо - получается нормальный датчик.

Хорошо, когда частота семплирования меньше, чем слышит ухо, и вообще, это единственная задача. 

При чем тут ухо? Может это семплы от радарной антенны или вообще от фотодиода.

Использование FIFO для передачи данных из прерывания основной программе излишне, имхо. Если всё пишется аппаратно через DMA, то проще передавать указатель на начало/середину буфера с половиной длины.

А как быть, если примём семплов и обработка семплов происходят с разной скоростью? Причем скорость обработки семплов - величина переменная.

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

Не делать же DSP обработку семплов внутри прерываний по DMA.

1
23 ...

Информация

В рейтинге
150-й
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность

Специализация

Инженер встраиваемых систем, DevOps-инженер
Старший
Git
Bash
CI/CD
C
Встраиваемая система
Программирование микроконтроллеров
Разработка программного обеспечения
Алгоритмы и структуры данных
Системное программирование
Разработка драйверов