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

@Kaiff · Регистрация: 14.07.2021

Author24 — интернет-сервис помощи студентам

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

quwy · 29.07.2021, 22:39

Схемотехнику и электронику знаете хотя бы на базовом уровне?

Не по теме:

Закон Ома?
Почему светодиод нельзя подключать непосредственно к источнику напряжения?
Чему равен коэффициент передачи делителя из двух резисторов известных номиналов?
Чем реальный диод отличается от идеального?
И т.д.

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

А так, купить на алике отладочную плату простейшего микроконтроллера, например эту. Она выгодно отличается от других плат тем, что на ней уже распаян полный учебный набор: переменный делитель напряжения, два светодиода, две кнопки (плюс reset), и при этом все пины подключены к схеме через перемычки и их можно подключать/отключать/менять местами. Эту плату можно использовать и просто для программирования микросхем ATtiny 13/25/45/85 благодаря панельке.

Кроме платы, еще нужен USB-программаатор для этого семейства контроллеров, например. Программатор универсальный и подходит для прошивки любого контроллера AVR, не только этой отладочной платы, нужно только правильно соединить ножки микросхемы с выводами шлейфа программатора.

Добавлено через 5 минут
Есть еще несколько больших семейств микроконтроллеров, например, PIC или STM. PIC по своей сути мало чем отличается от AVR (одна контора), но программатор для них гораздо дороже. А начинать с STM не советую. Они хоть и более быстрые, но там вся документация по-дурацки организована, и начать работать с ними труднее. Помигайте светодиодами на ATtiny, а потом можете смотреть на другие семейства.

@locm · 29.07.2021, 22:42

Сообщение от quwy

А начинать с STM не советую.

Они одни из самых перспективных на данный момент.

quwy · 30.07.2021, 01:15

locm, ага, а теперь еще и одни из самых дорогих.

Я не советую начинать с STM, просто потому что держать перед глазами три здоровенных PDF-а для того, чтобы понять, что вообще делать -- вариант не для "чайника". Да и учебных плат вменяемых для них ни разу не видел, сплошь почти голые переходники с SMD-микросхемы на "гребенку", для любителей проволочных поделок arduino-style.

КСТАТИ! Kaiff, запомни слово "Arduino" и, если хочешь профессионально работать с контроллерами, то никогда не прикасайся ни к каким изделиям этой серии.

@sharpey · 30.07.2021, 04:26

Сообщение от quwy

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

Какой вредный совет Вы даёте, не разобравшись в сути вопроса. Чем так Вам не угодили макетные платы этой серии? Не нравится Вам программный пакет к ним - так не используйте, никто не запрещает писать на чистом Си/С++ под МК ATmega328P на платах Nano, Mini Pro, UNO R3, ATmega32U4 на Micro, Pro Micro. Удобно распаяны и выведены периферийные контакты от МК. Для прототипирования и учёбы в самый раз. И возможностей по сравнению ATtiny13 гораздо больше.

@COKPOWEHEU · 30.07.2021, 10:04

Сообщение от locm

Они одни из самых перспективных на данный момент.

Но и гораздо более сложные в освоении. Поэтому НАЧИНАТЬ с них не следует. Как не следует и задерживаться на восьмибитках.

Сообщение от sharpey

Какой вредный совет Вы даёте, не разобравшись в сути вопроса. Чем так Вам не угодили макетные платы этой серии?

А вы в вопросе разобрались? Ну так озвучьте свое экспертное мнение.
Лично я возражаю против Ардуины потому что она провоцирует характерный подход "тяп-ляп и сойдет" включая как использование кривых готовых библиотек, так и готовых модулей. Причем готовые модули само по себе далеко не всегда кривые, но тот же ардуино-подход провоцирует не делать нормальную плату, а лепить все на беспаечной макетке (в лучшем случае - спаивать проводками) и заливать термосоплями, в результате чего полученное "изделие" выглядит, да и работает, как известная субстанция.
Конечно, при должном опыте можно с этим бороться - использовать вместо Ардуинской IDE человеческую AVRStudio или хотя бы AtmelStudio, использовать готовые модули только для отладки, после чего распаивать по-нормальному. Но для этого нужно хотя бы пару раз приложиться граблями по лбу.

Сообщение от Kaiff

Появился такой вопрос "С чего же лучше начать изучение мк?"

Я бы посоветовал с AVR и ассемблера. Можно почитать курс DiHalt'а на изиэлектрониксе, можно книжку Ревича "Занимательная электроника". Там, кстати, дается и общее представление об электронике.

@Voland_ · 30.07.2021, 10:18

Сообщение от quwy

PIC по своей сути мало чем отличается от AVR (одна контора)

PIC и AVR - совершенно разные конкурирущие платформы. Может быть на сегодняшний день они могут иметь общие блоки периферии, но изначально они были абсолютно разные.

Сообщение от quwy

А начинать с STM не советую

не согласен, хотя тут

Сообщение от quwy

вся документация по-дурацки организована

соглашусь.
также соглашусь с критикой выше.

На мой взгляд, изучать МК можно от задач. И на сегодня есть уже несколько устоявшихся "уровней" имбеддед. На самом низком уровне люди тесно контачат с электроникой и супер-мелкими МК, заостряя внимание на взаимодействии кода и логики внутри МК и снаружи. На уровне по-выше люди выполняют проект на МК плюс недостающей периферии на микросхемах и модулях. Это и есть уровень или голого Си в программировании, либо всяких Ардуино. И на более высоком (в плане иерархии, а не мастерства или сложности) уровне люди собирают программы на модульном уровне. Это платформы уровня Raspberry Pi, и пр., когда конфигурирование и сборка на базе Линукса становится основой проекта.

