А правильно я понимаю что в STM32F1xx можно сделать как-то так:
- настроить последовательность (регистрами SQR*) чтобы ADC за раз сканировал кучу каналов
- настроить ADC дергать DMA чтобы класть результаты этого в некий буфер
- настроить continious conversion чтобы ADC гонял по кольцу эту последовательность всегда
- настроить DMA на circular mode - так что получив отсчеты он сам перейдет к началу буфера
(порядок приблизительный; подразумевается что ADC и DMA будут запущены когда все настроено)

Ну а когда оно ухватило всю пачку отсчетов либо ADC, либо DMA можно убедить кинуть IRQ сообщающее что данные готовы. И соответственно все выглядит так что в этом раскладе железки сами все сделают и останется только забрать буфер с кучей отсчетов по сути, при том этот цикл будет сам повторяться железками STM32 вообще без участия софта - кроме разве что IRQ в момент когда буфер с всеми отсчетами готов?

Продвинутый вариант: нечто типа двойного буфера, настроить DMA таскать в 2 раза больше чем то что в ADC настроено и использовать также и прерывание DMA half transfer - а так прокатит? И соответственно, по тому дернули нас half или full понятно какую из половинок буфера сейчас следует жевать.

Тогда по идее будет 2 буфера - в один DMA пишет, второй можно довольно долго педалировать в фоне, лишь бы в целом успело сжевать буфер за время которое ADC нагребает новый. С одним буфером время реакции сильно ограничено, DMA ждать не будет и по мере готовности ADC перепишет отсчеты новыми.

Я правильно понимаю что на STM32F1 можно вот такой почти полностью аппаратный захват отсчетов организовать, когда железки даже переконфиругировать не придется после очередного набора? Так что получил IRQ, забрал отсчеты и делай там себе в фоне что хотел.

Да. Только имей в виду, что к моменту прихода прерывания по полному буферу, у тебя должна быть обсчитана первая половина буфера. Поэтому не забудь правильно настроить приоритеты прерываний и оценить загрузку процессора МК.

Т.е. реально будет крутиться по кольцу, живя своей жизнью и не требуя перенастройки? Так что только IRQ получить и забрать кучу данных? Прикольно, тогда надо накодить.

А в упомянутой логике с двойным буфером - по идее еще и к приходу irq про half transfer должен быть обсчитан буфер вверху (вторая половина). Иначе DMA пойдет писать тот буфер, и если он не обсчитан - DMA все-равно, это не его проблемы.

Кстати, а в крайнем случае, если так вышло что где-то все же не успели - а он атомарно таскает отсчеты? То-есть весь отсчет - улетит за 1 транзакцию? Чтобы я видел либо старый, либо новый отсчет канала, но ни в коем случае не половину старого и половину нового? Какой размер трансфера при этом правильно указывать DMA? 16 битов его устроят? Можно и 32, конечно, но памяти в 2 раза больше сожрет а в верхушке регистра ничего полезного нет, ADC 12-битный же (я юзаю adc с результатом в 12 битах в младших разрядах). Это если отсчеты должны меняться не очень быстро или всяко было некое усреднение.

И я думаю жевать обработку фоном - так что мысль про приоритеты IRQ соответственно не при чем: в этом случае MCU должен глобально успевать + не блокировать IRQ надолго. В энном случае ADC можно и притормозить ADC немного, тем более что быстрое сэмплирование капризно к сопротивлению источника сигнала. Но вообще чем быстрее тем лучше.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Ошибаешься. Подумай сам, почему. Ты в течение дня, например, кушаешь 3 раза, 1 раз спишь и 5 раз ходишь в туалет. А одновременно сможешь всё это сделать? Глобально-то успеваешь!

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

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

Еще подумалось что в принципе можно и вот так:
- заранее определиться, что абстракция такова что есть буфер отсчетов и он живет своей жизнью.
- если отсчеты нужны где-то еще, несколько раз, именно те же, первое что делать - копировать отсчет куда-то еще.
- рассматривать буфер как состояние эн каналов - прямо СЕЙЧАС - на момент чтения, а не что-нибудь еще.

В таком допущении даже перезапись отсчета DMA под самым носом не является особой проблемой, если это все атомарно. Как максимум нам перед самым носом положат свежий отсчет. Можно поспорить баг это получился или фича.

Очевидные проблемы которые я вижу.
1) некая неопределенность таймингов отсчетов. Можно быть уверенным только до 1 цикла сканирования но не более того.
2) экскурсия на тему изучения атомарности работы DMA в этом случае. Вроде судя по его описанию там все внутрях 32-битное, по шине всяко 32 бита за присест, и соответственно все вроде бы должно быть атомарно, и 32 и 16 битов вроде бы.

