[STM32 для чайника]

Почему-то сразу вспомнилась "трагедия" в детском саду: 

Скрытый текст

 

 

 

[STM32 для чайника]

1 минуту назад, mail_robot сказал:

спора о чем? кто нить вообще помнит?

А чёрт его знает, каждый потихоньку "набрасывает", он и крутится.

[STM32 для чайника]

47 минут назад, my504 сказал:

1. А Вы не  нуб? 

Новичок - да, нуб нет. (“Эта роль ругательная, и я прошу ее ко мне не применять!”) Не припомню такого слова в русском языке, раз Вы первый решили "похвастаться" знаниями литературных терминов.

50 минут назад, my504 сказал:

Только из лени ознакомиться с оригинальными возможностями МК? Я не понимаю такой лени. Не нравится железо - смените хобби.

Мне возвращаться к примерам с отверткой и шуруповёртом? Для каждой задачи свой инструмент и точка.

[STM32 для чайника]

11 минуту назад, my504 сказал:

Еще раз - Вы лжете. Имбецил  - вполне литературный термин и

Причём тут имбецил, речь шла о "полного нуба", Вы когда отвечаете ответы хоть как-то читаете? И где я написал, что имбецил это НЕ литературный термин? Или продолжаете линию: есть моё мнение и неправильное. Второй раз Вы лжёте, когда обвиняете меня во лжи, явившееся следствием Вашей невнимательности.

15 минут назад, my504 сказал:

Повторяю. Абстракция призванная упростить ВАЖНУЮ сущность  принципиально ущербна. Даже разные модели МК одной платформы могут иметь специфические особенности, которые не позволяют написать универсальный драйвер периферии (тут речь идет о драйверах кода прошивки, естественно, а не о драйверах ОС).

Смотрите, моё мнение как новичка в МК, есть CubeMX, который, по моему мнению, очень хорошо подстраивается под конкретный МК, показывается вся доступная периферия присуще только тому МК, который выбирается. Также настраивается и т.д. В случае превышения частот - сигнализируется, что конкретный МК не может работать в таком режиме. Т.е. риск "загнать" МК в нехорошие состояние значительно снижается. Я считаю, что когда происходит частая смена контроллеров, лучшего средства, чем CubeMX нет. Например, возвращаясь к своей халабуде, мне вообще не составило труда в очень кратчайшие сроки перенести проект на новый МК, причём МК по периферии достаточно отличаются.

В общем, постараюсь в последний раз донести свою мысль, т.к. итак «загадили» тему ненужными «разговорами», собственно как и писал ранее, всё равно каждый останется при своём мнение. Если и без HAL при программирование МК можно найти достаточно «кубиков созданным чужим дядей для имбецилов», нет смысла зацикливаться на ещё одном «кубике». Надеюсь так будет коротко и понятно.
 

[STM32 для чайника]

2 минуты назад, mail_robot сказал:

только теоретическая. На практике это врятли кому то нужно ибо смысла не имеет

Согласен, но это я к тому, что всё-равно используется "кубик созданный чужим дядей для имбецилов". Так если всё-равно используется данный кубик и не один, в чём HAL тогда заслужил к себе такое отношение.

[STM32 для чайника]

1 минуту назад, my504 сказал:

1. Вы лжете. Я ни разу ни Вас, ни Ваших единомышленников в этой ветке не называл ни "чмо", ни "ущербный", ни "имбецил".

Внимательно читаете? Я написал "можете не стесняться в выражениях, сразу переходИте на "чмо, ущербный и т.д.".", перевожу для Вас, что можете не ограничиваться в выражениях и в дальнейшем переходит на "чмо, ущербный и т.д.". Просьба в дальнейшем читать внимательнее.

Один вопрос: при использовании драйвера есть ли у него возможность преобразовывать передаваемые данные?

[STM32 для чайника]

53 минуты назад, my504 сказал:

полного нуба.

Да, я действительно, как Вы выразились "нуб в микроконтроллерах" и это не скрываю, только начал знакомство, можете не стесняться в выражениях, сразу переходите на "чмо, ущербный и т.д.".

