С чего вообще лучше начать путь в программировании микроконтроллеров

Всем привет!
Появился такой вопрос "С чего же лучше начать изучение мк?".ЯП - Си. Но именно по аппаратной части, что лучше подходит новичку, чтобы серьезно этим заниматься?
Хочу изучать, чтобы связать с этим будущую профессию.
Буду рад почитать все ваши ответы, заранее спасибо!

0

Сообщение от locm Нет такого понятия "контроллерный Си". Языковые конструкции такие как в "компьютерном Си".

Угу. К периферии он, разумеется, не обращается - весь ввод-вывод черед iostream stdio.

Сообщение от locm Почему? Все функции с открытым котом и можно посмотреть как они устроены.

А вы пробовали?
Я - пробовал. Когда разбирался с тем, что они там накрутили в своей реализации USB. Трижды проклянул этих наркоманов, которые ПЯТЬ раз перекладывают одни и те же аргументы из пустого в порожнее. Написать свою реализацию оказалось проще, чем разбираться в говнокоде Куба.

Сообщение от locm Написать переносимую программу даже на Си между x86, AVR и ARM крайне сложно. Не соглашусь. Посмотрите подобные проекта например FreeRTOS.

Ну да, RTOS же каждый любитель-кнтроллерщик пишет. Непременно заботясь о вынесении платформо-зависимого кода в слой абстракции. Лично у вас много кроссплатформенных проектов написано по сравнению с платформо-зависимыми?

Сообщение от locm То есть переписать 10% Си кода сложнее чем 100% асм кода?

А зачем вы вообще хотите переписывать реализацию учебных задач?! Я бы еще понял портирование полноценных решений, но их на асме не пишут.
Завязывайте с фанатизмом, ладно?

Сообщение от locm Все намного сложнее. Отличия не только в совершенно других асм инструкциях, но и в процессоре. В PIC16 один регистр общего назначения, аппаратный 8-ми уровневый стек и др.

Хотите, я вам еще особенностей накидаю?
ATtiny6 - оперативки нет вообще. Есть аппаратный стек на 3 числа и есть 32 регистра - все.
PIC - единственный регистр, банковая организация памяти, зато возможность проводить арифметические операции регистр-память.
RISC-V - инструкций работы со стеком нет вообще, все реализуется руками. Нет регистра флагов, то есть сложение 128-битных чисел становится довольно интересным.
ARM - есть инструкции, которые могут выполняться или нет в зависимости от флага.
Про PIC я знаю мало, поэтому его опущу.
В ARM и RISC-V не всегда можно загрузить константу в регистр за одну инструкцию (просто потому что они 32-битные). Зато возможна косвенная адресация вроде lw r1, 5(r2) в отличие от AVR, где в регистр адреса надо положить точный адрес (lpm r16, X).
Организация прерываний: в AVR переход идет сначала по номеру прерывания, и оттуда если надо еще один прыжок к обработчику. В ARM ядро сначала читает адрес и переходит по нему сразу. В RISC-V можно сделать как в ARM, а можно - единый обработчик всех прерываний, а там уж пусть программист решает.
Организация памяти: в AVR память данных, память программ и память периферии - три разных памяти. Часть регистров периферии доступна по специальным командам in/out, а часть только через отображение на память (но это костыль) В ARM, RISC-V вся память доступна единообразным способом, плюс есть разграничение прав доступа.
---
А теперь внезапный вывод: это НИКАК не опровергает мое высказывание про ассемблеры.

Сообщение от locm Перенести прогу на асме одной платформы на другую намного сложнее чем на Си.

Могу только повторить вопрос: зачем вам переносить учебные программы между контроллерами? Или вы хотите писать сложные программы целиком на ассемблере?

Добавлено через 21 минуту

Сообщение от Voland_ inline'ассемблера достаточно.

Для использования да. Для всяких хитрых оптимизаций, например. Но его ведь тоже надо как-то выучить. И анализ дизасма тоже несколько другой навык.

Сообщение от Voland_ Попробуйте сравнить какой-нибудь кусок кода скомпилированный под озвученные Вами платформы и сравните. Разница будет колоссальная.

