Периферия и ядро от другой шины питаются. Вот ей бы ты внимание уделил.
Полезный сигнал и 'шум' ты цифровать будешь не синфазно, а поочередно. Так что сработать это может (в предположении твоего происхождения шумов -)) ) только если верхняя граница спектра шума много меньше частоты дискретизации.
Вобщем, рекомендую заняться разводкой и питанием (и Vref внешний!), а не этими изысканиями
За совету спасибо) . Я понимаю, что надо заняться и трассировкой нормально и дроссель хоть повесить (там нарушено все что можно сейчас .)
Satyr писал(а):только если верхняя граница спектра шума много меньше частоты дискретизации
Вот на это акцент и делаю.
Сейчас чисто научный интерес появился, так как ранее такого подхода не встречал. Не разберусь только с каналами. Как там у меня с алгоритмом, может подскажет кто?
Давно c STM32 не возился.
Но, насколько помню, там тупо делается 'карусель' - набираешь список каналов, запрягаешь DMA, а дальше он тупо подряд выкладывает в буфер значения по очередно с каналов в списке и так далее по кругу.
Помню только, что там в документации и примерах все было вполне доступно и доходчиво.
Да, и не надо сразу лезть к голым регистрам - используй библиотеки производителя. Выгоды от ковыряния с регистрами - пара сотней байт кода и ноль в производительности. Ибо только настройка.
Но пытаться чтото там алгоритмически компенсировать при убитой аналоговой части - это глупость.
По хорошему аналоговая часть питается от отдельного стабилизатора. Аналоговые Vcc, Vref, Vpll (не помню, есть он на STM32 ?) каждый отдельным LC фильтром вплотную к ногам.
И не игнорировать рекомендации на стабилизаторы - типы и номиналы кондеров. бОльше совсем не значит лучше.
Satyr писал(а):Но, насколько помню, там тупо делается 'карусель' - набираешь список каналов, запрягаешь DMA, а дальше он тупо подряд выкладывает в буфер значения по очередно с каналов в списке и так далее по кругу.
Регистр один, а каналов много. Да и никаких флагов с номером канала, данные от которого хранятся в регистре, я не нашел
Satyr писал(а):
Да, и не надо сразу лезть к голым регистрам - используй библиотеки производителя.
Я ещё с АВР работаю с регистрами. Так у меня все на глазах .
Satyr писал(а): - это глупость.
Это не глупость - это интерес. Интересны результаты вообщем, а не к конкретному случаю.
Да и вообще, у меня проект предусматривает несколько каналов АЦП, а тут хрень такая - по-любому что-то решать нужно....
Далее в ADC3ConvertedValue[] чудным образом постоянно сами обновляются значения на 12 и 13 канале. Впринципе хоть все можно в список напихать.
И еще на DMA надо прерывание наточить, чтоб сообщало как об обновлении значений в массиве (как круг по памяти сделает)
И на некоторых семействах надо еще калибрацию ADC в ините запустить
Добрый день, скажите кто как использует DWT.
Хочу сделать профилирование процессов главного цикла по скорости работы, но ни чего путнего не выходит.
Пока остановился на таком:
Myp3ik писал(а):И ячеек в массиве тоже много, что бы DMA сохранял каждый канал по определённому индексу в массиве.
Тоесть, в DMA есть специально выделенный буфер, который хранит инфу о каждом конкретном канале?
Satyr писал(а):Как пример. Вызвал и забыл.
За код спасибо. С DMA не работал никогда, но видимо, пришла пора .
Satyr писал(а):Совершенно неблагодарная трата времени.
Может при использовании SPI, USB, UART и прочего это и оправдано (хотя не знаю, не использовал), но при настройке таймеров, АЦП и прочей простой периферии это излишне (сугубо мое мнение ).
isx писал(а):
Тоесть, в DMA есть специально выделенный буфер, который хранит инфу о каждом конкретном канале?
Нееет! Если на пальцах:
DMA вещь совершенно тупая - ей сказано по сигналу DRQ от ADC брать с такой то позиции в памяти (дата регистр ADC) и класть попрядку в кольцевой буфер. Все, больше ничего не может и не знает. Кто и какие данные ему предлагает взять (ну, кроме известной линии DRQ от источника) понятия не имеет.
'Массив' есть в ADC - представляет их себя так же закольцованное (и длина кольца у него и ДМА одинаковая) очередь - в ней инструкции с какого канала какой разрядности и за какое время семплинга брать значение и класть в дата регистр. Точнее там не кольцо, а список + директива после окончания списка - "повторить".
Т.к. кольца совпадают - то и в буфере в ОПЕРАТИВКЕ по расположению данных полностью повторяет список ADC.
Ну это если нам надо кольцевой режим для чего то инструментального. Так то он может и в линейный буфер класть.
isx писал(а):
Satyr писал(а):Как пример. Вызвал и забыл.
За код спасибо. С DMA не работал никогда, но видимо, пришла пора .
Вот этим меня '8-битчики' (это не спектр интересов, а скорее тип человека -)) ) всегда удивляют - готовы кучу время потратить на изобретение велосипеда над голыми регистрами. Код, который выполняется один раз при ините и абсолютно никакого влияния на производительность не оказывает. Вместо того, чтоб взять готовый инит из SDK проихводителя (хотя багов там у всех обычно куча, регистры и мануал почитать прийдется - не соскучитесь -)) ). Но реальными и удобными средствами организации процесса и повышения производтельности - DMA, прерывания, правильное размещение по зонам памяти, выравнивания, учет особенностей шин - этим начисто пренебрегают.
isx писал(а):
Satyr писал(а):Совершенно неблагодарная трата времени.
Может при использовании SPI, USB, UART и прочего это и оправдано (хотя не знаю, не использовал), но при настройке таймеров, АЦП и прочей простой периферии это излишне (сугубо мое мнение ).
Никакой разницы. Периферия не пахнет -))
Хотя с USB... сколько не делал на каких чипах и производителей - не помню, чтоб там без феерических фокусов обходилось -)))))
Satyr писал(а):Вот этим меня '8-битчики' (это не спектр интересов, а скорее тип человека -)) ) всегда удивляют - готовы кучу время потратить на изобретение велосипеда над голыми регистрами. Код, который выполняется один раз при ините и абсолютно никакого влияния на производительность не оказывает. Вместо того, чтоб взять готовый инит из SDK проихводителя (хотя багов там у всех обычно куча, регистры и мануал почитать прийдется - не соскучитесь -)) ). Но реальными и удобными средствами организации процесса и повышения производтельности - DMA, прерывания, правильное размещение по зонам памяти, выравнивания, учет особенностей шин - этим начисто пренебрегают.
О, да! Я тоже люблю эту древнюю и красивую легенду. Жил да был SDK у ST под названием "Standard Peripherial Library". И были там и баги и готовые иниты. И пользовались им программеры продвинутые, да посмеивались над 8-битничками неразумными. Только, вдруг, БАЦ!, и забила ST на SPL большой-пребольшой болт эмбеддерский и сказала, что теперь вместо SPL убогой будет HAL навороченный, а те дурни, что для SPL свой код писали, пусть теперь код под новый SDK переписывают или в управдомы переквалифицируются. А чтобы никто не слабился, мы через годик-другой новый SDK выкатим, там вы у нас и попляшете.
этот "регистровый" код при смене или обновлении платформы можно практически выбрасывать и садиться изобретать велосипед с нуля.
у кого жизнь началась с ATMEGA8 и ей же закончится, возможно, подход целесообразный.
в остальных случаях это нецелесообразно и не дальновидно
p.s. года 2 как атмел взялся на ум и начал чтото конкурентоспособное выпускать. смотрите ихние Cortex M4/M7/A5. Ушел на них с AT32UC3A3xx, LPC247x/LPC178x, STM32F2xx, i.MX233
Учитывая законсервированность контенгента, то используется реже всех. Но кто использует - доволен, это ты скорее всего видел, когда гуглил
Развивается, поддержка нового добавляется. Удобно, что это ни разу STM32 only. Т.е. встал и свалил на другой камень.. Если он поддерживается
Satyr писал(а):этот "регистровый" код при смене или обновлении платформы можно практически выбрасывать и садиться изобретать велосипед с нуля.
у кого жизнь началась с ATMEGA8 и ей же закончится, возможно, подход целесообразный.
в остальных случаях это нецелесообразно и не дальновидно
Единственный смысл всех этих SDK заключается в том, чтобы писать код с их помощью могли малограмотные индусы за чашку риса. Любой, кто в теме чуть глубже, скорее всего уже владеет и библиотечным и регистровым подходом (или разберется с ними в разумные сроки) и предпочитает тот, каким лично ему пользоваться удобнее. Кому-то нужно быстрее запуститься и он выберает SDK, кто-то любит поосновательнее и ему хочется покопаться в регистрах. Ничто не мешает практиковать любой из подходов в зависимости от требований проекта. Какую-то надуманную тему вы подняли, да еще делить всех принялись на белых сахибов и грязных туземцев. Не серьезно.
hybroid писал(а):Т.е. встал и свалил на другой камень..
А смысл?
Смысл свалить на другой камень есть только тогда, когда этот другой представляет из себя нечто ДЕЙСТВИТЕЛЬНО другое.
А сваливать на тот же хер, только в профиль - нет никакого смысла.
У меня в разных проектах разные платформы лишь потому, что эти проекты реализуются на них посредством особенностей платформ.
И заменить 24-ый ПИК на СТМ32 или наоборот не получится.
Каждому овощу - своя грядка.
Полагаю, что создавать переносимый на разные платформы проект, жертвуя функционалом (включая экономический функционал, конечно), - полная глупость.
Затраты на портирование практически равны затратам на новый проект.
.) 