Очевидные плюсы:
1) Менеджмент прерываний и прочего может быть равен вообще нулю. Это может быть и минусом - готовность отсчетов некий логичный "нативный" период к которому не так уж глупо привязываться.
2) Отсчеты можно просто прочитать там где надо, когда надо.

p.s. а когда у кортекса диарея прерываний - он как раз с унитаза не вскакивает, штаны не натягивает, да и бутерброд там же умеет дожевать, для экономии времени. И кстати так не только кортекс делает

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Это стандартный подход, если нет необходимости синхронизма данных. Сильно зависит от задачи. В сигнальных приложениях это может быть категорически недопустимо. Например при синтезе диаграммы от двух (и более) антенн путем цифрового матрицирования сигналов. Другой пример - фильтрация. Пропуск актуальных отсчетов будет эквивалентен децимации, причем нештатной. Это может привести к паразитным каналам приема из-за неучтенности ситуации в антиалиасинге.

За исключением особо экстремальных случаев, это через очереди сообщений разруливается. В прерываниях делается только самое необходимое, и заталкиваем данные в очередь. Потом уже в main спокойно выгребам и обрабатываем поток данных (типа, event loop). Ну или в RTOS, дело вкуса. Остается только подобрать размеры очередей, чтобы не переполнялись на самых длинных пробуксовках.

Там где надо без RTOS, для очередей и прочих паттернов есть https://github.com/ETLCPP/etl.

А если надо какую-то особо длинную простыню напилить на части - гуглите protothreads.

https://github.com/speedcontrols/ac_sc_grinder - тут можно посмотреть пример. Там и АЦП с двойным буфером проталкиватся в очередь, и длиннющая логика нарезается через самопальный yield. Самые ходовые случаи, с которыми приходится иметь дело на практике.

В случае с сигналами очередь ничего не даст, мало того, еще и сожрет часть времени на обработку.
Либо успеваем обрабатывать поток, либо нет.

Я отвечал предыдущему оратору, который переизобретал паттерн "Message Queue" для Single Producer / Single Consumer.

Это просто удобный клей между разными уровнями абстракции - низкоуровневым i/o и бизнес-логикой. Накладные расходы там небольшие. Использовать или нет - каждый решит сам. Конкретный пример привел.

1)Фазировать антенны процом и программные фильтры для чего-то типа SDR, наверное, очень круто - но мне это некуда приткнуть, да и для какого-нибудь F100 с 24МГц и 4K RAM это, наверное, перебор. Это звучит как baseband. F100 наверное все же не baseband по призванию.

2) RTOS, C++, питон, meson и прочие очереди сообщений с темплейтами - без меня. Особенно в МК. Мне от МК надежность, скорость и предсказуемость хочется, а не супер-абстракции от железа, которые в таком контексте только все испортят. И оверинжиниринг я не люблю. Вопрос был "могут ли железки так взаимодействовать?" а не "дайте супер фреймворк" (который пожалуй у меня сожрет больше ресурсов чем все остальное вместе взятое).

И кстати consumer'ов у подпертого DMA буфера может быть сколько угодно - достаточно глобальной переменной его сделать. Можно подумать, он обидится на то что его прочитали не 1 раз а все 10.

А если мы об "экстремальных случаях" - я как раз хочу на пробу soft-buck на основе этого попробовать (в инверсном исполнении, для использования N-fet и удобства управлени) - для начала для светодиодной ленты. Обкатать технологию в варианте с жесткими времянками, полагая что чем быстрее реакция feedback, тем лучше, и посмотреть чего получится. Постепенно еще можно ремотное управление, по радио или проводу сделать - будет полезный (как минимум мне и окружающим) дивайс. Там интересны как минимум Vin, Vout, Iin, Iout а еще желательно Vrefint для уверенности в намеряном, а может и temp sensor (но он тормоз) или NTC - замечать откровенный перегрев, например. В этой штуке логично получив IRQ от DMA корректировать PWM прямо там, делая стабилизацию. Это максимально быстро и максимально логично для такого случая. Там же можно и реакцию на КЗ, попытавшись выключить все до того как питальник среагирует. При этом никакой особо длинной логики нет. И даже и потеря сэмпла не настолько уж и ужасна, и нахрен там RTOS с очередями и темплейтами я не понимаю. Идея жевать тухлые сэмплы из очереди в такой штуке вообще все испортит, там акуальное состояние важнее жевания ВСЕХ сэмплов любой ценой. И кстати идея с высоким приоритетом IRQ будет к месту, эти IRQ важнее всего остального, абстракция такая. Сначала control loop, потом все остальное.

