Koret

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

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

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

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

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

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

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

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

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

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

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

Думал, что закончу со спором, но не могу пройти мимо подобных оскорблений. Я Вам открою страшную тайну, операционная система, которой Вы пользуетесь при проектировании, также является «кубиком созданным чужим дядей для имбецилов», среда разработки, в которой Вы пишите код, аналогично. Драйвер для МК на ОС я также не думаю, что Вы с нуля писали и эту цепочку можно продолжить/расширить. И каждый из этих «кубиков» может тем или иным образом повлиять на дальнейшую правильную работу МК. Добро пожаловать в клуб по «складыванию кубиков созданных чужим дядей для имбецилов». Открою ещё одну страшную тайну, бОльшая часть кода ОС, ИСР писалАсь людьми, которые, возможно, не до конца понимали как работает тот или иной регистр на ПК, но это не мешает миллионам людей пользоваться данными продуктами. Да, можно резонно заметить, что ОС периодически тормозят, их надо перезагружать из-за утечек памяти и т.п., но несмотря на это люди такие "мазохисты", что почему-то предпочитают периодически подвисающий смартфон, чем хорошо сделанный калькулятор на регистрах. Не следует. Если есть функция, класс, не важно, которая на 80% подходит для решаемой задачи и вы прекрасно её читаете и понимаете что и как она делает, нет смысла писать всё с нуля, достаточно доработать 20%. Вот в этот момент и переходите на ППР. Это из разряда: "есть два мнения: моё и неправильное". Вам это интересно, а другому интересно делать "подвисающие смартфоны", которыми будут пользоваться многие.

Это кто-то оспаривает? Повторюсь, в том то и дело, что это зависит от конкретного ЧЕЛОВЕКА, захочет разобраться - разберётся, нет - регистры его не спасут. Скорее речь идёт о "патологическим мазохизме". Взял человек всё ту же злосчастную отвёртку, попробовал закрутить 1 шуруп - получилось, 2-й, 3-й,...10-й - получилось, может настало время для модернизации/рационализации/оптимизации и перейти на шуруповёрт, а отвертку использовать только в труднодоступных местах , где без неё действительно не справиться. Пожалуй, дальнейший обмен завуалированными "любезностями" пора прекращать, кто хотел понять мою мысль, скорее всего понял. Я могу конечно привести ещё один пример оптимизации на ручной мясорубке и мясорубке с мотором, но боюсь она не выдержит интеграции мкс и бензопилы.

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

Ребята, не в обиду будет сказано, но те у кого код HAL вызывает "шок", непонимание и т.д., у меня складывается такое впечатление, что вы на Си все перешли с ассемблера, причём впопыхах. Т.е. не разобравшись до конца со всеми преимуществами высокоуровнего программирования, сразу же по старинке начали использовать язык лишь как средство для обращения к регистрам. Поэтому и волна возмущений, что код это «кошмар», «ужас», «Читаемый КЕМ» и т.д. Мне это напоминает следующее. Вы закручиваете шурупы отверткой, к вам подходит человек и говорит: «не мучайтесь, не делайте одну и ту же монотонную работу, возьмите лучше шуруповерт, будет гораздо быстрее». Вы решили воспользоваться советом и взяли шуруповёрт, но т.к. вам не объяснили, как им пользоваться, вы начали шуруповёртом закручивать шурупы также как и обычной отверткой, создав тем самым ещё больше неудобств, вместо того, чтобы просто нажать на кнопку. Т.е. Вы считаете, что программируя «напрямую в регистры» Вы защищены от утечек памяти? Если да, разочарую Вас и повторюсь, это не зависит от того, человек программирует «напрямую в регистры» или на «высоком уровне», это зависит от самого программиста. Если программист изначально не приучен с ними бороться, он их не будет отслеживать ни на каком уровне. Ещё раз акцентирую внимание, что «не хотят вникать и разбираться» зависит от человека. Что мешает взять чужой код «на регистрах», вставить в свой проект и бездумно использовать. Если человек хочет разобраться, он разберётся, если нет, то и «регистры» его не спасут. Повторю, я не против обращения к регистрам напрямую, сам потихоньку с ними знакомлюсь, но В РАЗУМНЫХ ПРЕДЕЛАХ, когда в этом есть крайняя необходимость, постоянно писать программу на них считаю несколько утопичным занятием. Что мешает добавить ещё немного дискретности, выкинуть МК и всё устройство делать на 155-й серии (таймера, сдвиговые регистры, счётчики делители, мультиплексора и т.д., всё есть), чем я в юношестве занимался. Да будет долго, да будет громоздко, но вы ведь добьётесь тогда главного результата, к которому стремитесь – ощущение, что вы полностью «овладели регистрами». На правах начинающего заявляю, да, сэкономил время причём очень существенно. Причём не просто сэкономил, а послужил определённым "мотиватором" для дальнейшего изучения МК. И как начинающий говорю, если бы я начинал с регистров напрямую, подводных камней было бы в разы больше, т.к. поначалу флаг бы какой-то не установил, режим не тот выставил, ещё что не понял, в результате получились бы сплошные грабли. А HAL с самого начала направлял в "правильное русло". Повторюсь, сейчас и прямой код на регистрах стал гораздо понятнее. Полностью согласен с mail_robot. Смотрите как у меня происходило знакомство с МК пару недель назад. Я открыл пару примеров с "регистрами на прямую", вообще ничего не понятно, т.е. чтобы мне полноценно писать программу, мне надо в каждый регистр заходить и смотреть за что он отвечает. С HAL, т.к. код самодокументируемый, я уже из названия функции, например, приведённая выше HAL_GPIO_WritePin() уже понимаю за что она отвечает. Захожу во внутренности функции, смотрю регистры и становится гораздо понятнее.

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

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