53 минуты назад, my504 сказал:

1. Ни драйверы обслуживающие программатор/отладчик, ни сам этот прибор НИКАК не влияют на процесс прошивки. Либо прошивка пройдет удачно, либо эти приборы/оболочки тупо неисправны.

2. Компилятор действительно влияет на код, но это тот уровень абстракций, который  никак не изменяет выходную функциональность. Просто  одни сущности заменяются на другие. Что характерно, все компиляторы Си для МК ПЛАТФОРМОЗАВИСИМЫ. То есть создать полностью кроссплатформенный код на Си для микроконтроллеров принципиально невозможно.

Вы уверены в драйвере, что он не пошлёт какую-то доп. команду программатору или код, который может быть заменён исходный. Компилятор ВСЕГО-ТО заменяет одни сущности на другие. Вы уверены что только одни сущности на другие, а не добавляет/изменяет код так, что даже по размеру прошивки нельзя будет узнать, что код изменён. В конце концов банально в программаторе может быть "закладушка", которая будет что-либо добавлять в код или что-то изменять. Это я к тому, с чего такая уверенность, что промежуточный код и устройства, которыми Вы пользуетесь, НИКАК не влияют, а вот только код HAL так и кишит разными "вирусами". Не хочу опускаться до оскорблений, но у меня есть предположение, что Вы не до конца понимаете как устроены и работают те же  драйвера.

Не понимая особо в МК, я лишь хочу донести одну мысль, но пока не очень получается, попробую с другой стороны. 

С чего Вы взяли, что именно Ваш подход считается профессиональным, золотой серединой и единственно-правильным, а все остальные "кубики созданные чужим дядей для имбецилов". Тогда надо идти дальше и убирать все остальные промежуточные звенья и переходить на полностью дискретный уровень, чтобы исключить драйвера, среды разработок и т.д. Покупаем отдельно таймера, мультиплексора, счётчики, сдвиговые регистры и т.д. и делаем действительно профессиональное устройство.Ещё раз, Вы также используете "кубики созданные чужим дядей для имбецилов", но при этом одни кубики Вы, по всей видимости, таковыми не считаете. Почему-то сразу вспомнился фрагмент из кинофильма "Инспектор ГАИ"

Скрытый текст

 

 

[STM32 для чайника]

1 минуту назад, my504 сказал:

А это имеет значение? Если говорить об STM32 - это ST-link. Если о dsPIC33 - ICD3 или PICkit3.

Конечно имеет, Вы же за "чистоту" кода, а здесь оказывается появился ST-link, драйвера под него и т.д., т.е. пользуемся сторонним устройством и кодом, который может также "криво" написан  и как следствие МК может "прошиваться" не так как заявлено или при каких-то условиях что-то недозагрузить или загрузиться с ошибками и т.п. 

5 минут назад, my504 сказал:

Некоторые вообще пишут код в стороннем редакторе и используют компилятор с командной строки.

Компилятор сами писали? А как же "чистота" кода? Нельзя использовать сторонние "кубики созданные чужим дядей для имбецилов". Вы и сами понимаете абсурдность полного написания всего с нуля, но при этом не замечаете, как сами пользуетесь сторонними устройствами и кодом, которые МОГУТ тем или иным образом влиять на МК. 

Я бы и не стал продолжать данную "дискуссию", если бы не Ваше сравнение всех кто пользуется "сторонними кубиками имбецилами".

[STM32 для чайника]

8 минут назад, my504 сказал:

1. Операционная система и среда, которыми я пользуюсь  для разработки никакого отношения к обсуждаемому вопросу не имеют, поскольку  не являются предметом разработки.

Т.е. Вы абсолютно уверены, что ОС, среда разработки, драйвера и т.д. никак не повлияют на МК? Может я где-то ошибаюсь, т.к. в МК новичок, но стесняюсь спросить, а чем собственно Вы "прошиваете" контроллер?

[STM32 для чайника]

