PIC или AVR ?

[dosikus]

Albert_V писал(а):

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

А я вот знаю и много работал и с пЫк,авр и 51ми и всяко их никому советовать не буду...

[Albert_V]

Так там выбор то между Pic16f628a и Attiny2313a...

[КРАМ]

Albert_V писал(а):

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

Вопрос только в тому, КОМУ это требуется понять?
Если у персонажа есть необходимая подготовка, то да - понять можно любую вменяемую документацию.
Тут же речь идет о детях.
Если детям интересны ТОЛЬКО внешние проявления - причем тут МК?
Если задача в ИЗУЧЕНИИ, то из документации на АРМ они ровным счетом ничего не поймут.

[BOB51]

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

В то же время глубокие знания вопроса по каждому конкретному устройству, аналогично развитию в среде радиолюбителей 80х-90х годов БУДЕТ УДЕЛОМ ЕДИНИЦ ПРОФЕССИОНАЛОВ...
ГРЮСТЬНО...
особо ощущать неминуемость "вымирания" аки класса динозавирей...

[vacvvm]

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

[Мурик]

Если дети поймут принцип, то перейти на более продвинутую технику смогут легко, а вот наоборот - уже нет.

Т. е. научившись кататься на мотоцикле, на велосипеде уже не смогут научится?

При том, что я ассемблером реально не владею

Он вам надо? Конечно если возьмете тиньку с 1 КБ флеша и 64 байта ОЗУ, придется писать на асме, а если возьмете стмку, асм не нужен. Можно без напряга писать на ЯВУ.
А еще вам нужно будет объяснять ребятам как выполняется программа в МК. Поддержка аппаратной отладки будет как раз кстати. Я недавно показывал гифки (они под спойлером) на подобную тему. https://radiokot.ru/forum/viewtopic.php ... 6#p3479946
https://radiokot.ru/forum/viewtopic.php ... 8#p3480528
Но при этом используется аппаратный отладчик, который подключается к МК и полностью контролирует его работу. Не все МК (особенно это касается 8-ми битных AVR и PIC) это поддерживают.

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

Сначала определитесь под что (МК) на чем (язык) и в чем (IDE) писать хотите.

[valentinovich]

Мурик
Сначала определитесь под что (МК) на чем (язык) и в чем (IDE) писать будете.

Всё правильно!
vacvvm, оба выбранных МК имеют право на "жизнь". Но начать работу по осмыслению архитектуры хотя бы одного (любого) их них придётся всё же самому. Т. к. все советы заведомо сильно субъективны.
-И на который (по вашему разумению) будет более подробный и удачный для вас даташит, тот и возьмёте на "вооружение". Т. е. выберете МК.
-Следом берёте (для себя) любую простенькую программку для данного МК и "обсасываете" каждый её оператор до полного понятия что и зачем. Или можно найти, что очень пользительно, пример (вариант) программы с комментариями для данного МК по показу на этом примере всех его возможностей. (Я бы всё же посоветовал для самого себя начать с ассемблера. Для автоматики и без сложных арифметических расчётов - прям из даташита самое простое и понятное.)
-Ну и на последок выберете для себя в чём (т. е. среда написания и компиляции) будете ваять программки. Ибо для каждого из контроллеров таких сред тоже может быть не одна, отличаясь как дизайном, конкретными удобствами и возможностями отладки. Отладка, кстати, может быть и виртуальной (подготовленная вами на компьютере) - что очень интересно и познавательно может быть для детей.
P.S. Но работы, по освоению всего перечисленного, у вас на данном поприще, учитывая вашу "подготовленность" к сему, прямо скажем - чуть более, чем до фига.

[КРАМ]

Мурик писал(а):

Если дети поймут принцип, то перейти на более продвинутую технику смогут легко, а вот наоборот - уже нет.

Т. е. научившись кататься на мотоцикле, на велосипеде уже не смогут научится?

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

[ARV]

если возьмете тиньку с 1 КБ флеша и 64 байта ОЗУ, придется писать на асме

не факт

Поддержка аппаратной отладки будет как раз кстати

не факт

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

и при этом полностью изменяет взаимодействие с периферией

[Мурик]

не факт

Факт.

и при этом полностью изменяет взаимодействие с периферией

Нет. В зависимости от ситуации можно настроить поведение периферии при отладке. Например даже если МК остановлен отладчиком, USB продолжает работать и отсылает хосту NACK тем самым поддерживая связь. Т. е. USB можно вполне нормально отлаживать. С остальной периферией так же. Это относится к STM32. В МК других производителей все может быть по другому.