Пробовал, говорю же. Они только выглядят по-разному, принцип один.
Особенно если не писать огромные программы на ассемблере, как предлагает locm, а уметь читать интересующие куски и писать вставки.
Согласитесь, что знание какого-нибудь Питона читать дизасм x86 не поможет вообще. А вот знание AVR-ассемблера хоть немного, но поможет.
А для общего понимания что происходит в процессоре при выполнении кода вообще без разницы какой ассемблер. Тем более что в навороченных ARM или x86 точную последовательность далеко не всегда угадать можно.

Сообщение от Voland_ Но речь о другом была - мы говорили о необходимости изучать ассемблер, чтобы на нем писать программы, не читать. А это совершенно другая задача.

Сколько помню, такая задача уже давным-давно не ставится. Даже на AVR большие программы на ассемблере не пишут. Сейчас его задачи другие:
- учебная: показать как строка на ЯВУ преобразуется в машинные команды, как машинная команда оперирует регистрами и памятью, как выполняется. Сюда же работа с прерываниями, наглядное объяснение volatile и контекста выполнения.
- оптимизационная: сделать небольшую inline-вставку или отдельный файл с критичным к времени или платформо-специфичным кодом (переключатели задач в ОС, например).
- аналитическая: посмотреть дизасм чтобы найти багу или узкое место реализации.

Сообщение от Voland_ В смысле вы конечно можете писать на ассемблере ARM писать программы так, как вы это делаете для AVR

Для RISC-V писал. Причем сознательно упрощал код - в некоторых местах можно было сделать чтение по смещению, но нагляднее - заново загрузить константу и читать именно по ней. Уверен, что компилятор Си сделал бы лучше, но задача стояла научиться, а не ставить рекорды производительности.

Сообщение от Voland_ PS: я когда писал GUI и серверные задачи под PC

В данном случае я вас полностью поддерживаю: ассемблер х86 ужасен. Очень плохо когда именно ему учат студентов.Лучше бы взяли тот же AVR или RISC-V, они гораздо проще, а объясняемые на них вещи ровно те же - регистры, память, стек и т.д.
А учитывая, что фактических знаний о синтаксисе именно того ассемблера у учащихся почти не сохраняется, да и пользоваться им они скорее всего не будут, ничего плохого именно в "модельном" языке. Это не поможет и не помешает в дальнейшей жизни.

Сообщение от Voland_ Соответственно, и изучение МК тоже эволюционирует - люди приходят со стороны программистов, а не электронщиков и цифровиков, и это очень важно.

А тут вопрос интересов ТСа что ему нужнее - получать готовые устройства, пусть менее оптимизированные, или ковыряться в низкоуровневых понятиях.
Клинический вариант первого - Ардуина: сразу получаешь готовое поделие, которое кое-как работает. Правда, допилить до нормальной работы уже сложно.
Близкий к клиническому вариант второго - я

0

Сообщение от COKPOWEHEU Угу. К периферии он, разумеется, не обращается - весь ввод-вывод черед iostream stdio.

Не путайте ЯП и библиотеки. Доступ к периферии через библиотеки. Или скажите что в Си добавили языковые конструкции специально для МК? Приведите их примеры.

Сообщение от COKPOWEHEU А вы пробовали?

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

Сообщение от COKPOWEHEU Когда разбирался с тем, что они там накрутили в своей реализации USB.

USB, CAN, Ethernet - не самые лучшие примеры, потому что кроме работы с регистрами нужно много чего еще знать, не относящегося к конкретному МК.
Они усложнили библиотеки ради универсальности. Чтобы получить любой класс устройства для любого МК.

Сообщение от COKPOWEHEU А зачем вы вообще хотите переписывать реализацию учебных задач?!

Я отвечал на ваше заявление. Неужели забыли что вы писали?

Сообщение от COKPOWEHEU Поэтому платформо-зависимость ассемблера недостатком не является.

Сообщение от COKPOWEHEU Завязывайте с фанатизмом, ладно?

А вы завязывайте с троллингом, ладно?

Сообщение от COKPOWEHEU А теперь внезапный вывод: это НИКАК не опровергает мое высказывание про ассемблеры.

Это лишний раз подтверждает что переносимость кода на асме ниже чем на ЯВУ. Хотя вы утверждаете что "платформо-зависимость ассемблера недостатком не является."