ТС, Вам нужно самому определиться, на каком уровне вы хотите сфокусироваться. Но на начальном этапе я бы поигрался как раз на платформах "Ардуино" или каких-нибудь специализированных evaluation board' ах, с каким-нибудь набором датчиков (посоветую борды от ST, TI, NXP или Nordic). Надо также понимать, что Ардуино даст начальный толчок в познании системы "вцелом", но потом придется углубиться в изучение каждого компонента в частности. Скажем, "вертолет полетит", "машинка поедет", но точно знать, как был опрошен какой-то датчик - вы не будете. А в случае с EVO-бордами - у вас на руках будет довольно ёмкий мануал - как запустить тот или иной компонент, чтобы вы смогли поупражняться в программировании МК в целом, и взаимодействия с конкретными датчиками - в частностями. Я бы поставил на это. Скажем, борда на базе STM32F769 (купленная по случаю для одной задачи) мне очень понравилась. Для оживления знакомства - к ней бы прикупить десяток-два датчиков Ардуино с Али - и будет чем "развлекаться" на пол-года ).

@Kaiff · 30.07.2021, 10:41 **[ТС]**

А если именно с плат то лучше ATtiny?
Просто множество знакомых говорят начинать с STM или Arduino. Про Ассемблер тоже плохо отзываются ссылаясь на то что очень сложно будет его изучать.
А с физикой и электроникой со школы знания крепкие остались.

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

Сообщение от Voland_

Скажем, борда на базе STM32F769

То есть можно начать с STM?

@COKPOWEHEU · 30.07.2021, 11:35

Сообщение от Kaiff

А если именно с плат то лучше ATtiny?

Нет. У них довольно мало ног и периферии, быстро упретесь в ограничения камня. На мой взгляд наиболее удачными оказались ATmega8 и ее потомки ATmega48 - 88 - 168 - 328. Такие же, кстати, в Ардуину устанавливаются.
По сравнению с тиньками у них достаточно выводов (28 минус питание, земля, ресет и кварц получается 20), есть почти вся основная периферия - таймеры, UART, I2C, SPI, даже АЦП. Но при этом корпус не такой монструозный, как у каких-нибудь ATmega32.
А по сравнению со старшими AVR а тем более ARM - опять же приятный корпус, под который можно развести плату буквально чем угодно - ЛУТом, маркером, даже процарапать.

Если будете делать плату внучную

Стоит предусмотреть систему питания. Возможно, от USB, возможно от внешнего блока питания - тогда стоит поставить стабилизатор 5 В, а лучше два переключаемых - на 5В и на 3.3В для совместимости с разной периферией. Не забыть фильтрующие конденсаторы. Для АЦП часто рекомендуют ставить дополнительную развязку, но для отладочной платы это все же лишнее, поэтому VCC и AVCC можно просто соединить. AREF можно вывести на штырек, но можно просто оставить болтаться в воздухе.
Естественно, не забыть ISP-6 или ISP-10 разъем программирования. Рекомендую именно ISP-10, причем у него 3 нога обычно не используется - можно туда завести вывод CS контроллера чтобы подключать SPI-устройства мало-мальски стандартным разъемом.
Разъем UART для обмена отладочными сообщениями. Лично я ставлю трехконтактный разъем Rx-GND-Tx чтобы была возможность соединить любое устройство с любым просто перевернув шлейф.
2-3 светодиода. Можно через джампер или даже цифровой буфер чтобы была возможность их отключить на случай если эти выводы под что-то понадобятся.
1-2 кнопки. Лучше между выводом и землей, чем между выводом и питанием. В противном случае придется ставить резисторы.
А вот навешивать всякие крутилки и дисплеи вряд ли нужно - они все либо на один раз поиграться, либо будут мешать другой периферии. А для отладки и UART хватит.
Максимальное число ножек вывести на гребенки, но без фанатизма. Если "обычная" ножка ну вот никак не помещается, то и плюнуть. Исключение если там висит какая-то периферия вроде SPI или I2C, до которой иначе не добраться.

Сообщение от Kaiff

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

Это они просто не пробовали. Ассемблер сам по себе очень простой язык, каждая команда делает что-то одно. Но у него два основных недостатка: приходится многие элементарные конструкции реализовывать вручную и как следствие писать много команд.
Но тут надо понимать, что ассемблер это не для повседневного программирования, а для того, чтобы прочувствовать контроллер, понять как он работает на низком уровне. Ну и не бояться залезать в дизассемблерный выхлоп чтобы посмотреть где именно "компилятор начудил" и как его убедить работать правильно. Когда освоите базовые конструкции можно переходить на Си.

Сообщение от Kaiff

То есть можно начать с STM?

Теоретически можно, но сложнее будет. Особенно если начинать не с stm32f103 а с навороченного F7.

@Kaiff · 30.07.2021, 12:07 **[ТС]**

Сообщение от COKPOWEHEU

Когда освоите базовые конструкции можно переходить на Си.

А вот если уже Си изучаю тогда бросать и переходить на Ассемблер?

@Voland_ · 30.07.2021, 12:20

Сообщение от Kaiff

То есть можно начать с STM?

Та можно, я думаю ). Пусть даже и сложный поначалу STM. На сегодня ST, я бы сказал, лучше поддерживает свои продукты, чем Microchip (Atmel).
А с STM Cube вы получаете какую-никакую рабочую конфигурацию, тем более если речь идет об evaluation-борде. В этом смысле у AVR есть разве что имеет мастер проектов от CodeVision AVR, но я не уверен, что этот проект поддерживает последние версии чипов, давно его не видел. Есть еще KEIL - его библиотеки тоже (относительно) визуально позволяют настраивать периферию.

на мой взгляд, если вы хорошо себя чувствуете в (относительно) больших проектах на Си, ориентируетесь в embedded билд-системе, и знаете где что можно посмотреть - то беритесь за STM'ки. Если вы на знакомы с озученным - возьмитесь за AVR - он просто меньше по объему всего этого. Потом привыкнете и прыгнете уже, куда Вам интереснее. Потому что есть довольно большие платформы (как у нордика, например), с большим количеством уровней в иерархии библиотек. И это начинает пугать, потому что изначально не понимаешь, где и что тебе надо написать и откуда взять.

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

