АЦП и энергопотребление Опции

[data_stack]

Есть необходимость оцифровывать несколько сигналов, с разной частотой (2кГц, 256Гц, 16Гц) и разной разрядностью (8-12бит) и скидывать все это дело на карту памяти. Все это усложняется батарейным питанием. Как лучше поступить?

1. Вариант, запускать преобразование по таймеру, с самой большой частотой дискретизации, с максимальной разрядностью, по окончанию преобразования забирать через DMA. По заполнению буфера DMA, выдаст прерывание, после него заполнять другой буфер, а за это время разгребать то что накопилось. Чем нравится решение, тем что, наверное, будет время для сна. Чем не нравится - не гибко, это будет огромный массив, в который будут свалены все данные скопом. Придется вычленять нужные данные, преобразовывать их битность, затем распихивать по мелким массивам, чтобы отсортировать, затем снова правильно раскладывать.

2. Вариант постоянно преобразовывать значения АЦП и сразу складывать их через DMA в массив. Запускать таймер с частотой 2кГц, в прерывании забирать только нужные значения, сразу же преобразовывать и аккуратно складывать. Чем нравится, удобно, займет меньше места в оперативе. Чем не нравится, не понятно что получится с энергопотреблением, думаю что оно вырастет, этого не хотелось бы.

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

[AlanDrakes]

Как понимаю, использовать собираетесь что-то из STM32?
Если применить STM32L - то можно запускать ADC по таймеру, заранее выставив биты пониженного потребления. В таком случае - ADC запускается таймером, включается, инициализируется, проводит оцифровку и сбрасывает данные по DMA в участок памяти.
На DMA потребуется настроить прерывания по половинному заполнению буфера и окончанию буфера.
Просыпаться, соответственно, два раза за буфер.
Оцифровывать можно с изначально известной частотой дискретизации. Причём, чем ниже частота выборки, тем больше времени будет контроллер находиться в состоянии сна при одинаковом размере буфера.
Опять же, при оцифровке с достаточно большой частотой сэмплирования (более 100kSa/s) выигрыша Вы уже не получите.
Хотя, для 16Гц (Sa/s?) можно проводить во сне более 99.5% времени.

Вариант с большми буфером для медленного заполнения (как у вас) будет наилучшим.

[data_stack]

Видимо не очевидно проблему описал. Использовать буду STM32L1, вы как раз описали первый случай, еще раз попытаюсь объяснить чем он мне не нравится, частота дискретизации будет 2кГц, ибо АЦП придется настраивать по максимальной частоте. Получится что все каналы будут оцифровываться с частотой 2кГц и 16бит. У меня 10 каналов. 2000*2*10 = 40кБ за секунду, вместо 5кБ планируемых. Даже если забирать буфер раз в 1/16 сек, это будет 2.5кБ вместо 312байт, которые нужно еще отсортировать и преобразовать. Поэтому я задумался, не проще ли копировать только в нужные моменты в прерывании и преобразовывать на ходу?

Сообщение отредактировал IgorKossak - Dec 1 2015, 22:25

Причина редактирования: бездумное цитирование

[Сергей Борщ]

не проще ли копировать только в нужные моменты в прерывании и преобразовывать на ходу?

Напишите оба варианта. Сравните размер получившегося кода. Прикиньте проигрыш по потреблению на исполнение этого лишнего кода. Я тоже за первый вариант - пробежаться по массиву с фиксированным шагом гораздо проще, чем обрабатывать кучу счетчиков в прерывании. Могу предложить улучшение - выборки частотой 256 и 16 Гц делать как инжектированные. Тогда буфер DMA вам нужен будет только для отсчетов частотой 2 кГц.

[Alechek]

Не знаю как для STM32L, но я бы сравнил потребление при программной выборке с DMA режимом. При выборке 2 кГц практически 100% времени DMA будет в режиме ожидания. Но даже в этом режиме сколько-то он все равно может кушать.
На никак несберегающем LPC175X DMA оказался настолько жручим, что решил запускать его только тогда, когда действительно надо и после окончания работы сразу выключать (SPI). При поданной на него тактовой 12МГц, даже при неработающих каналах и сброшенном бите ENABLE он потребляет порядка 1мА!

[jcxz]

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

вариант 3:
Имеем большой пустой буфер, есть диаграмма опроса 3-х АЦП каналов (каждый со своей частотой), CPU работает на предельно малой частоте (1МГц или ниже, PLL выкл.),
по диаграмме запускает очередное преобразование для очередного канала (внутри ISR), затем выходит из ISR в фоновый цикл команды WFI, до след. прерывания, в котором считывает полученное значение, записывает в буфер без какой-либо обработки, запускает след. преобразование если буфер ещё не заполнен.
И так - пока не заполнится буфер. По его заполнению включаем PLL, разгоняем CPU, в фоновом процессе обрабатываем накопленный буфер (пакуем, сортируем и т.п.) и пишем на SD. В это время измерительный процесс в ISR
продолжает работать (частота работы АЦП не должна измениться при увеличении тактовой CPU), но пишет во 2-й буфер.
После записи на SD опять понижаем частоту ядра.
Процесс повышения/понижения тактовой частоты должен быть реализован так, чтобы не нарушал временную диаграмму работы процесса чтения АЦП.
DMA здесь не нужен и такой алгоритм работы будет думаю самым экономичным.

[data_stack]

Была и такая мысля. Почему не понравилась. В STM32L1 АЦП тактируется только от HSI. Поэтому HSI будет включен всегда, все остальные шины и так занижены. Включение любого дополнительного источника будет дополнительно жрать энергию. На борту еще периодически включается uart, spi, таймеры, каждый раз их переконфигурить. Может идея и не плоха, но я не решился ее воплощать.