Сообщение от COKPOWEHEU Могу только повторить вопрос: зачем вам переносить учебные программы между контроллерами? Или вы хотите писать сложные программы целиком на ассемблере?

В третий раз повторить? Я отвечал на ваше высказывание что "платформо-зависимость ассемблера недостатком не является."
Что учебные или реальные задачи, я ничего не писал. Это ваши толль-домыслы!

Сообщение от COKPOWEHEU Особенно если не писать огромные программы на ассемблере, как предлагает locm

Где я это предлагал? Опять троллите!!!!

Сообщение от COKPOWEHEU Согласитесь, что знание какого-нибудь Питона читать дизасм x86 не поможет вообще.

А знание x86 сильно поможет читать дизасм ARM? Может будете догадываться о назначении каких-то инструкций, но не всех и не на 100%.

0

Сообщение от locm Не путайте ЯП и библиотеки. Доступ к периферии через библиотеки.

Не угадали. Доступ к периферии через регистры. А уж кто их будет дергать, основной код или библиотеки - дело десятое.

Сообщение от locm Или скажите что в Си добавили языковые конструкции специально для МК? Приведите их примеры.

Иногда добавляют. Например, модификатор PROGMEM в AVR или объявление прерываний как ISR там же.
Но вы старательно виляете из стороны в сторону лишь бы не признавать тот простой факт, что программирование на МК очень сильно отличается от программирования для ПК.

Сообщение от locm Пробовал. Библиотеки - хорошие примеры.

Если хорошие - то да, безусловно. Скажем, в инициализации дисплеев без библиотеки разобраться почти невозможно.
Но мы говорили не о хороших библиотеках, а о Кубе.

Сообщение от locm Я отвечал на ваше заявление. Неужели забыли что вы писали?

Вы не ответили на вопрос: если ассемблер нужен в учебных целях, что именно вы на нем собрались переписывать?

Сообщение от locm А вы завязывайте с троллингом, ладно?

Лучше вы завязывайте с демагогией и приписыванием мне своей чуши.

Сообщение от locm Это лишний раз подтверждает что переносимость кода на асме ниже чем на ЯВУ. Хотя вы утверждаете что "платформо-зависимость ассемблера недостатком не является."

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

Сообщение от locm В третий раз повторить? Я отвечал на ваше высказывание что "платформо-зависимость ассемблера недостатком не является." Что учебные или реальные задачи, я ничего не писал. Это ваши толль-домыслы!

А, то есть вы сейчас сами признались, что вырвали фразу из контекста и яростно ее опровергаете. И этот человек еще будет обвинять меня в троллинге!

Сообщение от locm Где я это предлагал? Опять троллите!!!!

Перечитайте свой предыдущий пост, где вас возмущала непереносимость асма.
Для меня она недостатком не является, поскольку больших программ на нем я не пишу.
Из чего логичный вывод, что вы пишете, или подозреваете, что ТС будет писать. Хотя непонятно зачем.

Сообщение от locm А знание x86 сильно поможет читать дизасм ARM? Может будете догадываться о назначении каких-то инструкций, но не всех и не на 100%.

Поможет, конечно. Значения инструкций можно и в справочнике посмотреть, как собственно все и делают. А вот понять логику ассемблерной программы, ее типичные ограничения и подходы можно только на практике.

0

Сообщение от COKPOWEHEU Не угадали. Доступ к периферии через регистры.

И что в Си для этого предусмотрена спец. языковая конструкция? Если нет, то что вы пишите что есть какой-то Си для МК?

Сообщение от COKPOWEHEU Но мы говорили не о хороших библиотеках, а о Кубе.

HAL/LL можно использовать как примеры работы с регистрами.

Сообщение от COKPOWEHEU Например, модификатор PROGMEM в AVR

https://manned.org/___ATTR_PROGMEM__/95d57a16
pgmspace.hЭто не новая языковая конструкция, но всего лишь __attribute__ то есть атрибут __progmem__ для компилятора. Поддерживается не всеми компилятор и тем более в стандарт Си не входит. Так что нет никакого Си для МК.

0

Сообщение от locm И что в Си для этого предусмотрена спец. языковая конструкция? Если нет, то что вы пишите что есть какой-то Си для МК?