Сообщение от COKPOWEHEU

Но у него два основных недостатка:

я думал, Вы сейчас озвучите основные:

1) Ассемблер жутко платформозависимый. Каждый процессор, даже если он в одной платформе, может иметь свои специальные команды и особенности. Это все учитывает компилятор, но в случае с ручным написанием кода нужно постоянно это учитывать.
2) Ассемблеры разных плаформ, да и можно сказать - принцип использования конструкций в алгоритме - фундаментально отличаются. Это касается как синтакиса команд, так и их набора. То есть фактически да - зная 2-3 ассемблера разных платформ, вы можете со временем быстро писать на очередном другом асме. Но имея в голове 10-20 разных синтаксисов и особенностей это не так-то просто сделать.

Вместо этого можно 1 раз научиться писать программы на Си.

@locm · 30.07.2021, 12:22

Сообщение от quwy

теперь еще и одни из самых дорогих.

Раньше были намного дешевле. Сейчас спрос больше чем предложение. Производитель не успевает выпускать МК, отсюда и цены!

Сообщение от quwy

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

Вот тут вы не правы. Важно знать основные моменты работы с периферией, а остальное можно решать с помощью библиотек (SPL, HAL, LL и т. д.).
Для того чтобы писать для компа не изучаете от и до все его железо? С МК также.

Сообщение от Kaiff

То есть можно начать с STM?

Можно, но не с STM32F769, а с чего-то попроще типа STM32F103C8T6 или STM32F030K6T6.

Сообщение от COKPOWEHEU

Нет. У них довольно мало ног и периферии

Не вы ли пишите что чем проще тем лучше для изучения? А если нужно больше периферии, надо брать STM32.

@Voland_ · 30.07.2021, 12:33

3) Код на ассемблере имеет в десяток раз больше размер. Его очень тяжело дебажить и саппортить (что-то менять). Да, можно, конечно организовать кучу темплейтов или макросов, обложиться тулами по организации памяти и т.д., но зачем они, если все это очень эффективно и безошибочно работает в Си? Победить компилятор, имея достаточные знания в Си почти невозможно. ) однажды мне удалось втиснуть в скомпиленый кем-то код девайса хакерскую приблуду, на месте сэкономленном моей же оптимизацией кода (на AVR ассемблере), чтобы высвободить место. Но это было 2 или 4 инструкции и 3 дня работы - уже не помню.

@locm · 30.07.2021, 12:35

Сообщение от Voland_

Пусть даже и сложный поначалу STM.

Чем он сложный по началу?
Тактирование можно вообще не настраивать. Для изучения хватит тактовой 8 МГц. Нужно запомнить что перед работой с периферией нужно включать ее тактирование. Если использовать библиотеку то будет не сложно. Вот к примеру Blink для F103. https://www.cyberforum.ru/atta... 1527795937

C

#include "stm32f10x_conf.h"
 
void Delay(volatile uint32_t nCount)
{
    for (; nCount != 0; nCount--);
}
 
int main(void)
{
    GPIO_InitTypeDef Init;
 
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); // Вкл тактирование порта GPIOC
 
    Init.GPIO_Pin = GPIO_Pin_13;       // Пин 13.
    Init.GPIO_Mode = GPIO_Mode_Out_PP;
    Init.GPIO_Speed = GPIO_Speed_50MHz;
 
    GPIO_Init(GPIOC, &Init); // Конфигурация GPIOC
 
    while(1)
    {
        GPIO_SetBits(GPIOC, GPIO_Pin_13); // Мигание светодиода.
        Delay(1000000);
        GPIO_ResetBits(GPIOC, GPIO_Pin_13);
        Delay(1000000);
    }
}

@COKPOWEHEU · 30.07.2021, 12:37

Сообщение от Kaiff

А вот если уже Си изучаю тогда бросать и переходить на Ассемблер?

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

Сообщение от Voland_

А с STM Cube вы получаете...

...черную магию, которая непонятно как работает, непонятно почему не работает (а у меня настроить USB через Куб получилось единственный раз, случайно), как заставить работать и как допилить от заготовки до законченного прототипа.

Сообщение от Voland_

1) Ассемблер жутко платформозависимый. Каждый процессор, даже если он в одной платформе, может иметь свои специальные команды и особенности

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

Сообщение от Voland_

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

Эти различия чисто косметические. Ну умеет какой-нибудь PIC проводить арифметические операции с оперативкой, ну умеет какой-нибудь ARM условные инструкции, выполняемые только если выставлен флаг, ну обходится RISC-V вообще без флагов.
Умения программировать на нескольких ассемблерах обычно не требуется, а прочитать код даже на незнакомом ассемблере (тот же выхлоп дизасма) проблем не составит. Говорю по своему опыту, поскольку начинал с AVR+Assembler, потом AVR+C -> stm32+C -> RISC-V+asm -> RISC-V+C и вот недавно просматривал STM32-ассемллер - ничего страшного, вполне читаемо.

Сообщение от Voland_

Вместо этого можно 1 раз научиться писать программы на Си.

Надо не "вместо", надо "вместе".

@Voland_ · 30.07.2021, 12:41

Сообщение от locm

не с STM32F769, а с чего-то попроще типа STM32F103C8T6 или STM32F030K6T6.

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

@COKPOWEHEU · 30.07.2021, 12:49

Сообщение от locm

Вот к примеру Blink для F103.

А вот для AVR (пишу из головы)

C

#include <avr/io.h>
#include <util/delay.h>
 
int main(){
  DDRD = (1<<7);
  while(1){
    PORTD ^= (1<<7);
    _delay_ms(500);
  }
}

Assembler

.inc "m8def.inc"
.equ DELAY_CYCLES=(F_CPU/5)
 
sbi DDRD, 7
 
MAIN_LOOP:
  in r16, PORTD
  ldi r17, (1<<7)
  eor r16, r17
  out PORTD, r16
 
  ldi r16, (DELAY_CYCLES >> 16) & 0xFF
  ldi r17, (DELAY_CYCLES >> 8 ) & 0xFF
  ldi r18, (DELAY_CYCLES >> 0 ) & 0xFF