[ARV]

Факт

сможете доказать?

Например даже если МК остановлен отладчиком, USB продолжает работать и отсылает хосту NACK тем самым поддерживая связь

то есть поведение ОСТАНОВЛЕННОГО микроконтроллера не соответствует истине. ШИМ тоже можно генерировать "по тактам счетчика"? практически вся периферия в любом МК при отладке ведет себя НЕ ТАК, как при обычной работе. то, что можно настроить что-то как-то, не меняет сути.

[Мурик]

сможете доказать?

Сначала вы докажите обратное.

то есть поведение ОСТАНОВЛЕННОГО микроконтроллера не соответствует истине.

Как раз соответствует. NACK сообщает компу что конечная точка не готова к приему или передаче и требуется повторить запрос позже, т. е. обмена по USB нет, но и соединение сохраняется. Пакеты данных предназначенные для МК находятся в очереди на отправку и как только конечные точки будут готовы к работе, комп их отправит в МК. Т. е. ничего не теряется и отладка не мешает работе USB.

ШИМ тоже можно генерировать "по тактам счетчика"?

Зависит от настроек. Если периферии разрешено работать когда МК остановлен отладчиком, она будет работать.

Спойлер

Код:

/**
  * @brief  Configures the specified peripheral and low power mode behavior
  *   when the MCU under Debug mode.
  * @param  DBGMCU_Periph: specifies the peripheral and low power mode.
  *   This parameter can be any combination of the following values:
  *     @arg DBGMCU_SLEEP: Keep debugger connection during SLEEP mode
  *     @arg DBGMCU_STOP: Keep debugger connection during STOP mode
  *     @arg DBGMCU_STANDBY: Keep debugger connection during STANDBY mode
  *     @arg DBGMCU_IWDG_STOP: Debug IWDG stopped when Core is halted
  *     @arg DBGMCU_WWDG_STOP: Debug WWDG stopped when Core is halted
  *     @arg DBGMCU_TIM1_STOP: TIM1 counter stopped when Core is halted
  *     @arg DBGMCU_TIM2_STOP: TIM2 counter stopped when Core is halted
  *     @arg DBGMCU_TIM3_STOP: TIM3 counter stopped when Core is halted
  *     @arg DBGMCU_TIM4_STOP: TIM4 counter stopped when Core is halted
  *     @arg DBGMCU_CAN1_STOP: Debug CAN2 stopped when Core is halted
  *     @arg DBGMCU_I2C1_SMBUS_TIMEOUT: I2C1 SMBUS timeout mode stopped when Core is halted
  *     @arg DBGMCU_I2C2_SMBUS_TIMEOUT: I2C2 SMBUS timeout mode stopped when Core is halted
  *     @arg DBGMCU_TIM5_STOP: TIM5 counter stopped when Core is halted
  *     @arg DBGMCU_TIM6_STOP: TIM6 counter stopped when Core is halted
  *     @arg DBGMCU_TIM7_STOP: TIM7 counter stopped when Core is halted
  *     @arg DBGMCU_TIM8_STOP: TIM8 counter stopped when Core is halted
  *     @arg DBGMCU_CAN2_STOP: Debug CAN2 stopped when Core is halted
  *     @arg DBGMCU_TIM15_STOP: TIM15 counter stopped when Core is halted
  *     @arg DBGMCU_TIM16_STOP: TIM16 counter stopped when Core is halted
  *     @arg DBGMCU_TIM17_STOP: TIM17 counter stopped when Core is halted
  *     @arg DBGMCU_TIM9_STOP: TIM9 counter stopped when Core is halted
  *     @arg DBGMCU_TIM10_STOP: TIM10 counter stopped when Core is halted
  *     @arg DBGMCU_TIM11_STOP: TIM11 counter stopped when Core is halted
  *     @arg DBGMCU_TIM12_STOP: TIM12 counter stopped when Core is halted
  *     @arg DBGMCU_TIM13_STOP: TIM13 counter stopped when Core is halted
  *     @arg DBGMCU_TIM14_STOP: TIM14 counter stopped when Core is halted
  * @param  NewState: new state of the specified peripheral in Debug mode.
  *   This parameter can be: ENABLE or DISABLE.
  * @retval None
  */
void DBGMCU_Config(uint32_t DBGMCU_Periph, FunctionalState NewState)
{
  /* Check the parameters */
  assert_param(IS_DBGMCU_PERIPH(DBGMCU_Periph));
  assert_param(IS_FUNCTIONAL_STATE(NewState));

  if (NewState != DISABLE)
  {
    DBGMCU->CR |= DBGMCU_Periph;
  }
  else
  {
    DBGMCU->CR &= ~DBGMCU_Periph;
  }
}

