Медленно переползая с PIC24F на ARM (по причине того, что Микрочип банально не справляется с толпой конкурентов), поставил я себе тривиальную цель. Дай-ка, думаю, найду промеж АРМ-ов и ейных IDE такие, которые сходу (т.е. без особых затрат моего времени на изучение док и на вопросы на форумах) справятся с привычными и тривиальными для Мплаб и PicKit/ICD задачами:

1) инсталлировать среду
2) создать проект (или лучше взять из готовых примеров), типа, помигать светодиодом
3) скомпилировать проект
4) загрузить его в отладочную плату
5) отладить, т.е. пройти C-шный код по шагам

Постепенно закупил некоторое количество отладочных плат и приблуд:
- ST - Нуклео STM32L152 и STM32F030
- Freescale - FRDM-KL25Z
- Cypress - CY8KIT-049
- Infineon - KIT_XMC_2GO_XMC1100_V1
- SiLabs - EFM32WG-STK3800
- MBED - LPC1768
- TI - MSP432 LaunchPad
- китайские ULINK2, J-LINK, ST-LINK-V2

Помимо этого, еще и платку Atmel Xplained Mini прикупил, чтобы заодно попробовать, каково отлаживать Atmega328

Не претендуя на полноту, докладываю о результатах и своих субъективных впечатлениях.

1. Бесплатные IDE - никто не дошел до финиша. Пробовал:
- CooCox
- emIDE
- ChibiStudio
- SW4STM32
Далее всего продвинулся с ChibiStudio, базируясь на их видео. Удалось даже скомпилировать проект и загрузить его в STM32F030. На отладке я сломался, как с этим г... можно работать, я так и не понял. Остальные сошли с дистанции раньше. На самых ранних стадиях накрылся SW4STM32, он даже инсталлироваться не способен - не может у меня в компе найти Жабу.

2. Фирменные IDE от производителей чипов - ситуация смешанная, какие-то работают, иные - нет.

- TI - ихняя студия после закачки и установки еще час-другой самообновлялась, что само по себе маразм. Затем, по ходу прохождения самого первого примера "out of box experience" она обновила фирмварь на LaunchPad, после чего тот накрылся медным тазом. Несколько дней я потратил на вопросы на форуме TI, и мне даже ответили, сказали, как сделать factory reset. Я его сделал, после чего фирмварь опять самообновился и снова накрылся медным тазом. Короче, не работает ни хрена, сырое все, а софт пишут какие-то фрики и выкладывают в сеть не проверяя.

- Friscale - какие-то у них странности с самой отладочной платой. Под MBED все работает, под KDS - полный тухляк. Ниасилил.

- Atmel Studio 7 - работает все, кроме отладки. При отладке по шагам все время вылетает в какую-то точку хрен знает где. Ничуть не лучше ChibiStidio.

- Cypress - PSoC Creator мне понравился, однако отладочную платку я купил неправильную: в ней нет отладчика, а есть только бутлодер. По сути, эта платка - аналог Ардуино Нано. Собираюсь купить другую платку, с отладчиком, и пробовать дальше.

- Infineon - Dave заработал с полпинка, никаких проблем. Все просто и понятно.

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

3. Фирменные IDE

mbed - классная вещь, все просто и все работает, но отладки нет, увы.

Keil - никаких проблем, все интуитивно понятно и хорошо работает.

-------------------------------------------------------

По результатам своих изысканий, я стал с бОльшим почтением относиться к MPLAB.

Ещё IAR забыли посмотреть для полноты картины Ну и с Эклипсой сексом позаниматься.

К сожалению, до IAR-а руки не дошли. Однако уверен, что в IAR-у тоже все ОК, как и в Keil. Когда-то работал под IAR-ом для MSP430, впечатление было очень позитивное.

Что же касается Эклипса, то бОльшая часть перепробованных IDE сделана на Эклипсе, в т.ч. Инфинеон и СиЛабс. Это изрядно добавляет кривизны, но привыкнуть можно, лишь бы работало.

Критерий выбора контроллера, по критерию, как ничего не понимая, ни в чем не разбираясь и ничего не написав получить моргалку светодиодом весьма странен.
При сколь-нибудь разумном подходе IDE всегда для любых контроллеров и КОМПИЛЯТОРОВ должна быть одна. Это, конечно, не быстрый старт, ввиду того, что именно такого подхода категорически не хотят допускать производители компиляторов, но верный.