Как новичок, который начал по вечерам осваивать микроконтроллеры 2-3 недели назад не соглашусь с Вами. Программируя на ООП (Java, PHP7 и т.п.), всегда хотел хотя бы на домашнем уровне освоить МК и глядя на разные примеры (CMSIS), где люди в коде оперировали непонятными регистрами всегда хотелось "бежать" отсюда, представляя себе что надо будет проштудировать многостраничные справочники по МК. Но HAL помог начать не понимая самого МК, что очень важно для новичка. Получив первый результат меня это вдохновило и методом проб и ошибок потихоньку начал осваиваться, безусловно постоянно приходится обращаться к справочной литературе и т.д., но HAL в моём случае стал определённым "мотиватором". Сейчас и регистры напрямую не кажутся такими пугающими, как это было вначале. Насчёт "практически тот же объем кода" и про "странные сомнения". Например, в моём случае по АЦП с ПДП. Поставил себе задачу, получать данные с 4-х каналов АЦП передавая данные с помощью ПДП. Реализовал это буквально за 5 минут 2-мя способами: 1) АЦП запускается напрямую по таймеру, ПДП в режиме Circular автоматически переносит значения. 2) АЦП запускается через обратную функцию по прерыванию от таймера, ПДП в режиме Normal. Но ради спортивного интереса захотел реализовать 3-й вариант, когда АЦП запускается напрямую по таймеру и ПДП при этом настроен в режиме Normal, вот это у меня и вызвало трудности. Не думаю, что мне как новичку удалось бы это сделать быстрее через регистры напрямую хотя бы одним из способов. При этом ошибок, как новичок, я бы действительно много допустил. Возможно в дальнейшем и поменяю своё мнение, но на данный момент мне HAL пока нравится, библиотечный код HAL-а после ООП читается на ура.

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

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

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

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

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

Ребята, подскажите, в чём ошибка, 3 канала АЦП в режиме Interruption и постоянно выдаётся значение с последнего канала, т.е. того, у которого sConfig.Rank = 3 ? В adcResult[0...2] значения получаемые с 3-го канала. Если сконфигурировать на 2-а канала, то будут значения с 2-го канала.

Благодарю за ответы! Будут делать с ДМА, но хотелось бы вначале "добить" (найти причину что не так) с polling. В общем пробовал разные варианты и получилось, что если перед условиями if (HAL_ADC_PollForConversion(&hadc1, 100) == HAL_OK) ADCValue[0] = HAL_ADC_GetValue(&hadc1); // Первый канал обнулять элементы массива (ADCValue[0...2]=0), в которые заносятся значения возвращаемые HAL_ADC_GetValue, всё прекрасно работает. А если не обнулять, то чихарда. Почему так получается, ведь значения всё равно перезаписываться должны? Как будто время на что-то процессором тратится и значения получаемые от АЦП приходят с произвольной задержкой.