Комментарии 78
Неплохое введение для какой-нибудь курсовой работы.
По правописанию — автор, смотри переписку…
По правописанию — автор, смотри переписку…
А разве IAR кроссплатформенный?
Насколько мне известно, он выпущен только под Windows. Или я ошибаюсь?
Насколько мне известно, он выпущен только под Windows. Или я ошибаюсь?
Очевидно автор имел ввиду что IAR имеет множество компиляторов под разные архитектуры микроконтроллеров.
Да именно это я имел ввиду.
Посмотрите здесь на колонку слева. Где вы еще такое найдете?
Как я писал выше это затягивает (-:
Посмотрите здесь на колонку слева. Где вы еще такое найдете?
Как я писал выше это затягивает (-:
Отладка есть и без IAR. Например, для AVR: avr.ru/tools/linux/debug
Конечно, есть. Только какую отладку вы имеете ввиду? JTAG-отладку?
Она есть в:
AVR Studio (один старый программист из Ростова говорил что ей «мозгов не хватает» в отличии от IAR, отладчик он использовал JTAGICE3)
Code Composer Studio (дипломную работу на MSP430 писал в ней, отладчик использовал MSP-FET430UIF- неубиваемая вещь)
E-LAB (делал в ней хобби-проекты для AVR, один мой коллега в ней небольшие рабочие проекты делает, у него и JTAG есть-редкая штука)
HEW (фирменная среда для микроконтроллеров Renesas, в частности для семейство Renesas RX, JTAG-отладчик Renesas E1, использовали до появления семейства STM32F4xx)
и т.д.
Только для каждого нового семейства вам придется изучать новую среду разработки и ее особенности.
А так язык C, как первая кроссплатформенная дверь, и IAR, как вторая (особенно для ARM), открывают вам дорогу ко множеству семейств микроконтроллеров.
Она есть в:
AVR Studio (один старый программист из Ростова говорил что ей «мозгов не хватает» в отличии от IAR, отладчик он использовал JTAGICE3)
Code Composer Studio (дипломную работу на MSP430 писал в ней, отладчик использовал MSP-FET430UIF- неубиваемая вещь)
E-LAB (делал в ней хобби-проекты для AVR, один мой коллега в ней небольшие рабочие проекты делает, у него и JTAG есть-редкая штука)
HEW (фирменная среда для микроконтроллеров Renesas, в частности для семейство Renesas RX, JTAG-отладчик Renesas E1, использовали до появления семейства STM32F4xx)
и т.д.
Только для каждого нового семейства вам придется изучать новую среду разработки и ее особенности.
А так язык C, как первая кроссплатформенная дверь, и IAR, как вторая (особенно для ARM), открывают вам дорогу ко множеству семейств микроконтроллеров.
Я вообще на gdb пытался мягко намекнуть. Который… Немного шире распространен, чем IAR. И open source. Не знаю как для вас, а для меня это важно.
По поводу open source свое мнение я ниже Eddy_Em написал.
Если кратко вы пользуетесь менее удобным продуктом, а платите собственным тестированием.
Если продукт менее удобен. А время на разработку увеличивается.
Какой в этом смысл? Если деньги есть. Только «религиозный».
Если кратко вы пользуетесь менее удобным продуктом, а платите собственным тестированием.
Если продукт менее удобен. А время на разработку увеличивается.
Какой в этом смысл? Если деньги есть. Только «религиозный».
У нас на работе коллеги используют IAR, а наш отдел — свободные инструменты. Возможно, ключевое значение в скорости разработки играет различие методик, которые мы используем, но у нас получается быстрее. А в случае с IAR коллегам минимум дважды удавалось обнаружить баги в кодогенерации, которые средствами IAR не ловились (емнип, неверное представление float как в памяти контроллера, так и в отладочном выводе, точнее не скажу).
То, что вы говорите это отлично. Это лучший вариант, когда используются разные инструменты.
Отлично, что вы основываетесь на своем опыте и на проведенной работе.
Возможно дело в вас. И вы лучше справляетесь, чем они.
А вы сами работали в IAR?
И перемещались с одного семейства на другое?
Какие проекты на каких МК делаете?
Какие связки инструментов используете?
Какой у вас субъективный опыт и к каким подходом он привел?
Отлично, что вы основываетесь на своем опыте и на проведенной работе.
Возможно, ключевое значение в скорости разработки играет различие методик, которые мы используем, но у нас получается быстрее.
Возможно дело в вас. И вы лучше справляетесь, чем они.
А вы сами работали в IAR?
И перемещались с одного семейства на другое?
Какие проекты на каких МК делаете?
Какие связки инструментов используете?
Какой у вас субъективный опыт и к каким подходом он привел?
Да, работал в IAR с AVR, STM32F и некоторыми другими ARM. С одного семейства на другое проекты перемещать не приходилось, но, например, я переносил интерпретатор basic с ANSI C на AVR — проблем вообще никаких не было. К сожалению (или к счастью) использование Windows вызывает у меня неприятное ощущение дискомфорта; мне удобнее работать в консоли, чем пользоваться мышью.
Сейчас мы работаем как с контроллерами на ARM, так и с контроллерами на embedded x86 (*смайл с высунутым языком*). Железки у нас «мощнячие». Используем открытые кросс-платформенные решения; платформенно-зависимого кода буквально два экрана. Используем исключительно свободное ПО.
Сейчас мы работаем как с контроллерами на ARM, так и с контроллерами на embedded x86 (*смайл с высунутым языком*). Железки у нас «мощнячие». Используем открытые кросс-платформенные решения; платформенно-зависимого кода буквально два экрана. Используем исключительно свободное ПО.
Сейчас мы работаем как с контроллерами на ARM
контроллерами на embedded x86
Не понятен класс устройств. Что-то похожее на это.
Расскажите поподробней, пожалуйста.
Используем открытые кросс-платформенные решения; платформенно-зависимого кода буквально два экрана. Используем исключительно свободное ПО.
Вот сейчас в чем конкретно работаете, в какой среде? Или это военная тайна?
Что-то похожее, только на x86. Огромное количество периферии, плюс большие требования к аналитике на стороне контроллера и позитивная позиция «нужно оставить задел для развития».
Конкретно сейчас мои основные инструменты — это zsh+emacs+gcc+gdb+python в консоли, и Geany IDE, объединяющая всё это в GUI.
Конкретно сейчас мои основные инструменты — это zsh+emacs+gcc+gdb+python в консоли, и Geany IDE, объединяющая всё это в GUI.
Для такого класса устройств я бы тоже использовал Linux.
Я подходил однажды к этому, ядро было ARM9. Постучался в эту дверь (-:
Но потом вернулся обратно к менее мощным «друзьям». Где до сих пор и пребываю.
А вели ли вы разработку ПО для микроконтроллеров на ядрах ARM7,Cortex-M0,Cortex-M3,Cortex-M4?
Я подходил однажды к этому, ядро было ARM9. Постучался в эту дверь (-:
Но потом вернулся обратно к менее мощным «друзьям». Где до сих пор и пребываю.
А вели ли вы разработку ПО для микроконтроллеров на ядрах ARM7,Cortex-M0,Cortex-M3,Cortex-M4?
Мне вот всегда интересно было каким образом джедаи используют все эти JTAG отладчики? Можете поделиться реальным примером где он полезен?
У меня во всех проектах так получается, что работа МК завязана на внешние шины передачи данных или иные устройства, с которыми происходит общение. И если поставить любой брэйкпойнт, то работа МК либо полностью теряет смысл, либо что еще более забавно — глюк перестает воспроизводиться, т.к. появляется лишняя временнАя задержка, которая устраняет баг ))
И для наблюдения за этими динамическими процессами как-то больше подходит лог.анализатор, чтобы вывести на определенные ножки МК состояние и наблюдать в динамике за тем как они ведут себя. Радость же от обладания отладчиком я так и не смог вкусить.
У меня во всех проектах так получается, что работа МК завязана на внешние шины передачи данных или иные устройства, с которыми происходит общение. И если поставить любой брэйкпойнт, то работа МК либо полностью теряет смысл, либо что еще более забавно — глюк перестает воспроизводиться, т.к. появляется лишняя временнАя задержка, которая устраняет баг ))
И для наблюдения за этими динамическими процессами как-то больше подходит лог.анализатор, чтобы вывести на определенные ножки МК состояние и наблюдать в динамике за тем как они ведут себя. Радость же от обладания отладчиком я так и не смог вкусить.
Можно хоть глобальные переменные просматривать «типа на лету», да и иногда шагание по строчкам тоже бывает полезным, в том числе и для обнаружения, что временные задержки избавляют от бага. Просмотр регистров при инициализации новой для себя периферии тоже очень полезен.
Но конечно лог анализатор это вещь без которой сложно, хорошо если он и протоколы сам расшифровывает.
Но конечно лог анализатор это вещь без которой сложно, хорошо если он и протоколы сам расшифровывает.
+1
Всегда пользовался светодиодом в качестве «дебаггера»
Всегда пользовался светодиодом в качестве «дебаггера»
Так, не поверите, и я пользуюсь. И осциллографом пользуюсь тоже.
Для отладки есть штуки и лучше светодиода :)
www.saleae.com
www.saleae.com
Лучшая отладка — терминал, HIPERтерминал.
Очень сомнительно, вот ее сложнее всего сделать non-intrusive, вообще лучшая отладка это умение пользоваться трейсом и дорогущий трейс-отладчик, да и чем больше средств тем лучше имхо.
Да и терминальными программами тоже бывает.
Ага, камень шарашит на 168 МГц, а мы в терминал неспеша пописываем отладочную информацию на 115200
Производители ОСРВ Micrium, которые годами разрабатывали ОСРВ для МК, тогда тоже не правы.
Вот здесь есть пример проекта для семейства STM32F4xx (отладочная плата STM3240G-Eval).
В проекте присутствует библиотека uC-Serial, которая обеспечивает возможность терминальной отладки проекта.
Библиотека Micrium uC/Probe тоже может работать по UART с роковой скоростью 115200.
Вот здесь есть пример проекта для семейства STM32F4xx (отладочная плата STM3240G-Eval).
В проекте присутствует библиотека uC-Serial, которая обеспечивает возможность терминальной отладки проекта.
Библиотека Micrium uC/Probe тоже может работать по UART с роковой скоростью 115200.
Никто не говорит, что терминал — плохо. Есть ряд случаев, когда терминал без ужимок и прыжков не работает. Например прерывания — далеко не всегда удается успевать скинуть в терминал данные.
Я молчу про то, что когда появилась дуня, народ в обработчиках прерываний начал слать данные в сериал на дефолтных 9600
Я молчу про то, что когда появилась дуня, народ в обработчиках прерываний начал слать данные в сериал на дефолтных 9600
За деревьями леса не видно? (-:
Ваши проекты это не все многообразие проектов на МК.
Возможно в ваших задачах это и не нужно.
JTAG-отладчик важный инструмент отладки проектов и, конечно, не единственный.
Все микроконтроллеры, с которыми я работал, имели внутри модуль JTAG.
Вы хотите сказать, что такие производители МК и сред разработки для МК как Texas Instruments, Analog Devices, STMicroelectronics,
Renesas Electronics Corporation заблуждаются?
Вы хотите сказать, что создатели кроссплатформенной среды IAR Systems тоже заблуждаются? И зря для каждого семейства делают поддержку всех возможных для него JTAG-отладчиков? И зря делают плагины для JTAG-отладки под самыми известными ОСРВ (FreeRTOS, µC/OS-II и т.д.)
Вы хотите сказать что все люди, с которыми я работал и которые делают крупные проекты для частных компаний и государства тоже идут не по верному пути?
Я во всех проектах использовал JTAG-отладку. И использовал ее с такими популярными в мире МК интерфейсами, как SPI, I2C,UART и производными от него HART, RS-485, RS-232. При работе с Ethernet. С внешними АЦП, ЦАП, памятью, аналоговыми и цифровыми датчиками, GPS-модулями.
При работе с сложными математическими библиотеками. При отладке проектов под управлением ОСРВ (embOS, µC/OS-II, FreeRTOS).
Сама эволюция разработки программ для вычислительной технике идет по пути упрощения этого процесса.
Раньше ЭВМ были огромными и отладки не было никакой. Пришел с перфокартами, вставил.
Результат тебе она выдала. Неправильный? Сиди думай. Никакой отладки.
Сейчас любая среда разработки для ПК имеет отладчик. Это теперь не неотъемлемая часть процесса разработки.
И попробуй у современного программиста на C# отбери возможность отладки. Он без нее не сможет.
Тоже самое постепенно происходило и с микроЭВМ. Вычислительные возможности выросли. Проекты усложнились.
Стали представлять из себя многозадачные приложения, которые обрабатывают много информации сложным образом.
И потребовались методы отладки таких сложных приложений. Один из таких методов интерфейс JTAG.
Он по образу и подобию обеспечивает функции отладки такие же, как отладчик для разработки ПО высокого уровня.
Вычислительные мощности МК выросли, проекты усложнились, методы проектирования и отладки подтянулись.
Это эволюция. Очевидно же.
Ваши проекты это не все многообразие проектов на МК.
Возможно в ваших задачах это и не нужно.
JTAG-отладчик важный инструмент отладки проектов и, конечно, не единственный.
Все микроконтроллеры, с которыми я работал, имели внутри модуль JTAG.
Вы хотите сказать, что такие производители МК и сред разработки для МК как Texas Instruments, Analog Devices, STMicroelectronics,
Renesas Electronics Corporation заблуждаются?
Вы хотите сказать, что создатели кроссплатформенной среды IAR Systems тоже заблуждаются? И зря для каждого семейства делают поддержку всех возможных для него JTAG-отладчиков? И зря делают плагины для JTAG-отладки под самыми известными ОСРВ (FreeRTOS, µC/OS-II и т.д.)
Вы хотите сказать что все люди, с которыми я работал и которые делают крупные проекты для частных компаний и государства тоже идут не по верному пути?
Я во всех проектах использовал JTAG-отладку. И использовал ее с такими популярными в мире МК интерфейсами, как SPI, I2C,UART и производными от него HART, RS-485, RS-232. При работе с Ethernet. С внешними АЦП, ЦАП, памятью, аналоговыми и цифровыми датчиками, GPS-модулями.
При работе с сложными математическими библиотеками. При отладке проектов под управлением ОСРВ (embOS, µC/OS-II, FreeRTOS).
Сама эволюция разработки программ для вычислительной технике идет по пути упрощения этого процесса.
Раньше ЭВМ были огромными и отладки не было никакой. Пришел с перфокартами, вставил.
Результат тебе она выдала. Неправильный? Сиди думай. Никакой отладки.
Сейчас любая среда разработки для ПК имеет отладчик. Это теперь не неотъемлемая часть процесса разработки.
И попробуй у современного программиста на C# отбери возможность отладки. Он без нее не сможет.
Тоже самое постепенно происходило и с микроЭВМ. Вычислительные возможности выросли. Проекты усложнились.
Стали представлять из себя многозадачные приложения, которые обрабатывают много информации сложным образом.
И потребовались методы отладки таких сложных приложений. Один из таких методов интерфейс JTAG.
Он по образу и подобию обеспечивает функции отладки такие же, как отладчик для разработки ПО высокого уровня.
Вычислительные мощности МК выросли, проекты усложнились, методы проектирования и отладки подтянулись.
Это эволюция. Очевидно же.
Ок, я ведь всего-лишь спросил про конкретные примеры на практике, я разве утверждал что отладчик не нужен?
JTAG это не преимущество контроллеров, а необходимость. Изначально JTAG не использовался в отладке, он использовался чтобы иметь возможность тестировать «многоножки» прямо на пластине, где есть только контактные площадки размером с микрон и вести туда сотню контактов для отбраковки будущих кристаллов было расточительством. Вот и придумали такой интерфейс при помощи которого можно было бы быстро протестировать внутренности микросхем и их выходные драйверы не подключаясь к ним. Это потом уже подумали что неплохо бы этот интерфейс использовать для отладки, ибо удобно. Так что JTAG это суровая необходимость производства а не отладки. JTAG по сути есть не только в микроконтроллерах, а и в подавляющем большинстве специализированных микросхем вроде драйверов ЖК матриц.
JTAG это не преимущество контроллеров
Я говорил выше, что это инструмент отладки. Причем здесь вообще слово «преимущество»?
Перед чем преимущество? Перед схемами на логике?
Изначально JTAG не использовался в отладке
И что? А теперь используется в большинстве семейств МК, как отладочный иструмент.
Это вы решили ретроспективу внести?
Так и ЭВМ были раньше огромными шкафами и управлялись машинными кодами.
И предназначались для решения дифференциальных уравнений.
А задачу МК выполнял набор цифоровых логических схем.
И чего?
Так что JTAG это суровая необходимость производства
Посмотрите на семейство AVR Atmega.
У Atmega8 нет JTAG, потому что мало памяти, мало выводов у МК.
Большую программу не создашь нечего отлаживать.
Нужно экономить выводы, следовательно JTAG здесь роскошь.
У Atmega16 есть JTAG, потому больше памяти, больше выводов у МК.
Можно создать программу побольше, есть что отлаживать.
Хоть выводов и не очень много, но можно пожертвовать часть на JTAG.
Где здесь суровая необходимость?
Скорее целевое назначение МК. Объем памяти, кол-во выводов.
Оцените внимательно.
Необходимость при производстве. Думаю, что на кристалле JTAG есть, но его выводы не выведены наружу. В конце концов, отладка на ATMEGA8 есть, значит и есть внутренний доступ ко всем регистрам — это считай 90% реализованного JTAG. Вероятно, внутри на кристалле есть площадки под JTAG но используется он только автоматом еще до того как кристалл попадет в корпус. А может быть, такие малоножки выгодней тестировать уже в корпусе путем выполнения тестовой прошивки с контролем внешних сигналов. Вот с 40+ выводных микросхем дешевле тестировать через JTAG. А отладка… это побочная функция интерфейса. Ну да, оказалась настолько востребованой что о главной функции и не вспоминают, да и для потребителя она не нужна.
Я вашу мысль понял. История вопроса ясна.
Но выше, если вы внимательно прочтете выше велась речь именно о «побочной функции».
И для любого программиста МК — это «побочная функция» осязаема в виде дополнительных возможностей по отладке.
А «основная функция» никак не осязаема при программировании МК.
Для меня «побочная функция» было и будет основной при программировании МК.
Помните, что мы в разделе «Программинг микроконтроллеров» находимся?
А вы похоже в разделе «Производство микросхем» (-:
Но выше, если вы внимательно прочтете выше велась речь именно о «побочной функции».
И для любого программиста МК — это «побочная функция» осязаема в виде дополнительных возможностей по отладке.
А «основная функция» никак не осязаема при программировании МК.
Для меня «побочная функция» было и будет основной при программировании МК.
Помните, что мы в разделе «Программинг микроконтроллеров» находимся?
А вы похоже в разделе «Производство микросхем» (-:
Очень часто нужно даже в хобби, примеры (для STM32)
1. Посмотреть, какие на какие частоты настроена периферия. Тормозишь после инициализации и смотришь переменные клоков
2. Проверить, что в реальности сыпется в УАРТ. Тормозишь после отправки данных и смотришь содержимое буфера.
3. Проследить работу периферии (например, работа с энкодером: каунтер в зависимости от настроек может инкрементить на 1, 2 или 4 и при бедноте документации возможность заглянуть в железо бесценна)
4. Пошагать по коду, поймать место, где камень падает в хардфолт
Ну и т.д.
1. Посмотреть, какие на какие частоты настроена периферия. Тормозишь после инициализации и смотришь переменные клоков
2. Проверить, что в реальности сыпется в УАРТ. Тормозишь после отправки данных и смотришь содержимое буфера.
3. Проследить работу периферии (например, работа с энкодером: каунтер в зависимости от настроек может инкрементить на 1, 2 или 4 и при бедноте документации возможность заглянуть в железо бесценна)
4. Пошагать по коду, поймать место, где камень падает в хардфолт
Ну и т.д.
Главным недостатком AVR является слабое вычислительное ядро без вспомогательных математических блоков...Это не совсем так, есть аппаратная поддержка умножения, ключевые слова для поиска: "AVR201: использование аппаратного перемножителя AVR".
Нету? )-:Чего нету?.. Этот самый великий и ужасный «Hardware Multiplier» на платформе MSP430 ничем принципиально не отличается от аппаратного перемножителя AVR, разве что поддерживает операции 16X16, и носит гордое название «Hardware Multiplier».
Вы меня процитировали:
Здесь я говорю вычислительном ядре и вспомогательном блоке(!!!).
Вы даете ссылку даже не на документацию от производителя, где говорится про умножитель в составе ядра(!!!), а не отдельный блок.
Процессов обращается к нему через регистры, как к периферийному устройству.
Видимо блочные диаграммы вы не смотрели. Хорошо, вырежу картинки.
MSP430F169
Atmega16
Не видите разницы? Будете спорить с инженерами, которые создали эти микроконтроллеры?
Главным недостатком AVR является слабое вычислительное ядро без вспомогательных математических блоков...
Здесь я говорю вычислительном ядре и вспомогательном блоке(!!!).
Вы даете ссылку даже не на документацию от производителя, где говорится про умножитель в составе ядра(!!!), а не отдельный блок.
Процессов обращается к нему через регистры, как к периферийному устройству.
Видимо блочные диаграммы вы не смотрели. Хорошо, вырежу картинки.
MSP430F169
Atmega16
Не видите разницы? Будете спорить с инженерами, которые создали эти микроконтроллеры?
Повторяю еще раз, для тех кто в танке: Ваша фраза "… недостатком AVR является слабое вычислительное ядро без вспомогательных математических блоков ..." говорит о неких недостатках AVR применительно к вычислениям. Однако Hardware Multiplier платформы MSP430, судя по даташитам, по функциям аналогичен аппаратному перемножителю, встроенному в AVR. Следовательно говорить о том, что платформа AVR чего-то не имеет, а ядро MSP430 что-то имеет — пустая болтология.
"Не видите разницы?" Нет, не вижу! Я так понял, для Вас важны картинки, блоки, нарисованный большими буквами шрифт и красивые звучные термины? То, что вложили в функционал инженеры, которые создали эти контроллеры, Вас совсем не интересует? Сочувствую…
"Не видите разницы?" Нет, не вижу! Я так понял, для Вас важны картинки, блоки, нарисованный большими буквами шрифт и красивые звучные термины? То, что вложили в функционал инженеры, которые создали эти контроллеры, Вас совсем не интересует? Сочувствую…
Да вы злитесь (-:
Если я в танке, то вы в броневике (-:
Давайте разберем детально мою фразу:
Вы тут видите что-то свое. И так разобьем на две части:
Ядро AVR действительно слабое. Но опять же это мое субъективное мнение. Оно сформировано тем,
что микроконтроллеры AVR самые слабые микроконтроллеры для решения математических задач,
с которыми я работал. Вот пример сравнительного теста из книги «Семейство микроконтроллеров MSP430. Рекомендации по применению»:
Если хотите узнать детали тестирования, прочтите одну главу этой книги.
А тут по поводу аппаратного умножителя:
Дополнительных для процессора математических блоков в AVR действительно нет.
Нет ни Hardware Multiplier, ни FPU.
Для процессора это «родная» команда, которая работает с регистрами общего назначения:
У MSP30F16x это внешний для процессора периферийный блок, который имеет
свои собственные регистры:
Это информация из книг от производителя и даташитов дополняет блочные диаграммы выше.
Из тех МК, с которыми я работал, они самые математически слабые. Что здесь плохого?
Если бы я до этого работал c MCS51, они мне показались бы «титанами».
Функции и структура системы не одно и тоже.
Структура системы у них разная. Это очевидно. Из документации.
Функции эффективней выполняет MSP430, как связка процессора внешнего периферийного блока.
Она имеет слабую производительность и не имеет внешних для процессора математических блоков направленных на решение математических задач.
Вы ссылаетесь только на собственное мнение.
И не анализируете документацию, которую для вас писали инженеры.
На пустую болтовню похожи больше ваши заявления.
Это плохо. Я даже красным отметил.
Это мой способ передать информацию. Но вам это не помогло похоже (-:
Как раз наоборот. А вот вас только ваше мнение.
В чем? У меня все отлично (-:
для тех кто в танке
Если я в танке, то вы в броневике (-:
Давайте разберем детально мою фразу:
недостатком AVR является слабое вычислительное ядро без вспомогательных математических блоков
Вы тут видите что-то свое. И так разобьем на две части:
недостатком AVR является слабое вычислительное ядро
Ядро AVR действительно слабое. Но опять же это мое субъективное мнение. Оно сформировано тем,
что микроконтроллеры AVR самые слабые микроконтроллеры для решения математических задач,
с которыми я работал. Вот пример сравнительного теста из книги «Семейство микроконтроллеров MSP430. Рекомендации по применению»:
Если хотите узнать детали тестирования, прочтите одну главу этой книги.
А тут по поводу аппаратного умножителя:
без вспомогательных математических блоков
Дополнительных для процессора математических блоков в AVR действительно нет.
Нет ни Hardware Multiplier, ни FPU.
Для процессора это «родная» команда, которая работает с регистрами общего назначения:
У MSP30F16x это внешний для процессора периферийный блок, который имеет
свои собственные регистры:
Это информация из книг от производителя и даташитов дополняет блочные диаграммы выше.
говорит о неких недостатках AVR применительно к вычислениям
Из тех МК, с которыми я работал, они самые математически слабые. Что здесь плохого?
Если бы я до этого работал c MCS51, они мне показались бы «титанами».
Однако Hardware Multiplier платформы MSP430, судя по даташитам, по функциям аналогичен аппаратному перемножителю, встроенному в AVR.
Функции и структура системы не одно и тоже.
Структура системы у них разная. Это очевидно. Из документации.
Функции эффективней выполняет MSP430, как связка процессора внешнего периферийного блока.
платформа AVR чего-то не имеет, а ядро MSP430
Она имеет слабую производительность и не имеет внешних для процессора математических блоков направленных на решение математических задач.
пустая болтология.
Вы ссылаетесь только на собственное мнение.
И не анализируете документацию, которую для вас писали инженеры.
На пустую болтовню похожи больше ваши заявления.
«Не видите разницы?» Нет, не вижу!
Это плохо. Я даже красным отметил.
Я так понял, для Вас важны картинки, блоки, нарисованный большими буквами шрифт и красивые звучные термины?
Это мой способ передать информацию. Но вам это не помогло похоже (-:
То, что вложили в функционал инженеры, которые создали эти контроллеры, Вас совсем не интересует?
Как раз наоборот. А вот вас только ваше мнение.
Сочувствую
В чем? У меня все отлично (-:
"Где он? Нету..." Если обведете красным кружком ALU на блок-схеме ядра AVR, то Вы собственно и получите Hardware Multiplier. Не видите? А он там есть.
Не получу. Структура систем разная. Системы работают по разному.
Ну пересекаются по функциям, но работаю по разному.
И эффективность решения функций разная.
Пытаетесь сделать подмену понятий постоянно.
Ну пересекаются по функциям, но работаю по разному.
И эффективность решения функций разная.
Пытаетесь сделать подмену понятий постоянно.
Слова «hardware multipier» не накладывают ограничения на то, где этот блок расположен, в АЛУ или вне него.
То что в данном случае он вне него расположен на суть никак не влияет, просто в данном конкретном случае этот блок поддерживает больше команд, чем встроенный в AVR (умножение с накоплением, аппаратное 16-битное умножение) и все.
То что в данном случае он вне него расположен на суть никак не влияет, просто в данном конкретном случае этот блок поддерживает больше команд, чем встроенный в AVR (умножение с накоплением, аппаратное 16-битное умножение) и все.
Вы точно читали то что я выше написал?
Прочтите, пожалуйста.
Тоже хотите сделать подмену понятий?
У рассмотренных выше микроконтроллеров разная внутренняя структура.
Смотрите схемы выше.
Слово «hardware multipier» это вербальное описание того, что у MSP430 есть дополнительный внешний для процессора периферийный блок, к которому процессор обращается через регистры.
Функциональная диаграмма блоков МК в даташите подтверждают это.
Это накладывает ограничение на то где этот блок расположен.
При программирование на ассемблере обращение к нему будет разным.
Про какую суть вы говорите?
Суть в разности структур двух систем.
То что две системы пересекаются по функциям.
Не делает их одинаковыми.
Прочтите, пожалуйста.
Слова «hardware multipier» не накладывают ограничения на то, где этот блок расположен, в АЛУ или вне него.
Тоже хотите сделать подмену понятий?
У рассмотренных выше микроконтроллеров разная внутренняя структура.
Смотрите схемы выше.
Слово «hardware multipier» это вербальное описание того, что у MSP430 есть дополнительный внешний для процессора периферийный блок, к которому процессор обращается через регистры.
Функциональная диаграмма блоков МК в даташите подтверждают это.
Это накладывает ограничение на то где этот блок расположен.
При программирование на ассемблере обращение к нему будет разным.
на суть никак не влияет
Про какую суть вы говорите?
Суть в разности структур двух систем.
То что две системы пересекаются по функциям.
Не делает их одинаковыми.
>Слово «hardware multipier» это вербальное описание того, что у MSP430 есть дополнительный внешний для процессора периферийный блок, к которому процессор обращается через регистры.
Слова «hardware multipier» это вербальное описание того, что в составе кристалла, не важно где — в АЛУ, или снаружи, есть схема, которая позволяет аппаратно перемножить два числа а не эмулировать это умножение сложениями и сдвигами. И ничего больше. Не надо придумывать своих понятий, а потом обвинять всех, что их «подменяют».
У AVR есть аппаратный умножитель, в АЛУ, 8-битный. У МСП тоже есть, отдельным блоком, 16-битный. Разумеется, 16-битный умножитель позволит провести вычисления с 16-битными значениями быстрее, чем 8-битный.
С 8-битными, судя по таблицам, он проигрывает умножителю в АВР — вероятно, как раз из-за того, что находится вне АЛУ.
Слова «hardware multipier» это вербальное описание того, что в составе кристалла, не важно где — в АЛУ, или снаружи, есть схема, которая позволяет аппаратно перемножить два числа а не эмулировать это умножение сложениями и сдвигами. И ничего больше. Не надо придумывать своих понятий, а потом обвинять всех, что их «подменяют».
У AVR есть аппаратный умножитель, в АЛУ, 8-битный. У МСП тоже есть, отдельным блоком, 16-битный. Разумеется, 16-битный умножитель позволит провести вычисления с 16-битными значениями быстрее, чем 8-битный.
С 8-битными, судя по таблицам, он проигрывает умножителю в АВР — вероятно, как раз из-за того, что находится вне АЛУ.
не важно где
Кому не важно?
Вам?
Не важно для чего?
О чем вы вообще говорите?
Не надо придумывать своих понятий
Мои понятия это система и структура? Вам они не знакомы?
Вы пытаетесь сказать что MSP430 и AVR — это одно и тоже.
Вы плюете на блочную диаграмму и организацию вычислений в рассмотренных МК.
Техническую документацию из рассуждения выкидываете.
И ссылаетесь только на свое мнение, пытаясь упростить то, что упрощать нельзя.
Нельзя потому, что техническая документация результат работы инженеров, создавших эти МК,
Вы просто играете словами не на что не ссылаясь.
судя по таблицам, он проигрывает умножителю в АВР
Посмотрите внимательно.
Он выключен, а в следующей таблице включен.
И вообще заявление безграмотное.
Можно только говорить о том как в целом микроконтроллер(система) справляется с задачей.
Простите, а русский язык для вас родной? А то что-то вы не можете понять ни одного сообщения, ни моего, ни других людей.
>Кому не важно?
Вам?
Не важно для чего?
О чем вы вообще говорите?
>Кто мы? Вы и снова вы?
Вас сложно понять, про что вы вообще говорите.
Боюсь, с вами не получится вести конструктивную беседу — вы не понимаете язык.
Давайте попробую еще раз сказать вам простыми словами: когда вы видите надпись «hardware multiplier», она означает, что в составе процессора есть блок, который выполняет умножение. Это все, что она означает. Она не несет никакой информации о том, где конкретно этот блок. Он может быть в АЛУ, может быть вне него.
Так понятнее?
Да, еще посмотрите внимательнее на ваши же таблицы, может быть увидите числа, показывающие количество циклов для AVR и для MSP со включенным умножителем на одной и той же задачи. Например, 157 для AVR, 299 для MSP при выключенном умножителе, 268 при включенном и без оптимизации, 249 при влюченном и с оптимизацией.
>Кому не важно?
Вам?
Не важно для чего?
О чем вы вообще говорите?
>Кто мы? Вы и снова вы?
Вас сложно понять, про что вы вообще говорите.
Боюсь, с вами не получится вести конструктивную беседу — вы не понимаете язык.
Давайте попробую еще раз сказать вам простыми словами: когда вы видите надпись «hardware multiplier», она означает, что в составе процессора есть блок, который выполняет умножение. Это все, что она означает. Она не несет никакой информации о том, где конкретно этот блок. Он может быть в АЛУ, может быть вне него.
Так понятнее?
Да, еще посмотрите внимательнее на ваши же таблицы, может быть увидите числа, показывающие количество циклов для AVR и для MSP со включенным умножителем на одной и той же задачи. Например, 157 для AVR, 299 для MSP при выключенном умножителе, 268 при включенном и без оптимизации, 249 при влюченном и с оптимизацией.
>Кому не важно?
Вам?
Не важно для чего?
О чем вы вообще говорите?
>Кто мы? Вы и снова вы?
Вас сложно понять, про что вы вообще говорите.
Боюсь, с вами не получится вести конструктивную беседу — вы не понимаете язык.
Вы не ответили не на один мой вопрос.
когда вы видите надпись «hardware multiplier», она означает, что в составе процессора есть блок, который выполняет умножение
В случае MSP430F16x он находится в составе МК, но не в составе процессора. Он называется «hardware multiplier».
В случае Atmega16 в составе процессора есть «On-chip 2-cycle Multiplier», который является составной частью МК.
Разница, если внимательно почитать документацию, очевидна.
MSP430
Atmega16
Да, еще посмотрите внимательнее на ваши же таблицы, может быть увидите числа, показывающие количество циклов для AVR и для MSP со включенным умножителем на одной и той же задачи. Например, 157 для AVR, 299 для MSP при выключенном умножителе, 268 при включенном и без оптимизации, 249 при влюченном и с оптимизацией.
Вы пытаетесь уйти от ответа. Сначала вы говорили о первой таблице, где MSP430F135. У данного контроллера физически нет аппаратного умножителя.
Теперь вы оцениваете только только по нижней позиции. И как бы опомнились, после моей подсказки, что там нет умножителя.
Да, еще посмотрите внимательнее на ваши же таблицы, может быть увидите числа, показывающие количество циклов для AVR и для MSP со включенным умножителем на одной и той же задачи. Например, 157 для AVR, 299 для MSP при выключенном умножителе, 268 при включенном и без оптимизации, 249 при влюченном и с оптимизацией.
А остальные числа и то что один контроллер 16-ти разрядный, а другой 8-ми разрядный от вас как бы ускользает?
Впервые вижу так упорно бредящего человека)
Я ответил на эти, с позволения сказать, вопросы. Но вы опять не в состоянии прочитать по-русски.
Читайте до просветления ветку с самого начала, если у вас не совсем запущеный случай, то рано или поздно смысл моих слов до вас дойдет.
>В случае MSP430F16x он находится в составе МК, но не в составе процессора. Он называется «hardware multiplier».
В случае Atmega16 в составе процессора есть «On-chip 2-cycle Multiplier», который является составной частью МК.
Разница, если внимательно почитать документацию, очевидна
Разница очевидна, дальше что? На суть вопроса это не влияет. Я вам который раз повторяю фразу, которую вы понять не можете: «слова „аппаратный умножитель“ значат, что внутри микроконтроллера умножение выполняется отдельной схемой, а не эмулируется через сложение и сдвиги». Где эта схема находится эти слова не определяют, будь она в АЛУ или внешним блоком, это все равно называется аппаратный умножитель, потому что «не аппаратный» — это софтварный, так же как и софтварные флоаты.
Вот этот выделенный текст внимательно прочтите. Может быть даже стоит его переписать медленно и вдумчиво (вам, а то вы опять не поймете «кому»). Вот единственный тезис который тут обсуждался. Больше ничего не оспаривалось, ни то что в АВР он внутри АЛУ а не отдельным блоком, ни то что в АВР он может работать только в 8-битными операндами.
>Вы пытаетесь уйти от ответа. Сначала вы говорили о первой таблице, где MSP430F135. У данного контроллера физически нет аппаратного умножителя.
Вам совсем худо стало, что вы даже придумывать несуществующие факты начали?)
>судя по таблицам
Не знаю, как у вас из этих слов получилось что я внезапно говорил о первой таблице)
>А остальные числа и то что один контроллер 16-ти разрядный, а другой 8-ми разрядный от вас как бы ускользает?
Это тут к чему? Что вы пытаетесь этим доказать или обосновать? Никто не говорил, что они одной разрядности. Никто не говорил, что с 16-битной математикой АВР справляется лучше. К чему вы еще раз озвучили то, что не имеет отношения к разговору?
Я ответил на эти, с позволения сказать, вопросы. Но вы опять не в состоянии прочитать по-русски.
Читайте до просветления ветку с самого начала, если у вас не совсем запущеный случай, то рано или поздно смысл моих слов до вас дойдет.
>В случае MSP430F16x он находится в составе МК, но не в составе процессора. Он называется «hardware multiplier».
В случае Atmega16 в составе процессора есть «On-chip 2-cycle Multiplier», который является составной частью МК.
Разница, если внимательно почитать документацию, очевидна
Разница очевидна, дальше что? На суть вопроса это не влияет. Я вам который раз повторяю фразу, которую вы понять не можете: «слова „аппаратный умножитель“ значат, что внутри микроконтроллера умножение выполняется отдельной схемой, а не эмулируется через сложение и сдвиги». Где эта схема находится эти слова не определяют, будь она в АЛУ или внешним блоком, это все равно называется аппаратный умножитель, потому что «не аппаратный» — это софтварный, так же как и софтварные флоаты.
Вот этот выделенный текст внимательно прочтите. Может быть даже стоит его переписать медленно и вдумчиво (вам, а то вы опять не поймете «кому»). Вот единственный тезис который тут обсуждался. Больше ничего не оспаривалось, ни то что в АВР он внутри АЛУ а не отдельным блоком, ни то что в АВР он может работать только в 8-битными операндами.
>Вы пытаетесь уйти от ответа. Сначала вы говорили о первой таблице, где MSP430F135. У данного контроллера физически нет аппаратного умножителя.
Вам совсем худо стало, что вы даже придумывать несуществующие факты начали?)
>судя по таблицам
Не знаю, как у вас из этих слов получилось что я внезапно говорил о первой таблице)
>А остальные числа и то что один контроллер 16-ти разрядный, а другой 8-ми разрядный от вас как бы ускользает?
Это тут к чему? Что вы пытаетесь этим доказать или обосновать? Никто не говорил, что они одной разрядности. Никто не говорил, что с 16-битной математикой АВР справляется лучше. К чему вы еще раз озвучили то, что не имеет отношения к разговору?
Теперь остается выбросить две дряни (мастдайку и iar) и сделать то же самое в консольке линукса.
С «религиозными» людьми спорить сложно (-: Ведь они фанатики. И просто верят в одно решение.
Иногда довольно неудобное для себя. Но надо так делать, потому что это «правильно».
Иногда еще «самобичиванием» занимаются и надевают на себя «вериги».
Я в отличии от вас не отмахиваюсь от Linux. Это инструмент, а не цель реализации.
Но не всегда это целесообразно и удобно.
Можем обсудить все детально.
IAR коммерческий продукт, в который инвестированы средства, он проработан, протестирован.
Имеет поддержку от разработчика, портирован на многие семейства.
Что мы имеем? Минимальное неудобство при переходе с семейства на семейство.
Минимальное неудобство при работе и отладке с микроконтроллерами разных семейств.
Можно вести несколько проектов для разных МК в одной среде. Удобно же.
Все JTAG-отладчики поддерживаюся. Есть плагины для многих ОСРВ.
Многие производители микроконтроллеров делают свои примеры для IAR.
Все это повышает скорость и удобство разработки, если поставлена задача
быстро и эффективно сделать проект.
Windows это тоже лишь инструмент разработки. И тоже удобный инструмент.
Т.к. это самая популярная ОС для ПК, все производители будут стремится делать
под нее среды разработки, драйверы для JTAG-отладчиков.
Это коммерчески целесообразно.
Ну зачем в плане ОС искать себе неудобство?
Единственный адекватный аргумент это дорого.
Ну с Linux тоже не все так просто.
Группа единомышленников поддерживает эту ОС.
По сути работает разрабатывает, тестирует и сопровождает бесплатно.
Потом на основе нее выпускают коммерческие продукты.
Больше похоже, что кто-то вкладывается в маркетинг «бесплатного» ПО.
Создавая толпы людей, которые работают бесплатно.
А потом имеет основу для коммерческого продукта.
Удобно участвовать в этом процессе? Мне не особо.
Развивает ли это мозг? Безусловно.
Но не в направлении решения задачи разработки ПО для МК.
А в направлении преодоления трудностей, которые при связки Windows+IAR
могут и не возникнуть. И останется больше времени решить задачи и проблемы
собственно программного проекта для МК удобным образом,
с минимальным затратами времени.
Дорого? Да. Но если у организации есть деньги, ограничены сроки на проект,
а задачу надо решать на новом семействе МК — это будет оптимальный вариант.
Очевидно же. Нет?
Иногда довольно неудобное для себя. Но надо так делать, потому что это «правильно».
Иногда еще «самобичиванием» занимаются и надевают на себя «вериги».
Я в отличии от вас не отмахиваюсь от Linux. Это инструмент, а не цель реализации.
Но не всегда это целесообразно и удобно.
Можем обсудить все детально.
IAR коммерческий продукт, в который инвестированы средства, он проработан, протестирован.
Имеет поддержку от разработчика, портирован на многие семейства.
Что мы имеем? Минимальное неудобство при переходе с семейства на семейство.
Минимальное неудобство при работе и отладке с микроконтроллерами разных семейств.
Можно вести несколько проектов для разных МК в одной среде. Удобно же.
Все JTAG-отладчики поддерживаюся. Есть плагины для многих ОСРВ.
Многие производители микроконтроллеров делают свои примеры для IAR.
Все это повышает скорость и удобство разработки, если поставлена задача
быстро и эффективно сделать проект.
Windows это тоже лишь инструмент разработки. И тоже удобный инструмент.
Т.к. это самая популярная ОС для ПК, все производители будут стремится делать
под нее среды разработки, драйверы для JTAG-отладчиков.
Это коммерчески целесообразно.
Ну зачем в плане ОС искать себе неудобство?
Единственный адекватный аргумент это дорого.
Ну с Linux тоже не все так просто.
Группа единомышленников поддерживает эту ОС.
По сути работает разрабатывает, тестирует и сопровождает бесплатно.
Потом на основе нее выпускают коммерческие продукты.
Больше похоже, что кто-то вкладывается в маркетинг «бесплатного» ПО.
Создавая толпы людей, которые работают бесплатно.
А потом имеет основу для коммерческого продукта.
Удобно участвовать в этом процессе? Мне не особо.
Развивает ли это мозг? Безусловно.
Но не в направлении решения задачи разработки ПО для МК.
А в направлении преодоления трудностей, которые при связки Windows+IAR
могут и не возникнуть. И останется больше времени решить задачи и проблемы
собственно программного проекта для МК удобным образом,
с минимальным затратами времени.
Дорого? Да. Но если у организации есть деньги, ограничены сроки на проект,
а задачу надо решать на новом семействе МК — это будет оптимальный вариант.
Очевидно же. Нет?
Сколько писанины…
Я вот что скажу: мы про промышленные разработки не говорим. Там деньги не считают.
Мы говорим про хобби. И уж тратить на хобби бешеные деньги может себе позволить только безмозглый баран, живущий за счет родителей. Потому что даже самый богатый человек потому и богатый, что деньгами сорить не привык!
Мне насрать на мнение других в этом плане. Лично меня все устраивает: в линуксе есть практически весь нужный мне софт, поэтому иметь секс с прошивкой для игровых приставок, да мучиться с кривым анально огороженным софтом я не собираюсь.
// ответ love_energy, что-то не туда щелкнул
Я вот что скажу: мы про промышленные разработки не говорим. Там деньги не считают.
Мы говорим про хобби. И уж тратить на хобби бешеные деньги может себе позволить только безмозглый баран, живущий за счет родителей. Потому что даже самый богатый человек потому и богатый, что деньгами сорить не привык!
Мне насрать на мнение других в этом плане. Лично меня все устраивает: в линуксе есть практически весь нужный мне софт, поэтому иметь секс с прошивкой для игровых приставок, да мучиться с кривым анально огороженным софтом я не собираюсь.
// ответ love_energy, что-то не туда щелкнул
В промышленных разработках деньги ещё как считают!
Теперь остается выбросить две дряни (мастдайку и iar) и сделать то же самое в консольке линукса.
мы про промышленные разработки не говорим
Мы говорим про хобби
Кто мы? Вы и снова вы?
Вас сложно понять, про что вы вообще говорите.
Вы говорите, что только iar и Windows надо выкинуть.
Теперь уже не надо. Это только для хобби.
Даже если хобби можно пользоваться обрезанными версиями IAR.
По времени или по объему кода.
Ощутите удобство.
Но это только возможный вариант.
Он не единственный.
Там деньги не считают
К сожалению, это не так.
И поэтому в некоторых конторах разрабатывают на чем вы хобби пишите.
И уж тратить на хобби бешеные деньги может себе позволить только безмозглый баран, живущий за счет родителей. Потому что даже самый богатый человек потому и богатый, что деньгами сорить не привык!
Как много эмоций в этих словах (-:
Что с вами?
Чувствуете социальное неравенство?
Не можете даже такого в мыслях допустить?
А я могу.
«Религиозность» сменилась «коммунизмом». Буржуи во всем виноваты.
Пусть лучше пусть IAR купит чем пять айфонов (-:
Мне насрать на мнение других в этом плане.
Вот корень вашей проблемы. Отключение критического мышления.
«Религиозность» опять пошла.
Вообще в последнее время все увлекаются АРМами и АВРами, забыв что традиционные процессоры тоже имеют неплохой потенциал.
Посмотрите в сторону Renesas RL78 хотя бы. У них тоже есть интересные демоборды. Достаточно низкие цены на микросхемы. Но, конечно, уровень вхождения у них повыше чем в Arduino.
Посмотрите в сторону Renesas RL78 хотя бы. У них тоже есть интересные демоборды. Достаточно низкие цены на микросхемы. Но, конечно, уровень вхождения у них повыше чем в Arduino.
Может это потому, что АРМ и АВР более доступе с точки зрения приобретения в розницу? А если ледом поморгать, то и LPT порта достаточно (правда его сейчас днем с огнем не сыщешь)…
К тому что вы сказали, мне кажется, стоит добавить то, что AVR и такие семейства на ядре ARM, как STM32, более популярны. И, как следствие, в интернете можно найти много готовых проектов, статей, переведенной документации и библиотек. Помимо этого, если у тебя есть J-Link, то ты можешь прошивать и отлаживать множество ARM'ов разных производителей. С Renesas'ами такое не прокатит, потому что у них специализированные, замкнутые на свое семейство JTAG-отладчики. Если есть IAR для ARM'ов и J-Link, вы можете иметь доступ ко множеству микроконтроллеров на ядре ARM в одной среде и с одним отладчиком.
Для AVR, помимо «самодельных» программаторов и JTAG-отладчиков, есть сравнительно недорогие решения от сторонних производителей. Ну и популярность Arduino никто не отменял. Т.к. данная платформа построена на AVR, это еще более популяризирует данное семейство.
Для AVR, помимо «самодельных» программаторов и JTAG-отладчиков, есть сравнительно недорогие решения от сторонних производителей. Ну и популярность Arduino никто не отменял. Т.к. данная платформа построена на AVR, это еще более популяризирует данное семейство.
Не фанат «Дурилки», так как считаю ее слишком избыточной, по моему скромному мнению, ее наличие скорее минус чем плюс (плюс в том, что хороший аналог конструктора для детей увлекающихся электроникой). То же касается готовых решений — отлично, когда разработчик опираясь и анализируя вырабатывает свое решение, плохо когда занимается Ctrl+C Ctrl+V, ужасно когда копирует не удосужившись даже прочесть описание.
Я согласен с оратором выше, в том контексте, что низкий порог входа для АРМ, АВР, Ардуино это хорошо, но опять же это влечет появление «специалистов» которые понимают в контроллерах очень и очень мало, а в схемотехнике зачастую с пятого на десятое — вот и получаем тонны некачественной продукции ( хотя вопрос дискуссионные, тут есть и плюсы и минусы)
По поводу программаторов — это да, как говорится, не в бровь, а в глаз. Да же добавить нечего.
Я согласен с оратором выше, в том контексте, что низкий порог входа для АРМ, АВР, Ардуино это хорошо, но опять же это влечет появление «специалистов» которые понимают в контроллерах очень и очень мало, а в схемотехнике зачастую с пятого на десятое — вот и получаем тонны некачественной продукции ( хотя вопрос дискуссионные, тут есть и плюсы и минусы)
По поводу программаторов — это да, как говорится, не в бровь, а в глаз. Да же добавить нечего.
Я вас понял. То что вы говорите применительно к разработчику несомненно правильно.
Я сам считаю, что пока на чистом C, без библиотек одно семейство не освоишь, много не поймешь. Будут пробелы в понимании теории и практики.
Но еще есть люди, которые этим профессионально не занимаются. Постараюсь написать свое виденье вопроса и в этом ключе. Если вспомнить историю развития персональных компьютеров и их использования, то они двигаются по пути упрощения для простого человека. Появление платформы x86 и графического интерфейса позволять большинству людей без труда пользоваться компьютером. Сейчас планшеты на Android еще проще чем были раньше ПК на Windows, процесс установки и настройки ОС и дополнительных приложений максимально упрощен. Даже дети легко ими пользуются. Как мне кажется, похожий процесс запущен и в сфере микроконтроллеров. Появление платформы Arduino, открывает возможность создания своих простых устройств автоматизации и роботов для большинства людей, как инструмента творческого самовыражения.
Я сам считаю, что пока на чистом C, без библиотек одно семейство не освоишь, много не поймешь. Будут пробелы в понимании теории и практики.
Но еще есть люди, которые этим профессионально не занимаются. Постараюсь написать свое виденье вопроса и в этом ключе. Если вспомнить историю развития персональных компьютеров и их использования, то они двигаются по пути упрощения для простого человека. Появление платформы x86 и графического интерфейса позволять большинству людей без труда пользоваться компьютером. Сейчас планшеты на Android еще проще чем были раньше ПК на Windows, процесс установки и настройки ОС и дополнительных приложений максимально упрощен. Даже дети легко ими пользуются. Как мне кажется, похожий процесс запущен и в сфере микроконтроллеров. Появление платформы Arduino, открывает возможность создания своих простых устройств автоматизации и роботов для большинства людей, как инструмента творческого самовыражения.
Я тоже с вами согласен, как инструмент самовыражения, хобби, либо развивающее занятие для детей/подростков (как старые советские конструкторы :) ) — это отличное решение. Кроме того «Дурилка» и иже с ней позволяет создавать простенькие системы для дома и личного пользования в не критичных приложениях. Хотя я бы отдал предпочтение Rosbery Pi в этом случае, а если порог входа кажется высоким — то можно начать с установки на него Linux.
На счет упрощения в области ПК (это касается всех ОС, не только Windows), все таки упрощение идет для конечного пользователя — то есть процесса установки и использования ПО, улучшение и упрощение интерфейса (как GUI так и консольного) помню консоль на «электронике» — так это фортран почти что. А вот внутреннее устройство ОС и самого ПК как не странно наоборот претерпело серьезное усложнение и давно вышло за рамки хобби, если раньше каждый радиолюбитель мог спаять из набора транзисторов ПК, то сейчас это сделать не получится (точнее получится, но с известными последствиями). На мой взгляд микроконтроллеры — все таки ближе к железу чем к коддингу.
На деле «Дурилка» и иже с ней смещает эти устройства в сторону программирования. Вы берете модуль, пару шилдов и не нужно думать о схемотехнике, пиши софт и будет счастье. Дошло до того, что есть готовая прошивка для «Дурилки» которая предоставляет API для доступа к внутренним ресурсам МК через USB порт и Adobe Flash!!!
На счет упрощения в области ПК (это касается всех ОС, не только Windows), все таки упрощение идет для конечного пользователя — то есть процесса установки и использования ПО, улучшение и упрощение интерфейса (как GUI так и консольного) помню консоль на «электронике» — так это фортран почти что. А вот внутреннее устройство ОС и самого ПК как не странно наоборот претерпело серьезное усложнение и давно вышло за рамки хобби, если раньше каждый радиолюбитель мог спаять из набора транзисторов ПК, то сейчас это сделать не получится (точнее получится, но с известными последствиями). На мой взгляд микроконтроллеры — все таки ближе к железу чем к коддингу.
На деле «Дурилка» и иже с ней смещает эти устройства в сторону программирования. Вы берете модуль, пару шилдов и не нужно думать о схемотехнике, пиши софт и будет счастье. Дошло до того, что есть готовая прошивка для «Дурилки» которая предоставляет API для доступа к внутренним ресурсам МК через USB порт и Adobe Flash!!!
Работал с микроконтроллером R5F562N8 семейства Renesas RX62N на отладочной плате The Renesas Starter Kit+.
Это был для меня предшественник семейства STM32F4xx на ядре Cortex-M4. Семейство RX62N, как и STM32F4xx,
имеет встроенный FPU, имеет библиотеку периферии от производителя. Мне понравился курс лекций по встраиваемым
системам Джеймса Конрада, первую лекцию которого можно здесь.
Для примеров и лабораторных взято именно семейство Renesas RX62N.Остальные лекции легко найти в поиске.
Это был для меня предшественник семейства STM32F4xx на ядре Cortex-M4. Семейство RX62N, как и STM32F4xx,
имеет встроенный FPU, имеет библиотеку периферии от производителя. Мне понравился курс лекций по встраиваемым
системам Джеймса Конрада, первую лекцию которого можно здесь.
Для примеров и лабораторных взято именно семейство Renesas RX62N.Остальные лекции легко найти в поиске.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микроконтроллеры семейств AVR, MSP430, STM32 и мои субъективные впечатления