@ruhi соглашусь с Вами. Поймал себя на мысли, что нередко попадаются статьи, где тот же полиморфизм трактуют как исключительно перегрузку методов.

[STM32 для чайника]

Ребята, не "ругайтесь", чтобы в общих чертах понять суть ООП, достаточно в поисковике набрать "парадигмы ооп".

[STM32 для чайника]

12 часа назад, my504 сказал:

Тогда и появится интерес к настоящему творчеству, а не примитивному складыванию кубиков созданных чужим дядей для имбецилов. 

Думал, что закончу со спором, но не могу пройти мимо подобных оскорблений.

Я Вам открою страшную тайну, операционная система, которой Вы пользуетесь при проектировании, также является «кубиком созданным чужим дядей для имбецилов», среда разработки, в которой Вы пишите код, аналогично. Драйвер для МК на ОС я также не думаю, что Вы с нуля писали и эту цепочку можно продолжить/расширить. И каждый из этих «кубиков» может тем или иным образом повлиять на дальнейшую правильную работу МК. Добро пожаловать в клуб по «складыванию кубиков созданных чужим дядей для имбецилов».

Открою ещё одну страшную тайну, бОльшая часть кода ОС, ИСР писалАсь людьми, которые, возможно, не до конца понимали как работает тот или иной регистр на ПК, но это не мешает миллионам людей пользоваться данными продуктами. Да, можно резонно заметить, что ОС периодически тормозят, их надо перезагружать из-за утечек памяти и т.п., но несмотря на это люди такие "мазохисты", что почему-то предпочитают периодически подвисающий смартфон, чем хорошо сделанный калькулятор на регистрах.

3 часа назад, my504 сказал:

1. Абстракции являются частью кода и потому должны соответствовать решаемой задаче. Отсюда следует, что и дефайны, и макросы, и  функции нужно создавать самому. 

Не следует. Если есть функция, класс, не важно, которая на 80% подходит для решаемой задачи и вы прекрасно её читаете и понимаете что и как она делает, нет смысла писать всё с нуля, достаточно доработать 20%. 

4 часа назад, my504 сказал:

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

Вот в этот момент и переходите на ППР.

4 часа назад, my504 сказал:

Именно так устроена реальная жизнь. Именно это интересно.

Это из разряда: "есть два мнения: моё и неправильное". Вам это интересно, а другому интересно делать "подвисающие смартфоны", которыми будут пользоваться многие.

[STM32 для чайника]

1 час назад, my504 сказал:

На самом деле, разработка железа и софта к нему невозможна без точного знания ПОЛНЫХ спецификаций и параметров на элементную базу.

Это кто-то оспаривает?

1 час назад, my504 сказал:

Тут проблема в том, что большинство любителей по сути любителями не являются. Они просто дети. Поиграл и бросил. Бросил, как только возникла необходимость неинтересной, на первый взгляд, работы.

Повторюсь, в том то и дело, что это зависит от конкретного ЧЕЛОВЕКА, захочет разобраться - разберётся, нет - регистры его не спасут.

1 час назад, my504 сказал:

тут дело в том, что речь идет не об отвертке/шуруповерте, а о "блондинистом" восприятии железа.

Скорее речь идёт о "патологическим мазохизме". Взял человек всё ту же злосчастную отвёртку, попробовал закрутить 1 шуруп - получилось, 2-й, 3-й,...10-й - получилось, может настало время для модернизации/рационализации/оптимизации и перейти на шуруповёрт, а отвертку использовать только в труднодоступных местах  , где без неё действительно не справиться.

Пожалуй, дальнейший обмен завуалированными "любезностями" пора прекращать, кто хотел понять мою мысль, скорее всего понял. Я могу конечно привести ещё один пример оптимизации на ручной мясорубке и мясорубке с мотором, но боюсь она не выдержит интеграции мкс и бензопилы.

[STM32 для чайника]

10 часов назад, my504 сказал:

Еще раз. Высокоуровневое программирование и HAL - никакого отношения друг к другу не имеют. От слова совсем. 