DELAY:
  subi r18, 1
  sbci r17, 0
  sbci r16, 0
    brne DELAY
 
  rjmp MAIN_LOOP

В ассемблерном коде не очень уверен, надо будет проверить. Кстати, на нем показано как происходят операции с числами, не влезающими в разрядность камня - при помощи бита переноса.

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

Сообщение от Voland_

а какая разница? ну, чуть по-больше настроек.

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

@locm · 30.07.2021, 12:52

Сообщение от COKPOWEHEU

А вы знаете именно контроллерный Си?

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

Сообщение от COKPOWEHEU

черную магию, которая непонятно как работает

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

Сообщение от COKPOWEHEU

Написать переносимую программу даже на Си между x86, AVR и ARM крайне сложно.

Не соглашусь. Посмотрите подобные проекта например FreeRTOS. Платформозависимый код в отдельных файлах.
А вот например на асме переносимую программу между x86, AVR и ARM невозможно.

Сообщение от COKPOWEHEU

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

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

Сообщение от COKPOWEHEU

Эти различия чисто косметические. Ну умеет какой-нибудь PIC проводить арифметические операции с оперативкой

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

@COKPOWEHEU · 30.07.2021, 12:54

Сообщение от COKPOWEHEU

В ассемблерном коде не очень уверен, надо будет проверить.

Проверил. Как ни странно, заработало сразу и без ошибок, разве что частота 2 Гц оказалась, надо было делитель воткнуть. А "странно" - потому что я уже давно не программировал на асме для AVR и ограничения некоторых инструкций мог забыть.

@Voland_ · 30.07.2021, 13:11

Сообщение от COKPOWEHEU

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

не согласен ни с одним предложением, сорри.

Сообщение от COKPOWEHEU

Надо не "вместо", надо "вместе".

inline'ассемблера достаточно.

Сообщение от COKPOWEHEU

Ну умеет какой-нибудь PIC проводить арифметические операции с оперативкой, ну умеет какой-нибудь ARM условные инструкции, выполняемые только если выставлен флаг, ну обходится RISC-V вообще без флагов.

ну так это и есть ФУНДАМЕНТАЛЬНЫЕ отличия. Попробуйте сравнить какой-нибудь кусок кода скомпилированный под озвученные Вами платформы и сравните. Разница будет колоссальная. Конечно, если речь не идет о "Hello world".

Сообщение от COKPOWEHEU

ничего страшного, вполне читаемо.

я ж не об этом говорил

. "ну, можно и обезьяну научить курить" <C>. В смысле вы конечно можете писать на ассемблере ARM писать программы так, как вы это делаете для AVR. Но это ж не значит, что эти программы вообще-то могли бы быть написаны в 1,5-2 раза эффективнее, и занимать меньше места, соответственно.
Но речь о другом была - мы говорили о необходимости изучать ассемблер, чтобы на нем писать программы, не читать. А это совершенно другая задача.

Не по теме:

PS: я когда писал GUI и серверные задачи под PC - ни разу не интересовался и не лазил в асме и даже API Windows, особо. Достаточно было смотреть в MSDN, и никогда не "ходил" до ассемблерного уровня. Хотя я писал на Паскале (Delphi), и мне приходилось таки уточнять соответствия типов данных и вызова функций между их Си и Паскалем. Может быть, и зря, но вообще - смысла для меня изучать дебри x86-го ассемблерного дизасма не было никакого.

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

Сообщение от COKPOWEHEU

Вот именно тем, что больше настроек. Вы, наверное, забыли, как это пугает.

я согласен с Вами, потому что сам вырос, еще с ассемблера Z80, но и не отрицаю доводы locm'а, который твердит об STM32 как хорошем "старте". Разница в том, что народ эволюционирует, и то что мы (ок, я лично) считали нормой в 90е (отсутствие библиотек и скудная документация, почти нет ни бордов в продаже, ни даже самих МК), плохой доступ к примерам и тулам - на сегодня нонсенс. Соответственно, и изучение МК тоже эволюционирует - люди приходят со стороны программистов, а не электронщиков и цифровиков, и это очень важно. На сегодня имбеддером называют и человека, собирающего ядро линукса под платформу, который вообще-то "знается" на сборке ядра, но не тому, как там должна настроиться периферия МК и запуститься клоки. Соответственно, "изучать МК" для него началось не с AVR, а с линукса, и Вы его не переубедите, что Вами предложенный путь "правильнее, чем сделал он".

@COKPOWEHEU 3881 / 2479 / 418 Регистрация: 09.09.2017 Сообщений: 10,877
	30.07.2021, 12:54	19
	Сообщение от COKPOWEHEU В ассемблерном коде не очень уверен, надо будет проверить. Проверил. Как ни странно, заработало сразу и без ошибок, разве что частота 2 Гц оказалась, надо было делитель воткнуть. А "странно" - потому что я уже давно не программировал на асме для AVR и ограничения некоторых инструкций мог забыть. 0

@Kaiff 0 / 0 / 0 Регистрация: 14.07.2021 Сообщений: 14
		1
	С чего вообще лучше начать путь в программировании микроконтроллеров 29.07.2021, 20:50. Показов 11464. Ответов 54 Метки микроконтроллер, новички (Все метки) Всем привет! Появился такой вопрос "С чего же лучше начать изучение мк?".ЯП - Си. Но именно по аппаратной части, что лучше подходит новичку, чтобы серьезно этим заниматься? Хочу изучать, чтобы связать с этим будущую профессию. Буду рад почитать все ваши ответы, заранее спасибо! 0