То есть вы бы программировали все в одном стиле - что ядро ОС, что графическое приложение, что микроконтроллер? Или все-таки есть особенности в том, какое подмножество языка использовать?

Сообщение от locm Поддерживается не всеми компилятор и тем более в стандарт Си не входит.

Именно так! Это специфика данного конкретного порта Си на контроллер. У cvavr вообще разрешена конструкция PORTB.1, что тоже не входит в стандарт Си.

Сообщение от locm HAL/LL можно использовать как примеры работы с регистрами.

Можно, но лучше поискать человеческие библиотеки. Даже libopencm3 лучше, хотя тоже накручена.

0

Сообщение от COKPOWEHEU То есть вы бы программировали все в одном стиле - что ядро ОС, что графическое приложение, что микроконтроллер?

Причем здесь это?
Я пишу что на Си есть стандарт и в нем нет такого понятия как "Си для МК". Другой стиль программирования не назначает что Си другой.

Сообщение от COKPOWEHEU Даже libopencm3 лучше, хотя тоже накручена.

Вы писали про куб. Он не генерирует код для libopencm3.

0

А если начать с ARM, то будет плохо?

0

locm, COKPOWEHEU, давно не виделись, да
прекращайте пикетирование, ТС вы не поможете еще сильней запутаете, а друг с другом вам договорится вряд ли удастся
резюмируйте свои пожелания
я так понял
COKPOWEHEU, -AVR и ассемблер
locm, - ARM,точнее его разновидность STM, и Си

свое мнение высказывать не буду, дабы не раздувать холивар
единственно скажу Kaiff, чтобы научится плавать надо лезть в воду, а не спрашивать какие плавки купить

возьми какой-нибудь китайский брелок, разбери его и попытайся повторить, половина вопросов сами исчезнут
Правда появятся другие но это уже совсем другая история

0

Сообщение от locm Причем здесь это?

Могу повторить: "программирование на "Си для ПК" сильно отличается от программировани на "Си для МК"". Кавычки здесь тоже неспроста.

Сообщение от locm Вы писали про куб. Он не генерирует код для libopencm3.

Я писал что куб лучше вообще не использовать. А для анализа алгоритма использовать человеческие библиотеки.

Сообщение от Kaiff А если начать с ARM, то будет плохо?

Вы видели примеры простейшей мигалки на ST-HAL для ARM, на обычном Си для AVR и на ассемблере для него же. Попробуйте в них разобраться. Если вариант STM кажется вам достаточно понятным берите его. Но не плачьтесь потом, что "я накидал в Кубе проект, а ничего не работает".

Сообщение от ValeryS свое мнение высказывать не буду, дабы не раздувать холивар

Ну как теперь не спросить какой же подход к обучению считаете правильным лично вы?!

0

Сообщение от Kaiff А если начать с ARM, то будет плохо?

Нет. Эти МК поддерживают отладку и можно посмотреть как выполняется программа и если не так как задумано, понять почему. Большинство AVR не поддерживают отладку и приходится только догадываться почему не работает или просить помощи на форуме.
Думайте что для вас важнее, видеть как выполняется программа или представлять как выполняется программа (по началу это не просто, т. к. опыта нет).

0

Сообщение от locm Большинство AVR не поддерживают отладку

откуда такая уверенность?

Добавлено через 5 минут
...в AVR озвучен debugWIRE, это в девайсах, в которых нет JTAG. Но, честно сказать, я им никогда не пользовался, и о качестве дебага ничего сказать не могу.

Добавлено через 8 минут

Сообщение от locm И что в Си для этого предусмотрена спец. языковая конструкция? Если нет, то что вы пишите что есть какой-то Си для МК?

тут вы явно играете словами. Думаю, вы сталкивалить с различиями между компиляторами для разных МК. Они вроде и не существенные, но встроенные макросы прерываний, назначение атрибутов, разное использование флагов __pragma__ имеют непосредственное влияние на поведение _определенного_ компилятора. Различия эти можно найти на поверхности - в библиотеках от TI или ST - особенности для компиляторов IAR, KEIL, GCC... То же есть и в AVR - CodeVision AVR имеет вообще "свое" понимание организации доступа к памяти и к портам, не совсем Си-подобное. Другими словами, проекты под этот компилятор не совместимы и не портируемы, например, под GCC.
И да - это не "Си для МК", но это отдельный набор макросов, команд компилятору, которых нет ни в одном PC-шном компиляторе, но есть в любом МК-шном.