...

Мало того, подобная (для дилетантов) читабельность затрудняет работу с кодом для специалистов в предмете разработки

Я где-то писал, что HAL это исключительный атрибут высокоуровневого программирования? Ещё раз, повторюсь, человеку дали шуруповёрт, но пользуется им как обычной отвёрткой, при этом считает себя опытным оператором кибернетического устройства (это к вопросу затруднительной читабельности).

Смотрите, я делаю халабуду (специально подчеркнул), не модуль управления космического корабля, не кардиостимулятор, а халабуду, которой буду пользоваться сам, может ещё и друзья захотят. Снимаю показания с 5-6 датчиков, обрабатываю несколько внешних прерываний, немножко использую АЛУ, память, несколько таймеров и вывожу на дисплей (в дальнейшем планировал на Java сделать приложения для смартфонов). По "настоятельной рекомендации" здешних форумчан и ради собственного спортивного интереса, начал переписывать код в формате ППР (Пишу Прямо в Регистры), сделал пока правда только половину. Запустил и о чудо, на моей халабуде это никак не отразилось  .

НО, переписывание кода в ППР меня натолкнуло на одну мысль (может кому-то покажется дурацкой и идиотской), а что мешает делать код на HAL, т.к. это гораздо удобнее, быстрее и если появится необходимость, просто взять и "перенести" его из HAL в ППР. Т.е. HAL можно использовать как своего рода макетную плату, на которой быстро всё сделал, протестировал, а потом также быстро сделал печатку (ППР), если в этом будет необходимость. Т.е. сначала работаем крупным абразивом (HAL), придаём первоначальную форму, а потом шлифуем и полируем (ППР). Ведь если сразу начать с полировки, то на это уйдёт слишком много времени.

[STM32 для чайника]

Ребята, не в обиду будет сказано, но те у кого код HAL вызывает "шок", непонимание и т.д., у меня складывается такое впечатление, что вы на Си все перешли с ассемблера, причём впопыхах. Т.е. не разобравшись до конца со всеми преимуществами высокоуровнего программирования, сразу же по старинке начали использовать язык лишь как средство для обращения к регистрам. Поэтому и волна возмущений, что код это «кошмар», «ужас», «Читаемый КЕМ» и т.д.

Мне это напоминает следующее. Вы закручиваете шурупы отверткой, к вам подходит человек и говорит: «не мучайтесь, не делайте одну и ту же монотонную работу, возьмите лучше шуруповерт, будет гораздо быстрее». Вы решили воспользоваться советом и взяли шуруповёрт, но т.к. вам не объяснили, как им пользоваться, вы начали шуруповёртом закручивать шурупы также как и обычной отверткой, создав тем самым ещё больше неудобств, вместо того, чтобы просто нажать на кнопку.

10 часов назад, ttt222 сказал:

проблемы с памятью которая даже в ядре течет. и всем этим пользуется как прокладкой программист пишущий пользовательскую программу. и который тоже по большому счету мало понимает что за инструменты и "материалы" применяет. потому что его приучили не думать об этом изначально, а довериться тому кто предоставил все это в связи со всем этим мне приходится раз в неделю перезагружать свой смартфон, поскольку он начинает конкретно тупить,  а тупит потому что память течет, результат работы какой_то "хорошей" программы) возможно не одной.

Т.е. Вы считаете, что программируя «напрямую в регистры» Вы защищены от утечек памяти? Если да, разочарую Вас и повторюсь, это не зависит от того, человек программирует «напрямую в регистры» или на «высоком уровне», это зависит от самого программиста. Если программист изначально не приучен с ними бороться, он их не будет отслеживать ни на каком уровне. 

6 часов назад, MasterElectric сказал:

Да что там спорить просто люди не хотят вникать и разбираться, взяли пример работает и хорошо

Ещё раз акцентирую внимание, что «не хотят вникать и разбираться» зависит от человека. Что мешает взять чужой код «на регистрах», вставить в свой проект и бездумно использовать. Если человек хочет разобраться, он разберётся, если нет, то и «регистры» его не спасут.