quwy Native x86 5512 / 3271 / 934 Регистрация: 13.02.2013 Сообщений: 10,416
	29.07.2021, 22:39	2
	Схемотехнику и электронику знаете хотя бы на базовом уровне? Не по теме: Закон Ома? Почему светодиод нельзя подключать непосредственно к источнику напряжения? Чему равен коэффициент передачи делителя из двух резисторов известных номиналов? Чем реальный диод отличается от идеального? И т.д. Без понимания электрических схем профессии у вас не выйдет, потому что программисту контроллеров всегда приходится взаимодействовать со всеми этими транзисторами, делителями, светодиодами, и прочим электронным барахлом. Иногда это здорово облегчает жизнь, если на начальных этапах разработки устройства суметь аргументированно обосновать изменения в схеме, которые программисту удобнее в реализации прошивки. А так, купить на алике отладочную плату простейшего микроконтроллера, например эту. Она выгодно отличается от других плат тем, что на ней уже распаян полный учебный набор: переменный делитель напряжения, два светодиода, две кнопки (плюс reset), и при этом все пины подключены к схеме через перемычки и их можно подключать/отключать/менять местами. Эту плату можно использовать и просто для программирования микросхем ATtiny 13/25/45/85 благодаря панельке. Кроме платы, еще нужен USB-программаатор для этого семейства контроллеров, например. Программатор универсальный и подходит для прошивки любого контроллера AVR, не только этой отладочной платы, нужно только правильно соединить ножки микросхемы с выводами шлейфа программатора. Добавлено через 5 минут Есть еще несколько больших семейств микроконтроллеров, например, PIC или STM. PIC по своей сути мало чем отличается от AVR (одна контора), но программатор для них гораздо дороже. А начинать с STM не советую. Они хоть и более быстрые, но там вся документация по-дурацки организована, и начать работать с ними труднее. Помигайте светодиодами на ATtiny, а потом можете смотреть на другие семейства. 1

@locm 4392 / 2242 / 252 Регистрация: 28.10.2011 Сообщений: 8,571 Записей в блоге: 6
	29.07.2021, 22:42	3
	Сообщение от quwy А начинать с STM не советую. Они одни из самых перспективных на данный момент. 0

quwy Native x86 5512 / 3271 / 934 Регистрация: 13.02.2013 Сообщений: 10,416
	30.07.2021, 01:15	4
	locm, ага, а теперь еще и одни из самых дорогих. Я не советую начинать с STM, просто потому что держать перед глазами три здоровенных PDF-а для того, чтобы понять, что вообще делать -- вариант не для "чайника". Да и учебных плат вменяемых для них ни разу не видел, сплошь почти голые переходники с SMD-микросхемы на "гребенку", для любителей проволочных поделок arduino-style. КСТАТИ! Kaiff, запомни слово "Arduino" и, если хочешь профессионально работать с контроллерами, то никогда не прикасайся ни к каким изделиям этой серии. 0

@sharpey 612 / 373 / 69 Регистрация: 21.09.2008 Сообщений: 1,277
	30.07.2021, 04:26	5
	Сообщение от quwy запомни слово "Arduino" и, если хочешь профессионально работать с контроллерами, то никогда не прикасайся ни к каким изделиям этой серии. Какой вредный совет Вы даёте, не разобравшись в сути вопроса. Чем так Вам не угодили макетные платы этой серии? Не нравится Вам программный пакет к ним - так не используйте, никто не запрещает писать на чистом Си/С++ под МК ATmega328P на платах Nano, Mini Pro, UNO R3, ATmega32U4 на Micro, Pro Micro. Удобно распаяны и выведены периферийные контакты от МК. Для прототипирования и учёбы в самый раз. И возможностей по сравнению ATtiny13 гораздо больше. 2

@COKPOWEHEU 3881 / 2479 / 418 Регистрация: 09.09.2017 Сообщений: 10,877
	30.07.2021, 10:04	6
	Сообщение от locm Они одни из самых перспективных на данный момент. Но и гораздо более сложные в освоении. Поэтому НАЧИНАТЬ с них не следует. Как не следует и задерживаться на восьмибитках. Сообщение от sharpey Какой вредный совет Вы даёте, не разобравшись в сути вопроса. Чем так Вам не угодили макетные платы этой серии? А вы в вопросе разобрались? Ну так озвучьте свое экспертное мнение. Лично я возражаю против Ардуины потому что она провоцирует характерный подход "тяп-ляп и сойдет" включая как использование кривых готовых библиотек, так и готовых модулей. Причем готовые модули само по себе далеко не всегда кривые, но тот же ардуино-подход провоцирует не делать нормальную плату, а лепить все на беспаечной макетке (в лучшем случае - спаивать проводками) и заливать термосоплями, в результате чего полученное "изделие" выглядит, да и работает, как известная субстанция. Конечно, при должном опыте можно с этим бороться - использовать вместо Ардуинской IDE человеческую AVRStudio или хотя бы AtmelStudio, использовать готовые модули только для отладки, после чего распаивать по-нормальному. Но для этого нужно хотя бы пару раз приложиться граблями по лбу. Сообщение от Kaiff Появился такой вопрос "С чего же лучше начать изучение мк?" Я бы посоветовал с AVR и ассемблера. Можно почитать курс DiHalt'а на изиэлектрониксе, можно книжку Ревича "Занимательная электроника". Там, кстати, дается и общее представление об электронике. 1

