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

[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 забирать их не умеет).

[jcxz]

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

[data_stack]

Кругозор действительно ограничен, наличие того что есть у местных барыг и сроков. Изначально планировалось использовать msp, который вроде как является лидером в этой области, не нашлось подходящего камня по фаршу, да и как я говорил цифры из даташита говорят о том, что потребление stm32 ниже чем мсп.

[AlanDrakes]

ТСу вроде как требуется оцифровывать три разных канала, каждый со своей частотой сэмплирования, причём частоты некратны друг другу (и не про какие допустимые погрешности частоты сэмплирования ТС не писал - а значит принимаем что нужно точно 2кГц, 256Гц и 16Гц).

Пардон, мне показалось, что это были режимы.
В таком случае, я бы выбрал сэмплирование на 2048Sa/s и прореживал данные перед записью в буфер карты.

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

Эти "цифры" вычислены из Datasheet'а - STM32L1xx Datasheet.
Кстати, я неправ в размере буфера. Общий объём памяти кристалла - 16кБ.

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

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

У STM32L152 есть 2 АЦП.
И много таймеров.
Частота 256 кратна 16-ти (16 раз), а вот 2000 - нет.
Так что, можно заставить оцифровывать один АЦП и один канал DMA низкочастотные выборки (256Sa/s) в одну область памяти, а более скоростные (2000Sa/s) - в другую по другому каналу.
Время между выборками столь большое, что можно запускать не боясь перехлёста каналов DMA.
Соответственно, использовать два таймера.

Если так важно получить минимальное потребление, то может имеет смысл расширить кругозор и рассмотреть разные семейства от разных поизводителей, а не зацикливаться на STM32?

Поддерживаю. Хотя, у меня аналогичная ситуация и ТС - что есть, с тем и работаем.

[MiklPolikov]

Я постоянно занимаюсь вопросами потребления, считаю себя в этой сфере специалистом. Так вот:

1) STM32 - лидер по потреблению. Меньше ни у кого не будет.

2) STM32L может означать STM32L151 и STM32L476
L4 вышел недавно и потребляет значительно меньше старых L151
Ещё есть F411 , он потребляет так же или меньше чем L151

3)Из моего опыта, на L151 при оцифровывании 8бит 8КГц и записи результата на карту памяти потребление 2.5мА, из которых 50% потребляет карта.
При этом обрабатывается поток данных 8Кбит /с
В Вашем случае поток данных ~3Кбит/с. Думаю что потребление будет порядка 1.25 мА. Если постараться.


Советую делать так:
Преобразовывать 3 канала с разрядностью 12 бит и частотой 2 КГц , через DMA писать в массив1.
При заполнении массива1 прерывание ДМА , по которому процессор выходит из сна и разбирает массив1, кладя результаты в массив2.
Прерывание конечно же по половине и концу передачи, что бы массив1 работал как кольцевой буфер.
При заполнении массива2 писать в карту, то же по ДМА во время сна процессора.
Массивы занимают всю память, обращение к карте как можно реже.
Это решение "в лоб"
Но если посмотреть на АЦП внимательнее, то там вроде как injected и regular каналы можно запускать независимо и данные получать независимо.
Если и правда так, то можно один катал преобразовывать с частотой 2000, а два других 256. С этим надо разбираться. Сначала попробуйте сделать "в лоб"

[jcxz]

Я постоянно занимаюсь вопросами потребления, считаю себя в этой сфере специалистом. Так вот:
1) STM32 - лидер по потреблению. Меньше ни у кого не будет.

На такое безаппеляционное утверждение сразу скажу что Вы не правы.
Всё зависит от задачи и требуемого алгоритма работы.
Недавно выбирал МК под задачу связанную с работой с АЦП и батарейное питание.
Рассмотрел многие МК от разных производителей, в том числе и STM32L4. В итоге выбрал LPC4370 как обеспечивающий минимальное потребление для данной задачи (ну и минимальную стоимость комплектующих).
С STM32L4 получалось гораздо большее потребление по расчётам.

[data_stack]

Если кому интересно, то в конкретно моем случае оказалось не выгодно использовать DMA. Разница не велика, порядка 400мкА, но все таки в пользу использования прерываний. Кроме того, без ДМА используется меньше оперативной памяти. Уточняю, что это справедливо только для именно моей ситуации.