Повторю, я не против обращения к регистрам напрямую, сам потихоньку с ними знакомлюсь, но В РАЗУМНЫХ  ПРЕДЕЛАХ, когда в этом есть крайняя необходимость, постоянно писать программу на них считаю несколько утопичным занятием. 

Что мешает добавить ещё немного дискретности, выкинуть МК и всё устройство делать на 155-й серии (таймера, сдвиговые регистры, счётчики делители, мультиплексора и т.д., всё есть), чем я в юношестве занимался. Да будет долго, да будет громоздко, но вы ведь добьётесь тогда главного результата, к которому стремитесь – ощущение, что вы полностью «овладели регистрами». 

3 часа назад, Alex сказал:

Многим начинающим, которые здесь пишут, он сэкономил время ? Постоянно вижу, что люди натыкаются на подводные камни, от непонимания работы HAL'а.

На правах начинающего заявляю, да, сэкономил время причём очень существенно. Причём не просто сэкономил, а послужил определённым "мотиватором" для дальнейшего изучения МК. И как начинающий говорю, если бы я начинал с регистров напрямую, подводных камней было бы в разы больше, т.к. поначалу флаг бы какой-то не установил, режим не тот выставил, ещё что не понял, в результате получились бы сплошные грабли. А HAL с самого начала направлял в "правильное русло". Повторюсь, сейчас и прямой код на регистрах стал гораздо понятнее.

6 часов назад, MasterElectric сказал:

Все просто и понятно, и совсем не асм)

 

5 часов назад, mail_robot сказал:

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

Полностью согласен с mail_robot. Смотрите как у меня происходило знакомство с МК пару недель назад. Я открыл пару примеров с "регистрами на прямую", вообще ничего не понятно, т.е. чтобы мне полноценно писать программу, мне надо в каждый регистр заходить и смотреть за что он отвечает. С HAL, т.к. код самодокументируемый, я уже из названия функции, например, приведённая выше HAL_GPIO_WritePin() уже понимаю за что она отвечает. Захожу во внутренности функции, смотрю регистры и становится гораздо понятнее.

[STM32 для чайника]

1 час назад, MasterElectric сказал:

 Как можно програмировать МК и не знать как там что устроено?

Я ни в коем разе не призываю "не знать как там что устроено", а даже наоборот, но достаточное большое кол-во современных программистов на ПК практически понятия не имеют как устроен ПК, но при этом пишут хорошие программы. Ранее @my504  написал, что "МК  это не ПК", к сожалению, у меня нет пока достаточного опыта, чтобы рассуждать о МК, но чем больше я о них читаю, тем больше складывается впечатление, что это почти ПК, а через несколько лет так вообще думаю будут все МК идти с предустановленными ОС.

1 час назад, MasterElectric сказал:

обычно люди которые понимают уровень регистров и смотрят в HAL видят там кошмар и ужас, где вы там нашли что-то хорошее?

Могу задать Вам встречный вопрос, а где там "кошмар и ужас", но воздержусь. Возможно люди привыкли к короткому "регистровому" коду и когда заходят в библиотеки с кучей условий просто теряются. Как вариант, я бы им порекомендовал посмотреть нормальный ООП код на Java и тогда, возможно, код HAL-а им покажется настолько родным и понятным, аж до безобразия.

1 час назад, MasterElectric сказал:

И меня особо улыбнуло сравнение программировать на регистрах с опусканием до уровня ассемблера, да это точно такой же С/С++. 

Именно поэтому вначале своего сообщения слова "низкий" и "высокий" я взял в кавычки. Язык то один, только одни оперируя исключительно регистрами превращают его "по сути в ассемблер" и потом возмущаются, что код от HAL это "кошмар" и "ужас", а другие пользуются всеми преимуществами относительно-высокоуровнего программирования.