@Voland_ 1976 / 1275 / 130 Регистрация: 04.01.2010 Сообщений: 4,607
	30.07.2021, 10:18	7
	Сообщение от quwy PIC по своей сути мало чем отличается от AVR (одна контора) PIC и AVR - совершенно разные конкурирущие платформы. Может быть на сегодняшний день они могут иметь общие блоки периферии, но изначально они были абсолютно разные. Сообщение от quwy А начинать с STM не советую не согласен, хотя тут Сообщение от quwy вся документация по-дурацки организована соглашусь. также соглашусь с критикой выше. На мой взгляд, изучать МК можно от задач. И на сегодня есть уже несколько устоявшихся "уровней" имбеддед. На самом низком уровне люди тесно контачат с электроникой и супер-мелкими МК, заостряя внимание на взаимодействии кода и логики внутри МК и снаружи. На уровне по-выше люди выполняют проект на МК плюс недостающей периферии на микросхемах и модулях. Это и есть уровень или голого Си в программировании, либо всяких Ардуино. И на более высоком (в плане иерархии, а не мастерства или сложности) уровне люди собирают программы на модульном уровне. Это платформы уровня Raspberry Pi, и пр., когда конфигурирование и сборка на базе Линукса становится основой проекта. ТС, Вам нужно самому определиться, на каком уровне вы хотите сфокусироваться. Но на начальном этапе я бы поигрался как раз на платформах "Ардуино" или каких-нибудь специализированных evaluation board' ах, с каким-нибудь набором датчиков (посоветую борды от ST, TI, NXP или Nordic). Надо также понимать, что Ардуино даст начальный толчок в познании системы "вцелом", но потом придется углубиться в изучение каждого компонента в частности. Скажем, "вертолет полетит", "машинка поедет", но точно знать, как был опрошен какой-то датчик - вы не будете. А в случае с EVO-бордами - у вас на руках будет довольно ёмкий мануал - как запустить тот или иной компонент, чтобы вы смогли поупражняться в программировании МК в целом, и взаимодействия с конкретными датчиками - в частностями. Я бы поставил на это. Скажем, борда на базе STM32F769 (купленная по случаю для одной задачи) мне очень понравилась. Для оживления знакомства - к ней бы прикупить десяток-два датчиков Ардуино с Али - и будет чем "развлекаться" на пол-года ). 1

@Kaiff 0 / 0 / 0 Регистрация: 14.07.2021 Сообщений: 14
	30.07.2021, 10:41 [ТС]	8
	А если именно с плат то лучше ATtiny? Просто множество знакомых говорят начинать с STM или Arduino. Про Ассемблер тоже плохо отзываются ссылаясь на то что очень сложно будет его изучать. А с физикой и электроникой со школы знания крепкие остались. Добавлено через 9 минут Сообщение от Voland_ Скажем, борда на базе STM32F769 То есть можно начать с STM? 0

@COKPOWEHEU 3881 / 2479 / 418 Регистрация: 09.09.2017 Сообщений: 10,877
	30.07.2021, 11:35	9
	Сообщение от Kaiff А если именно с плат то лучше ATtiny? Нет. У них довольно мало ног и периферии, быстро упретесь в ограничения камня. На мой взгляд наиболее удачными оказались ATmega8 и ее потомки ATmega48 - 88 - 168 - 328. Такие же, кстати, в Ардуину устанавливаются. По сравнению с тиньками у них достаточно выводов (28 минус питание, земля, ресет и кварц получается 20), есть почти вся основная периферия - таймеры, UART, I2C, SPI, даже АЦП. Но при этом корпус не такой монструозный, как у каких-нибудь ATmega32. А по сравнению со старшими AVR а тем более ARM - опять же приятный корпус, под который можно развести плату буквально чем угодно - ЛУТом, маркером, даже процарапать. Если будете делать плату внучную Стоит предусмотреть систему питания. Возможно, от USB, возможно от внешнего блока питания - тогда стоит поставить стабилизатор 5 В, а лучше два переключаемых - на 5В и на 3.3В для совместимости с разной периферией. Не забыть фильтрующие конденсаторы. Для АЦП часто рекомендуют ставить дополнительную развязку, но для отладочной платы это все же лишнее, поэтому VCC и AVCC можно просто соединить. AREF можно вывести на штырек, но можно просто оставить болтаться в воздухе. Естественно, не забыть ISP-6 или ISP-10 разъем программирования. Рекомендую именно ISP-10, причем у него 3 нога обычно не используется - можно туда завести вывод CS контроллера чтобы подключать SPI-устройства мало-мальски стандартным разъемом. Разъем UART для обмена отладочными сообщениями. Лично я ставлю трехконтактный разъем Rx-GND-Tx чтобы была возможность соединить любое устройство с любым просто перевернув шлейф. 2-3 светодиода. Можно через джампер или даже цифровой буфер чтобы была возможность их отключить на случай если эти выводы под что-то понадобятся. 1-2 кнопки. Лучше между выводом и землей, чем между выводом и питанием. В противном случае придется ставить резисторы. А вот навешивать всякие крутилки и дисплеи вряд ли нужно - они все либо на один раз поиграться, либо будут мешать другой периферии. А для отладки и UART хватит. Максимальное число ножек вывести на гребенки, но без фанатизма. Если "обычная" ножка ну вот никак не помещается, то и плюнуть. Исключение если там висит какая-то периферия вроде SPI или I2C, до которой иначе не добраться. Сообщение от Kaiff Про Ассемблер тоже плохо отзываются ссылаясь на то что очень сложно будет его изучать. Это они просто не пробовали. Ассемблер сам по себе очень простой язык, каждая команда делает что-то одно. Но у него два основных недостатка: приходится многие элементарные конструкции реализовывать вручную и как следствие писать много команд. Но тут надо понимать, что ассемблер это не для повседневного программирования, а для того, чтобы прочувствовать контроллер, понять как он работает на низком уровне. Ну и не бояться залезать в дизассемблерный выхлоп чтобы посмотреть где именно "компилятор начудил" и как его убедить работать правильно. Когда освоите базовые конструкции можно переходить на Си. Сообщение от Kaiff То есть можно начать с STM? Теоретически можно, но сложнее будет. Особенно если начинать не с stm32f103 а с навороченного F7. 0

@Kaiff 0 / 0 / 0 Регистрация: 14.07.2021 Сообщений: 14
	30.07.2021, 12:07 [ТС]	10
	Сообщение от COKPOWEHEU Когда освоите базовые конструкции можно переходить на Си. А вот если уже Си изучаю тогда бросать и переходить на Ассемблер? 0