0

Сообщение от Voland_ откуда такая уверенность?

Потому многие AVR не поддерживают ни JTAG ни debugWIRE.

Сообщение от Voland_ в AVR озвучен debugWIRE

У него много ограничений https://ru.wikipedia.org/wiki/... граничения
Из-за некоторых может быстро израсходоваться лимит стираний флешки и/или заглючить программа в МК из-за отладчика.
Кроме того debugWIRE отладчик стоит немалых денег.

Сообщение от Voland_ Думаю, вы сталкивалить с различиями между компиляторами для разных МК.

У каждого компилятора свои особенности. Если говорить о ПК то даже у MS студии, C++ билдере и GCC немного отличаются компиляторы. Почему они не должны отличаться для МК?

0

Сообщение от Voland_ откуда такая уверенность?

Из личного опыта подтверждаю: в младших AVR со встроенной отладкой все плохо. Впрочем, внутрисхемная отладка в любых контроллерах далеко не так полезна, как в компьютере, неважно AVR это или STM.

Сообщение от Voland_ И да - это не "Си для МК", но это отдельный набор макросов, команд компилятору, которых нет ни в одном PC-шном компиляторе, но есть в любом МК-шном.

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

0

Блин, далась вам эта отладка!

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

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

Что касается исчерпания лимита перезаписи flash, то это не смешно. Даже если ценой многомесячной отладки удалось довести контроллер до помирания флеша, то берем другой и мучаем дальше, чай не коллайдер. Когда-то, напомню, контроллеры были вообще однократно программируемыми, и ничего, жили как-то с этим.

0

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

Справедливости ради,SWD может работать асинхронно, без остановки контроллера.
Плюс одна из задач отладки - определить где именно контроллер заклинил. Правда, это не слишком поможет, поскольку непонятно как он туда попал и почему не может выбраться.

Сообщение от quwy Отлаживать нужно в эмуляторе, где и течение времени можно притормозить хоть в миллион раз, и бабахов не будет ни при каких раскладах.

В эмуляторах проблема с периферией.

0

Сообщение от quwy Что касается исчерпания лимита перезаписи flash, то это не смешно. Даже если ценой многомесячной отладки удалось ...... контроллер до помирания флеша

например stm8s003, там всего 100 циклов
За сколько месяцев его убьёшь?

0

Сообщение от quwy далась вам эта отладка

Значительно облегчает и ускоряет разработку.

Сообщение от quwy Отлаживать нужно в эмуляторе

Эмулятор не на 100% соответствует реальному устройству. Ни разу не было такого что в эмуляторе работает, а в железе нет или наоборот?
И не на все МК есть эмулятор.

0

Сообщение от ValeryS например stm8s003, там всего 100 циклов За сколько месяцев его убьёшь?

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

PS: показатель количества записей, я так себе подозреваю, устанавливается производителей, исходя из спецификации. То есть производитель, скажем, гарантирует, что при температуре -40 или +80 FLASHвыдержит 100 перезаписей (без ошибки) при питании МК, например, 2,2В и, главное - данные будут сохраняться заданное количество времени. Конечно, данные с потолка, но это для сути. Это значит, что, скажем, повторная запись будет иметь ту же вероятность ошибки (и скорее всего не произойдет). И вероятность повторной ошибки очень низкая, поначалу, особенно если МК программируется в нормальных условиях. То есть МК в режиме отладки можно смело "убивать", как с точки зрения ремонтопригодности, так и с точки зрения надежности FLASH.

0

Сообщение от Voland_ Может тысяча была перезаписей, может и больше ). а может то s103 был - я не знаю.

скорее всего
я отлаживаю на 103, есть у меня макетка, а потом лью в 003

0

Сообщение от locm Эмулятор не на 100% соответствует реальному устройству. Ни разу не было такого что в эмуляторе работает, а в железе нет или наоборот?

Было, конечно, но если знать косяки, то в эмуляторе все равно в 100 раз проще и быстрее.

0