Вменямые люди, я думаю, меня прекрасно поняли. Это нечто подобное "индексу Биг-Мака" в экономике, простой и наглядный способ оценить затраты и качество софта. У кого много времени и мало денег - выберет бесплатную среду. Кто ценит свое время - выберет универсальный Кайл или Иар или же сядет на "фирменную" IDE.


Это маниловщина. Можно сколько угодно хвалить Кайл, но Сайпрессовский PSoC он не поддерживает, и вряд ли когда-либо будет поддерживать. А посему не надо догматизма, лучше использовать IDE по обстоятельствам.

И после этого вы еще утверждаете, что:


=АК=, если серьезно, мне вот, интересно, почему АРМ? Почему не МИПС? Я после 24-й серии перешел на 32 и прекрасно себя чувствую. Может я что-то пропустил? Вопрос серьезный, без подкола.

Я делаю устройства с батарейным питанием. В линейке PIC32 нет ни одного "нановатт" чипа. А линейка PIC24F очень ограничена по размерам памяти. И это при том, что PIC24 жрет память программ как свинья, а пресловутые "нановатт" PIC24F по потреблению на фоне АРМ-ов выглядят очень блекло.

Кроме того, иногда я делаю иные устройства, не малопотребляющие, но чувствительные к цене. И вижу, что за те же деньги, за какие Микрочип продает "дешевые" PIC24 с 16К памяти программ, я могу купить Atmega328 с 32К памяти, или XMC1100/STM32 с 32K или 64К памяти.

Спасибо за ответ! Да, действительно на счет энергопотребления вы правы - батарейное питание вносит свою корекцию. Мне не приходилось, вот и не задумывался.
Я одно время поглядывал в сторону Cypress-а, но потом появились 16-ые пики с расширенной аналоговой периферией и они меня устроили.

Я ценю свое время и трачу время совсем не в соревнованиях в минимальном количестве нажатий на кнопки для получения моргалки светодиодом. Посему для реальной профессиональной работы НЕ использую привязаные к какому-то одному производителю софта и/или железа халявно прилагаемые IDE.

ARM компиляторы поддерживают ЛЮБОЙ ARM. Остальное неважно. Это относится и к другим контроллерам. С теми-же PSoC 2 поделками я более, чем нормально, работаю без их IDE и визардов - только Image Craft компилятор, хотя есть и GCC альтернатива.

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

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

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

Я бы рекомендовал отдельно тестировать редактор, IDE и отладочный адаптер.
Тут по моим тестам лучше всех будет тройка: SlickEdit, IAR, JLink.

На второе место в качестве редактора поставил бы Visual Studio обязательно с Visual Assist.
На второе место в IDE поставил бы Keil.
Второе место в отладочный адаптерах отдал бы клонам JLink.

Мне нужен отладчик. С пошаговой отладкой, брекпойнтами и вотч-виндовс.

А если без отладчика, то меня и Ардуино бы устроил, и mbed, и любой Эклипс с GCC. Однако мне без отладчика и даром не надо.

JLink дает такой мощный отладочный канал как RTT
Покупая отладочные платы с встроенным адаптером сразу лишаете себя выбора.

Анализирую IDE сразу надо говорить на какой платформе они устроены.
Скажем KDS сделан на Eclipse.
А Atmel Studio сделан на MS Visual Studio.

Зная платформу можно сразу понять на какие Add-On-ы можно рассчитывать. Опытным программистам это все скажет.
Например под Eclipse есть Add-On SlickEdit который дешевле обычного SlickEdit, а это превращает KDS в мощнейший редактор. А если в KDS добавить Add_On компилятора IAR то можно и Keil переплюнуть.
Но у всех монструозных студий есть большой недостаток в том что они медленно открываются и медленно компилируют.

Именно так - все из отдельных МАКСИМАЛЬНО продвинутых компонентов. Среди которых редактор это тот инструмет с которым работаешь больше всего и котрый должен быть буквально продолжением кончиков пальцев. Он же и база для интеграции всего.
Пожалуй, в качестве редактора от которого надо начать создавать СВОЙ набор инструметов, именно SlickEdit выглядит весьма достойно.
Среди компиляторов (только не IDE!, а именно компиляторов), если есть выбор, тоже выбираю IAR. На втором месте максимально всеядный GCC. Остальные (типа убогих микрочиповских Hi-Tech) уже по жесткой необходимости.