Ну то-есть обычная управляющая задача. А сама такая конструкция относительно безопасна в отладке - в самом плохом случае врубится на полную, но лента и питальник расчитаны на это. Наверное логично отлаживать незнакомую логику на чем-то failsafe. А вот когда мне понравится как это работает и у меня будет ощущение как это работает - попробую и более требовательные/опасные вещи.

Антенны могут быть магнитными на частоты порядка 50...200 кГц, причем антеннами совсем не эфирными (дальней зоны), а для приема какого нибудь положения датчика.
Фильтр так же собственно к SDR отношения не имеет. Это может быть фильтр для вытаскивания сигнала с датчика или линии.
Скажем, в петле регулирования необходим ФНЧ с определенной частотой среза и ФЧХ.

Ну да, ну да. Блокировки и барьеры придумывают идиоты, а коллизий боятся только трусы.

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

1) Спасибо за идеи насчет датчиков. Как-то не задумывался о таких применениях. А тут на тебе, попался на глаза некий quasar ARM, чтоли. Это продвинутый металлоискатель, STM32 использует. Который как раз что-то очень наподобие делает. Сказать что я на 100% понял принцип работы этой штуки было бы неправдой. И сорца вроде нет. Довольно мистическая конструкция, как я понимаю с DAC выдает что-то типа синуса, и, видимо, вычитает это из сигнала. И делает далеко идущие выводы, чуть ли не по чему-то типа фазы.

А насчет именно петель регулирования - мне кажется, там вот именно посэмплово в крайнем случае и не обязательно, а фильтр можно упрощенный, который не сильно обидится на i+1'й сэмпл вместо i'го. Хотя конечно смотря что и как регулировать, а сам факт что вместо i'го сэмпла жуется i+1'й говорит о неких системных проблемах.

2) А я таки забацал ADC+DMA - и это работает. Пускаем ADC сканить по кругу (cont+scan) последовательность, програмим DMA в circular с тем же количеством трансферов что и число сканов ADC. Опа, буфер который сам заполняется, и так по кругу, само. Красота! По желанию IRQ от канала DMA когда все готово (да, я запрогал ему самый крутой приоритет на всякий). Все же у STM'ок прикольное железо, что ни говори. Всегда хотел что-нибудь такое запрограмить. Самое интересное во всей этой истории что я им память ни разу не вынес в процессе.

И да, я обошелся без всяких мега-либ в две мои фирмвари весом и каких там еще питонов. В конечном итоге мне была интересна работа тех железок. И как оно между собой взаимодействует. Зато теперь я неплохо улучшил познания в STMовском ADC, а с DMA настолько разогнался что и dma-memcpy до кучи сделал, просто посмотреть на это.

С блокировками и коллизиями я никаких проблем не поимел. DMA лупит 32 -> 16 транзакцию (попутно обкусывая ADC_DR до 16 битов как раз. Это конечно асинхронно по отношению к фоновому чтецу, но в конечном итоге я получаю или старый сэмпл, или новый. Это атомарное действо. И если вот прямо строго конкретные сэмплы волновали, в конкретное время - логичнее к IRQ привязываться, там уже можно весьма жесткий контроль таймингов получить. И даже двойной буфер, если жевание сэмплов медленное. А, если что - использование всяких ртосов в мои планы не входит. Если мне большую и крутую ОС захочется, у линукса все-равно больше, и треды там крутые и правильные. В отличие от микроконтроллерных недомерков. Не говоря про сеть и файловые системы "круче только яйца". Но это более крупные и менее реалтаймные системы. А если меня ADC+DMA заинтересовал, очевидно, я хотел погонять именно на грани, максимально быстро. Очереди и блокировки в это пожелание совершенно точно не входили, они не об этом.

Единственная небольшая загадка - корректно разобрать эту абстракцию с полной отменой всех эффектов оказалось чуть хитрее чем собрать. После разборки этой штуки adc первый сэмпл выдает странным, видимо потому что асинхронно срубается в процессе работы. Интересно, как его полностью корректно вырубать, когда он сам по себе асинхронно шпарит? Так то dma-backed и поллинг сами по себе взаимоисключающие, но мало ли, вдруг когда-то захочется странного? Т.е. чередовать эти подходы. Я конечно могу как воркэраунд первый сэмпл выбросить, но наверное есть и менее дурные способы это сделать.