[ARV]

Сначала вы докажите обратное

личный примерпрактический опыт для вас достаточное доказательство?

Как раз соответствует.

то есть если у МК с USB отключить тактирование, именно так и будет вести себя программа? если поведение МК определяется тем, как вы настроили отклонения от нормы, это именно то, о чем я говорю.

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

и напоследок вопрос для моего общего развития: например, в AVR есть регистры, состояние которых меняется при чтении/записи других регистров. например, чтение регистра данных USART меняет флаги регистра состояния. если под отладчиком повесить в окно Watch и регистр данных и регистр состояния USART, аппаратная отладка будет очень занятным действием. как там в ваших супер-микроконтроллерах с этим?

[Мурик]

личный практический опыт для вас достаточное доказательство?

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

то есть если у МК с USB отключить тактирование, именно так и будет вести себя программа?

Зачем отключать тактирование? Или вы думаете что отладка это все равно что отключение тактирования? Судя по всему USB продолжает работать даже если МК остановлен отладчиком. Если конечная точка готова к приему или передаче, модуль USB примет/передаст хосту пакет, иначе отправит NACK.

конечно, мы говорим о состоянии приостановки программы для наблюдения за её состоянием.

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

например, в AVR есть регистры, состояние которых меняется при чтении/записи других регистров. например, чтение регистра данных USART меняет флаги регистра состояния

Примерно тоже самое. Чтение отладчиком мало чем отличается от чтения программной с точки зрения железа МК.

[ARV]

Опыт является достаточным доказательством что отладчиком нужно пользоваться

речь шла об опыте написания программ на Си для attiny13 (64 байта ОЗУ и 1К flash).

Или вы думаете что отладка

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

Короче, все зависит от ситуации

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

Примерно тоже самое.

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

Добавлено after 3 minutes 14 seconds:

отладчиком нужно пользоваться

не факт "можно" не эквивалентно "нужно"

[КРАМ]

Мурик писал(а):

NACK сообщает компу что конечная точка не готова к приему или передаче и требуется повторить запрос позже

Вообще то ПО определяет повторяемость запросов. Ответ совершенно не обязателен. Остановленный стек (а это ПРОГРАММА в МК, которая остановлена) может ничего не посылать хосту. От этого ничего не зависит.

[Мурик]

речь шла об опыте написания программ на Си для attiny13 (64 байта ОЗУ и 1К flash).

Такую мелочь не использую. Если говорить об AVR, то минимум Mega8, а еще лучше Mega328.
Мне на практике такие ситуации не нужны. http://we.easyelectronics.ru/Asticon/is ... bayta.html
Мы же не в царские времена живем когда, большинство населения голодало. Стоимость МК с нормальной начинкой такова что можно купить несколько десятков и это будет вообще незаметно для бюджета. Например STM32F030K6T6 стоит 0.5$ при партии 5 штук. https://ru.aliexpress.com/item/YUXINYUA ... 76218.html

с точки зрения программы под отладчиком в точке останова МК остановлен полностью.

Вы наверное имеете в виду процессорное ядро? Потому что периферия может продолжать работать дальше.

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

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

Вообще то ПО определяет повторяемость запросов.

За это отвечает USB драйвер. Он должен доставить посылку и если устройство сообщило что не готово принять, он произведет попытку позже.

[КРАМ]

Мурик писал(а):

За это отвечает USB драйвер. Он должен

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

[ARV]

Стоимость МК с нормальной...

да слышали, в курсе! сколько можно рекламировать?!

Вы наверное имеете в виду процессорное ядро?

по-моему, я вполне конкретно оисал, что я имею ввиду. отладчик позволяет отладить ПРОГРАММУ, а в момент остановки ПРОГРАММА стоит, что с её точки зрения полностью эквивалентно отсутствию любой деятельности и "замороженному" состоянию всех регистров. если в это время что-то где-то продолжает работать, то это в данном контектсе нонсенс и не помогает, а осложняет ОТЛАДКУ ПРОГРАММЫ.

Она поможет своими глазами увидеть

все это ЕЩЕ ЛУЧШЕ поможет увидеть симулятор.

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

[Мурик]

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

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

в момент остановки ПРОГРАММА стоит, что с её точки зрения полностью эквивалентно отсутствию любой деятельности

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

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

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

все это ЕЩЕ ЛУЧШЕ поможет увидеть симулятор.

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