А мне почему то нет . Предпочитаю думать прежде, чем начинать писать и внятно излагать мысли компилятору, когда пишу. Ну очень помогает. При ПОЛНОЙ коллекции отладчиков под все типы используемых контроллеров, крайний раз отладчик запускал лет 10 тому назад при написании эфирного загрузчика для изделия под PIC16, да и то в общем-то не для отладки, а для лабораторной работы перед написанием. С тех-же примерно пор у всех изделий на ARM похерен отладочный интерфейс. Единственое исключение парочки ARM+FPGA. Но и в них JTAG из-за Boundary Scan оставался.
Ну а про отладку Вам уже выше ответили - ничего недоступного нет и без IDE.

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

А консоль для отладки, это, конечно, приятный бонус, но он на втором-третьем месте среди моих приоритетов. Обычно мне хватает "запасного" (неиспользуемого) UART для этих целей. Однако интегрированного отладчика/эмулятора мне он не заменяет.

Использую geany, все в порядке.

То есть, вам эмулятор не нужен, я правильно понимаю? Эта позиция уже была озвучена ранее.

Еще бы я не понимал о чем речь.
Вот окно KDS (оно же Eclipse Luna SR2) в режиме отладки.
Нажмите для просмотра прикрепленного файла

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

И это еще одна из самых слабых конфигураций отладочной перспективы в терминах Eclipse. Над ней поработать еще кучу фичей можно встроить из Eclipse Marketplace

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

дело в филармонии, попробовать ещё раз ?
и ms vs таки да, рулит

Вот не понимаю, откуда у людей столько времени тыцкать в расфуфыренные окошки в надежде что-то там увидеть (из-под отладчика!!!)

Боже! Почувствовал себя полным лохом. Но да. Я тоже пользуюсь отладчиком при переходе на новую платформу, потому что для меня важно разобратся как оно там внутри тикает. И кстати, когда принимаю новых коллег, если они мне не успевают объяснить как "оно там внутри тикает", прикрываясь фразами "С компилятор все сам сделает", я их просто ... не принимаю.
Vanity, defenitely my favorite sin!

Дааа... совсем недавно, при переходе на stm8 - обнаружил что и отладка - гуано и симули все что есть - совсем отстой, и еще более недавно наконец-то руки дошли до mplab.Хэ
Так вот это "Хэ"-он точно оправдывает, поскольку симуль оказался непривычно скупым, как для микрочипа. И времена, когда люди незлым тихим вспоминали avrstudio, у которых что-то с таймерами было, уже не помню, - теперь кажутся раем.

"Хэ", это еще цветочки! Чего стоит одна только "MPLAB® Harmony Software Framework"...

Em::Blocks

Правильно. Отлаживаю через USB (CDC).

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

Я не смог достучатъся до их сайта. Кто-то взамен подсовывает страницы с голландского полит сайта со всякой пургой о малазийском МН-17. Сегодня попробовал еще раз через анонимайзер, так удалось зайти и скачатъ дистриб. Штука интересная, буду пробоватъ.


Как я уже писАл, в моем случае KDS не пожелал работать с FRDM KL25Z, в результате - не прошел в финал по озвученным в первом посте критериям. Я не стал настаивать, поскольку общая монстроидальность Фрискэйла вазывает у меня отвращение. Хуже них, наверное, только Тексас и Интел.

К большому сожалению, эту всю шелуху, которая какбы "открытые решения" - нужно выпиливать и делать с нуля.


Постыдились бы своих слов

Да нет, я такое не писал. Мы-то с вами это понимаем. Однако грустно, конечно, но есть достаточно большое количество молодых людей, которые смотрят на ассемблерский листинг как собака Павлова - с такими большими умными глазами, как будь-то бы вот-вот и начнут говорить... Я имел ввиду, что "железо" нужно знать и понимать как оно работает. Это моя философия, никому, конечно, не навязываю.
И, кстати, ни один листинг вам не скажет что происходит, например, с логическими ячейками (logic cell - новая выдумка Майкрочипа)... Так что, ничего не надо доводить до абсолютизма, я считаю. Но это уже флуд в данной теме.

программисты просто упоротые. но ИДЕ у них получилась хорошая. Поправили немало косяков самого кодблокса, собрали разные наборы для сборки и отладки. Всё это посолили и поперчили. Не супер-пупер, но вполне достойно вышло.