@Voland_ 1976 / 1275 / 130 Регистрация: 04.01.2010 Сообщений: 4,607
	30.07.2021, 12:20	11
	Сообщение от Kaiff То есть можно начать с STM? Та можно, я думаю ). Пусть даже и сложный поначалу STM. На сегодня ST, я бы сказал, лучше поддерживает свои продукты, чем Microchip (Atmel). А с STM Cube вы получаете какую-никакую рабочую конфигурацию, тем более если речь идет об evaluation-борде. В этом смысле у AVR есть разве что имеет мастер проектов от CodeVision AVR, но я не уверен, что этот проект поддерживает последние версии чипов, давно его не видел. Есть еще KEIL - его библиотеки тоже (относительно) визуально позволяют настраивать периферию. на мой взгляд, если вы хорошо себя чувствуете в (относительно) больших проектах на Си, ориентируетесь в embedded билд-системе, и знаете где что можно посмотреть - то беритесь за STM'ки. Если вы на знакомы с озученным - возьмитесь за AVR - он просто меньше по объему всего этого. Потом привыкнете и прыгнете уже, куда Вам интереснее. Потому что есть довольно большие платформы (как у нордика, например), с большим количеством уровней в иерархии библиотек. И это начинает пугать, потому что изначально не понимаешь, где и что тебе надо написать и откуда взять. Добавлено через 5 минут Сообщение от COKPOWEHEU Но у него два основных недостатка: я думал, Вы сейчас озвучите основные: 1) Ассемблер жутко платформозависимый. Каждый процессор, даже если он в одной платформе, может иметь свои специальные команды и особенности. Это все учитывает компилятор, но в случае с ручным написанием кода нужно постоянно это учитывать. 2) Ассемблеры разных плаформ, да и можно сказать - принцип использования конструкций в алгоритме - фундаментально отличаются. Это касается как синтакиса команд, так и их набора. То есть фактически да - зная 2-3 ассемблера разных платформ, вы можете со временем быстро писать на очередном другом асме. Но имея в голове 10-20 разных синтаксисов и особенностей это не так-то просто сделать. Вместо этого можно 1 раз научиться писать программы на Си. 0

@locm 4392 / 2242 / 252 Регистрация: 28.10.2011 Сообщений: 8,571 Записей в блоге: 6
	30.07.2021, 12:22	12
	Сообщение от quwy теперь еще и одни из самых дорогих. Раньше были намного дешевле. Сейчас спрос больше чем предложение. Производитель не успевает выпускать МК, отсюда и цены! Сообщение от quwy Я не советую начинать с STM, просто потому что держать перед глазами три здоровенных PDF-а для того, чтобы понять, что вообще делать -- вариант не для "чайника". Вот тут вы не правы. Важно знать основные моменты работы с периферией, а остальное можно решать с помощью библиотек (SPL, HAL, LL и т. д.). Для того чтобы писать для компа не изучаете от и до все его железо? С МК также. Сообщение от Kaiff То есть можно начать с STM? Можно, но не с STM32F769, а с чего-то попроще типа STM32F103C8T6 или STM32F030K6T6. Сообщение от COKPOWEHEU Нет. У них довольно мало ног и периферии Не вы ли пишите что чем проще тем лучше для изучения? А если нужно больше периферии, надо брать STM32. 0

@Voland_ 1976 / 1275 / 130 Регистрация: 04.01.2010 Сообщений: 4,607
	30.07.2021, 12:33	13
	3) Код на ассемблере имеет в десяток раз больше размер. Его очень тяжело дебажить и саппортить (что-то менять). Да, можно, конечно организовать кучу темплейтов или макросов, обложиться тулами по организации памяти и т.д., но зачем они, если все это очень эффективно и безошибочно работает в Си? Победить компилятор, имея достаточные знания в Си почти невозможно. ) однажды мне удалось втиснуть в скомпиленый кем-то код девайса хакерскую приблуду, на месте сэкономленном моей же оптимизацией кода (на AVR ассемблере), чтобы высвободить место. Но это было 2 или 4 инструкции и 3 дня работы - уже не помню. 0

@COKPOWEHEU 3881 / 2479 / 418 Регистрация: 09.09.2017 Сообщений: 10,877
	30.07.2021, 12:37	15
	Сообщение от Kaiff А вот если уже Си изучаю тогда бросать и переходить на Ассемблер? А вы знаете именно контроллерный Си? Там контроллеро-специфики больше, чем самого языка. По большому счету решать вам. Попробуйте программировать на Си - если получится, будет огромный плюс к мотивации, что тоже важно. В принципе, можно и так, а ассемблер потыкать позже. Или, например, подглядывать в дизассемблерный выхлоп, анализировать как какие конструкции разворачиваются. Сообщение от Voland_ А с STM Cube вы получаете... ...черную магию, которая непонятно как работает, непонятно почему не работает (а у меня настроить USB через Куб получилось единственный раз, случайно), как заставить работать и как допилить от заготовки до законченного прототипа. Сообщение от Voland_ 1) Ассемблер жутко платформозависимый. Каждый процессор, даже если он в одной платформе, может иметь свои специальные команды и особенности Это характерно для контроллеров в целом. Написать переносимую программу даже на Си между x86, AVR и ARM крайне сложно. Тем более когда каждый из этих камней использует разную периферию для одного и того же действия. А это тоже типично для контроллеров. Поэтому платформо-зависимость ассемблера недостатком не является. Тем более если не пытаться писать на нем операционки. Он нужен только чтобы понять как процессор вообще работает - причем любой процессор. Сообщение от Voland_ 2) Ассемблеры разных плаформ, да и можно сказать - принцип использования конструкций в алгоритме - фундаментально отличаются. Эти различия чисто косметические. Ну умеет какой-нибудь PIC проводить арифметические операции с оперативкой, ну умеет какой-нибудь ARM условные инструкции, выполняемые только если выставлен флаг, ну обходится RISC-V вообще без флагов. Умения программировать на нескольких ассемблерах обычно не требуется, а прочитать код даже на незнакомом ассемблере (тот же выхлоп дизасма) проблем не составит. Говорю по своему опыту, поскольку начинал с AVR+Assembler, потом AVR+C -> stm32+C -> RISC-V+asm -> RISC-V+C и вот недавно просматривал STM32-ассемллер - ничего страшного, вполне читаемо. Сообщение от Voland_ Вместо этого можно 1 раз научиться писать программы на Си. Надо не "вместо", надо "вместе". 0