Ребята, своим сообщением с разными языками программирования я лишь хотел донести мысль, что каждому своё. Подобные споры, к сожалению, всегда были, есть и будут. Помню в институте чуть ли не до "драк" доходило :), когда ассемблеристы доказывали своё превосходство над Си, а когда к этому подключались любители Java с ООП, так вообще жара. Но как ни странно, мнения своего так никто и не менял, поэтому данные споры считают априори бессмысленные.

[STM32 для чайника]

5 часов назад, mail_robot сказал:

Я думаю любой, кому не в лом заглянуть в код библиотеки довольно быстро поймет всю прелесть и логичность ее кода. Да, он напоминает шаблонный. Да в нем много "универсального" мусора, который часто и не компилируется вовсе. Но это хороший код

В том то и дело, что данный "универсальный" мусор зачастую и не компилиурется. Ведь программист, независимо от того на каком языке будет программировать, все равно будет в том или ином виде пользоваться какими-то шаблонам (наработками), в противном случае на написание кода у него будет уходить слишком много времени. Будут ли эти шаблоны на "низком" уровне или "высоком", это уже предпочтение каждого.Будут ли это свои шаблоны или нет, это также личное предпочтение каждого, ведь никто не мешает, если что-то не устраивает, подкорректировать его под себя или полностью переписать.

Также работа с регистрами напрямую не даст полной гарантии, что человек досконально разбирается в МК. Сколько примеров попадалось на глаза, когда люди пишут напрямую в регистры, но при этом, например, для инициализации того же АЦП просто копируют-вставляют код, которым ранее пользовались или где-то увидели, возможно, даже, не полностью понимая что этот код значит, но при этом они пишут напрямую в регистры. Особенно актуально среди новичков, когда код просто копируется, чтобы поскорее получить заветный результат. 

Поэтому я считаю, что если человек хочет разобраться с МК, он разберётся независимо от того, программирует он на низком уровне или высоком. А если ему это не надо или надо для получения разового результата, то он и работая напрямую с регистрами, вряд ли поймёт все тонкости работы с МК.

[STM32 для чайника]

52 минуты назад, my504 сказал:

так вот эти самые новички тупо оперируют самым верхним слоем абстракций, впадая в странные сомнения, которых ни за что бы не обрели, если бы написали практически тот же объем кода, но без лишних сущностей.

Как новичок, который начал по вечерам осваивать микроконтроллеры 2-3 недели назад не соглашусь с Вами. Программируя на ООП (Java, PHP7 и т.п.), всегда хотел хотя бы на домашнем уровне освоить МК и глядя на разные примеры (CMSIS), где люди в коде оперировали непонятными регистрами всегда хотелось "бежать" отсюда, представляя себе что надо будет проштудировать многостраничные справочники по МК. Но HAL помог начать не понимая самого МК, что очень важно для новичка. Получив первый результат меня это вдохновило и методом проб и ошибок потихоньку начал осваиваться, безусловно постоянно приходится обращаться к справочной литературе и т.д., но HAL в моём случае стал определённым "мотиватором". Сейчас и регистры напрямую не кажутся такими пугающими, как это было вначале.

Насчёт "практически тот же объем кода" и про "странные сомнения". Например, в моём случае по АЦП с ПДП. Поставил себе задачу, получать данные с 4-х каналов АЦП передавая данные с помощью ПДП. Реализовал это буквально за 5 минут 2-мя способами:

1) АЦП запускается напрямую по таймеру, ПДП в режиме Circular автоматически переносит значения.

2) АЦП запускается через обратную функцию по прерыванию от таймера, ПДП в режиме Normal.

Но ради спортивного интереса захотел реализовать 3-й вариант, когда АЦП запускается напрямую по таймеру и ПДП при этом настроен в режиме Normal, вот это у меня и вызвало трудности. Не думаю, что мне как новичку удалось бы это сделать быстрее через регистры напрямую хотя бы одним из способов. При этом ошибок, как новичок, я бы действительно много допустил.

Возможно в дальнейшем и поменяю своё мнение, но на данный момент мне HAL пока нравится, библиотечный код HAL-а после ООП читается на ура.

[STM32 для чайника]