зы. но сам я назад на кодблокс вернулся - мне кроссплатформенность нужна. но до этого пользовался успешно. эта та IDE, за которую не надо платить, которая не отжирает сотни мегабайт явой и в которой после создания проекта можно нажать F8 и отладка работает без всяких бубнов.


прежде чем начинать процесс пафосной газификации, сходили бы и посмотрели что там написано.

Напрасно, там у Freescale еще есть KW40Z как раз с UART через BLE.
Это с тем BLE где у вас эпический облом был на других чипах.

Не слишком ли много у вас историй неудач, а?



Да забавно. Говорят комплекс, но показывают везде и ищут только одну самоходку.

EmBlocks заработал с полпинка с платкой Нуклео STM32F030. Круто.

Я кодблоками пользуюсь время от времени, тоже хорошая вещь.

Пользуюсь Keil начиная с версии 2.0 микровижна под разные МК. Всем доволен. Для проектов на Cortex-M ограничения в 32кБ пока что хватает. В будущем придется воспользоваться "таблеткой".

С тех пор как ARM приобрел Keil у них компилятор перестал давать эффективный код. Урезали оптимизацию видимо. Теперь она вся у ARM DS-5.

Лучше всех нынче из доступных под Cortex-M компилирует IAR.

Кстати, DS-5 раздают бесплатно до 30-го. Есть шанс протестировать.

У MDK и DS-5 один и тот же компилятор. Да и заявление "перестал давать эффективный код" слишком громко звучит. Уже сто раз сравнивали GCC, IAR и ARMCC, вывод один и тот же: примерно одинаково, на каких-то задачах один чуть лучше, на других - другой.

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

Остальные компиляторы реально разные и очень сильно. "Сто раз" сравнивал.

Купил Cypress пионерский кит Cy8CKIT-042. Посмотрел и повторил первую обучалку из серии PSoC101. Все запахало с полпинка, отладка работает. То есть, Cypress PSoC Creator 3.3 (судя по всему, это все тот же изначально кривой Эклипс, но на сей раз сильно переделанный под свои нужды) вместе с семейством PSoC 4 выходят в финал.

Интересная штука, этот PSoC 4. Чем больше читаю, тем больше нравится. Похоже, что Сайпресс действительно нашел магическое решение, которое позволит ему уделать всех конкурентов. Правда, в кремнии они пока уступают, но это дело наживное. Зато подход к разработке, действительно, революционный.

Этому "революционно" дерьмовому Cypress Creator подходу к разработке уже много лет. Дерьмописателям-мышкотаскателям нравится. Число дерьмописателей растет. Но даже при таких тенденденциях дерьмописания "уделать всех" не будет. Приходилось работать готовым железом на 2 и 3 поколении PSoC после того, как дерьмописатели из южного полушария, уже после поставки оборудования на объект, расписались в своей беспомощности. Первым делом похерил все дерьмо нагенеренное визардом из движений мышкой. Все запустил. Работает и даже еще выпускается. Но фигня.

А что там тестировать - DS5 это Eclipse - полное г...о
А компилятор ARMCC он один и тот же.

Поставил Atmel Studio 7 - так его изговнякали плагинами своими, что работает как арифмометр.
IAR 7.5 не захотел с Atmel'овским CMSIS-DAP работать.
Такая же херня с TI CCS 6 (Eclipse)

Плюнул - взял Keil и на нем под SAM4L тесты сделал и под СС2650.

Eclipse DS5 с отладочными плагинами лучше Keil-а на порядок.
И ARMCC у них разные.

Характерное для персонажа бурление говн доказывает разве что разлитие желчи в конкретном организме. Поскольку про это и так всем известно, то представленная информация сводится к шуму. Не к белому, и даже не розовому, а скорей к коричневому. Ретроградам, способным только набрасывать дерьмо на вентилятор, - стыд и позор.

Что же касается Сайпреса, то они элегантно решают две задачи:

1. Устраняют противоречие между гибкостью периферии и ее сложностью.
2. Уменьшают потери времени разработчика на изучение документации.

