[Mik174 0]

Вопрос к тем, кто на практике использовал эти чипы и опираясь на свой реальный опыт работы с чипом, может ответить.

Подскажите, пожалуйста, какая реально достижимая скорость преобразования встроенного АЦП у STM32f103.

 

Читаю документацию, но четкого указания не нахожу -

"Sampling rate от 0.05 до 1 МГц

Total conversion time от 1 до 18 мкс"

но к обоим пунктам есть интересная пометка:

"Guaranteed by design, not tested in production."

 

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

 

Мне нужно получить преобразование по 3 каналам.

Преобразование по всем каналам должно происходить параллелльно.

Время преобразования нужно порядка 1 мкс

На всех 3 каналах захват сигнала должен происходить одновременно.

 

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

[Forger 20]

Мне нужно получить преобразование по 3 каналам.

Преобразование по всем каналам должно происходить параллелльно.

Время преобразования нужно порядка 1 мкс

На всех 3 каналах захват сигнала должен происходить одновременно.

 

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

 

Одновременно возможно по трем каналам, если у выбранного кристалла есть три УВХ и три отдельных АЦП.

У STM32 точно есть такие кристаллы. На одном УВХ и АЦП одновременно три канала не оцифровать - только поочередно.

Но очередность можно гибно настроить так, что все три преобразования будут ложится в ОЗУ с помощью ПДП (DMA) аппаратно без участия ядра.

 

Смотрите по ссылкам ниже, многие вопросы сами собой отпадут:

STM32 The insider's guide ENG

STM32 The insider's guide RUS

[adnega 11]

Использовал в таком варианте:

При 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 1]

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

[baralgin 0]

- после преобразования с 1.5 -тактовым промежутком остается "след" от предыдущего преобразования, но это, по-моему, и есть "not tested in production". В моем случае измеряемый сигнал подается на вход через резистор, на входе АЦП, так или иначе, стоит емкость - а ля, интегратор;

Значит всё же суслик есть. Я вот тоже столкнулся с этим( тут ), по моему достаточно неприятный момент.. 1Мц есть и в тоже время нет :crying: . Не могли бы вы поподробней расказать про тот самый резистор и степень исправления проблемы?

[adnega 11]

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

 

На ум приходят несколько, пожалуй, не самых удачных идей:

1. Поставить повторитель сигнала перед каждым каналом: взять какой-нить быстродействующий ОУ, соединить выход с отрицательным входом, сигнал подавать на положительный вход, выход ОУ без всяких резисторов на ногу АЦП.

2. Менять тайминги (т.е. 1.5 увеличить) или еще хуже между каждым каналом оцифровывать фиктивный с константой. Но это самых худший вариант по скорости.

3. Перетасовать каналы и последовательность оцифровки так, чтобы предыдущий и последующий каналы не сильно отличались по амплитуде. На практике сложно выполнимо.

4. Прикинуть модель работы входных цепей и делать программную коррекцию полученных данных. Потребует хорошей матобработки данных. Но, по-моему, самый перспективных вариант, если еще и п.1 сделать :)

5. "Сгородить" схему, которая бы делала автоматическую компенсацию "следа", т.е. к сигналу, который нужно измерить добавлять "ошибку", такую, чтобы после работы АЦП получать исходный сигнал. Т.е. матобработку из п. 4 "переложить" но внешнюю аналоговую схему.

 

Попробуйте проследить влияние предыдущей оцифровки на последующую - может не такая уж и сложная зависимость. Что-нить типа "из текущей оцифровки вычитай модуль разности текущей и предыдущей оцифровки деленный на 128"...

[adnega 11]

По ссылке 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 0]

adnega Спасибо, кое что прояснилось. Из вышесказанного я прикинул что наверное нужно поставить ОУ. У меня с датчика хола сигнал через 1.2К (Rain) идёт на ацп. Но в любом случае пустышки между каналами оставлю (и тайминги по возможности тоже).