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

[data_stack]

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

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

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

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

[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мкА, но все таки в пользу использования прерываний. Кроме того, без ДМА используется меньше оперативной памяти. Уточняю, что это справедливо только для именно моей ситуации.