Сообщение отредактировал IgorKossak - Dec 2 2015, 15:36

Причина редактирования: бездумное цитирование

[AlanDrakes]

Итак, обобщу снова.
- DMA в L1 достаточно экономный.
- Оцифровывать несколько каналов можно в режиме ждущего преобразования (заранее собираете очередь преобразований, а затем запускаете по таймеру).
- DMA будет складывать посылки данных в буфер и по заполнению его на половину контроллер должен проснуться и обработать их первую часть, соответственно, по окончании буфера - вторую.
Потребление... Заранее предупрежу, что пишу на имеющийся лично у меня STM32L152.
RUN @8MHz, VCore = 2 - 2.5mA
SLEEP @8MHz, VCore = 2 - 0.6mA
Переферия:
ADC: 9uA * MHz (8) = 72uA.
GPIOA: 3.5uA * MHz (8) = 28uA.
DMA: 8uA * MHz (8) = 64uA.
ADC (режим преобразования) - 1.45mA
TIM2 (таймер для запуска преобразования) - 8uA * MHz (8) = 64uA.
Итого, ожидаемый ток: 0.6 + (0.072 + 0.028 + 0.064 + 0.064) = 0.828mA в режиме сна.
Считаем ток во время преобразования: Время преобразования на канал (худшее для мультиплексированных): 1uS * 10 каналов + PowerOnTime 3.5uS. Итого - 13.5uS + время преобразования. Обычно 4 + 12 тактов, что при 8 МГц даёт 0.5uS на преобразование. Итого - 13.5 + 4 = 17.5uS.
Частота выборки - 2000Sa/s = 500uS. 17.5 / 500 = 3.5% времени преобразование. В течении этого времени потребление должно возрасти на 1.45mA, плюс-минус 0.1mA.
При размере буфера в 40кБ, он будет заполняться 2 раза в секунду.
Таким образом, нужно будет писать данные на карту памяти те же 2 раза в секунду.

Итого, суммарный ток (не учитывая рабочее время на запись) будет:
0.828 * 0.965 + 1.45 * 0.035 = 0,79902 + 0,05075 = 0,84977
Приблизительно, 0.85mA это только преобразования и складирование их в RAM.
Остальной ток потребления будет зависеть от потребностей карты памяти и быстроты работы кода.

[jcxz]

TIM2 (таймер для запуска преобразования) - 8uA * MHz (8) = 64uA.

ТСу вроде как требуется оцифровывать три разных канала, каждый со своей частотой сэмплирования, причём частоты некратны друг другу (и не про какие допустимые погрешности частоты сэмплирования ТС не писал - а значит принимаем что нужно точно 2кГц, 256Гц и 16Гц).
И как Вы собрались запускать эти преобразования одним таймером с разными некратными друг другу частотами без пробуждения CPU и перепрограммирования таймера???
Я конечно не очень хорошо знаю периферию STM32, но сомневаюсь что TIM2 в нём способен формировать события на 3-х разных частотах, суммируя их на выходе в единый поток событий, да ещё переключать каналы АЦП в зависимости от события.
Такое умеет делать например АЦП в LPC4370 - ему можно задать довольно произвольную диаграмму работы нескольких каналов АЦП одновременно с разными частотами сэмплирования на связке ADC+DMA без участия CPU.
А вот в STM32L я думаю вряд-ли такое можно сделать не пробуждая ядро. А пробуждая ядро получите потребление близкое к потреблению RUN-моде на 8МГц.

ТС нужно или искать МК, в котором периферия позволяет работать АЦП по нескольким каналам одновременно с разными некратными частотами без участия ядра (например как сделано в LPC4370).
Либо искать МК с более экономичным ядром и работать на нём управляя АЦП программно ядром. Здесь я бы смотрел в сторону MSP430.

0.828 * 0.965 + 1.45 * 0.035 = 0,79902 + 0,05075 = 0,84977

А эти цифры вообще с потолка...

[data_stack]

Либо искать МК с более экономичным ядром и работать на нём управляя АЦП программно ядром. Здесь я бы смотрел в сторону MSP430.

Судя по даташиту L1 рвет топовые MSP по токопотреблению.

Виноват, не уточнил, если это даст выигрыш по току, то подогнать частоты можно. поэтому наверно логично взять 2048, 256 и 16Гц. Думаю, пока остановлюсь на 1 варианте и как было сказано выше, буду чаще их обрабатывать и скидывать.

[jcxz]

Виноват, не уточнил, если это даст выигрыш по току, то подогнать частоты можно. поэтому наверно логично взять 2048, 256 и 16Гц. Думаю, пока остановлюсь на 1 варианте и как было сказано выше, буду чаще их обрабатывать и скидывать.

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

[data_stack]

Вы не внимательно читали мой первый вопрос Запускать от одного таймера несколько каналов получается, просто данные будут копироваться с частотой таймера, т.е. 2048 раз в секунду. Весь и вопрос был в том, что оптимальнее, включить несколько таймеров и по ним запускать преобразование, или сортировать большой буфер.

[jcxz]

Вы не внимательно читали мой первый вопрос Запускать от одного таймера несколько каналов получается, просто данные будут копироваться с частотой таймера, т.е. 2048 раз в секунду. Весь и вопрос был в том, что оптимальнее, включить несколько таймеров и по ним запускать преобразование, или сортировать большой буфер.

Я имел в виду - не получится даже на кратных частотах. Придётся всё делать на макс. частоте, а потом прореживать ненужные отсчёты. Не позволяет периферия.

[data_stack]

Да именно так, вроде так я и писал.

[Сергей Борщ]

Есть возможность более редкие измерения делать от отдельного таймера как injected, но выгребать их придется в прерывании АЦП (DMA забирать их не умеет).