Comments 84
Я тоже начинал примерно по такому сценарию, только в 2001 году. Приехали с другом на Митинский рынок и я с горящими глазами в первой же палатке попросил продать мне PIC16F84. Программатор собрал сам для последовательного порта, тогда это было еще актуально. В качестве языка выбрал творение сумрачного гения под названием JAL (http://justanotherlanguage.org), это было самое дружелюбное, что я нашел (по сравнению с ассемблером). Написал программу для мигания светодиодом, порадовался, не придумал чтобы сделать на нем еще, поэтому сложил все артефакты в коробочку и забыл об этом на много лет.
Почему выбрали именно PIC? Почему не AVR, который для новичка будет в освоении попроще + по ним у DIHALT целый курс статей расписан. PIC'и, конечно, дешевле, но эта дешевизна будет ощущаться при партии устройств этак в тысяч десять штук и полбакса в цене для новичка абсолютно никакой роли не играет.
Я-то учился работать с МК в начале 2000-ых, но то было в рамках высшего образования и у меня свободного выбора не было — моим первым МК стал Motorola 68HC11 =)
Я-то учился работать с МК в начале 2000-ых, но то было в рамках высшего образования и у меня свободного выбора не было — моим первым МК стал Motorola 68HC11 =)
Наверное потому, что на тот момент у пика был полностью переведённый на русский даташит и вообще с документацией получше немного было.
Ага, а еще пики бывало проще достать, чем авр-ки. Если не в Москве, выбирать не приходилось. Начал где-то в середине нулевых. Наслушался про AVR, прихожу в магаз говорю ATmega есть — неа, ATtiny есть — неа, а что есть — а вот PIC16F628. ну я такой — давайте чо уж) С тех пор почти нет опыта с AVR. С пиков перешел на АРМы
При партиях в десятки штук и цене готового модуля $20 разница уже ощущается.
Был примерно 1997 год. Шла мода на халяву, если кто еще понит что это такое. Microchip прислал толстенную книгу по их контролерам с примерами схем и диск с какой-то древней версией MPLAB. Вот по примерам с этой книги изучались програмки и ассемблер PIC, набирались в MPLAB и там же смотрелось как оно работало. Реальных контролеров не было, только отладчик. Все это добро было на английском и читалось с бумажным словарем в руках.
А сейчас у них гуглы, яндексы, всякие форумы и т.д. и все равно сложности какие-то возникают. Эхххх, молодеж :-)
А сейчас у них гуглы, яндексы, всякие форумы и т.д. и все равно сложности какие-то возникают. Эхххх, молодеж :-)
Молодежь… отладчик у них был… программки… диски с мплабом микрочип прислал…
Как насчет дизассемблировать прогу архитектуры MCS48 — 2к содержимое 537РФ2 ручкой в тетрадке в 1988 году? — потому, что других примеров, чтоб учиться — нет. Ну разве, что было немножко в «микропроцессорных средствах и системах». А за ними между прочим надо в центральную районную библиотеку переться на метро и двух троллейбусах — потому что в местной они не предусмотрены. С тетрадкой… Бо ксерокс туда не завезли… а сканер — вообще никто не знал что так можно…
Как насчет дизассемблировать прогу архитектуры MCS48 — 2к содержимое 537РФ2 ручкой в тетрадке в 1988 году? — потому, что других примеров, чтоб учиться — нет. Ну разве, что было немножко в «микропроцессорных средствах и системах». А за ними между прочим надо в центральную районную библиотеку переться на метро и двух троллейбусах — потому что в местной они не предусмотрены. С тетрадкой… Бо ксерокс туда не завезли… а сканер — вообще никто не знал что так можно…
Классно вам, у вас метро было… :-)
Книга «Микропроцессорные средства и системы», насколько я помню спустя 30 лет, не содержала (почти) сведений по программированию, фокусируясь на аппаратных решениях. У меня она была, случайно купил в обычном книжном. Там вроде было описание синтеза системы микрокоманд процессора на 556РТ5 (которое и сейчас изучают в Бауманке на ИУ5 в качестве курсовой на 4 курсе), но не более того. Но в 1988 году в дефолт-сити уже вовсю функционировал Митинский радиорынок, где продавались распечатки инструкций по программированию на ассемблере, Паскале и т.п. Не уверен насчет MSC-48, конечно — не спрашивал :) К тому же там можно было заказать за относительно небольшую денежку многое из доступного в мире на тот момент, уж ксерокс-то из русскоязычной литературы можно было заказать любой, да и оригинальных книг хватало, хотя, конечно, не по магазинным ценам. Я жил в 200км от Москвы тогда, в Калуге, так что мне приходилось вставать в 5 утра в выходные, чтобы попасть на Митинку до того, как основная масса народа разойдется.
Да, тогда не было сканера-ксерокса в библиотеках, но фотоаппарат никто не запрещал с собой приносить. Если выбрать солнечный день и место у окна, чтобы не вызывать ругань библиотекаря работающей вспышкой — вполне себе приемлемо получалось. Переходные кольца и т.п.
Да, тогда не было сканера-ксерокса в библиотеках, но фотоаппарат никто не запрещал с собой приносить. Если выбрать солнечный день и место у окна, чтобы не вызывать ругань библиотекаря работающей вспышкой — вполне себе приемлемо получалось. Переходные кольца и т.п.
Речь про журнал выходивший раз в 2 месяца. там были и примеры кода. и дампы тоже были.
а митино вообще было «3 дома» и пустырь вокруг с проектом застройки. Жизнь была у магазина пионер.
Но в 1988 году в дефолт-сити уже вовсю функционировал Митинский радиорынок,Даже Тушинский не функционировал!
а митино вообще было «3 дома» и пустырь вокруг с проектом застройки. Жизнь была у магазина пионер.
А разве МПСС — не журнал?
Тогда можно было сконцентрироваться на одной задаче, да и аппаратных средств не было что бы распыляться.
Мое дилетантское мнение: маломощным контроллерам нужен ассемблер. При этом для них есть кучи библиотек, к которым постепенно добавятся самодельные, которые ускоряют написание программ. Ассемблер и прост, и сложен одновременно, разбираться с ним в домашних условиях вместо купить для разовой поделки контроллер на доллар-два дороже и порядково производительнее, для которого можно набросать что-то на высокоуровневом языке, не каждый станет. Но как хобби, как мне кажется, ассемблер прекрасен.
Та не. Даже я, любитель ассемблера, не стал бы писать бизнес-логику на нем. Небольшие вставки или математическую библиотеку — да, а так нет.
Контроллеру с 64+ килобайтами памяти программ ассемблер уже не нужен. Только если для каких-то вставок в критически важные места, которые по-другому никак не оптимизировать.
Мы под xmega даже C++11 применяем, в доступном объёме оф коз.
Ну а для всяких мелких контроллеров с 256 байт флеша вариантов и нет. Но это уже совсем своя особая область разработки.
Мы под xmega даже C++11 применяем, в доступном объёме оф коз.
Ну а для всяких мелких контроллеров с 256 байт флеша вариантов и нет. Но это уже совсем своя особая область разработки.
Нет никакого смысла сегодня использовать «маломощные» МК.
Они дороже (из-за низкого спроса) и больше потребляют (из-за старого техпроцесса).
Они дороже (из-за низкого спроса) и больше потребляют (из-за старого техпроцесса).
Грабли, на которые чаще всего наступают при освоении микроконтроллеров, в статье перечислены почти все. Самые большие грабли — это выбор устаревшего микроконтроллера, такого как PIC16 или ATmega. Со времён, когда ресурсы микроконтроллера ограничивались несколькими килобайтами оперативной памяти и несколькими десятками килобайт памяти программ, много воды утекло. Сейчас диапазон очень широк — микроконтроллер может иметь от нескольких килобайт до нескольких сотен килобайт встроенной оперативной памяти, до нескольких мегабайт встроенной памяти программ и работать на частотах до 400МГц. Подключив к микроконтроллеру по QuadSPI 8-ногую микросхему Flash-памяти можно увеличить размер памяти программ до гигабайт, другое дело — сложно написать настолько объёмную прошивку, поэтому это применяется редко. Оперативную память микроконтроллеров, напротив, часто наращивают внешними микросхемами динамической памяти до десятков мегабайт, чтобы получить графический буфер для подключения графического ЖК-экрана, но для новичков может оказаться сложной трассировка печатной платы с высокочастотным параллельным интерфейсом такой памяти, поэтому лучше поначалу ограничиться встроенной памятью микроконтроллера. Программатор не обязателен для загрузки в микроконтроллер программы — многие микроконтроллеры имеют вшитый при производстве загрузчик, который позволяет загружать прошивку через USB или COM-порт с преобразователем уровней. Но если программа не совсем элементарная — очень рекомендую купить программатор с функцией отладки. Он позволит остановить программу в любом месте, и пройти по ней пошагово, строку за строкой, наблюдая изменение данных — это очень помогает найти ошибки. Для освоения лучше выбрать современную серию 32-битных микроконтроллеров на ядре ARM — они есть у всех ведущих производителей мекроконтроллеров. Я рекомендую STM32 — эта серия отличается очень большим числом моделей микроконтроллеров под любые задачи, и дешевизной клонов программаторов-отладчиков ST-LINK, которые подходят для всех STM32. Если вникать не хочется, а хочется собрать что-то из готовых модулей — можно выбрать Arduino. Язык программирования для начала — только C и С++ — на них пишет большинство профессионалов, и написано большинство примеров и модулей.
После того как поморгал светодиодами, становится понятно, что необходимо учить/вспоминать радиоэлектронику, я на этом моменте собственно и забросил… много лет назад ) может посоветуете книги, сайты?
На тот год в тренде как раз были восьмибитки. Армы слишком сложны были для сборки в домашних условиях и вообще там много чего надо было знать. Тогда даже кортексов вроде бы не было. Кругом арм7тдми царил.
А как по мне так начинать лучше всего вообще с ат89с51. Периферии только порты да уарт. Заблудиться негде, ресурсов мизер и быстро учишься их экономить и писать эффективный и ловкий код. Натыкать в кубе монстр прошивку то может и проще, да только понимания не прибавит ни на грамм. Как была магией так и останется.
Дополню: лучше ат89S51/52. Программируется USBASP-ом.
В 2009 году уже выпускались STM32F1, хотя выбор в их пользу был тогда не очевиден, и в тренде продолжали оставаться AVR, а ARM7TDM были дороговаты для начинающего. Но PIC16 и AT89C51/52 уже были сильно устаревшим, а сейчас устарели и AVR. Если начинать с устаревших контроллеров — придётся много внимания уделять ограничениям, неактуальным для современных микроконтроллеров — переключать в прерываниях банки регистров и экономить каждый байт ОЗУ для AT89C51, где его всего 128 байт, избегать выделять код в функции в PIC16, где стек возвратов аппаратный, и можно наткнуться на ограничение вложенности вызовов, распределять данные между быстрой и медленной внутренней памятью в реализациях архитектуры 8051 с более чем 128 байтами памяти, привязывать код работы с периферией к конкретному экземпляру однотипной периферии в AVR. А если ещё и использовать ассемблер — к этому добавляется страничная адресация памяти PIC16, и ограничения по адрессации данных, вынуждающие писать неестественный код. Всё это вырабатывает трудночитаемый «ассемблерный» стиль написания кода, затрудяет повторное использование кода, и препятствует использованию C++. Вместо этого стоит сосредоточиться на алгоритмах и архитектуре программы, а низкоуровневую оптимизацию, требующую хорошего знания контроллера, применять точечно, по необходимости. То, что периферия STM32 намного богаче чем у AVR не заставляет изучать и начинать её использовать сразу всю. UART STM32F0..F4 не намного сложнее UART AVR, System timer и Basic timer — тоже не сложнее таймеров AVR.
работать на частотах до 400МГц
У вас устаревшая информация: i.MX-RT1170 — 1 GHz Cortex M7+ 400 MHz Cortex M4
Можно считать и так. Но, на мой взгляд, i.MX-RT1170 — это не микроконтроллер, а SoC для задач реального времени, потому что он не имеет встроенной энергонезависимой памяти программ. В этом смысле он не сильно отличается от TMS320 C67xx или BCM2835. Хотя и раньше выпускались микроконтроллеры без встроенной памяти программ, например intel 8031, на сегодняшний день стандартно для микроконтроллера — иметь такую память. Но я действительно запамятовал, у NXP в серии i.MX-RT есть и микросхемы со встроенной flash-памятью — i.MX-RT1164 с частотой 600МГц.
А может наоборот, грабли это сразу взяться за какой-нибудь жирный STM32 и увязнуть там в изучении периферии, которую мало кто полностью изучил. А для начала PIC16F84 вполне сойдёт, разобраться со всем, что в нем есть можно за пару вечеров. И поработав с отдельными регистрами на ассемблере поймешь, что такое микроконтроллер и как он работает. А если начать с другого конца, то микроконтроллер так и останется чёрным ящиком, общение с которым происходит через кем-то написанные драйвера и библиотеки. Вот ардуинщики они как раз не с того конца начали. Да, они могут программировать микроконтроллер, но очень мало кто из них понимает как там всё внутри устроено.
Разобраться в ассемблере и понять как работает микроконтроллер, конечно, полезно. Но для этого плохо подходят RISC микроконтроллеры вообще, и PIC16 особенно, уж очень он не по-человечески сделан. Гораздо больше подойдёт какой-нибудь микроконтроллер с CISC ядром, особенно простые микроконтроллеры с ядром 8051 или 8052 — например, AT89C52. Потому что CISC-системы команд разрабатывались с ориентацией на удобство программирования на ассемблере, а RISC — с ориентацией на минимизацию количества транзисторов на ядро, и времени выполнения одной команды. Но чтобы понять как работает микроконтроллер не обязательно писать на ассемблере — достаточно хотя бы поверхносно изучить систему команд, и читать фрагменты дизасемблированного кода в отладчике для интересующих моментов. А с регистрами периферии можно работать и на C и на C++. Кем-то написанные драйвера и библиотеки помогают избежать затыков в случаях, когда что-то описано в документации не очень понятно, или есть жесткая последовательность действий, непонятно чем определяемая — вот здесь действительно можно увязнуть.
Ну что PIC — это якобы RISC, прожужжано конечно во всех даташитах. Но на самом деле какой же это риск, если он может сложить регистр с памятью и положить результат в память же?
На самом деле его команды, в т.ч. 12-14 битная их ширина очень похожи на команды каких-нибудь ранних ЭВМ, типа PDP-8 или ей подобных. И это ни разу не RISC.
Конечно если понимать RISC не буквально (типа, мало команд, в PDP-8 8 команд всего!), а как то, что все команды простые.
Туда же и MSP430, который махровейший CISC с командами от 1 до 3 слов, может прибавить 1 командой память к памяти, как и PDP-11, глядя на который он и делался.
Как наращивают оперативную память микроконтроллеров?
В основном подключением микросхем SRAM и SDRAM к аппаратной параллельной шине, для STM32 это FSMC или FMC в корпусах с более чем 100 ногами (в меньших корпусах они тоже есть, но могут не подходить для этого, потому что выведены не все необходимые линии). Но бывают и экзотические варианты — микросхемы SRAM с последовательным интерфейсом, и программная реализация параллельного интерфейса.
23LC1024 может помочь. :)
Тут надо заметить, что не во всех МК это возможно. То есть, подключить внешнюю RAM можно, а вот включить её в общее адресное пространство возможно далеко не во всех МК, тем более запустить программный код, находящийся во внешней памяти.
Знатоки, подскажите, существует ли аналог книги уровня Хоровица Хилла — Искусство схемотехники, но по микроконтроллерам? Ну или просто посоветуйте хорошую книгу по ним.
Не по МК, но рядом полезно будет почитать Харис и Харис, название уже не помню.
Digital Design and Computer Architecture by David Money Harris and Sarah L Harris
Цифровая схемотехника и архитектура компьютера
http://easyelectronics.ru/files/Book/digital-design-and-computer-architecture-russian-translation.pdf
Начинал в далеком 2007 году что-ли с AVR, случайно наткнувшись на базаре на книгу А.Белова «Микроконтроллеры в радиолюбительской практике». Не лучшая книга, но на тот момент наверно других и не было доступно и не лучшая модель в линейке (tiny2313) для начала.
Но, книга помогла в 3 моих затыках:
1. Оказывается в шараге где я учился все зависло в году 85, и для помигать светодиодиком не нужен 8080 с россыпью чипов.
2. Програмировать надо не 16х кодах не понятно где, а вполне себе в современных IDE.
3. Программатор собирается на одной микросхеме стандартной логики.
Самое интересное, что хоть в книге все примеры были на asm/c мне почемуто сначала зашел asm что здорово помогло в потом в понимании кода, даже на совсем других архитектурах.
Но, книга помогла в 3 моих затыках:
1. Оказывается в шараге где я учился все зависло в году 85, и для помигать светодиодиком не нужен 8080 с россыпью чипов.
2. Програмировать надо не 16х кодах не понятно где, а вполне себе в современных IDE.
3. Программатор собирается на одной микросхеме стандартной логики.
Самое интересное, что хоть в книге все примеры были на asm/c мне почемуто сначала зашел asm что здорово помогло в потом в понимании кода, даже на совсем других архитектурах.
Знакомый учился в Харьковском политехническом универе на программиста. Его дипломная работа была запрограммировать pic контроллер, что бы он помигал светодиодом)) Я на ESP32 за один вечер сделал это, когда разбирался с arduino.
Этого не может быть! Мой знакомый тоже недавно закончил Харьковский политехнический университет, и его дипломной работой была приставка-кардиограф для смартфона, с приложением для Android. По своей материальной базе этот университет, конечно, сильно отстал от жизни, но даже в 80-е, когда я там учился, на первом курсе был курсовой-фрагмент синтаксического анализатора компилятора, на втором курсе — ПИД-регулятор на ассемблере 8086, на третьем курсе — программа управления системой резервирования мэйнфрейма. И это даже по специальности «Разработка ЭВМ», а не программирование.
в 2002 я работал на стройке (иногда с лопатой и ломом), однажды увидел в журнале Circuits Cellar рекламу Cypress PSOC купил набор и стал самостоятельно изучать практически с нуля. На чипе CY8C26233 сделал первый комерчекий проект — стерео передатчик FM 5w, стерео кодер и PLL в одном чипе, тогда не было однокристальных передатчиков и мой руками собранный хорошо продавался на eBay $220/шт и понеслось ;), до сих пор не понимаю почему PSOC остаются экзотикой, 15летний чип с 16k ROM/256b RAM позволяет проекты неосуществимые на STM32F103.
Ассемблер знать обязательно нужно, это очень простой язык, а начинать нужно именно с простого. Почему это восьми битный контроллер устаревший? Ну и естественно куда в него Си++? Автору спасибо за статью.
Форт (Forth) тоже даёт неплохие условия для знакомства с контроллерами (при реализации Форт-систем знание ассемблера только приветствуется)
По PIC16 есть и некоторая учебная методичка F2P (Forth to PIC compiler) Г.Р.Алпатов Применение PIC-контроллеров. (Южный Федеральный университет)
P.S. Здесь немного больше по Форт и PIC
Pic Forth
PIC Projects
FlashForth
…
А так, да Форт (Forth) есть в разных вариантах на любой контроллер.
По PIC16 есть и некоторая учебная методичка F2P (Forth to PIC compiler) Г.Р.Алпатов Применение PIC-контроллеров. (Южный Федеральный университет)
P.S. Здесь немного больше по Форт и PIC
Pic Forth
PIC Projects
FlashForth
…
А так, да Форт (Forth) есть в разных вариантах на любой контроллер.
Поддерживаю полностью. Только лучше начать с ассемблера простого 8-битника типа AVR, например. ARM для старта сложнее будет. Научитесь писать на ассемблере, освоить более высокоуровневые языки (как
С, например) уже будет не проблема. А потом уже можно и другие архитектуры осваивать.
Сегодня полезнее всего будет начать с ESP32, которую программировать из VS + VisualGDB.
Никакой мороки со средой/программаторами/драйверами, сразу мощный двухядерный МК на 240 МГц с вайфаем, блютусом и мегатоннами примеров и готового кода плюс возможность для новичка сразу получить какой-то полезный готовый результат.
Как бонус: отладочные платы стоят дешево.
В восьмибитное погружаться смысла нет никакого вообще.
В будущем, с переходом на батарейное питание можно перейти на stm32l или msp430. Все остальное вымерло либо очень узкоспециализированное.
Никакой мороки со средой/программаторами/драйверами, сразу мощный двухядерный МК на 240 МГц с вайфаем, блютусом и мегатоннами примеров и готового кода плюс возможность для новичка сразу получить какой-то полезный готовый результат.
Как бонус: отладочные платы стоят дешево.
В восьмибитное погружаться смысла нет никакого вообще.
В будущем, с переходом на батарейное питание можно перейти на stm32l или msp430. Все остальное вымерло либо очень узкоспециализированное.
так вы все равно потом со своих 8 биток пересядете на 32битки. Во и зачем тогда начинать с 8 биток — только время терять.
Есть например устройства 10 лет работающие на одной литиевой таблетке батарейке.
с процессорами у которых в слип ток потребления меньше чем саморазряд этой батарейки.
И никаких 32х биток в них не будет никогда (как и кода не на ассемблере).
с процессорами у которых в слип ток потребления меньше чем саморазряд этой батарейки.
И никаких 32х биток в них не будет никогда (как и кода не на ассемблере).
Серийно выпускаем устройства на STM32L0, работают от одной литиевой батарейки 10+ лет.
Пишу на С, потихоньку перехожу на С++.
В стопе все МК любой архитектуры примерно потребляют одинаково на обновление памяти и работу таймеров. Какая разница на чем написан код, если ядро вообще выключено по питанию?
STM32 в low-power run примерно в два раза энергоэффективнее STM8, при этом потенциально быстрее.
Из всех выделяется только msp430 с FRAM, там можно сэкономить последние 2-3 мкА, но так же можно любой другой МК просто полностью отключать, сохраняясь во флеш.
Пишу на С, потихоньку перехожу на С++.
В стопе все МК любой архитектуры примерно потребляют одинаково на обновление памяти и работу таймеров. Какая разница на чем написан код, если ядро вообще выключено по питанию?
STM32 в low-power run примерно в два раза энергоэффективнее STM8, при этом потенциально быстрее.
Из всех выделяется только msp430 с FRAM, там можно сэкономить последние 2-3 мкА, но так же можно любой другой МК просто полностью отключать, сохраняясь во флеш.
В стопе одинаково — а при работе любой лишний исполняющйся код = лишнее потребление! И в одном техпроцессе, чем меньше бит тем меньше жрет.
К тому же ваш STM32 10 лет не существует — а 8-ми биткам с наноамперным потреблением 20 лет (т.е. все уже было когда никаких вас не было — все задачи решены!)
К тому же ваш STM32 10 лет не существует — а 8-ми биткам с наноамперным потреблением 20 лет (т.е. все уже было когда никаких вас не было — все задачи решены!)
Что вы подразумеваете под «наноамперным потреблением»?
Покажите страницу из даташита или название МК, который при исполнении кода потребляет наноамперы?
Покажите страницу из даташита или название МК, который при исполнении кода потребляет наноамперы?
PIC12-16 — все токи по каждому модулю даны. в определенных конфигах можно получить наноамперы.
Это отлично, но вопрос был о другом:
Покажите страницу из даташита или название МК, который при исполнении кода потребляет наноамперы?
Гугол «microchip nanowatt mcu» — их там как грязи за баней. у меня под рукой нет даташитов.
Гуглом я пользоваться умею, но вы утверждаете что знаете что существует то, чего на самом деле не существует.
Я просто убеждался, что вы лукавите.
Я просто убеждался, что вы лукавите.
Мне просто лень сейчас прикидывать конкретный конфиг для наноамперного потребления и конкретный чип который это даст перелопачивая кучу данных — мне достаточно. что сам микрочип заявляет, что так можно, на этой архитектуре…
Да. В теории вы думаете что такое возможно, но реального опыта у вас нет.
Реальный опыт — я вам уже сказал, что 20 лет назад производились изделия с потреблением ниже саморазряда батареек на линейках для этого не предназначенных. Хотя никаких нановаттных технологий тогда и в помине не было, но они уже жрали микроамперы…
Ваши сообщения здесь читают другие люди, в том числе новички.
Вы утверждаете что восьмибитные контроллеры потребляют меньше, чем 32-битные, из-за чего новички будут мучаться с восьмибитным мусором и тратить свое время зря. Причем вы еще никак не может доказать то что говорите, теоретизируя, отправляя в гугл и несуществующие даташиты.
На конец 2019 STM32L0 потребляют меньше всего, они доступнее и дешевле всего остального и имеют нормальную периферию.
Вы утверждаете что восьмибитные контроллеры потребляют меньше, чем 32-битные, из-за чего новички будут мучаться с восьмибитным мусором и тратить свое время зря. Причем вы еще никак не может доказать то что говорите, теоретизируя, отправляя в гугл и несуществующие даташиты.
На конец 2019 STM32L0 потребляют меньше всего, они доступнее и дешевле всего остального и имеют нормальную периферию.
У вас неправильное понимание слова «мусор» в контексте обсуждения…
1) да любой 8-ми битный CPU by design жрет меньше 32х битного — ибо содержит меньше транзисторов и требует меньше энергии на их переключение в процессе выполнения кода.
1a) Так же любой код на ассемблере, жрет меньше по тем же самым причинам: не имеет «лишнего» исполняющегося мусора — лишних переключений состояний.
1б) Ровно по этим же причинам в бекграунде идентичные ноутбуки работают дольше от батареи, если их ОС выполняет меньше мусорных инструкций и если в ней запущено меньше мусорного софта.
Все это надо учитывать, когда нужна энергоэффективная система. Новичкам не надо — но вот если специалист этого не знает, это какой то так себе специалист.
2) Оригинальная микропроцессорная архитектура разработанная самим производителем с учетом требования рынка (microchip), всегда имеет качество лучше, чем дженерик архитектура на ip модулях купленных как правило хрен знает у кого и насыпанные в кристалл по быстрому (ST). Дичайшие баги с АЦП в ST-шных поделках тому пример… А уж конфликты модулей друг с другом по ногам вообще смех — думать было некогда, надо было за кем то гнаться (за кем?)… Так что в вашем случае — это именно ST мусор. И этот мусор: сюрприз — стоит как мусор! кто бы мог подумать… А не как настоящие ARM процессоры которые например делает та же фуджитсу, и у которых степень доводки тех же самых по сути IP модулей — вообще космос по сравнению с глюкавыми ST. И это не ST-шный индустриальный only шлак — а чипы в автомотив-милитри-спейс грейд. Цена у них тоже конечно выше на порядок. Ибо так и должно быть! При том, что еще ST умеет секретить баги, пока эти баги до тех пор ну просто уже из горла не лезут у каждого 2-го разработчика…
3) особенно весело в контексте новичка например обсуждать минимальное число деталей, необходимых для запуска этих ваших 32-хбиток… когда те же PIC12-16 могут работать имея только батарейку подключенную к чипу 2-мя проводами — И ВСЕ! Можно по обсуждать корпуса, ведь те кто учатся еще не уверенно паяльник держит. Этот ваш STM32L0 — В ДИПЕ ГДЕ!? нету конечно… вы сразу паять в TSSOP20 будете учиться? ну ну — я бы посмотрел на этот цирк…
Так вот новичку лучше начинать работать с тем, что проще надежнее и предсказуемее, с меньшим числом деталей и в понятном корпусе с большим шагом и на что даташит на русском — а не этим вашим «а зато оно дешево». Чтоб не ходить по чужим граблям когда своих будет поле не пройденное.
1) да любой 8-ми битный CPU by design жрет меньше 32х битного — ибо содержит меньше транзисторов и требует меньше энергии на их переключение в процессе выполнения кода.
1a) Так же любой код на ассемблере, жрет меньше по тем же самым причинам: не имеет «лишнего» исполняющегося мусора — лишних переключений состояний.
1б) Ровно по этим же причинам в бекграунде идентичные ноутбуки работают дольше от батареи, если их ОС выполняет меньше мусорных инструкций и если в ней запущено меньше мусорного софта.
Все это надо учитывать, когда нужна энергоэффективная система. Новичкам не надо — но вот если специалист этого не знает, это какой то так себе специалист.
2) Оригинальная микропроцессорная архитектура разработанная самим производителем с учетом требования рынка (microchip), всегда имеет качество лучше, чем дженерик архитектура на ip модулях купленных как правило хрен знает у кого и насыпанные в кристалл по быстрому (ST). Дичайшие баги с АЦП в ST-шных поделках тому пример… А уж конфликты модулей друг с другом по ногам вообще смех — думать было некогда, надо было за кем то гнаться (за кем?)… Так что в вашем случае — это именно ST мусор. И этот мусор: сюрприз — стоит как мусор! кто бы мог подумать… А не как настоящие ARM процессоры которые например делает та же фуджитсу, и у которых степень доводки тех же самых по сути IP модулей — вообще космос по сравнению с глюкавыми ST. И это не ST-шный индустриальный only шлак — а чипы в автомотив-милитри-спейс грейд. Цена у них тоже конечно выше на порядок. Ибо так и должно быть! При том, что еще ST умеет секретить баги, пока эти баги до тех пор ну просто уже из горла не лезут у каждого 2-го разработчика…
3) особенно весело в контексте новичка например обсуждать минимальное число деталей, необходимых для запуска этих ваших 32-хбиток… когда те же PIC12-16 могут работать имея только батарейку подключенную к чипу 2-мя проводами — И ВСЕ! Можно по обсуждать корпуса, ведь те кто учатся еще не уверенно паяльник держит. Этот ваш STM32L0 — В ДИПЕ ГДЕ!? нету конечно… вы сразу паять в TSSOP20 будете учиться? ну ну — я бы посмотрел на этот цирк…
Так вот новичку лучше начинать работать с тем, что проще надежнее и предсказуемее, с меньшим числом деталей и в понятном корпусе с большим шагом и на что даташит на русском — а не этим вашим «а зато оно дешево». Чтоб не ходить по чужим граблям когда своих будет поле не пройденное.
1) да любой 8-ми битный CPU by design жрет меньше 32х битного — ибо содержит меньше транзисторов и требует меньше энергии на их переключение в процессе выполнения кода.
1a) Так же любой код на ассемблере, жрет меньше по тем же самым причинам: не имеет «лишнего» исполняющегося мусора — лишних переключений состояний.
Я слышу что вы не программист, поэтому у вас нет понимания того, что чем быстрее работает ядро, тем меньше по времени оно работает. Современное ядро -> меньше техпроцесс -> меньше потребление на ватт -> меньше общее потребление.
Про ассемблер даже комментировать не буду. Пока вы будете писать код на ассемблере для выравнивания износа на FLASH, я уже дойду до выпуска многотысячной партии устройств и поеду в отпуск отдыхать на берегу моря.
Одна только реализация HashMap на ассемблере займет не один месяц и потребует идеальных академических знаний, с которыми человек в гугле будет зарабатывать пол миллиона долларов в год, а не программировать восьмибитные контроллеры.
2) Оригинальная микропроцессорная архитектура разработанная самим производителем с учетом требования рынка (microchip), всегда имеет качество лучше, чем дженерик архитектура на ip модулях купленных как правило хрен знает у кого и насыпанные в кристалл по быстрому (ST).
Такая прекрасная, что программировать под нее придется не в нормальном VisualGDB, а в мусорной IDE из 90х, где ни гит не поддерживается, ни инструментов рефакторинга нет.
Дичайшие баги с АЦП в ST-шных поделках тому пример… А уж конфликты модулей друг с другом по ногам вообще смех — думать было некогда, надо было за кем то гнаться (за кем?)
Вау, и в МК бывают баги. А я-то думал, что мир идеален
3) особенно весело в контексте новичка например обсуждать минимальное число деталей, необходимых для запуска этих ваших 32-хбиток… когда те же PIC12-16 могут работать имея только батарейку подключенную к чипу 2-мя проводами — И ВСЕ! Можно по обсуждать корпуса, ведь те кто учатся еще не уверенно паяльник держит. Этот ваш STM32L0 — В ДИПЕ ГДЕ!? нету конечно… вы сразу паять в TSSOP20 будете учиться? ну ну — я бы посмотрел на этот цирк…
Снова вы не в теме.
Плата с STM32L071KBU6. Подключена «только батарейка двумя проводками» и светодиод. Как раз для тестов потребления)))
Новички сегодня ничего не паяют сами. Зачем, если алика можно за 300 рублей заказать готовую отладочную плату.
И вы все еще не показали тот крутой МК двадцатилетней давности, у которого при работе ядра «наноамперное потребление». Мы все еще ждем.
Даже ваш любимый PIC16F15356 (самый современный) даст 1 микроампер на 32768 на 1.8 вольтах. Найти эту инфу у меня заняло 5 минут. Доказать свои слова вам лень, зато писать простыни гнева — нет.
И это не говоря, что вы сами свой главный аргумент
Есть например устройства 10 лет работающие на одной литиевой таблетке батарейке.
с процессорами у которых в слип ток потребления меньше чем саморазряд этой батарейки.
И никаких 32х биток в них не будет никогда (как и кода не на ассемблере).
в своем следующем сообщении дискредитировали:
В стопе одинаково
Предлагаю закончить, я уже все понял, ничего нового, кроме ностальгии по давно ушедшим годам вы мне не принесете этим диалогом.
Я слышу что вы не программист, поэтому у вас нет понимания того, что чем быстрее работает ядро, тем меньше по времени оно работает
А давно надо быть программистом, чтоб понимать что ничего не делать энергоэффективнее нежли бежать марафон? (учитывая что бег этот — по кругу).
Одна только реализация HashMap на ассемблере займет не один месяц и потребует идеальных академических знаний, с которыми человек в гугле будет зарабатывать пол миллиона долларов в год, а не программировать восьмибитные контроллеры.
Есть код экономящий 5$ в партии 10млн штук — КИХ фильтр. ассемблер. Люди что это сделали никогда не пойдут в гугл — им банально гугл не интересен.
(смешно но работает на ваших любимых ST).
Снова вы не в теме.
Это для новичка? А школьник спаяет? QFN для школьников? а откуда он плату возьмет? утюгом сделает? двухстороннюю? и у вас 9 деталей на плате кроме процессора, хотя вам сказали что можно — НОЛЬ.
Основная проблема этого вашего 32-битостроения тупо отсуствие реальных решаемых исключительно на нем задач! Когда придумали процессоры, придумали компиляторы, гиты и налабалии говнокода — а уровень задач как был «гирляндой» так и остался… А где не гирлянда — почему то гораздо проще промPC воткнуть с примитивным интерфейсом на линуксе чем изобретать кастомный говнокод на 32битках… (32 бита давно придумали — он x86 называется ;)
1) Не любой 8-ми битный CPU потребляет меньше 32х битного — это больше зависит от техпроцесса и напряжения питания. Но даже если они одинаковы — при отключенном питании ядра количество транзисторов в нём не имеет значения, а при включенном — расход энергии зависит от задачи. Если не требуется работать с данными разрядностью больше 8 бит — 8-битники могут выиграть. Но если значительный процент времени программа работает с данными разрядностью больше 8 — расход энергии 8-битником легко может оказаться выше. Сколько нужно 8-битных операций на MAC-операцию с 12-битными операндами и 24-битной суммой? Явно больше 8, а значит энергии будет потрачено больше, чем 32-битным ядром с его одной-двумя операциями и 4-кратным количеством транзисторов. А если взять ещё и PIC16 или ATtiny без умножителя — вообще катастрофически больше.
1a) Практика показывает, что большую часть времени выполняется небольшой процент кода. Это означает, что если для энергоэффективности недостаточно выбора контроллера с подходящим техпроцессом — нужно оптимизировать эту самую небольшую часть кода. Часто можно подобрать конструкцию на С, с которой компилятор сгенерирует эффективный код, но если этого недостаточно — можно использовать ассемблерные вставки и отдельные функции. Но писать на ассемблере всю программу — это как правило означает, что её функционал будет максимально урезан, потому что на всякие там выравнивания износа флэша банально не хватило времени. А если использовать что-то вроде ATtiny — на такие вещи ещё и просто не хватит ресурсов контроллера.
2) Модуль EEPROM для XmegaA3 разрабатывался не в Atmel? Или почему он нормально работает только в sleep-режиме?
3) STM32F070 может работать от батарейки без дополнительных деталей. Другим STM32 нужно лишь несколько конденсаторов по питанию.
1a) Практика показывает, что большую часть времени выполняется небольшой процент кода. Это означает, что если для энергоэффективности недостаточно выбора контроллера с подходящим техпроцессом — нужно оптимизировать эту самую небольшую часть кода. Часто можно подобрать конструкцию на С, с которой компилятор сгенерирует эффективный код, но если этого недостаточно — можно использовать ассемблерные вставки и отдельные функции. Но писать на ассемблере всю программу — это как правило означает, что её функционал будет максимально урезан, потому что на всякие там выравнивания износа флэша банально не хватило времени. А если использовать что-то вроде ATtiny — на такие вещи ещё и просто не хватит ресурсов контроллера.
2) Модуль EEPROM для XmegaA3 разрабатывался не в Atmel? Или почему он нормально работает только в sleep-режиме?
3) STM32F070 может работать от батарейки без дополнительных деталей. Другим STM32 нужно лишь несколько конденсаторов по питанию.
Каждой задаче свой инструмент. Зачем закручивать гвозди отверткой, если есть молоток? И мне не нравится слово «пересядете». Что запрещает использовать и 8, и 32 битки?
Как я научился работать с микроконтроллерами — опыт старичка. Какой был год точно уже не помню, да и не важно. Помню мой первый микроконтроллер. Он был в керамическом корпусе с окошком для стирания ПЗУ ультрафиолетом. Количество циклов перепрограммирования что-то в районе сотни. Зато стоил как пол автомобиля. А других тогда не было. Если не считать разово или масочно программируемых. Да и интернета не было. И спросить было не у кого. Информация вся из бумажных книг в советской библиотеке. Так вот и жили. А потом наступила величайшая геополитическая катастрофа, появился интернет, электрически стираемый ЕЕПРОМ, внутрисхемное программирование и остальной разврат.
И да, про Arduino тогда никто понятия не имел.
В 2009ом никто не имел понятия? Как это? Заказал diecimila в Линуксцентре ещё в 2008ом как раз чтобы попробовать программирование МК.
Создатель сайта написал ещё и учебник по программированию
видимо склоняемый на мелкочипе корабельникофф
Освоить МК реально даже самому и с нуля
я бы советовал начинающим вот такую плату
и уроки к ней, есть на асме и си.
Есть микроконтроллеры, а есть ещё ПЛИС (про которые тут человек из Америки пишет) и это разные вещи и используют разные языки программирования?
Тогда с чего лучше начинать новичку и почему?
Тогда с чего лучше начинать новичку и почему?
UFO just landed and posted this here
Думаю, что новичку в качестве хобби начать лучше с Ардуино. Плюсы: порог вхождения довольно невысок, т.е. готовые наборы, платы и компоненты стоят относительно недорого, среда разработки схематики и среда программирования бесплатные, большое сообщество, большое количество учебных материалов и примеров в инете
по поводу языка, все же сложившийся стандарт это Си + ассемблерные вставки и начинать имеет смысл с этого, т.к. банально больше информации
Считаю, что ассемблер весьма неплох для понимания того что же там внутри происходит. Залезть в МК руками, покопаться в регистрах, посмотреть на результат. И несложная 8-битка для этого весьма подходит.
К тому же, многие любтели могут вполне комфортно себя ощущать в этих самых 8 битах, без надобности в STM32 и подобных.
Уж извините, но кг/ам.
Очень зря не разобрался в ассемблере. Без основ не приходит понимание большего.
Советовать кому-либо ардуину, имхо моветон. Это всё равно как проколов колесо на трассе вопить "Алиса, поменяй мне колесо!".
Чудеса существуют, но делать вам их придётся самим.
Кто бы что ни говорил, но изобретать велосипеды — это и есть работа эмбеддера.
Другое дело, что нет необходимости изобретать комплектующие. Но для этого нужно знать номенклатуру, т.е. основы.
Круг замкнулся.
У PIC'ов ещё очень много библиотек. Например те же библиотеки для работы с пинами как с объектами более наглядно чем использовать битовые маски.
ИМХО, это мои ощущения по сравнению с AVR на момент 2011 года.
Ну и до покупки железок или с целью быстро набросать прототип прошивки можно воспользоваться эмуляторами. Очень мощная, на мой взгляд, это — Proteus
ИМХО, это мои ощущения по сравнению с AVR на момент 2011 года.
Ну и до покупки железок или с целью быстро набросать прототип прошивки можно воспользоваться эмуляторами. Очень мощная, на мой взгляд, это — Proteus
Приветствую, а существуют ли на сегодняшний день сравнительно дешёвые и доступные наборы мат.-плат и периферии (эдакий дев-кит) для 8-битных мк? Конкретные предпочтения есть (Мото 6809) однако мне не принципиально.
learn.parallax.com — до сих пор вспоминаю их чипы Scenix (50MHz PIC) и простой в одно окно компилятор, как DIHALT заметил в простом чипе невозможно заблудится.
без обид, но объективно — статья нынче не актуальна.
в каком нибудь 2012ом еще может быть и было бы полезно новичкам, но сейчас в интернетах тонна информации по этому поводу, как статей так и видео на ютубах с описанием всего, чего только можно
я и сам изучал мк в одиночку (без учителя / наставника). начал в 2014м, плотно занялся в 2016м, сейчас коммерческие проекты разрабатывают и вполне успешно, так что по опыту говорю — инфы доступной вагон, порог входа ниже плинтуса. нужно только желание
С самого начала — 8086 (Паскаль и Ассемблер). Потом MCS51 на ассемблере. Затем AVR, и тоже на ассемблере. А потом я по книжке Крупника «Изучаем Си» выучил Си, и жизнь стала сразу на порядок проще. А дальше — ARM7, ARM9, немного Cortex и проч. С PIC'ами не работал. Но без Си — никуда…
Sign up to leave a comment.
Как я научился работать с микроконтроллерами — опыт новичка