ADC -> DMA -> UART прерывния

[pavell]

Уважаемые устал биться, не работают прерывания, подскажите в чем может быть проблема? Данные идут сплошным потоком отладчик в обработку прерывания не заходит. STM32F051

main.txt

[mike-y-k]

pavell, я конечно все понимаю, но тут нет телепатов
Начните с чтения DS, AN, errata на сайте производителя по Вашему МК, семейству, блокам используемой периферии и напишите здесь что и как Вы делали.
Сюда бы схему включения означенного в списке проблем и код программы с комментариями во вложениях. Спойлеры имеют свойство не у всех открываться, а движок может вносить коррективы в публикуемый в топике код.
Тогда будет (помимо сферического коня в вакууме) предмет для анализа

Пока по текущему коду - а кто вызывает те самые что-то_ini функции?

[pavell]

Ок, вечером добавлю вложение с кодом и коментариями, а пока убрал из под спойлера

Пока по текущему коду - а кто вызывает те самые что-то_ini функции?

В main() же

[CERGEI1982]

буфер для приема один и для ацп и для юсарт ? это так на вскидку.
По поводу прерываний : Какой уровень оптимизации кода стоит ? Они пустые функции обработки исключений и потому компилятор может не внести их в исходник. В отладчике покажите что происходит когда вручную запускаете прерывание по дма ? В кейле есть такая возможность.

[28-63]

если б это не был кал, я б поделилсо кодом для уарт-дма

[akegor]

если б это не был кал

Святому - святое и снится. А Вам - кал...

[pavell]

буфер для приема один и для ацп и для юсарт ?

Ну в этом весь смысл )
Уровень оптимизации L0

В обработчики добавил остановку ADC, что бы сразу увидеть реакцию, но ее по прежнему нет (

потыкал прерывания руками вообще ничего не понял, что есть, что нету

[eddy]

1. А разве нельзя напрямую при помощи DMA доставать данные из ADCx-›DR и класть в USARTx-›TDR?
2. А разве успеет UART с такой бешеной скоростью данные отправлять, когда настроен всего лишь на 256кбод?
3. Нет смысла делать многократные |= и &= для регистров - они же волатильные, gcc не оптимизирует повторные вызовы!
4. А можно описать потребность, ТЗ, так сказать?
Я вообще не понял, что нужно. Потому что если нужно быстро копировать данные с АЦП в уарт, то как-то это неправильно на мой взгляд. Нужно синхронизировать по отправке с уарта, а не черт-те как...
5. Посмотрите в сниппетах. Там полно примеров по DMA.

[pavell]

1. А разве нельзя напрямую при помощи DMA доставать данные из ADCx-›DR и класть в USARTx-›TDR?
...

Конечно можно напрямую, но тут как раз и возникает проблема из второго вопроса. Для "синхронизации" поступающих и отправляемых данных я и применил буфер. Решение спорное, но применил его.
3. ну есть такой момент, надо отучаться )
Да задача именно быстро передавать данные из АЦП в УАРТ. По моей задумке сама синхронизация должна быть реализована в обработчике прерываний.

[eddy]

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

Чтобы обеспечить постоянную загрузку канала я бы сделал так. Запускаем ПДП на АЦП. На середине заполнения буфера выставляем флаг, что можно запускать ПДП на уарт. Прерывание по окончанию буфера АЦП не нужно. А вот по окончанию передачи уартом - нужно. Как только передача закончилась, опять запускаем заполнение буфера со стороны АЦП, а пока он первую половину заполняет, отправляем метку, что предыдущая порция данных кончилась и сейчас пойдет новая. А тут и флаг, разрешающий отправку, подоспеет. В принципе, можно вообще без него работать и сразу после отправления метки запускать ПДП на отправку буфера.