Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Какова реальная скорость преобразоваиня АЦП у STM32?
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Mik174
Вопрос к тем, кто на практике использовал эти чипы и опираясь на свой реальный опыт работы с чипом, может ответить.
Подскажите, пожалуйста, какая реально достижимая скорость преобразования встроенного АЦП у STM32f103.

Читаю документацию, но четкого указания не нахожу -
"Sampling rate от 0.05 до 1 МГц
Total conversion time от 1 до 18 мкс"
но к обоим пунктам есть интересная пометка:
"Guaranteed by design, not tested in production."

Т.е. получается типа такого "мы сделали, должно работать, но сами не смотрели, проверьте сами"?

Мне нужно получить преобразование по 3 каналам.
Преобразование по всем каналам должно происходить параллелльно.
Время преобразования нужно порядка 1 мкс
На всех 3 каналах захват сигнала должен происходить одновременно.

Возможно ли такое получить на STM32 или придется городить ПЛИС с отдельно стоящими АЦП?
Forger
Цитата(Mik174 @ Nov 14 2009, 02:32) *
Мне нужно получить преобразование по 3 каналам.
Преобразование по всем каналам должно происходить параллелльно.
Время преобразования нужно порядка 1 мкс
На всех 3 каналах захват сигнала должен происходить одновременно.

Возможно ли такое получить на STM32 или придется городить ПЛИС с отдельно стоящими АЦП?


Одновременно возможно по трем каналам, если у выбранного кристалла есть три УВХ и три отдельных АЦП.
У STM32 точно есть такие кристаллы. На одном УВХ и АЦП одновременно три канала не оцифровать - только поочередно.
Но очередность можно гибно настроить так, что все три преобразования будут ложится в ОЗУ с помощью ПДП (DMA) аппаратно без участия ядра.

Смотрите по ссылкам ниже, многие вопросы сами собой отпадут:
STM32 The insider's guide ENG
STM32 The insider's guide RUS
adnega
Использовал в таком варианте:
При ADCPRE=3 ("PCLK2/8") на частоте PLL 72МГц получаем 9МГц для тактирования АЦП.
Tconv=1.5 + 12.5 = 14 тактов => Частота на канал 0.6МГц.

Есть ряд замечаний:
- начало преобразования можно очень точно задать (с точностью до такта процессора). Используя этот факт можно оцифровывать сигнал с эквивалентной скоростью 72МГц (если начало периодического сигнала тоже синхронизируется до такта);
- после преобразования с 1.5 -тактовым промежутком остается "след" от предыдущего преобразования, но это, по-моему, и есть "not tested in production". В моем случае измеряемый сигнал подается на вход через резистор, на входе АЦП, так или иначе, стоит емкость - а ля, интегратор;
- DMA рулит!
- три канала одновременно не запомнить;
- на входе АЦП половинное напряжение питания, как оно там получается - не разбирался.

Кста, и при повышении частоты PLL до 96МГц - работает, но это для справки - можно судить об аналоговой части входа АЦП.
Axel
Там есть фишка синхронного преобразования, но только по двум каналам. Три не получится...
baralgin
Цитата(adnega @ Nov 16 2009, 10:02) *
- после преобразования с 1.5 -тактовым промежутком остается "след" от предыдущего преобразования, но это, по-моему, и есть "not tested in production". В моем случае измеряемый сигнал подается на вход через резистор, на входе АЦП, так или иначе, стоит емкость - а ля, интегратор;

Значит всё же суслик есть. Я вот тоже столкнулся с этим( тут ), по моему достаточно неприятный момент.. 1Мц есть и в тоже время нет crying.gif . Не могли бы вы поподробней расказать про тот самый резистор и степень исправления проблемы?
adnega
Резистор у меня "рукодельный" (т.е. я его специально ставил, чтоб как-то ток ограничивать). Сопротивление 20+33 ома. Про емкость завтра поищу. Что-то видел в доках. Но заранее хочу предупредить, что для меня это не проблема, т.к. я не использую все отсчеты - получается так, что на каждый "нужный" отчет у меня приходится несколько "фиктивных", а последовательное преобразование в АЦП делаю лишь для соблюдения точных временных параметров и сбора в буфер по ДМА. Сигнал затухающий и "фиктивные" выборки стремятся к константе, т.е. до "нужного" отчета у меня оцифровывается сигнал близкий к этой константе (к половине питания) и влияние всегда одинаково.

На ум приходят несколько, пожалуй, не самых удачных идей:
1. Поставить повторитель сигнала перед каждым каналом: взять какой-нить быстродействующий ОУ, соединить выход с отрицательным входом, сигнал подавать на положительный вход, выход ОУ без всяких резисторов на ногу АЦП.
2. Менять тайминги (т.е. 1.5 увеличить) или еще хуже между каждым каналом оцифровывать фиктивный с константой. Но это самых худший вариант по скорости.
3. Перетасовать каналы и последовательность оцифровки так, чтобы предыдущий и последующий каналы не сильно отличались по амплитуде. На практике сложно выполнимо.
4. Прикинуть модель работы входных цепей и делать программную коррекцию полученных данных. Потребует хорошей матобработки данных. Но, по-моему, самый перспективных вариант, если еще и п.1 сделать smile.gif
5. "Сгородить" схему, которая бы делала автоматическую компенсацию "следа", т.е. к сигналу, который нужно измерить добавлять "ошибку", такую, чтобы после работы АЦП получать исходный сигнал. Т.е. матобработку из п. 4 "переложить" но внешнюю аналоговую схему.

Попробуйте проследить влияние предыдущей оцифровки на последующую - может не такая уж и сложная зависимость. Что-нить типа "из текущей оцифровки вычитай модуль разности текущей и предыдущей оцифровки деленный на 128"...
adnega
По ссылке http://www.st.com/stonline/products/literature/an/15067.pdf можно найти документ "AN2834 How to get the best ADC accuracy in STM32F10xxx devices". Читать в пунктах 1.2.5 и 1.2.6. про паразитные R и C. Идея вкратце такая: большое значение Cain+Cp (ровно как Radc+Rain) могут ограничивать частоту исходного сигнала - т.к. требуется время для перезаряда конденсатора (что было очевидно изначально).
baralgin
adnega Спасибо, кое что прояснилось. Из вышесказанного я прикинул что наверное нужно поставить ОУ. У меня с датчика хола сигнал через 1.2К (Rain) идёт на ацп. Но в любом случае пустышки между каналами оставлю (и тайминги по возможности тоже).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.