Comments 101
до конца статьи надеялся, что автор пишет от первого лица.
Оказалось — нет — это перевод.
Оказалось — нет — это перевод.
UFO just landed and posted this here
Я поражаюсь тому, как можно сравнивать микроконтроллер и что-то вроде Raspberry Pi. Задачи у них очень разные.
Тем не менее, в соседнем посте (http://habrahabr.ru/post/158555/) написано про светильник с микрокомпьютером на ARMе внутри. Который позиционируется в первую очередь именно как светильник.
Не так давно начал интересоваться ARM архитектурой, а до этого плотно висел на AVR. Могу сказать следующее:
1) Отличия в размерах старших серий AVR и младших серий ARM практически нет
2) ARM даже дешевле чуточку
3) ARM в разы мощнее
4) ARM требует больше обвеса, в частности по питанию
5) ARM сложнее изучать, и программировать
6) ARM (я использую LPC) надежнее, чем AVR
А по существу, для каждой задачи есть свой инструмент. Вы конечно можете забивать гвозди пассатижами, никто не запрещает, но вот если рядом с ними лежит молоток зачем?
Думаю автор умного фонарика обходился не старшей серией AVR-ок, а вполне себе какой-нибудь ATTiny
1) Отличия в размерах старших серий AVR и младших серий ARM практически нет
2) ARM даже дешевле чуточку
3) ARM в разы мощнее
4) ARM требует больше обвеса, в частности по питанию
5) ARM сложнее изучать, и программировать
6) ARM (я использую LPC) надежнее, чем AVR
А по существу, для каждой задачи есть свой инструмент. Вы конечно можете забивать гвозди пассатижами, никто не запрещает, но вот если рядом с ними лежит молоток зачем?
Думаю автор умного фонарика обходился не старшей серией AVR-ок, а вполне себе какой-нибудь ATTiny
Поясните пожалуйста 6 пункт.
И ещё вопросик по третьему — вы сравниваете ARM и AVR32?
И ещё вопросик по третьему — вы сравниваете ARM и AVR32?
AVR 8-bit, с AVR 32-bit не работал, так что сказать ничего не могу про них. Но думаю что ARM будет все-таки лучше, на правах имхо.
По шестому пункту: как минимум у LPC есть контроль тактового генератора.
По шестому пункту: как минимум у LPC есть контроль тактового генератора.
Можете пояснит новичку что такое контроль тактового генератора? Что именно контролируется?
Контролируется стабильность и наличие частоты внешнего тактового генератора, в случае ее (частоты) ухода от заданных значений или отсутствия процессор автоматически переключается на встроенный тактовый генератор 8 МГц и вызывает прерывание, которое можно обработать и заалармить, перезагрузиться, или что придумаете…
Вот здесь в блоге DI Halt'a это подробно описано для STM32. Думаю вам будет интересно.
Вот здесь в блоге DI Halt'a это подробно описано для STM32. Думаю вам будет интересно.
Не знаю, как там у LPC, а у STM32, если внешний тактовый генератор склеил ласты (вандалы оторвали кварц), то контроллер падает на внутренний генератор и прерывание генерится :)
Я поспорю на счёт надёжности, вот по какому критерию: чем меньше деталей в любой конструкции (не обязательно электрической), тем она надёжнее. Когда требуется бОльший обвяз, то надёжность схемы падает в разы. Особенно это касается схем питания.
Ничуть не хочу обидеть АРМы. Разница между avr и arm такая же, как между велосипедом «Дружок» и болидом Формулы 1.
Ничуть не хочу обидеть АРМы. Разница между avr и arm такая же, как между велосипедом «Дружок» и болидом Формулы 1.
И на болиде формулы 1 не очень удобно ездить в магазин. Слишком часто колеса менять надо и бензина много уходит
Я не это имел в виду. Армы невероятно навороченые.
На armах можно реализовать все те же функции, что и на avr, но плюс к этому они невероятно навороченные и имеют море приятных плюшек.
Просто я всю жизнь работал с avr, а тут один проект сделал на lpc2103 (по современным меркам старенький проц), было полное ощущение будто я с жигулей пересел на космический корабль. Навороченно куча всего.
Да, сложнее в освоении, да, требует сильно больше внимания. Но дают несоизмеримо (в сотни тысяч раз) больше возможностей.
Соглашусь только с тем, если мне нужно по быстрому, из говна и палок, сделать крутой девайс, я беру avr.
На armах можно реализовать все те же функции, что и на avr, но плюс к этому они невероятно навороченные и имеют море приятных плюшек.
Просто я всю жизнь работал с avr, а тут один проект сделал на lpc2103 (по современным меркам старенький проц), было полное ощущение будто я с жигулей пересел на космический корабль. Навороченно куча всего.
Да, сложнее в освоении, да, требует сильно больше внимания. Но дают несоизмеримо (в сотни тысяч раз) больше возможностей.
Соглашусь только с тем, если мне нужно по быстрому, из говна и палок, сделать крутой девайс, я беру avr.
Пока не требует внешней памяти на высоких частотах, можно и АРМы из говна и палок)
Я когда на STM32 перешел — некоторое время привыкал, а потом про АВР вообще забыл, на младших СТМках я сделаю то же самое, что и на АВР, но в разы быстрее — хотя бы за счет того, что мне доступны полноценные 32-битные вычисления, DMA и прочая богатая периферия. DMA и вовсе после АВР кажется чудом) Так что только чуть-чуть привыкнуть надо, и станет намного проще использовать их вместо восьмибиток.
Вот платы под них похитрее, это да…
А вот с тяжелыми армами, на которых линукс крутится, и которым надо платы под 400 МГц разводить (память к ним вести) — с ними печаль, конечно, на коленке за день не склепаешь, а хотелось бы… Приходится использовать готовые модули да из роутеров выдирать платы.
Я когда на STM32 перешел — некоторое время привыкал, а потом про АВР вообще забыл, на младших СТМках я сделаю то же самое, что и на АВР, но в разы быстрее — хотя бы за счет того, что мне доступны полноценные 32-битные вычисления, DMA и прочая богатая периферия. DMA и вовсе после АВР кажется чудом) Так что только чуть-чуть привыкнуть надо, и станет намного проще использовать их вместо восьмибиток.
Вот платы под них похитрее, это да…
А вот с тяжелыми армами, на которых линукс крутится, и которым надо платы под 400 МГц разводить (память к ним вести) — с ними печаль, конечно, на коленке за день не склепаешь, а хотелось бы… Приходится использовать готовые модули да из роутеров выдирать платы.
LPC810 в корпусе DIP8
www.nxp.com/products/microcontrollers/cortex_m0plus/lpc800/LPC810M021FN8.html
www.nxp.com/products/microcontrollers/cortex_m0plus/lpc800/LPC810M021FN8.html
Что-то в голове у автора всё перепуталось. Система-на-Кристалле отличается от микроконтроллера наличием достаточной для работы периферии, включая контроллер памяти, интерфейсы и прочее. С этой, несколько устаревшей точки зрения, современные микроконтроллеры практически все как один есть система-на-кристалле. Никакого отношения к жёсткому/мягкому реальному времени такое деление не имеет — возьмите одноплатник, поставьте на него FreeRTOS, и будет «реальное» время.
В общем, перевод хороший, а вот автор статьи что-то недопонимает или не теми словами пытается нам свои мысли донести
В общем, перевод хороший, а вот автор статьи что-то недопонимает или не теми словами пытается нам свои мысли донести
ждем статьи на эту тему, проливающей свет…
А смысл ставить на одноплатник FreeRTOS? Смысл одноплатника как раз в линуксе. Если мне не нужен линукс — возьму МКшку.
Я бы выбор делал бы ровно по тем критериям, что озвучены автором.
Я бы выбор делал бы ровно по тем критериям, что озвучены автором.
Так я то же самое и говорю. Деление на микроконтроллер и микропроцессор появилось достаточно давно, когда достижимая степень интеграции мало что позволяла. Тогда и было разделение на голый процессор, требующий большого объёма обвязки, зато использующий всю площадь кристалла под вычислительные мощности против контроллера, у которого в самом простом режиме даже внешний тактовый генератор не нужен, но мощности ограничены.
С ростом степени интеграции на кристалле стало можно расположить даже часть согласования с аналоговыми интерфейсами, при том, что там же стоит по-настоящему мощный процессор. Это и стало называться SoC.
Строго говоря, практически все выпускаемые микроконтроллеры, широко используемые и освещённые на Хабре, и есть SoC в изначальной трактовке того термина. Нюанс в том, что в настоящее время термин SoC немного изменился и стал означать, что на кристалле присутствует реконфигурируемая аналоговая часть (близко к плис)
С ростом степени интеграции на кристалле стало можно расположить даже часть согласования с аналоговыми интерфейсами, при том, что там же стоит по-настоящему мощный процессор. Это и стало называться SoC.
Строго говоря, практически все выпускаемые микроконтроллеры, широко используемые и освещённые на Хабре, и есть SoC в изначальной трактовке того термина. Нюанс в том, что в настоящее время термин SoC немного изменился и стал означать, что на кристалле присутствует реконфигурируемая аналоговая часть (близко к плис)
Вы всё верное говорите, только это не имеет отношения к делу.
А вопрос в другом — нужно ли брать МК с такой обвязкой, что можно запустить линух из коробки или взять голый МК или МК с другой обвязкой, не предназначенной для запуска линуха (ардуины и подобное).
Об этом и говорит автор.
А вопрос в другом — нужно ли брать МК с такой обвязкой, что можно запустить линух из коробки или взять голый МК или МК с другой обвязкой, не предназначенной для запуска линуха (ардуины и подобное).
Об этом и говорит автор.
Если я говорю то же самое, что и вы, и вы согласны с тем, что я говорю всё правильно, но это не имеет отношения к делу, то это означает, что то, что вы говорите, тоже не имеет отношения к делу. Логика :)
А если серьёзно, я о том, что автор рассуждает, при этом использует термины, смысла которых не понимает. Как и классификации, среди которой он выбирает.
Понятно, что на Хабре люди умные, и поняли, -что- именно обсуждается, но для человека с профильным образованием по теме микроконтроллеров статья выглядит ужасно безграмотной — как раз по части терминов. Одно только назвать Raspberry Pi системой на кристалле чего стоит
А если серьёзно, я о том, что автор рассуждает, при этом использует термины, смысла которых не понимает. Как и классификации, среди которой он выбирает.
Понятно, что на Хабре люди умные, и поняли, -что- именно обсуждается, но для человека с профильным образованием по теме микроконтроллеров статья выглядит ужасно безграмотной — как раз по части терминов. Одно только назвать Raspberry Pi системой на кристалле чего стоит
Чуть-чуть дополню. На данный момент есть, хотя и несколько размытое, разграничение терминов микророцессор и микроконтроллер. Я долго думал над тем, кто же есть кто и не одно ли это и тоже, но в итоге удалось спросить об этом главного инженера по развитию NXP на одной из конференций. Вот, что он ответил.
Микроконтроллеры (MCU) — однокристальные микрокомпьютеры, предназначенные для исполнения т.н. задач (task). Задача — это самостоятельная программа, которая полностью и единолично управляет всеми ресурсами системы. Никого, кроме задачи в системе нет.
Микропроцессоры (MPU) — однокристальные микрокомпьютеры, предназначенные для исполнения связки операционная_система&приложения.
Из этих базисных положений вытекают разные конструкторские решения для MCU и MPU:
1. Микроконтроллеры как правило имеют и оперативную память и постоянную память на борту, т.к. для задачи и того и другого требуется не много. Средств для аппаратной защиты сегментов памяти (MMU и пр.) — нету (а зачем? мы же в системе одни!). Интерфейсов для RAM большого объема как правило нет. Часто нет и интерфейса для NVM большого объема.
2. Связка ОС&приложения требуют заметно больше места как в RAM, так и в NVM, причем диаппазон требуемой памяти в зависимости от задачи может разниться от 4 Мегабайт RAM до 4 ГБайт RAM на MPU одной мощности. Поэтому памяти как правило (но бывают исключения для специальных случаев) не размещают на кристалле, а делают для них интерфейсы (SDRAM, NAND интерфейс, MMC и т.д.).
А есть ещё один ещё более туманный термин — SystemOnChip. SystemOnChip — это микропроцессор, который специально заточен для исполнения на нем прикладной ОС для конечных пользователей. Возьмем обычный MPU, добавим туда видеопроцессор, аудиопроцессор и пр. необходимые для ПК или КПК вещи и вуаля.
Это всё несколько размыто, но тот NXP'шный инженер сам признался, что термины нигде не закреплены и витают в воздухе, просто есть более-менее общая трактовка.
Микроконтроллеры (MCU) — однокристальные микрокомпьютеры, предназначенные для исполнения т.н. задач (task). Задача — это самостоятельная программа, которая полностью и единолично управляет всеми ресурсами системы. Никого, кроме задачи в системе нет.
Микропроцессоры (MPU) — однокристальные микрокомпьютеры, предназначенные для исполнения связки операционная_система&приложения.
Из этих базисных положений вытекают разные конструкторские решения для MCU и MPU:
1. Микроконтроллеры как правило имеют и оперативную память и постоянную память на борту, т.к. для задачи и того и другого требуется не много. Средств для аппаратной защиты сегментов памяти (MMU и пр.) — нету (а зачем? мы же в системе одни!). Интерфейсов для RAM большого объема как правило нет. Часто нет и интерфейса для NVM большого объема.
2. Связка ОС&приложения требуют заметно больше места как в RAM, так и в NVM, причем диаппазон требуемой памяти в зависимости от задачи может разниться от 4 Мегабайт RAM до 4 ГБайт RAM на MPU одной мощности. Поэтому памяти как правило (но бывают исключения для специальных случаев) не размещают на кристалле, а делают для них интерфейсы (SDRAM, NAND интерфейс, MMC и т.д.).
А есть ещё один ещё более туманный термин — SystemOnChip. SystemOnChip — это микропроцессор, который специально заточен для исполнения на нем прикладной ОС для конечных пользователей. Возьмем обычный MPU, добавим туда видеопроцессор, аудиопроцессор и пр. необходимые для ПК или КПК вещи и вуаля.
Это всё несколько размыто, но тот NXP'шный инженер сам признался, что термины нигде не закреплены и витают в воздухе, просто есть более-менее общая трактовка.
А если я на MCU поставлю FreeRTOS он станет MPU?
Это философский вопрос :) А во фриртос пасьянс можно раскладывать?
Это действительно философский вопрос :)
FreeRTOS возможно и не требует MMU и Memory Protectrion модулей, но Linux уже не встанет.
FreeRTOS разрабатывалась в те времена, когда рядовому разработчику дотянуться до микропроцессора (не MCU, а MPU) было очень трудно. Да и SDRAM память в 32 мегабайта стоила прилично. А многозадачности хотелось. Сегодня можно свободно купить lpc31xx за гроши (менее $5) и поставить туда SDRAM от Hynix на 32 мегабайта за $1.5! И на этом железе можно свободно развернуть и Linux (если главное требование — скорость и стоимость разработки) и полноценный вариант FreeRTOS со всеми защитами памяти и пр. (если требуется ОСРВ) или ещё, что душеньке угодно. И главное — это будут полноценные ОС, процессы которых не могут случайно залезть в ядро и преврать жизнь разработчика в АД.
Я для себя, как для разработчика embedded систем, давно решил: ОС нужна только тогда, когда надо защитить одну ветвь выполнения от другой. В любом другом случае можно по-быстрому наклепать систему параллельно выполняемых задач и на этом успокоиться (хотя такое нужно редко). В качестве примера приведу случай из практики. Мы разрабатывали для стороннего заказчика аппаратную платформу (АП). Под АП подразумевается собственно железка (А) и уровень аппаратных абстракций (П, или, правильнее, — HAL). HAL нужен для того, чтобы программисты заказчика могли писать задачи для железки не зная её архитектурных особенностей. Для них мы предоставляем Си-шный интерфейс к железке, выраженный очень простыми и понятными терминами.
Когда уже казалось, что проект сдан, стали поступать многочисленные жалобы от них. Якобы наша железка ведет себя не стабильно. Отчасти это в том проекте и было так, процессор (только что вышедший) оказался редкостным Г, но были и другие причины: в своих программах разработчики заказчика, сидя в достаточно стесненных условиях (рамы мало, скорость процессора не велика), вели себя так же, как на полноценном ПК. Удобней передать в стек 15 КБайт данных — передам. Рекурсивная функция — пожалуйста. В итоге стек начал переполняться и программа начинала выкидывать фокусы (работа превратилась в морской бой, при пуске устройства никогда не знаешь заранее, что отвалится). Прикручивание тормозящей все и вся защиты стека дало мало: есть же ещё разыменования указателей и много других способов залезть куда не надо. Из-за их ошибок происходило повреждение памяти, где находился наш код HAL и после этого происходили самые невероятные вещи. Намучились мы тогда здорово…
В следующем проекте мы специально выбрали микропроцессор (MPU) и написали свою маленькую ОС с защитой памяти ядра (ядром являлся наш HAL) и системными вызовами. Получилась ОС с одной задачей, ядро — HAL, задача — прикладная задача заказчика. Ни одного сообщения, подобного тому, которое получали по прошлому проекту, в этот раз не было. Вот тогда мы поняли, зачем в действительности нужны операционные системы в embedded…
FreeRTOS возможно и не требует MMU и Memory Protectrion модулей, но Linux уже не встанет.
FreeRTOS разрабатывалась в те времена, когда рядовому разработчику дотянуться до микропроцессора (не MCU, а MPU) было очень трудно. Да и SDRAM память в 32 мегабайта стоила прилично. А многозадачности хотелось. Сегодня можно свободно купить lpc31xx за гроши (менее $5) и поставить туда SDRAM от Hynix на 32 мегабайта за $1.5! И на этом железе можно свободно развернуть и Linux (если главное требование — скорость и стоимость разработки) и полноценный вариант FreeRTOS со всеми защитами памяти и пр. (если требуется ОСРВ) или ещё, что душеньке угодно. И главное — это будут полноценные ОС, процессы которых не могут случайно залезть в ядро и преврать жизнь разработчика в АД.
Я для себя, как для разработчика embedded систем, давно решил: ОС нужна только тогда, когда надо защитить одну ветвь выполнения от другой. В любом другом случае можно по-быстрому наклепать систему параллельно выполняемых задач и на этом успокоиться (хотя такое нужно редко). В качестве примера приведу случай из практики. Мы разрабатывали для стороннего заказчика аппаратную платформу (АП). Под АП подразумевается собственно железка (А) и уровень аппаратных абстракций (П, или, правильнее, — HAL). HAL нужен для того, чтобы программисты заказчика могли писать задачи для железки не зная её архитектурных особенностей. Для них мы предоставляем Си-шный интерфейс к железке, выраженный очень простыми и понятными терминами.
Когда уже казалось, что проект сдан, стали поступать многочисленные жалобы от них. Якобы наша железка ведет себя не стабильно. Отчасти это в том проекте и было так, процессор (только что вышедший) оказался редкостным Г, но были и другие причины: в своих программах разработчики заказчика, сидя в достаточно стесненных условиях (рамы мало, скорость процессора не велика), вели себя так же, как на полноценном ПК. Удобней передать в стек 15 КБайт данных — передам. Рекурсивная функция — пожалуйста. В итоге стек начал переполняться и программа начинала выкидывать фокусы (работа превратилась в морской бой, при пуске устройства никогда не знаешь заранее, что отвалится). Прикручивание тормозящей все и вся защиты стека дало мало: есть же ещё разыменования указателей и много других способов залезть куда не надо. Из-за их ошибок происходило повреждение памяти, где находился наш код HAL и после этого происходили самые невероятные вещи. Намучились мы тогда здорово…
В следующем проекте мы специально выбрали микропроцессор (MPU) и написали свою маленькую ОС с защитой памяти ядра (ядром являлся наш HAL) и системными вызовами. Получилась ОС с одной задачей, ядро — HAL, задача — прикладная задача заказчика. Ни одного сообщения, подобного тому, которое получали по прошлому проекту, в этот раз не было. Вот тогда мы поняли, зачем в действительности нужны операционные системы в embedded…
Да, чёрт возьми, простые задачи без энергосбережения уже проще сделать на linux-based плате. Да и туда можно всякие няшки добавлять.
А вот отнять у чипов право быть быстрее, точнее и эффективнее (по батарейке) — пока сложно.
А вот отнять у чипов право быть быстрее, точнее и эффективнее (по батарейке) — пока сложно.
Как я это понимаю, – зачем кому-то покупать Arduino, когда можно приобрести Raspberry Pi, который может гораздо больше, а стоит столько же или меньше?
Ну пиз*ешь ведь. Оригинальный UNO 26$, Pi 35$ и смерть от старости в ожидании.
Плюс ко всему, после прототипипования, можно купить копеечный контроллер и практически без обвязки легко использовать в готовом устройстве.
+ nano/mini для совсем ленивых, а MSP430 — вообще 5$, сохраняя 80% функционала Arduino
Строго говоря, msp430 есть не микроконтроллер, а микроконвертор (так заявляет его производитель TI). Т.е. его вычислительные мощности не предназначены для решения общих задач, а являются придатком к АЦП, чтобы выполнять первичную обработку данных и организовывать т.н. «интеллектуальные датчики»
Строго говоря, msp430 есть не микроконтроллер, а микроконвертор (так заявляет его производитель TI).
Слышу эту легенду, передаваемую из уст в уста, не первый раз. Аж интересно стало — а доказательства есть? Потому что на самом деле его производитель TI называет его без выкрутасов — «Ultra-Low Power 16-Bit Microcontrollers». Еще он называет их «mixed-signal microprocessors», но из этого получить «микроконвертор» можно получить только с особыми трудностями перевода.
Не понял, доказательства чего нужны. Учитывая, что «микропроцессор», «микроконтроллер», «микрокомпьютер» и «система на кристалле» крайне раплывчатые термины, доказать можно что угодно.
Лично я имею в виду, что архитектура микроконтроллера имеет много общего с «микроконверторами».
Обозначение «микроконвертор» впервые применила Analog devices, изготавливавшая отличные высокоскоростные АЦП, требовавшие некоторой обвязки. Предполагалось, что код такой обвязки будет исполнять маломощное процессорное ядро.
Если посмотреть вглубь, в общем-то, такое ядро ничем не отличается от микропроцессора, но есть одно но: в msp, как и в упомянутых процессорах от AD, в отличие от обычного микропроцессора (где его ядро — для вас главное), в случае микроконвертора процессорное ядро суть дополнение, осуществляющее накопление и коммутацию потоков данных.
Подчёркивается это его свойствами:
— ядро может тактироваться отдельно от периферии (в msp каждый блок вообще тактируется отдельно),
— обладает большим количеством режимов сна (т.е. сон — его основное времяпрепровождение),
— обладает малым количеством памяти программ, зато имеет на борту EEPROM (для хранения и перезаписи уставок и алгоритмов предобработки),
— набор инструкций и разрядность предназначены для максимально удобного написания коротких программ по обработке данных со встроенного 10- и 12-битного АЦП,
— инструкции длинные, выполняются медленно и тратят много тактов, на большинстве конфигураций даже аппаратный умножитель вынесен в отдельный блок
Лично я имею в виду, что архитектура микроконтроллера имеет много общего с «микроконверторами».
Обозначение «микроконвертор» впервые применила Analog devices, изготавливавшая отличные высокоскоростные АЦП, требовавшие некоторой обвязки. Предполагалось, что код такой обвязки будет исполнять маломощное процессорное ядро.
Если посмотреть вглубь, в общем-то, такое ядро ничем не отличается от микропроцессора, но есть одно но: в msp, как и в упомянутых процессорах от AD, в отличие от обычного микропроцессора (где его ядро — для вас главное), в случае микроконвертора процессорное ядро суть дополнение, осуществляющее накопление и коммутацию потоков данных.
Подчёркивается это его свойствами:
— ядро может тактироваться отдельно от периферии (в msp каждый блок вообще тактируется отдельно),
— обладает большим количеством режимов сна (т.е. сон — его основное времяпрепровождение),
— обладает малым количеством памяти программ, зато имеет на борту EEPROM (для хранения и перезаписи уставок и алгоритмов предобработки),
— набор инструкций и разрядность предназначены для максимально удобного написания коротких программ по обработке данных со встроенного 10- и 12-битного АЦП,
— инструкции длинные, выполняются медленно и тратят много тактов, на большинстве конфигураций даже аппаратный умножитель вынесен в отдельный блок
Доказательства того, что TI называет свои микроконтроллеры MSP430 «микроконверторами». Так вот, они этого не делают. Их микроконтроллеры вполне себе позиционируются как general purpose. Я рад за маркетологов Analog Devices, отжигают. Но под их критерии можно подвести (или не подвести) что угодно:
> — ядро может тактироваться отдельно от периферии (в msp каждый блок вообще тактируется отдельно)
Не буду приводить в пример наболевший AVR, где все точно так же, просто напомню про современные Cortex A, где clock tree состоит из десятков а то и сотен тактовых сигналов для отдельных блоков.
> — обладает большим количеством режимов сна (т.е. сон — его основное времяпрепровождение),
Это они про Intel x86 что ли с их кучей C-states?
> — обладает малым количеством памяти программ, зато имеет на борту EEPROM (для хранения и перезаписи уставок и алгоритмов предобработки),
Средний размер флеша в MSP430 где-то 50 кил, есть больше. Вот чего в MSP430 нет, так это EEPROM, да.
> — набор инструкций и разрядность предназначены для максимально удобного написания коротких программ по обработке данных со встроенного 10- и 12-битного АЦП,
Есть MSP430 без АЦП, незадача, ядро есть, а то, к чему оно якобы довесок, нету.
> — инструкции длинные,
16 бит для 16-битного CPU, да. В ARM тоже был 32-битными, пока не придумали Thumb.
> выполняются медленно и тратят много тактов,
По такту на доступ к памяти асимптотически.
> на большинстве конфигураций даже аппаратный умножитель вынесен в отдельный блок
Типично для 8/16 битный микропроцессоров, не?
Собственно я к чему — очень часто высказывания вроде «MSP430 — не совсем микроконтроллер» звучат с подтекстом «поэтому я буду и дальше долбиться с AVR» (уверен, что это не ваш случай, но иногда так и сквозит). Хуже, что эти высказывания читают и новички, и выбирают ту чудноватую AVR-архитектуру с фьюзами и гарвардом. MSP430 не идеал, но глоток свежего воздуха по сравнению с AVR, и очень хорошо подходит для новичков, а TI реально старается сделать его доступным. Поэтому хотелось «замолвить словечко».
> — ядро может тактироваться отдельно от периферии (в msp каждый блок вообще тактируется отдельно)
Не буду приводить в пример наболевший AVR, где все точно так же, просто напомню про современные Cortex A, где clock tree состоит из десятков а то и сотен тактовых сигналов для отдельных блоков.
> — обладает большим количеством режимов сна (т.е. сон — его основное времяпрепровождение),
Это они про Intel x86 что ли с их кучей C-states?
> — обладает малым количеством памяти программ, зато имеет на борту EEPROM (для хранения и перезаписи уставок и алгоритмов предобработки),
Средний размер флеша в MSP430 где-то 50 кил, есть больше. Вот чего в MSP430 нет, так это EEPROM, да.
> — набор инструкций и разрядность предназначены для максимально удобного написания коротких программ по обработке данных со встроенного 10- и 12-битного АЦП,
Есть MSP430 без АЦП, незадача, ядро есть, а то, к чему оно якобы довесок, нету.
> — инструкции длинные,
16 бит для 16-битного CPU, да. В ARM тоже был 32-битными, пока не придумали Thumb.
> выполняются медленно и тратят много тактов,
По такту на доступ к памяти асимптотически.
> на большинстве конфигураций даже аппаратный умножитель вынесен в отдельный блок
Типично для 8/16 битный микропроцессоров, не?
Собственно я к чему — очень часто высказывания вроде «MSP430 — не совсем микроконтроллер» звучат с подтекстом «поэтому я буду и дальше долбиться с AVR» (уверен, что это не ваш случай, но иногда так и сквозит). Хуже, что эти высказывания читают и новички, и выбирают ту чудноватую AVR-архитектуру с фьюзами и гарвардом. MSP430 не идеал, но глоток свежего воздуха по сравнению с AVR, и очень хорошо подходит для новичков, а TI реально старается сделать его доступным. Поэтому хотелось «замолвить словечко».
>> вполне себе позиционируются как general purpose
Всё, что Тьюринг-полное, вполне себе может быть general purpose, кто спорит. Особо смысла не, хотя и можно
>> Так вот, они этого не делают.
Общался с инженерами из TI, было это в году 2004-2005. Называют.
>> Это они про Intel x86 что ли с их кучей C-states?
То-то я смотрю, все разработчики софта только и делают, что пишут софт под эти режимы
>>По такту на доступ к памяти асимптотически
От одного до шести тактов на инструкцию, чаще ближе к последнему. Это медленно. Тактовая частота в 8 Мгц тоже маловато для процессора основного назначения
>> просто напомню про современные Cortex A,
Сравнивать современный процессор с разработкой 99го года очень ок
>> Типично для 8/16 битный микропроцессоров, не?
Не. Буду рад увидеть, для кого ещё типично
>>а то, к чему оно якобы довесок, нету.
В семье не без урода. Вы сами говорите «для некоторых»
>> Средний размер флеша в MSP430 где-то 50 кил
Только 4 конфигурации больше 50 (56, 60, 92 и 116/120), остальные 12 штук — от 1кб до 48. Погорячились вы со средним. Кроме того, если писать на C, а не на форте, например, место заканчивается катастрофически быстро.
>>звучат с подтекстом «поэтому я буду и дальше долбиться с AVR»
Не-не, что вы. msp вполне удобно использовать как основной, особенно в носимых автономных девайсах. Скажем, если бы мне нужно было делать GPS-трекер, 430 был бы в числе кандидатов. Или, скажем, датчик давления — там нужен усреднение с накоплением и пересчёт по калибровочной кривой. Калибровочную кривую удобно шить как таблицу констант вместе с программой на флеш, а у msp430 память программ мапится в общее адресное пространство, и есть косвенная адресация как раз для таких целей.
Это вы просто переобщались с ардуинщиками, видимо, что заранее предполагаете фанатизм и категоричность.
Если честно, у меня до последнего абзаца было такое ощущение, что вам не важна точка зрения, вам важно доебаться и доказать, что оппонент неправ. Рад, что я ошибся :)
Всё, что Тьюринг-полное, вполне себе может быть general purpose, кто спорит. Особо смысла не, хотя и можно
>> Так вот, они этого не делают.
Общался с инженерами из TI, было это в году 2004-2005. Называют.
>> Это они про Intel x86 что ли с их кучей C-states?
То-то я смотрю, все разработчики софта только и делают, что пишут софт под эти режимы
>>По такту на доступ к памяти асимптотически
От одного до шести тактов на инструкцию, чаще ближе к последнему. Это медленно. Тактовая частота в 8 Мгц тоже маловато для процессора основного назначения
>> просто напомню про современные Cortex A,
Сравнивать современный процессор с разработкой 99го года очень ок
>> Типично для 8/16 битный микропроцессоров, не?
Не. Буду рад увидеть, для кого ещё типично
>>а то, к чему оно якобы довесок, нету.
В семье не без урода. Вы сами говорите «для некоторых»
>> Средний размер флеша в MSP430 где-то 50 кил
Только 4 конфигурации больше 50 (56, 60, 92 и 116/120), остальные 12 штук — от 1кб до 48. Погорячились вы со средним. Кроме того, если писать на C, а не на форте, например, место заканчивается катастрофически быстро.
>>звучат с подтекстом «поэтому я буду и дальше долбиться с AVR»
Не-не, что вы. msp вполне удобно использовать как основной, особенно в носимых автономных девайсах. Скажем, если бы мне нужно было делать GPS-трекер, 430 был бы в числе кандидатов. Или, скажем, датчик давления — там нужен усреднение с накоплением и пересчёт по калибровочной кривой. Калибровочную кривую удобно шить как таблицу констант вместе с программой на флеш, а у msp430 память программ мапится в общее адресное пространство, и есть косвенная адресация как раз для таких целей.
Это вы просто переобщались с ардуинщиками, видимо, что заранее предполагаете фанатизм и категоричность.
Если честно, у меня до последнего абзаца было такое ощущение, что вам не важна точка зрения, вам важно доебаться и доказать, что оппонент неправ. Рад, что я ошибся :)
+stm32f100 за 1$
В статье автор сравнивает Stellaris Launchpad и Arduino Due с Raspberry Pi. И если первый дешевле, то Arduino Due уже дороже Raspberry. И если есть кого винить в скорости доставки — так это почту. Уже с пол года нет задержек в поставках.
Ваше утверждение не соответствует действительности:
Заказывал у element14 в конце октября новую модель — получил через неделю.
Наверное, статью стоило назвать как-нибуь вроде «Микроконтроллеры (в качестве основы умного дома) устарели?». Есть ОЧЕНЬ много других применений, в которых идея заменить МК на миникомпьютер может прийти только в кошмарном сне.
А вы не путайте свою шерсть с государственной (с). Как-то не вяжутся хобби и DIY c экономией на железе и оценкой стоимости затраченного времени.
Ладно, на работе я лучше внедрю готовое решение за X баксов и получу за внедрение еще X баксов сверху, потратив Y часов, чем сяду, спаяю и напишу код, потрачу на железо 0.5Х баксов и 10Y времени на разработку.
Но дома то для хобби грех думать о времени и деньгах, иначе смысл им заниматься, а не тратить свободное время на работу и зарабатывание $$$.
Если я буду делать, допустим, умный выключатель, зачем мне ставить линукс на готовую плату? Гораздо интереснее и полезнее для собственного развития и железяку сделать с нуля и ось написать. А ежели лень, или способностей не хватает, или времени, то тогда конечно…
Ладно, на работе я лучше внедрю готовое решение за X баксов и получу за внедрение еще X баксов сверху, потратив Y часов, чем сяду, спаяю и напишу код, потрачу на железо 0.5Х баксов и 10Y времени на разработку.
Но дома то для хобби грех думать о времени и деньгах, иначе смысл им заниматься, а не тратить свободное время на работу и зарабатывание $$$.
Если я буду делать, допустим, умный выключатель, зачем мне ставить линукс на готовую плату? Гораздо интереснее и полезнее для собственного развития и железяку сделать с нуля и ось написать. А ежели лень, или способностей не хватает, или времени, то тогда конечно…
Гораздо интереснее и полезнее для собственного развития и железяку сделать с нуля и ось написать
это в первый раз
это в первый раз
А вы и не путайте свою шерсть с государственной)
Интереснее и полезнее — в случае если у вас цель обучиться. Причем, заметьте — ценность этого опыта тоже не абсолютная, потому как в реальной жизни от вас потребуется быстрое, дешевое и качественное решение (да-да, сложный компромисс), причем с возможностью поддержки. А значит очередной велосипед не пройдет.
Когда вы делаете железку с нуля — разбираетесь в низком уровне, например, в протоколах и интерфейсах, в типовой схемотехнике. Пишете ось с нуля — разбираетесь в IPC, шедулинге, абстракциях от железа и т.п.
Но это начальные ступени, дальше идет умение применить эти знания, для того чтобы запустить чужие, проверенные ОС, подключить к своим системам чужие модули и т.п.
Не все берется чужое, конечно. Но и далеко, далеко не все пишется с нуля. Я вам могу озвучить задачу, решаему за неделю при использовании 800-рублевой платы с линуксом, которую вы будете решать месяцами, и, вероятнее всего, так и не доведете до конца, истратив тысячи рублей на прототипы. И таких задач тысячи.
Просто потому, что линукс стал стандартом для такого рода систем, а значит — накопилась кодовая база, которая позволяет использовать большинство современной периферии, тонны библиотек и т.п.
Заведите со своей «голой железки» и самописной оси 3G модем. Сколько у вас времени займет полноценный драйвер? А драйвер, который осилит любой покупной модем, а не только тот, с которым вы связались? А веб-сервер поднять на нем, еще и с PHP? А вебку прикрутить и транслировать видео?
Это задачи другого плана, и в процессе профессионального роста вы увидите границу применимости простых контроллеров, ту черту, после которой надо не изобретать велосипед, а обращаться к готовым решениям.
Кстати, велосипед-то можно и изобрести, в виде модуля, на который встанет линукс, вот это сейчас оправдано и весьма неплохой навык в копилку — мало ли когда вас могут не устроить существующие аппаратные платформы.
Интереснее и полезнее — в случае если у вас цель обучиться. Причем, заметьте — ценность этого опыта тоже не абсолютная, потому как в реальной жизни от вас потребуется быстрое, дешевое и качественное решение (да-да, сложный компромисс), причем с возможностью поддержки. А значит очередной велосипед не пройдет.
Когда вы делаете железку с нуля — разбираетесь в низком уровне, например, в протоколах и интерфейсах, в типовой схемотехнике. Пишете ось с нуля — разбираетесь в IPC, шедулинге, абстракциях от железа и т.п.
Но это начальные ступени, дальше идет умение применить эти знания, для того чтобы запустить чужие, проверенные ОС, подключить к своим системам чужие модули и т.п.
Не все берется чужое, конечно. Но и далеко, далеко не все пишется с нуля. Я вам могу озвучить задачу, решаему за неделю при использовании 800-рублевой платы с линуксом, которую вы будете решать месяцами, и, вероятнее всего, так и не доведете до конца, истратив тысячи рублей на прототипы. И таких задач тысячи.
Просто потому, что линукс стал стандартом для такого рода систем, а значит — накопилась кодовая база, которая позволяет использовать большинство современной периферии, тонны библиотек и т.п.
Заведите со своей «голой железки» и самописной оси 3G модем. Сколько у вас времени займет полноценный драйвер? А драйвер, который осилит любой покупной модем, а не только тот, с которым вы связались? А веб-сервер поднять на нем, еще и с PHP? А вебку прикрутить и транслировать видео?
Это задачи другого плана, и в процессе профессионального роста вы увидите границу применимости простых контроллеров, ту черту, после которой надо не изобретать велосипед, а обращаться к готовым решениям.
Кстати, велосипед-то можно и изобрести, в виде модуля, на который встанет линукс, вот это сейчас оправдано и весьма неплохой навык в копилку — мало ли когда вас могут не устроить существующие аппаратные платформы.
Я о том, что хобби — это изобретение велосипедов. Некоторым нравится их изобретать и они это делают, а некоторым нравится ездить, и они покупают готовые.
Главное, чтобы этот абстрактный велосипед позволял ехать так, как нужно, а то бывают тысячи случаев, когда и готовый не едет, и новый изобретать нет возможности (это уже в разрезе профессиональной деятельности). И приходится его напильником, напильником! Или вообще брать болид формулы-1, хотя задачи решились бы четырехколесным велосипедом с двумя рулями.
Главное, чтобы этот абстрактный велосипед позволял ехать так, как нужно, а то бывают тысячи случаев, когда и готовый не едет, и новый изобретать нет возможности (это уже в разрезе профессиональной деятельности). И приходится его напильником, напильником! Или вообще брать болид формулы-1, хотя задачи решились бы четырехколесным велосипедом с двумя рулями.
Хобби — это не только изобретение велосипедов. Изобретение велосипедов — это подогрев ЧСВ и развлечение.
Я, например, ненавижу делать вещи более одного раза. Никакие. Если написал код, то лучше всего использовать его в следующий раз, а не писать заново, снова тратя время на поиск ошибок в нем. Если сделал девайс, то использовать его везде где это возможно как модуль. Все МК и одноплатные компьютеры для меня лишь кирпичики в общей системе, все может быть взаимосвязано если имеются нужные интерфейсы. Поэтому в первую очередь я всегда интересуюсь коммуникативными возможностями — есть ли UART, I2C, SPI, USB, WiFI или что-то еще такое, к чему можно стандартно без плясок с бубнами подключиться с другого модуля. Для меня любой МК — это числодробилка + ножки, которые могут что-то включать/выключать и передавать куда-то об этом информацию или принимать команды. Мне нравится делать устройства, которые нужны не один раз, устройства, которые захочет кто-то повторить, потому что они дешевы, просты в исполнении и полезны. В этом смысле вопрос стоимости и сложности разработки имеет смысл одновременно. Поэтому из распространненных МК пригодны достаточно дешевые, а из доступных по цене — самые распространенные и хорошо документированные — то есть массовое, доступное всем. Единичный прикольный девайс — это вещь в себе, 20 лет назад это было интересно. Сегодня — нет. Сегодня самое главное — это связь, если есть связь с внешним миром, можно управлять, быть управляемым, можно быть автономным, спрятанным, удобным, полезным. Если нет — нужно все делать вручную. А это имеет мало смысла.
Штучки только для развлечения мне неинтересны. Тетрис и прочие карманные игрушки становятся скучны после 3-5 повторений.
Я, например, ненавижу делать вещи более одного раза. Никакие. Если написал код, то лучше всего использовать его в следующий раз, а не писать заново, снова тратя время на поиск ошибок в нем. Если сделал девайс, то использовать его везде где это возможно как модуль. Все МК и одноплатные компьютеры для меня лишь кирпичики в общей системе, все может быть взаимосвязано если имеются нужные интерфейсы. Поэтому в первую очередь я всегда интересуюсь коммуникативными возможностями — есть ли UART, I2C, SPI, USB, WiFI или что-то еще такое, к чему можно стандартно без плясок с бубнами подключиться с другого модуля. Для меня любой МК — это числодробилка + ножки, которые могут что-то включать/выключать и передавать куда-то об этом информацию или принимать команды. Мне нравится делать устройства, которые нужны не один раз, устройства, которые захочет кто-то повторить, потому что они дешевы, просты в исполнении и полезны. В этом смысле вопрос стоимости и сложности разработки имеет смысл одновременно. Поэтому из распространненных МК пригодны достаточно дешевые, а из доступных по цене — самые распространенные и хорошо документированные — то есть массовое, доступное всем. Единичный прикольный девайс — это вещь в себе, 20 лет назад это было интересно. Сегодня — нет. Сегодня самое главное — это связь, если есть связь с внешним миром, можно управлять, быть управляемым, можно быть автономным, спрятанным, удобным, полезным. Если нет — нужно все делать вручную. А это имеет мало смысла.
Штучки только для развлечения мне неинтересны. Тетрис и прочие карманные игрушки становятся скучны после 3-5 повторений.
Что тут верно — так это то, что использование систем, на которых крутится линукс, сокращает время на разработку и поддержку.
Это безусловно и неоспоримо — почти для любого случая вы найдете готовую библиотеку, которую можно допилить до нужного результата. Многое можно написать на высокоуровневых скриптовых языках. Не требуется писать драйверы для часто встречающихся задач — работы с флеш-памятью, камерами, GPS, модемами.
Но расплачиваться за это приходится высокой стоимостью проектирования и производства самой аппаратной платформы.
В смысле, если вы будете проектировать свое устройство и вас не будет устраивать чужая Raspberry.
Но, правда, если у вас уже есть наработка, ее можно будет потом использовать почти без изменений, да и плату будет уже дешевле произвести.
Это безусловно и неоспоримо — почти для любого случая вы найдете готовую библиотеку, которую можно допилить до нужного результата. Многое можно написать на высокоуровневых скриптовых языках. Не требуется писать драйверы для часто встречающихся задач — работы с флеш-памятью, камерами, GPS, модемами.
Но расплачиваться за это приходится высокой стоимостью проектирования и производства самой аппаратной платформы.
В смысле, если вы будете проектировать свое устройство и вас не будет устраивать чужая Raspberry.
Но, правда, если у вас уже есть наработка, ее можно будет потом использовать почти без изменений, да и плату будет уже дешевле произвести.
можно взять готовый SoM и обойтись без проектирования велосипедов
Они часто избыточны, а часто — недостаточны) Избыточность, кстати, страшнее — свои-то модули можно доделать на доп. плате, а вот выкинуть из готовой чужие — не получится.
Если есть решение с минимумом (процессор+память+флеш для стартовой загрузки) — то это то, что нужно. У вас такие есть на примете?
Если есть решение с минимумом (процессор+память+флеш для стартовой загрузки) — то это то, что нужно. У вас такие есть на примете?
Прямо такой голяк в виде проца с мозгами конечно врядли удастся найти, но жеалиние не оригинально, и как правило модули довольно гибко конфигурирутся от и до. Лишнее повыбрасывать — вполне вариант.
С другой стороны, когда надо получить больше — вот тут раздолье, «из коробки» всё валом и готовое, включая производительность.
С другой стороны, когда надо получить больше — вот тут раздолье, «из коробки» всё валом и готовое, включая производительность.
А как там у Линукса с жестким реальным временем? ;)
Автор вообще не понимает о чём пишет. Думаю, он мог бы с таким же успехом написать статью с названием «Транзисторы устарели?».
Ага, подобными вещами тоже заморачиваюсь. И знаю людей кто тем же занимается.
В итоге у каждого свой велосипед, вместо того чтобы сделать крутой автомобиль вместе.
В итоге у каждого свой велосипед, вместо того чтобы сделать крутой автомобиль вместе.
Автор забыл упомянуть такой немаловажный момент: устройство на микроконтроллере (пусть и не на любом) легко или не очень, собирается дома, практически на коленке. А RaspberryPI — подобные устройства?
Думаю, вряд ли.
Думаю, вряд ли.
Перевод достойный, мнение ошибочно… IMHO.
Я не очень понимаю, что хочет сказать автор? Это примерно то же самое, что сравнивать резиновую лодку и авианосец.
Да лодка более манёвренна, легка и проста в управлении. Но увы, тяжёлые самолёты перевозить не может.
Но авианосец может нести тяжёлый груз и стоять в шторм, но за секунду не развернётся на 180 градусов.
По моему, для любого кто работал и с линуксом и с контроллерами сия статья очевидна.
Да лодка более манёвренна, легка и проста в управлении. Но увы, тяжёлые самолёты перевозить не может.
Но авианосец может нести тяжёлый груз и стоять в шторм, но за секунду не развернётся на 180 градусов.
По моему, для любого кто работал и с линуксом и с контроллерами сия статья очевидна.
> По моему, для любого кто работал и с линуксом и с контроллерами сия статья очевидна.
Именно, описаны типичные «интеллигентские метания» — «кто виноват и что делать». У каждого такие бывали, но обычно (ну, по крайней мере, у тех, кто из софта приходит) процесс обратный — сначала радуешься, как легко сделать «умный дом» воткнув в раутер USB-релюшку от «Мастеркита». И только потом понимаешь, что для умного дома таких точек нужно десятки, и делать так дорого и неудобно, а нужно мини-компьютер на Linux для управления, и микроконтроллеры для оконечных устройств.
Но автор оригинальной статьи клевый пацан, и сначала хотел сделать весь умный дом на микроконтроллерах. Теперь же он хочет весь дом на линух-платах. Для него метания продолжаются, аминь.
Единственное, что стоит добавить, что есть куда более достойные авторы для перевода — ну например jeelabs.org.
Именно, описаны типичные «интеллигентские метания» — «кто виноват и что делать». У каждого такие бывали, но обычно (ну, по крайней мере, у тех, кто из софта приходит) процесс обратный — сначала радуешься, как легко сделать «умный дом» воткнув в раутер USB-релюшку от «Мастеркита». И только потом понимаешь, что для умного дома таких точек нужно десятки, и делать так дорого и неудобно, а нужно мини-компьютер на Linux для управления, и микроконтроллеры для оконечных устройств.
Но автор оригинальной статьи клевый пацан, и сначала хотел сделать весь умный дом на микроконтроллерах. Теперь же он хочет весь дом на линух-платах. Для него метания продолжаются, аминь.
Единственное, что стоит добавить, что есть куда более достойные авторы для перевода — ну например jeelabs.org.
Это просто очередная констатация общеизвестного факта — закон Мура окончательно похерил мирок классического олдскульного embedded, порожденного много много лет назад 8051. Мир праху его.
И сегодня даже какой-то «хеловорд» (типа пару PIO подергать) целесообразнее делать на чем-то 32-х разрядном с Linux, чем на каких-то 8-ми битах. С другой стороны, наверное, сегодня многие такие «хеловорды» как-то даже и не представляют себе, без Ethernet на борту.
И сегодня даже какой-то «хеловорд» (типа пару PIO подергать) целесообразнее делать на чем-то 32-х разрядном с Linux, чем на каких-то 8-ми битах. С другой стороны, наверное, сегодня многие такие «хеловорды» как-то даже и не представляют себе, без Ethernet на борту.
Тем временем в мире по прежнему успешно продаются миллионными тиражами 4х разрядные микроконтроллеры.
Какие и где? Что-то мне кажется, что тут больше места для программируемой логики.
Моделей точно не скажу, особо не интересовался. Но почти все карманные калькуляторы (если это конечно не инженерные монстры с огромным таблом и кучей матана внутри), пульты от телеков, всякие микроволновки и прочая несложная хрень работает на чем то подобном.
И что? Экономят в два раза транзисторов на кристалле? :)
Да. Цена там вообще смешная выходит. ВО первых OTP, или даже масочные ПЗУ, во вторых они реально мелкие и простые. При массовых тиражах выходит НАМНОГО дешевле чем даже 8ми битники.
Ну и техпроцесс естественно. Он там древний, еще из 80х т.е. их производят всякие колхозные фабрики на старом оборудовании.
И да, они почти все OTP типа. А часто еще и бескорпусные в виде сопли на плате.
Тем временем в мире по прежнему успешно продаются миллионными тиражами 4х разрядные микроконтроллеры.
Ловлю на слове ;-). Миллионные тиражи — это крошечный рынок. Нормальные чипы идут миллиардными. Вот например инфа по Cortex M:
If I look at the whole of Cortex-M shipments across all markets we are well over 200M per quarter now and growing rapidly.
И ведь эта инфа полуторагодовой давности, до того, как все кому ни лень начали совать Cortex M даже в «специализированные» чипы. Труп 8051 гниет на глазах ;-). Собственно, выпуск NXP LPC в DIP8 ставит хороший крест на его могиле.
Неправда. Знаете, почему 8051 не помрет в ближайшее время?
Потому что есть куча его реализаций, не закрытых никакими NDA — бери и делай свои кристаллы.
Хотите я вам перечислю, где у вас 8051? Во всех флешках, во всех SD-картах, во всех хабах. В трансиверах для мышек и клавиатур.
«выпуск в дип8» это вообще несерьезно — там, куда пихают 8051, пихают бескорпусные версии. Он мог давно умереть для поделок на коленке, умереть как отдельный микроконтроллер, но как ядро спец микросхем он живее всех живых, и китайцы еще долгие годы не откажутся от него — потому что его юзать дешевле и проще (с точки зрения лицензирования кортексов), чем эти новомодные армы. И плюс — у них огромное, просто нереально огромное количество легаси кода и решений на нем.
Возьмите любую китайскую микросхему — если в ней есть процессорное ядро — вы вероятнее всего там найдете 8051.
Потому что есть куча его реализаций, не закрытых никакими NDA — бери и делай свои кристаллы.
Хотите я вам перечислю, где у вас 8051? Во всех флешках, во всех SD-картах, во всех хабах. В трансиверах для мышек и клавиатур.
«выпуск в дип8» это вообще несерьезно — там, куда пихают 8051, пихают бескорпусные версии. Он мог давно умереть для поделок на коленке, умереть как отдельный микроконтроллер, но как ядро спец микросхем он живее всех живых, и китайцы еще долгие годы не откажутся от него — потому что его юзать дешевле и проще (с точки зрения лицензирования кортексов), чем эти новомодные армы. И плюс — у них огромное, просто нереально огромное количество легаси кода и решений на нем.
Возьмите любую китайскую микросхему — если в ней есть процессорное ядро — вы вероятнее всего там найдете 8051.
Соглашусь с вами.
Выпуск ARM в DIP8 — это, скорее, популяризаторская мера на радость юным радиогубителям и другим любителям канифольного дыма, чтобы иметь возможность кочергой, нагретой в камине, распаять на макетке и попробовать Cortex. Причём, достаточно неплохая мера
Выпуск ARM в DIP8 — это, скорее, популяризаторская мера на радость юным радиогубителям и другим любителям канифольного дыма, чтобы иметь возможность кочергой, нагретой в камине, распаять на макетке и попробовать Cortex. Причём, достаточно неплохая мера
Да понятно, что во всех вчерашних устройствах, которые вокруг меня сегодня используется 8051. Речь то о том и идет, что ситуация меняется на глазах. Пока что в пресс-релизах вендоров, но завтра начнется реальная экспансия. Вот пример: я (как возможно и вы) слежу за беспроводными модулями. 2 последних попадавшихся: 1) XBee-PRO 900HP на Cortex M3 (и Energy Micro, а не эти всем приевшиеся ;-) ) + до селе невиданный трансивер; 2) Nordic так не попсует, и сует Cortex M0 прямо в чип в новой серии nRF51, вышедшей в замен старому nRF24LE1 на 8051 (был на презентации, так и подмывало спросить, что ж вы ядро 51 выкинули, а свою серию так и назвали, но как известно, все любят загадки и тайны).
Китайцы? Китайцы тоже меняются. Во-первых, им надо конкурировать друг с другом, а иметь лицензию на ARM, которой нет в соседнем селе, помогает. Кроме того, они забили на стену и продались продажному капитализму и тоже хотят выпускать инновационные продукты в красивых коробках с пресс-релизами.
Ну и ARM не зевает — не зря ж они на позапрошлогоднюю технологию (ARMv6) навесили новый ярлык «Cortex M0» (вместо того, чтобы забить и двигать новые архитектуры) — не иначе для того, чтобы былинно «сбрасывать с вертолета на всех желающих» ;-).
Китайцы? Китайцы тоже меняются. Во-первых, им надо конкурировать друг с другом, а иметь лицензию на ARM, которой нет в соседнем селе, помогает. Кроме того, они забили на стену и продались продажному капитализму и тоже хотят выпускать инновационные продукты в красивых коробках с пресс-релизами.
Ну и ARM не зевает — не зря ж они на позапрошлогоднюю технологию (ARMv6) навесили новый ярлык «Cortex M0» (вместо того, чтобы забить и двигать новые архитектуры) — не иначе для того, чтобы былинно «сбрасывать с вертолета на всех желающих» ;-).
Ого, вот про нордики это очень интересная новость, я с ними некоторое время плотно очень работал, интересно будет взглянуть на новые чипы.
Но вот насчет китайцев — имхо они очень, очень инертны в плане производства чипов — это же не просто софт переписать, это переделать все их кристаллы, думаю, они не скоро на это пойдут, в отличие от того же нордика, и во флешках, хабах и карточках мы еще долго не увидим кортексов.
То есть, рано или поздно, вероятно, это случится — но, вполне возможно, к тому моменты эти кортекс М0 станут как сейчас 8051, на пол пути на кладбище)
Но вот насчет китайцев — имхо они очень, очень инертны в плане производства чипов — это же не просто софт переписать, это переделать все их кристаллы, думаю, они не скоро на это пойдут, в отличие от того же нордика, и во флешках, хабах и карточках мы еще долго не увидим кортексов.
То есть, рано или поздно, вероятно, это случится — но, вполне возможно, к тому моменты эти кортекс М0 станут как сейчас 8051, на пол пути на кладбище)
Ах, да еще:
На ракульном 8051 асме, при том, что периферия все равно у каждого своя? Тогда чего уж удивляться, IT-приметам в духе «видеокамеру, диск, лучше подключать без хаба», или что эти хабы жрут по 100мА в idle ;-).
у них огромное, просто нереально огромное количество легаси кода и решений на нем
На ракульном 8051 асме, при том, что периферия все равно у каждого своя? Тогда чего уж удивляться, IT-приметам в духе «видеокамеру, диск, лучше подключать без хаба», или что эти хабы жрут по 100мА в idle ;-).
Для тех же флешек и СДшек не очень актуально «периферия у каждого своя», они у разных производителей иногда прямо как под копирку, только кодом различаются)
Хабы жрут, да, я сам с этим столкнулся, это адский ужас — втыкаешь пустой хаб, и на 500 мВт потребление повышается.
Но все же они не будут торопиться с переводом своего ширпотреба (то есть как раз тех микросхем что во флешках, карточках и хабах) на кортексы — они очень, очень много потеряют на производстве новой платформы — а именно — кристаллов и железки под них. В основном на кристаллах конечно.
Хабы жрут, да, я сам с этим столкнулся, это адский ужас — втыкаешь пустой хаб, и на 500 мВт потребление повышается.
Но все же они не будут торопиться с переводом своего ширпотреба (то есть как раз тех микросхем что во флешках, карточках и хабах) на кортексы — они очень, очень много потеряют на производстве новой платформы — а именно — кристаллов и железки под них. В основном на кристаллах конечно.
Вас, кстати, сейчас окружает огромное количество приборов с ядром 8051 внутри. Может, даже угадаете, где именно?)
Даже угадаю. Понятно, что на миллионных тиражах важно сэкономить даже цент.
Не только в этом дело, место для маломощных контроллеров все равно остается. И «хеллоу ворлд» часто целесообразно делать на контроллере без линукс. Великолепно идут гибридные решения, когда мелкий контроллер выступает как аппаратный контроллер какого-либо блока, хендля реалтайм, а логика более высокого уровня обрабатывается тяжеловесным, с линуксом. Допустим, собирает информацию с набора датчиков, предобрабатывает и формирует пакет для линуксовой платформы, или там генерит всякие шимы для управления сервами.
Вне всяких сомнений.
Мой комментарий был скорее о динозаврах, которые боятся двинуться дальше своих любимых восьми бит и надеются, что протянут на них до пенсии.
Мой комментарий был скорее о динозаврах, которые боятся двинуться дальше своих любимых восьми бит и надеются, что протянут на них до пенсии.
А, это да) Таких хватает.
Но, как правило, там где ценят эффективность решений, такие долго не протянут.
Если такой разработчик скажет что ему нужен год, чтобы разработать все необходимые драйверы периферии, свои стеки протоколов и т.п., в то время можно это реализовать на платформе с линуксом, где драйверы для периферии уже есть в наличии и обойтись неделей, то его, скорее всего, пошлют.
Не шлют там, где оплата гарантирована независимо от эффективности, то бишь, на большинстве государственных предприятий. Правда, я с тремя сталкивался (на одном лично работал) — там не доросли до 8-биток даже, везде пихают ПЛИСы (независимо от задачи), потому что там можно по учебникам 80х годов составлять схемы картинками И-НЕ, ИЛИ и прочих элементов — в отличие от программирования.
В итоге получаются адские монстры, на плате не хватает места, а все равно приходится выкидывать все что можно, но впихивать гигантскую ПЛИС.
Самое смешное было, когда места было мало, поставили мелкую ПЛИС, а «математика» в нее не лезла. При том что математика была простейшей, обычный ПИД. Так они половину навесили аналоговыми схемами снаружи, а ПЛИС тянула с нескольких АЦП сигналы и считала разности…
Но, как правило, там где ценят эффективность решений, такие долго не протянут.
Если такой разработчик скажет что ему нужен год, чтобы разработать все необходимые драйверы периферии, свои стеки протоколов и т.п., в то время можно это реализовать на платформе с линуксом, где драйверы для периферии уже есть в наличии и обойтись неделей, то его, скорее всего, пошлют.
Не шлют там, где оплата гарантирована независимо от эффективности, то бишь, на большинстве государственных предприятий. Правда, я с тремя сталкивался (на одном лично работал) — там не доросли до 8-биток даже, везде пихают ПЛИСы (независимо от задачи), потому что там можно по учебникам 80х годов составлять схемы картинками И-НЕ, ИЛИ и прочих элементов — в отличие от программирования.
В итоге получаются адские монстры, на плате не хватает места, а все равно приходится выкидывать все что можно, но впихивать гигантскую ПЛИС.
Самое смешное было, когда места было мало, поставили мелкую ПЛИС, а «математика» в нее не лезла. При том что математика была простейшей, обычный ПИД. Так они половину навесили аналоговыми схемами снаружи, а ПЛИС тянула с нескольких АЦП сигналы и считала разности…
Ну вот вам пример «Hello world». Сделайте контроллер обычной стиральной машины, с бонусным цветным экраном и выходом в интернет. Выберите проц, RAM к нему, потом ROM. Постучитесь в двери производителям, подаставайте документацию через NDA. Потом это все разведите слоев на 6, а то и на 8.
Ладно, платы готовы. Производитель SoC дал вам линукс, и вынаконец-то на питоне наваяли само приложение, которое машиной управляет.
А в это время, в соседней конторе, для этой же задачи взяли контроллер на базе Cortex-M3 с модулями LCD и Ethernet. Развели все на 4-х слоях. И написали софт на С.
Ресурсов на разработку потрачено меньше, результат получен быстрее, себестоимость изделия ниже, надежность выше.
Во втором случае, весь ваш код вам понятен и сопровождаем, в первом вам нужны дополнительнве специалисты, которые оценят то, что вам дал производитель чипа в виде Linux.
Я что хочу сказать, с точки зрения разработчика не все еще так шоколадно с SoC способными крутить Linux. Если задача решается за 10долл и месяц работы, нет смысла тратить 30долл и 3 месяца только ради того, чтобы крутить Linux.
Ладно, платы готовы. Производитель SoC дал вам линукс, и вынаконец-то на питоне наваяли само приложение, которое машиной управляет.
А в это время, в соседней конторе, для этой же задачи взяли контроллер на базе Cortex-M3 с модулями LCD и Ethernet. Развели все на 4-х слоях. И написали софт на С.
Ресурсов на разработку потрачено меньше, результат получен быстрее, себестоимость изделия ниже, надежность выше.
Во втором случае, весь ваш код вам понятен и сопровождаем, в первом вам нужны дополнительнве специалисты, которые оценят то, что вам дал производитель чипа в виде Linux.
Я что хочу сказать, с точки зрения разработчика не все еще так шоколадно с SoC способными крутить Linux. Если задача решается за 10долл и месяц работы, нет смысла тратить 30долл и 3 месяца только ради того, чтобы крутить Linux.
Не все процессоры находятся под жестким NDA, это больше относится к спец-SoC, типа тех, что в роутерах.
TI, например, открыто отдает свои доки на процессоры типа Sitara, вместе со схематикой их дев-бордов и прочим. На их основании сделать свою плату — не такое сложное дело. Кстати, есть и 4х-слойные платы с линуксом.
В соседней конторе будут трахаться со стеками протоколов и веб-сервером (иначе зачем там эзернет?), причем процесс ловли глюков, чтоб потом не отзывать свои машины, займет куда больше чем сама разработка.
Нет, если там только дисплейчик, да еще и знакосинтезирующий — отлично. Ну эзернет можно на каком-нибудь визинете прикрутить, ладно. Тогда основное будет — потрахаться с веб-сервером. Но по времени это займет не меньше, чем разработка линуксовой платформы, т.к. нужно только адаптировать схематику дев-борда и развести плату, с софтом проблем не будет после этого, ставите готовые сервера и радуетесь.
А вот если фирма делает что-то кроме однотипных машинок с дисплеем, то ей лучше пойти на разработку линуксовой платформы. Потому что описанные проблемы встают только в первый раз. После того, как платформу разработали, она может быть почти без изменения внедрена в остальные продукты, при этом набор софта может полностью отличаться, в отличие от случая с кортексом — к вашим услугам все репозитории с линуксом.
«весь ваш код вам понятен и сопровождаем» — не смешите, весь ваш код через месяц станет непролазными дебрями для ваших коллег, а через пол года — и для вас, потому что на кортексе вы при всем желании не сможете писать веб-сервер так же, как писали бы под линуксом. Кроме того, линуксовые сервера протестированы миллионы раз, а ваш будет кровоточить багами еще долгое время после написания. И как только вам понадобится сделать какой-нибудь стриминг видео для принципиально новой стиральной машинки, демонстрирующей процесс стирки на ее персональной веб-страничке, вы повеситесь на витой паре, потому что это надо будет писать с нуля, вместе с драйвером веб-камеры.
Не все так шоколадно, безусловно. Но и не так ужасно, как вы расписали. Если мы рассматриваем это все в масштабах фирмы, то фирме есть смысл один раз потратить некоторое время для выработки собственной базы решений. Когда у фирмы это решение будет хотя бы один раз внедрено, а у инженеров — получена соответствующая компетенция, их возможности расширятся на порядки и они уже смогут сильно сэкономить время и деньги там, где разработка на кортексе не имеет смысла.
TI, например, открыто отдает свои доки на процессоры типа Sitara, вместе со схематикой их дев-бордов и прочим. На их основании сделать свою плату — не такое сложное дело. Кстати, есть и 4х-слойные платы с линуксом.
В соседней конторе будут трахаться со стеками протоколов и веб-сервером (иначе зачем там эзернет?), причем процесс ловли глюков, чтоб потом не отзывать свои машины, займет куда больше чем сама разработка.
Нет, если там только дисплейчик, да еще и знакосинтезирующий — отлично. Ну эзернет можно на каком-нибудь визинете прикрутить, ладно. Тогда основное будет — потрахаться с веб-сервером. Но по времени это займет не меньше, чем разработка линуксовой платформы, т.к. нужно только адаптировать схематику дев-борда и развести плату, с софтом проблем не будет после этого, ставите готовые сервера и радуетесь.
А вот если фирма делает что-то кроме однотипных машинок с дисплеем, то ей лучше пойти на разработку линуксовой платформы. Потому что описанные проблемы встают только в первый раз. После того, как платформу разработали, она может быть почти без изменения внедрена в остальные продукты, при этом набор софта может полностью отличаться, в отличие от случая с кортексом — к вашим услугам все репозитории с линуксом.
«весь ваш код вам понятен и сопровождаем» — не смешите, весь ваш код через месяц станет непролазными дебрями для ваших коллег, а через пол года — и для вас, потому что на кортексе вы при всем желании не сможете писать веб-сервер так же, как писали бы под линуксом. Кроме того, линуксовые сервера протестированы миллионы раз, а ваш будет кровоточить багами еще долгое время после написания. И как только вам понадобится сделать какой-нибудь стриминг видео для принципиально новой стиральной машинки, демонстрирующей процесс стирки на ее персональной веб-страничке, вы повеситесь на витой паре, потому что это надо будет писать с нуля, вместе с драйвером веб-камеры.
Не все так шоколадно, безусловно. Но и не так ужасно, как вы расписали. Если мы рассматриваем это все в масштабах фирмы, то фирме есть смысл один раз потратить некоторое время для выработки собственной базы решений. Когда у фирмы это решение будет хотя бы один раз внедрено, а у инженеров — получена соответствующая компетенция, их возможности расширятся на порядки и они уже смогут сильно сэкономить время и деньги там, где разработка на кортексе не имеет смысла.
Абсолютно не понятно о чем вы говорите. Я написал для примера конкретную задачу, контролер стиральной машины, вы действительно считаете, что его целесообразней делать используя систему которая исполняет Linux?
Я делал плату которая запускала Linux и на 2-х слоях, но это не значит, что такое решение целесообразно для промышленого производства.
Все что вы написали — это борьба для запуска линукса только ради линукса.
На данный момент, есть несколько применений, когда Linux платформа, по моему мнению, необходима. Это всякого рода стриминги видео, аудио, полномосштабная работа с сетью. В этом случае, безспорно, нужно ориентироваться на Linux основаные архитектуры.
Решать абсолютно любую задачу используя Linux на данный момент крайне не эффективно.
Я делал плату которая запускала Linux и на 2-х слоях, но это не значит, что такое решение целесообразно для промышленого производства.
Все что вы написали — это борьба для запуска линукса только ради линукса.
На данный момент, есть несколько применений, когда Linux платформа, по моему мнению, необходима. Это всякого рода стриминги видео, аудио, полномосштабная работа с сетью. В этом случае, безспорно, нужно ориентироваться на Linux основаные архитектуры.
Решать абсолютно любую задачу используя Linux на данный момент крайне не эффективно.
и второй момент.
Вы говорите, что Linux можно развести на 4 слоя. Можно, но это будет по прежнему связка из CPU+RAM+ROM.
Неужели это такой необходимый минимум, чтобы постирать белье или сварить кофе?
Надежность системы же резко падает по сравнению с простым MCU.
Вы говорите, что Linux можно развести на 4 слоя. Можно, но это будет по прежнему связка из CPU+RAM+ROM.
Неужели это такой необходимый минимум, чтобы постирать белье или сварить кофе?
Надежность системы же резко падает по сравнению с простым MCU.
Зачем «чтобы постирать белье или сварить кофе» вам понадобился эзернет?
Вы упоминаете эзернет в стиральной машине — из этого я решил, что это не конкретная задача а абстрактный пример, попадающий под ваш пункт «полномосштабная работа с сетью».
И кто говорит «решать абсолютно любую задачу, используя линукс»?
Я говорю что решать абсолютно любую задачу используя только кортексы не менее неэффективно, нужно видеть границы применимости и не пытаться на хилых кортексах воспроизвести все драйверы и стеки протоколов, которые уже давно есть в линуксе.
Вы упоминаете эзернет в стиральной машине — из этого я решил, что это не конкретная задача а абстрактный пример, попадающий под ваш пункт «полномосштабная работа с сетью».
И кто говорит «решать абсолютно любую задачу, используя линукс»?
Я говорю что решать абсолютно любую задачу используя только кортексы не менее неэффективно, нужно видеть границы применимости и не пытаться на хилых кортексах воспроизвести все драйверы и стеки протоколов, которые уже давно есть в линуксе.
Когда-то, в древние стародавние времена, когда изобрели лампы, все говорили, что реле отомрут. Потом изобрели диоды и транзисторы, и предписывали скорую кончину для ламп. Затем появились простейшие микросхемы логики, и начали говорить, что конечно же, транзисторы теперь не нужны. Затем появились CPLD, FPGA, но почему-то логика никуда не делась. Потом появились мощные процессоры, микроконтроллеры, но по-прежнему осталась как и обычная логика, так и транзисторы, и даже лампы еще кому-то нужны. Теперь вот подешевели SoC и стали доступны встраиваемые системы на базе Linux, давайте забудем про микроконтроллеры?
По логике «вымирать» микроконтроллерам еще очень и очень долго.
По логике «вымирать» микроконтроллерам еще очень и очень долго.
Печально, что в технику идёт столько быдла, которое кроме писькомерства ничего не понимает.
Для серьезного промышленного производства пока аналогов простым микроконтроллерам, без всяких ардуин ещё нет. А используются они много где. Ардуины это пока для домашнего применения больше, а уж МК на линуксе и тем более.
>Ардуины это пока для домашнего применения больше, а уж МК на линуксе и тем более.
Вы или написали не то, что собирались, или очень серьезно ошибаетесь.
В подавляющем большинстве электроники, которая вас окружает, процессор, выполняющий ту или иную разновидность линукса.
Во всех роутерах, в мобильных телефонах (там где не линукс, там не менее тяжеловесная ОС), во всяких планшетах, терминалах и прочем.
У них другая ниша, они и не должны «вытеснять» микроконтроллеры.
Вы или написали не то, что собирались, или очень серьезно ошибаетесь.
В подавляющем большинстве электроники, которая вас окружает, процессор, выполняющий ту или иную разновидность линукса.
Во всех роутерах, в мобильных телефонах (там где не линукс, там не менее тяжеловесная ОС), во всяких планшетах, терминалах и прочем.
У них другая ниша, они и не должны «вытеснять» микроконтроллеры.
Представил себе свой квадрокоптер под управлением Raspberry Pi. Не-не-не-не-не.
а между тем, их делают уже: www.youtube.com/watch?feature=player_embedded&v=uV1ikae9QP0
UFO just landed and posted this here
Sign up to leave a comment.
[Перевод] Микроконтроллеры устарели?