@Voland_ 1976 / 1275 / 130 Регистрация: 04.01.2010 Сообщений: 4,607
	30.07.2021, 12:41	16
	Сообщение от locm не с STM32F769, а с чего-то попроще типа STM32F103C8T6 или STM32F030K6T6. а какая разница? ну, чуть по-больше настроек. Но принцип их одинаковый. Тут важно первым делом получить рабочий, собирающийся код. И в том и в другом случае усилия и тактика его получения будет одинаковой. Разница лишь в количестве всяких "краников", которые можно покрутить в настройках. Но и в том и другом случае для начинающего не предложат строить проект с нуля - все равно будет мастер проекта, который и в том и в другом случае соберет готовый рабочий проект. Стартовый юзер лучше сразу привыкает к количеству "краников" и привыкает улавливать главные, чем потом будет чертыхаться от перехода к более сложной платформе. 0

@locm 4392 / 2242 / 252 Регистрация: 28.10.2011 Сообщений: 8,571 Записей в блоге: 6
	30.07.2021, 12:52	18
	Сообщение от COKPOWEHEU А вы знаете именно контроллерный Си? Нет такого понятия "контроллерный Си". Языковые конструкции такие как в "компьютерном Си". Сообщение от COKPOWEHEU черную магию, которая непонятно как работает Почему? Все функции с открытым котом и можно посмотреть как они устроены. Сообщение от COKPOWEHEU Написать переносимую программу даже на Си между x86, AVR и ARM крайне сложно. Не соглашусь. Посмотрите подобные проекта например FreeRTOS. Платформозависимый код в отдельных файлах. А вот например на асме переносимую программу между x86, AVR и ARM невозможно. Сообщение от COKPOWEHEU Поэтому платформо-зависимость ассемблера недостатком не является. То есть переписать 10% Си кода сложнее чем 100% асм кода? Сообщение от COKPOWEHEU Эти различия чисто косметические. Ну умеет какой-нибудь PIC проводить арифметические операции с оперативкой Все намного сложнее. Отличия не только в совершенно других асм инструкциях, но и в процессоре. В PIC16 один регистр общего назначения, аппаратный 8-ми уровневый стек и др. В других контроллерах все может быть совершенно по другому. Перенести прогу на асме одной платформы на другую намного сложнее чем на Си. 0

@Voland_ 1976 / 1275 / 130 Регистрация: 04.01.2010 Сообщений: 4,607
	30.07.2021, 13:11	20
	Сообщение от COKPOWEHEU Написать переносимую программу даже на Си между x86, AVR и ARM крайне сложно. Тем более когда каждый из этих камней использует разную периферию для одного и того же действия. А это тоже типично для контроллеров. Поэтому платформо-зависимость ассемблера недостатком не является. Тем более если не пытаться писать на нем операционки. Он нужен только чтобы понять как процессор вообще работает - причем любой процессор. не согласен ни с одним предложением, сорри. Сообщение от COKPOWEHEU Надо не "вместо", надо "вместе". inline'ассемблера достаточно. Сообщение от COKPOWEHEU Ну умеет какой-нибудь PIC проводить арифметические операции с оперативкой, ну умеет какой-нибудь ARM условные инструкции, выполняемые только если выставлен флаг, ну обходится RISC-V вообще без флагов. ну так это и есть ФУНДАМЕНТАЛЬНЫЕ отличия. Попробуйте сравнить какой-нибудь кусок кода скомпилированный под озвученные Вами платформы и сравните. Разница будет колоссальная. Конечно, если речь не идет о "Hello world". Сообщение от COKPOWEHEU ничего страшного, вполне читаемо. я ж не об этом говорил . "ну, можно и обезьяну научить курить" <C>. В смысле вы конечно можете писать на ассемблере ARM писать программы так, как вы это делаете для AVR. Но это ж не значит, что эти программы вообще-то могли бы быть написаны в 1,5-2 раза эффективнее, и занимать меньше места, соответственно. Но речь о другом была - мы говорили о необходимости изучать ассемблер, чтобы на нем писать программы, не читать. А это совершенно другая задача. Не по теме: PS: я когда писал GUI и серверные задачи под PC - ни разу не интересовался и не лазил в асме и даже API Windows, особо. Достаточно было смотреть в MSDN, и никогда не "ходил" до ассемблерного уровня. Хотя я писал на Паскале (Delphi), и мне приходилось таки уточнять соответствия типов данных и вызова функций между их Си и Паскалем. Может быть, и зря, но вообще - смысла для меня изучать дебри x86-го ассемблерного дизасма не было никакого. Добавлено через 16 минут Сообщение от COKPOWEHEU Вот именно тем, что больше настроек. Вы, наверное, забыли, как это пугает. я согласен с Вами, потому что сам вырос, еще с ассемблера Z80, но и не отрицаю доводы locm'а, который твердит об STM32 как хорошем "старте". Разница в том, что народ эволюционирует, и то что мы (ок, я лично) считали нормой в 90е (отсутствие библиотек и скудная документация, почти нет ни бордов в продаже, ни даже самих МК), плохой доступ к примерам и тулам - на сегодня нонсенс. Соответственно, и изучение МК тоже эволюционирует - люди приходят со стороны программистов, а не электронщиков и цифровиков, и это очень важно. На сегодня имбеддером называют и человека, собирающего ядро линукса под платформу, который вообще-то "знается" на сборке ядра, но не тому, как там должна настроиться периферия МК и запуститься клоки. Соответственно, "изучать МК" для него началось не с AVR, а с линукса, и Вы его не переубедите, что Вами предложенный путь "правильнее, чем сделал он". 0