5 часов назад, mail_robot сказал:

Читайте внимательно документацию на процессор. Хоть чуть чуть труда то надо прикладывать

Вы не поверите, но стараюсь читать и внимательно, но ввиду того, что с микроконтроллерами начал своё знакомство только недели 2 назад, многое просто с первого-второго... раза сложно для понимания. Что-то незначительное упускается из виду и в результате в целом делаются неправильные выводы. 

5 часов назад, mail_robot сказал:

Запускается ПДП как обычно и "прицепляется" к своей группе АЦП. Как только АЦП имеет в регистре данных результат, он запускает цикл работы ПДП и тот переносит значение в память или еще там куда то. Этот процесс непрерывный. Вопрос - как им управлять? Очень просто - в конфигурации АЦП указать, что стартовым условием будет являться не софт, не авто, а таймер такой то. Как только таймер сработал, АЦП выполнил преобразование, пдп увидел и отработал. Остановили таймер, остановился весь паровоз. Сложно?

Можно было так и не разжёвывать, т.к. многое (выделил серым) было и так понятно, но главного (в пред. сообщении: "как собственно указать ПДП какой массив использовать") так и не понял. Непонятно для меня следующее: я в Кубе добавил таймер, включил АЦП (непрерывное преобразование выключено), в АЦП указал, чтобы он включался по переполнению таймера, привязал ПДП к АЦП (режим normal). Вопрос, куда ПДП будет переносить значения, если мы не указали ему начальный адрес в памяти (массив) относительно которого он со смещением будет раскладывать значения? В обычном варианте, как в документации написано, я вызываю функцию HAL_ADC_Start_DMA() которой в качестве одного из аргументов передаю массив (в Си это просто указатель) и всё нормально работает.

Если я, например, в main после инициализации периферии запущу один раз HAL_ADC_Start_DMA(), то, насколько я понимаю, после переноса значений ПДП HAL выполнит HAL_ADC_Stop_DMA() и "привязка" ПДП к массиву "слетит". Поэтому я и спрашивал, как указать ПДП массив, чтобы он не "слетал".

[STM32 для чайника]

46 минут назад, mail_robot сказал:

без запуска пдп ничего ты не используешь. Просто режим будет триггерный

Собственно и интересует вопрос как сделать, чтобы ПДП с АЦП запускались без использования возвратных функций таймера, т.е. как Вы ранее писали: "Если еще флаг-инициатор от таймера прикрутите к старту опроса, то вообще будет все автоматом", чтобы всё было автоматически.

Ребята, вопросами уже всех, конечно, замучил, но здесь одно из немногих мест, где помогают. Подскажите, есть ли какое нибудь глобальное прерывание с наивысшим приоритетом на случай, если контроллер подвис или не отвечает определённое время? Т.е. если вдруг какая-то нестандартная ситуация, чтобы можно было вывести какую-нибудь сигнализацию.

[STM32 для чайника]

1 час назад, Yurkin2015 сказал:

Значит в Вашем процессоре нет такого флага.

Уже сообразил. Сейчас немножко разбираюсь с ПДП и получилось, что АЦП в режиме ПДП вызывает функцию HAL_ADC_ConvCpltCallback() только после занесения данных со всех каналов, т.е. получается для ПДП нет необходимости сравнивать флаги (не в плане сортировки значений по каналам, а выполнения какого-то кода после преобразования всех данных) или я ошибаюсь? Т.е. не нужен флаг ADC_FLAG_EOS, т.к. функция HAL_ADC_ConvCpltCallback и так вызывается после всех преобразований и копирований ПДП.

Подскажите, если я 3-й таймер настроил на запуск по переполнению АЦП, который в свою очередь работает в режиме ПДП, как собственно указать ПДП какой массив использовать. Т.е. команду HAL_ADC_Start_DMA(&hadc1,(uint32_t*) &ADC_Data,3);   уже выполнять не надо, но куда ПДП сохранять результаты не указано, как это сделать?

[STM32 для чайника]