Существует явная тенденция усложнять периферийные узлы, поскольку кремний легко (читай - почти бесплатно) позволяет это делать, а область применения при этом заметно расширяется. Например, UART сейчас как правило имеет опциональный FIFO, адресацию для шинных протоколов, режим IrDA и т.п. Это приводит к многостраничным описаниям в даташитах и рефманах, и, как результат - к большим потерям времени на изучение толстых док, которые не нужны для решения конкретной задачи. Из всего этого многообразия чаще всего надо просто вычленить конкретный режим, наиболее подходящий для задачи.

В PSoC гибкость железа существенно увеличена, а время на изучение док при этом радикально уменьшено. Поскольку они первыми сообразили, что мне, как разработчику, по большому счету все равно в каком виде производитель кристалла представляет документацию, то ли в виде традиционного даташита, то ли в виде интерактивной составляющей IDE, которая настроит периферию в соответствии с моими пожеланиями. Но в последнем случае мое время будет сэкономлено, тогда как ответственность за достоверность информации так или иначе все равно лежит на фирме-производителе.

У меня нет сомнений, что рано или поздно все производители чипов пойдут по пути, нащупанному Сайпрессом. А им, как первопроходцам - почет и уважуха, честь и халва.

48МГц это очень мало
вот 200 - это был бы уххх страшно представить

Тоже думал
http://electronix.ru/forum/index.php?showtopic=129221
Ну лежит у меня такой даренный кит, а применить-то и некуда. Ему или на елке гирляндой работать или что-то совсем специфическое делать.
Если уж приспичит и процессоры не справляются- вспомню Альтеру, там хоть все понятно до потрохов (было, 15 лет назад), а эти урезанные PSoC 4 как-то очень уж специфичны.

"Ретроград", если еще не поняли, с этими PSoC реально работал, а не, в отличии от Вас, писал кипятком от радости, что у него хоть эта демоборда сама запустилась.

Среди луддитов тоже встречались придурки, работавшие на станках, которые они потом ломали.



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

Ну, я же свой кит на ЗЫщС4 PSoC4 тоже пока не выкинул . Но что с ним делать- не знаю. Посмотрим.

У меня так много лет лежали Сцениксы (Scenix), может помнит кто? Был такой писк моды, виртуальная периферия, любой интерфейс накрутим программно за счет супершустрости ядра (50 МИПСов 20 лет назад это было ого-го!), обеспечим программеров виртуальными программными модулями и завоюем весь рынок... Писк прошел, так в реальный проект нигде не применил, кроме как включить и поиграться с готовыми апнотами.
Пусть и PSoC полежит, посмотрим куда их- или выкинуть как Scenix, или применить все-таки получится).

Надо различать цели с которой что-то, как Вам кажется, "ломается". Идеальный придаток для работы на станке - ничего не понимает в работе станков, умеет нажимать только кнопку и смореть на лампочку на станке и все . Как и наскоро обученный пролетарий для работы "программистом" на конвейере. Но конвейер, на то и конвейер, что бы все рабочие были "винтиками" легко заменяемыми и "обучаемыми". Вот уже домохозяек (некоторых) уже научили "программировать", например, микроволновки на кухне. Так-что и PSoC и иже с ними их так-же "научат". Что делать будете со знаниями того, что Вы считаете "программированием" на PSoC Creator-е ?

Если не затруднит Вас, поделитесь опытом, как удалось исправить эту ситуацию?

Господа инженеры, не ссорьтесь) Верну разговор к истокам. Вчера пришлось перевести проект с stm32f051 на stm32f091. До этого в основном пользовался кокосом. Решил попутно сменить иде - на sw4stm32. Завелась с пол-пинка. Перетащил на нее проект минут за 10. Первое впечатление - в sw4stm32 намного меньше эклипсовых штук выпилено. Сама среда и дебаг запускаются намного быстрее чем кокос.

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

Мне пришлось быть "альфа-тестером" провального пятого "песка", так что мог бы тоже рассчитывать на лавры первопроходца.
Но предпочитаю не вспоминать этот страшный сон. На тот момент кремний не работал, креатор банально падал.
По кремнию допилили, что могли, урезали параметры и выпустили. Креатор видимо тоже.
Прошли годы. Месяц назад на выставке увидел решение Freescale, реализующее идею, которая планировалась на psoc-5. Cypress(первопроходец) не выставлялся.

Увы, zltigo прав. Профессионалу не нужны рюшечки, ему нужно ехать.
Одна только невозможность использования системы контроля версий совместно с креатором вызывает отторжение.