Ребята, а ещё по DMA (ПДП) не подскажите, почему-то при "бесконечной" работе АЦП (Continuos Conversion Mode) и ПДП (Mode: Circular) записанные значения в 1-ом и 2-ом элементах массива изменяются незначительно, в пределах 5-10 единиц, а вот в 3-ем (последнем) элементе периодически значения могут опускаться на 300-400 единиц. При этом если поменять источники АЦП местами, всё равно именно в последнем элементе массива сильно скачут значения.

[STM32 для чайника]

3 часа назад, Yurkin2015 сказал:

Признак последнего канала - флаг окончания сканирования каналов ADC_FLAG_EOS.

Почему-то на на флаг (ADC_FLAG_EOS) ругается как незадекларированный. 

Я вчера пробовал через простое условие сортировать, т.е. если i==0 это первый элемент массива, i==1 - 2-й, i==2 - 3-й и обнуляем в ноль. Но что-то результата не дало. А по Вашему коду ругается на ADC_FLAG_EOS.

[STM32 для чайника]

Ребята, подскажите, в чём ошибка, 3 канала АЦП в режиме Interruption и постоянно выдаётся значение с последнего канала, т.е. того, у которого sConfig.Rank = 3 ?

Скрытый текст

  /* USER CODE BEGIN 2 */
HAL_ADC_Start_IT(&hadc1);
  /* USER CODE END 2 */

/* ADC1 init function */
static void MX_ADC1_Init(void)
{

  ADC_ChannelConfTypeDef sConfig;

    /**Common config 
    */
  hadc1.Instance = ADC1;
  hadc1.Init.ScanConvMode = ADC_SCAN_ENABLE;
  hadc1.Init.ContinuousConvMode = ENABLE;
  hadc1.Init.DiscontinuousConvMode = DISABLE;
  hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START;
  hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;
  hadc1.Init.NbrOfConversion = 3;
  if (HAL_ADC_Init(&hadc1) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Configure Regular Channel 
    */
  sConfig.Channel = ADC_CHANNEL_0;
  sConfig.Rank = 1;
  sConfig.SamplingTime = ADC_SAMPLETIME_13CYCLES_5;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Configure Regular Channel 
    */
  sConfig.Channel = ADC_CHANNEL_1;
  sConfig.Rank = 2;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

    /**Configure Regular Channel 
    */
  sConfig.Channel = ADC_CHANNEL_2;
  sConfig.Rank = 3;
  if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)
  {
    _Error_Handler(__FILE__, __LINE__);
  }

}

/* USER CODE BEGIN 4 */
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc1)
{
		adcResult[0] = HAL_ADC_GetValue(hadc1);
		adcResult[1] = HAL_ADC_GetValue(hadc1);
		adcResult[2] = HAL_ADC_GetValue(hadc1);
}
/* USER CODE END 4 */

 

В adcResult[0...2] значения получаемые с 3-го канала. Если сконфигурировать на 2-а канала, то будут значения с 2-го канала.

[STM32 для чайника]

9 часов назад, mail_robot сказал:

как попало, потому что возможно у вас нарушен гдето порядок опроса поллингом. Вам перед каждым циклом поллинга надо делать перезапуск АЦП и тогда будет порядок. Ну и не мешало бы проверить порядок опроса каналов (в конфигурации куба)

С ДМА будет надежнее и быстрее.

Благодарю за ответы! Будут делать с ДМА, но хотелось бы вначале "добить" (найти причину что не так) с polling. В общем пробовал разные варианты и получилось, что если перед условиями 

if (HAL_ADC_PollForConversion(&hadc1, 100) == HAL_OK)
  ADCValue[0] = HAL_ADC_GetValue(&hadc1); // Первый канал

обнулять элементы массива (ADCValue[0...2]=0), в которые заносятся значения возвращаемые HAL_ADC_GetValue, всё прекрасно работает. А если не обнулять, то чихарда. Почему так получается, ведь значения всё равно перезаписываться должны? Как будто время на что-то процессором тратится и значения получаемые от АЦП приходят с произвольной задержкой.