Среда разработки: 16 лучших сред для веб-разработки

Среда разработки программного обеспечения — это… Что такое Среда разработки программного обеспечения?



Среда разработки программного обеспечения

(Интегрированная) среда разработки программного обеспечения (англ. IDE, Integrated development environment) — система программных средств, используемая программистами для разработки программного обеспечения.

Обычно среда разработки включает в себя текстовый редактор, компилятор и/или интерпретатор, средства автоматизации сборки и отладчик. Иногда также содержит средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов — для использования при объектно-ориентированной разработке ПО. Хотя и существуют среды разработки, предназначенные для нескольких языков — такие как Microsoft Visual Studio, обычно среда разработки предназначается для одного определённого языка программирования — как например, Visual Basic.

Примеры сред разработки — Eclipse, Sun Studio, Turbo Pascal, Borland C++, GNU toolchain, DrPython, Borland Delphi, Dev-C++, KDevelop, XCode.

Частный случай ИСР — среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы.

См. также

Wikimedia Foundation.
2010.

• Международная космическая станция
• Мифология майя

Смотреть что такое «Среда разработки программного обеспечения» в других словарях:

• Перечень школьного программного обеспечения — Содержание 1 Бразилия 2 Великобритания 3 Индия …   Википедия

• Жизненный цикл программного обеспечения — (ПО) период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл процесс построения и развития ПО. Содержание 1 Стандарты… …   Википедия

• Интегрированная среда разработки приложений — (Интегрированная) среда разработки программного обеспечения (англ. IDE, Integrated development environment) система программных средств, используемая программистами для разработки программного обеспечения. Обычно среда разработки включает в себя… …   Википедия

• Интегрированная среда разработки — У этого термина существуют и другие значения, см. IDE. Интегрированная среда разработки, ИСР (англ. IDE, Integrated development environment или integrated debugging environment)  система программных средств, используемая программистами… …   Википедия

• Eclipse (среда разработки) — У этого термина существуют и другие значения, см. Eclipse. Eclipse …   Википедия

• Спецификация программного обеспечения — Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS)  законченное описание поведения программы, которую требуется разработать. Включает ряд пользовательских сценариев (англ. use… …   Википедия

• Список программного обеспечения, написанного на языке программирования Python — Python  стабильный и распространённый язык. Он используется во многих проектах и в различных качествах: как основной язык программирования или для создания расширений и интеграции приложений. На Python реализовано большое количество проектов …   Википедия

• ОСТ 1 00341-86: Системы технологического программного обеспечения на основе языка высокого уровня для бортовых цифровых вычислительных машин. Принципы построения — Терминология ОСТ 1 00341 86: Системы технологического программного обеспечения на основе языка высокого уровня для бортовых цифровых вычислительных машин. Принципы построения: Аварийная ситуация Прекращение (завершение) выполнения какого либо… …   Словарь-справочник терминов нормативно-технической документации

• Среда визуальной разработки — Проверить нейтральность. На странице обсуждения должны быть подробности. Среда визуальной разработки среда разработки программного обеспечения, в которой наиболее распространенные блоки программного кода представлены в в …   Википедия

• среда — 3.3.3 среда (environment): Связь между синтаксисом и семантикой. Примечание В контексте настоящего стандарта объект environment привязывает к объекту generic variable (синтаксису) соответствующее ему значение (семантику), представленное объектом… …   Словарь-справочник терминов нормативно-технической документации

Лучшие IDE для Java | GeekBrains

7 номинаций, чтобы никого не обидеть.

https://d2xzmw6cctk25h.cloudfront.net/post/910/og_cover_image/9d8d4993c138cdc1ead4b586d6a0fd67

В прошлый раз мы постарались объять необъятное, вспомнив несколько наиболее популярных и универсальных сред разработки. Опыт получился не слишком удачным, поэтому в этот раз мы сконцентрируемся только на одном языке, а именно Java. Если вы только начинаете знакомиться с ним, рекомендуем пройти бесплатный интенсив по Java-программированию. 

Учредив 7 номинаций, субъективно определим лучшие из лучших:

Лучшая бесплатная IDE: NetBeans

NetBeans — мощнейшая среда разработки с открытым исходным кодом, ориентированная на интернет, мобильные и настольные приложения. Работает с Linux, Windows, MacOS и даже Oracle Solaris.

Несмотря на то, что NetBeans позволяет работать на нескольких языках, в среде разработчиков она считается Java-ориентированной. Она прекрасно взаимодействует с JPA, JSP, Struts, Spring и библиотекой Hibernate.

Ссылка на скачивание.

Лучшая коммерческая IDE: IntelliJ IDEA

По правде говоря, IntelliJ IDEA распространяется в двух версиях, одна из которых совершенно бесплатная — Free Community Edition. Причём для начинающего разработчика данного пакета хватит с головой. В частности, IDE Android Studio, речь о которой пойдёт чуть позднее, основана именно на этой версии.

В платной же версии вы получаете поддержку фреймворков Spring (Spring MVC framework, Spring Security, Spring Boot, Spring Integration и т. д.), Node.js, Angular React, Grails, возможность использовать дополнительные языки (javascript, typescript, coffeescript) и взаимодействовать почти со семи популярными серверами (Tomcat, TomEE, GlassFish, JBoss, WildFly, Weblogic, WebSphere, Geronimo, Virgo и т. д.).

Ссылка на скачивание.

Самая популярная IDE: Eclipse

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

Ссылка на скачивание.  

Cамая универсальная IDE: JDeveloper

Ещё один продукт от Oracle с массой преимуществ, среди которых поддержка системы контроля версий и облачного сервиса Oracle, он упакован SQL Developer,  PL / SQL обработчиком запросов, WebLogic Server, редакторами HTML, CSS, JavaScript, JSF, JSP, WSDL и ещё огромным количеством всевозможных полезностей.

Ссылка на скачивание.

Лучшая для Android: Android Studio

Было бы странно, если победителем в этой номинации стала какая-нибудь другая IDE. Помимо всех возможностей, который вам дарит исходная IDE IntelliJ IDEA, Android Studio включает в себя немало надстроек от Google, как чисто визуальных (макеты, форматы, GPU профайлер), так и функциональных (JUnit 4 и Firebase Test Lab для тестирования и отладки, система сборки Gradle, Instant Run).

Ссылка на скачивание.

Лучшая IDE для обучения: DrJava

Именно к такому выводу пришла команда разработчиков под названием JavaPLT,  представляющие университет Райса. Оно и неудивительно, учитывая, что DrJava — их детище. Впрочем, оставив шутки в стороне, стоит признать, что DrJava действительно прекрасно подойдёт новичкам, ведь данная IDE даже не ставит своей целью соперничество с выше названными. Главное её преимущество — предельно быстрая настройка и переход к непосредственному написанию кода. В качестве конкурентов можно на схожих условиях рассмотреть BlueJ, JGrasp и Greenfoot.

Ссылка на скачивание.

Самая перспективная IDE: MyEclipse

Приветственная надпись на странице скачивания гласит “The best Java EE IDE enhanced for the full stack developer”. Что ж, это весьма нескромно, совсем не подкреплено фактами, но по правде говоря — недалеко от истины. В сущности,  MyEclipse — это Eclipse, где всё изначально “привинчено”, “допилено” и ещё немного расширено. К услугам разработчика предлагается несколько версий, две основные — стандартная и профессиональная. Стандартная — это как раз Eclipse в новой оболочке, а Professional содержит мобильный веб-симулятор, редактор картинок, UML-редактор, шаблоны, надстройки — в общем, всё, что сделает создание продукта значительно проще.

Ссылка на скачивание.

А чем пользуетесь вы?

Интегрированная среда разработки — Википедия

Интегри́рованная среда́ разрабо́тки, ИСP (англ. Integrated development environment — IDE), также единая среда разработки, ЕСР — комплекс программных средств, используемый программистами для разработки программного обеспечения (ПО).

Среда разработки включает в себя:

Иногда содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов — для использования при объектно-ориентированной разработке ПО. ИСР обычно предназначены для нескольких языков программирования — такие как IntelliJ IDEA, NetBeans, Eclipse, Qt Creator, Geany, Embarcadero RAD Studio, Code::Blocks, Xcode или Microsoft Visual Studio, но есть и IDE для одного определённого языка программирования — как, например, Visual Basic, Delphi, Dev-C++.

Частный случай ИСР — среды визуальной разработки, которые включают в себя возможность наглядного редактирования интерфейса программы.

Обзор

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

ИСР обычно представляет собой единственную программу, в которой проводится вся разработка. Она, как правило, содержит много функций для создания, изменения, компилирования, развертывания и отладки программного обеспечения. Цель интегрированной среды заключается в том, чтобы объединить различные утилиты в одном модуле, который позволит абстрагироваться от выполнения вспомогательных задач, тем самым позволяя программисту сосредоточиться на решении собственно алгоритмической задачи и избежать потерь времени при выполнении типичных технических действий (например, вызове компилятора). Таким образом, повышается производительность труда разработчика. Также считается, что тесная интеграция задач разработки может далее повысить производительность за счёт возможности введения дополнительных функций на промежуточных этапах работы. Например, ИСР позволяет проанализировать код и тем самым обеспечить мгновенную обратную связь и уведомить о синтаксических ошибках.

Большинство современных ИСР являются графическими. Но первые ИСР использовались ещё до того, как стали широко применяться операционные системы с графическим интерфейсом — они были основаны на текстовом интерфейсе с использованием функциональных и горячих клавиш для вызова различных функций (например, Turbo Pascal, созданный фирмой Borland).

История

Клавиатура Maestro^[1]

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

Dartmouth BASIC был первым языком, который был создан с ИСР, и был также первым, который был разработан для использования в консоли или терминале. Эта ИСР (часть Dartmouth Time Sharing System) управлялась при помощи команд, поэтому существенно отличалась от более поздних, управляемых с помощью меню и горячих клавиш, и тем более графических ИСР, распространённых в XXI веке. Однако она позволяла править исходный код, управлять файлами, компилировать, отлаживать и выполнять программы способом, принципиально подобным современным ИСР.

Maestro I — продукт от Softlab Munich, был первой в мире интегрированной средой разработки для программного обеспечения в 1975 г.^[2] и, возможно, мировым лидером в этой рыночной нише в течение 1970-х и 1980-х годов. Он был установлен у 22000 программистов во всем мире. До 1989 года 6000 копий было установлено в Федеративной Республике Германия. Ныне Maestro I принадлежит истории и может быть найден разве что в Музее Информационной технологии в Арлингтоне.

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

Пометки в комментариях

Единые среды разработки также часто поддерживают пометки в комментариях в исходном тексте программ, отмечающие места, требующие внимания в будущем или предполагающие внесение изменений в дальнейшем, такие как TODO, FIXME и т. п.^[3][4]

См. также

Примечания

Идеальная среда разработки для PIC — личный опыт / Хабр

В связи с нововведениями на сайте, решил наконец-то вылезти из подполья и написать что-нибудь полезное. Ну а поскольку я программирую разные микроконтроллеры (МК) и являюсь фанатом Eclipse, то решил про это и написать. Начну со своей истории знакомства с программированием PIC, а закончу советами тем, кто по долгу службы или в силу увлечения программирует на МК семейства PIC, хотя, впрочем, эти же советы сгодятся и для других архитектур МК.

В среду железячников я попал в 2006 году на 4-м курсе учёбы в университете, когда пошёл на производственную практику в научно-технический центр, где, собственно, и работаю по сей день. В то время в нашей компании мейнстримом было использование Keil uVision2 для МК на базе C51 и ARM. Однако мне подсовывали простые задачи под PIC, вроде контроля и управления одним сигналом (кнопка вкл-выкл), и моей первой средой разработки были блокноты — бумажный и компьютерный, плюс книжки бумажные по PIC. Выглядела моя среда разработки примерно так:

Для компиляции файлов мне выдали экзешник компилятора и bat-файл, который использовался мной совершенно бездумно — даже не знаю, что за компилятор там был. В общем, суровые были времена…

Ах, если бы мне кто-то тогда подсказал, что есть такое чудо, как notepad++!

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

MPLAB IDE

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

В её состав входят:

• CC18 и ещё какой-то компилятор, которые можно выбирать в настройках проекта;
• хороший набор библиотечных функций;
• подключаемые inc-файлы описания МК семейства PIC, заточенные под использование в ассемблере;
• встроенный отладчик и программатор;
• Но главное — поддержка языка Си — это был для меня глоток свежего воздуха!

Хотя, если присмотреться к этой среде разработки, её убогость и отсталость могут отпугнуть любого мало-мальски привыкшего к хорошим условиям программиста, но я тогда об этом не знал. Справку по встроенным библиотечным функциям надо открывать отдельно и искать, что, где и как называется. Для новичков — непосильная задача. Тем не менее, на тематических форумах люди до сих пор спрашивают, какой компилятор лучше использовать; кто-то так и продолжает использовать MPLAB IDE.

MikroC

Задачи для PIC мне подкидывали всё реже и реже, начали набирать обороты разработки с МК серии C51, ARM7 (не путать с ARMv7!), Cortex-M. Но иногда ко мне снова обращались за помощью в написании программ под PIC, а я в силу любопытства пробовал новые средства разработки.
К тому времени уже давно и активно программировал в Keil uVision3 — возвращаться к допотопному MBLAB IDE совершенно не хотелось. Так я познакомился с MikroC, который поставляется вместе с программаторами PICKit:

Набор плюшек почти такой же как в MBLAB IDE, но всё же побогаче:

• свой собственный компилятор
• встроенные библиотеки функций с удобным поиском и доступным описанием;
• подключаемые h-файлы описания МК семейства PIC;
• набор дополнительных внешних утилит
• широкий спектр примеров с исходниками
• встроенный отладчик и программатор;
• встроенные вкладки открытых файлов;
• навигация по функциям в файле

Честно, для маленьких простых проектов, которые и составляют основную нишу программ под PIC, этого вполне достаточно. Даже новички нормально разбираются с помощью справки и быстро делают рабочий код. Большинство наших разработчиков, имеющих дело с PIC, используют эту среду при разработке.

Так или иначе, сделав очередной проект в MikroC, я благополучно забыл про PIC’и и думал, что уже никогда к ним не вернусь.

Однако история любит повторяться!

Через 3 года, в 2013 году, появилась задача разработать ПО по готовой КД, в которой был заложен PIC18F4680. Честно, я даже не знал, что среди PIC’ов бывают такие монстры, всегда имел дело только с мелочью!

Задачи были нетривиальные — реализация загрузчика для внутрисхемного обновления ПО, работа в режиме жёсткого реального времени, работа с АЦП, внешними ЦАП, линиями управления, несколькими таймерами-компараторами.

Кстати, немного отвлекаясь от темы: только на этом проекте я в полной мере понял, что такое банки памяти в PIC, как они работают и какие ограничения накладывают на разработку ПО. К примеру, все банки у МК по 256 байт. И хоть убейся, но для PIC нельзя создать структуру, превыщающую по объёму эти 256 байт — ограничение всплыло наружу при реализации протокола обмена, ну да ладно, проехали…

К этому времени Keil uVision3 мне уже изрядно поднадоел, поскольку сложность проектов росла и мне не хватало имевшегося в Keil функционала. Где-то с 2011 года я освоил Eclipse, GCC, синтаксис makefile — и все свои проекты начал вести с использованием этих инструментов. К тому же, у меня уже был опыт применения связки Eclipse + SDCC для реализации проекта под C51 МК. После появления Keil uVision4 я его установил, протестировал пол-часика и снёс, ибо по удобству программирования он всё равно сильно отстаёт от Eclipse.

Eclipse + SDCC

В настоящее время Eclipse де-факто является стандартом в области разработки ПО для встраиваемых систем. Вот список IDE, основанных на Eclipse, от популярных брендов:

• NXP LPCXpresso IDE
• Freescale CodeWarrior
• Xilinx Platform Studio
• Texas Instruments CCS
• Android Development Tools

Автоподстановка, всплывающие подсказки по автодополнению, макросы, затемнение неактивных участков кода, удобная навигация по коду и многое-многое другое, — я не буду всё перечислять, — многие разработчики встраиваемых систем совершенно не привыкли и не знают всех этих плюшек, значительно облегчающих жизнь:

Главной проблемой чистого Eclipse для разработки на C/C++ под МК является сложность вхождения в него железячных программистов, замена привычных инструментов, работающих после установки в 1-2 клика, на какие-то плагины, требующие настройки, или, что ещё хуже, на вручную написанные makefile — всё это требует значительных первоначальных усилий по чтению и изучению документации, поиску помощи и пособий для начинающих в интернете. Говорю как человек, имеющий опыт по переводу команды программистов-железячников на Eclipse.

Только для моей команды разработчиков

Коли прочитали эту статью — дайте знать, я хоть узнаю, как у нас читают профильные хабы на Хабрахабре

Однако, за месяц полностью освоив синтаксис и один раз написав качественный makefile, все остальные проекты создаются по накатанному шаблону и требуют лишь минимальной индивидуальной настройки.

Также пришлось сделать ряд дополнительных телодвижений по настройке проектов под PIC — по умолчанию Eclipse понимает синтаксис GCC. Различные макросы и директивы, встроенные в другие компиляторы (будь то СС18 или SDCC), приходится разделять на этапе компиляции и на этапе индексации проекта. Чтобы при навигации в коде редактор не выдавал ложных ошибок на неизвестные директивы, к исходникам проекта подключается файл eclipse-syntax.h:

eclipse-syntax.h

#ifndef ECLIPSE_SYNTAX_H_
#define ECLIPSE_SYNTAX_H_

// keyword SDCC defined when compiling with SDCC compiler
#ifndef SDCC

	#ifdef __SDCC_PIC18F4680
		#error "SDCC not found, project compile will be with errors!"
	#endif

	// file not parsed through makefile - just for proper eclipse syntax
	#ifndef __CC18__
		#error "__CC18__ not found, use `-D__CC18__` in makefile for proper CC18 compilation!"
		#define near
		#define far
		#define rom
		#define ram
		#define _asm
		#define _endasm
		#define Nop()
		#define ClrWdt()
		#define Sleep()
		#define Reset()
		#define clrwdt
		#define nop

		#define __code
		#define __data
		#define __xdata

		#define __sfr
		#define __sbit

		#define __naked
		#define __wparam

		#define __bit char
		#define __at(num)

	#else	//	__CC18__ defined - compile stage!
	#endif	// __CC18__

	#define __inline

	#define __asm
	#define __endasm

	#define __interrupt(x)
	#define INTERRUPT(x)

	#define USING(x)

	#define CRITICAL

	#define CRITICAL_START
	#define CRITICAL_END

	#define _REENTRANT

#else	// if SDCC defined

	#define INTERRUPT(x) __shadowregs __interrupt (x)

	//#define USING(x) __using (x)
	#define USING(x)

	#define CRITICAL __critical

	#define CRITICAL_START __critical {
	#define CRITICAL_END }
#endif	// SDCC defined

#endif /* ECLIPSE_SYNTAX_H_ */

Кроме того, в SDCC у меня не получилось слинковать большой проект в готовый бинарник — потребовалось также настроить GPUtils, в состав которого входят gpasm, gpdasm, gplink и скрипты .lkr карт памяти МК PIC. Правда, из-за одного найденного мной бага в SDCC на этапе отладки кода я в итоге вернулся на CC18 компилятор и линковщик. Тем не менее, SDCC и GPUtils были полностью настроены — для страждущих привожу часть makefile, касающуюся опций запускаемых компиляторов и линковщиков CC18, SDCC, GPUtils:
Кусочки makefile

###########################################################
# project-specific compile options
###########################################################
# Project definitions
CHIP = 18F4680
DEFINES := -DPIC$(CHIP)
#DEFINES += -D__SDCC_PIC$(CHIP)	# use SDCC compiler
DEFINES += -D__CC18__	# use MPLAB CC18 compiler
#DEFINES += -DOPTIMIZE_BITFIELD_POINTER_GET	# SDCC memory optimize for bitfield structures
###########################################################
#  common part for all sdcc-based projects
###########################################################
	SDCC_BASE = c:/DevTools/SDCC
	CC		= "$(SDCC_BASE)/bin/sdcc.exe"
	LD		= "$(SDCC_BASE)/bin/sdcc.exe"
	ELF2HEX	= "$(SDCC_BASE)/bin/packihx.exe"
	HEX2BIN = "$(SDCC_BASE)/bin/makebin.exe"
	
###########################################################
#  common part for all MPLAB MCC18-based projects
###########################################################
	MPLAB_BASE	= c:/DevTools/CC18
	CC_MPLAB	= "$(MPLAB_BASE)/bin/mcc18.exe"
	AS_MPLAB	= $(MPLAB_BASE)/mpasm/mpasmwin.exe
	LD_MPLAB	= $(MPLAB_BASE)/bin/mplink.exe

###########################################################
# GPUtils used with SDCC for linking project
###########################################################
	GPUTILS_BASE = c:/DevTools/GNUPICutils
	GPASM	= "$(GPUTILS_BASE)/bin/gpasm.exe"
	GPDASM	= "$(GPUTILS_BASE)/bin/gpdasm.exe"
	GPLINK	= "$(GPUTILS_BASE)/bin/gplink.exe"

###########################################################
# C preprocessor flags for MPLAB MCC18 compiler
###########################################################
#optimization parameters (default = full optimization)
OPT_ENABLE_ALL	:= -O+	# Enable all optimizations (default)
OPT_DEBUG		:=-Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
OPT 	:=$(OPT_ENABLE_ALL)
#OPT 	:=$(OPT_DEBUG)

CFLAGS_MPLAB := -p $(CHIP)
CFLAGS_MPLAB += -I $(MPLAB_INC_DIR)
CFLAGS_MPLAB += -nw=2066	# suppress Warning [2066] type qualifier mismatch in assignment
CFLAGS_MPLAB += -ml	# Large memory model
CFLAGS_MPLAB += -ls # large stack (can span multiple banks)
#CFLAGS_MPLAB += -scs # Enable default static locals
#CFLAGS_MPLAB += -sco # Enable default overlay locals (statically allocate activation records). Ignored if set --extended
CFLAGS_MPLAB += --extended	# generate extended mode code

COMPILE_MPLAB_STRING=$(CC_MPLAB) $(CFLAGS_MPLAB) $< -fo=$@ $(DEFINES) $(OPT)

AFLAGS_MPLAB := /y
AFLAGS_MPLAB += /rDEC				# set default radix HEX/DEC/OCT
AFLAGS_MPLAB += /l-				# disable listing file
#AFLAGS_MPLAB += /l$(OBJDIR_MPLAB)	# enable listing file
AFLAGS_MPLAB += /o	# specify path for object files
#AFLAGS_MPLAB += /o$(OBJDIR_MPLAB)	# specify path for object files
#AFLAGS_MPLAB += /q					# enable quiet mode 
AFLAGS_MPLAB += /d__LARGE__			# define symbol
AFLAGS_MPLAB += /p$(CHIP)			# set processor type

#ASSEMBLE_MPLAB_STRING=$(AS_MPLAB) $(AFLAGS_MPLAB) %<

# used linker script
LDFLAGS_MPLAB := $(CHIP)_g.lkr
# objects to compile
LDFLAGS_MPLAB += $(OBJS_MPLAB)
LDFLAGS_MPLAB += $(MPLAB_LIBS)
# specify chip for proper linking
LDFLAGS_MPLAB += /p$(CHIP)
# verbose mode operation
#LDFLAGS_MPLAB += /v
# generate report file for stack analysis
LDFLAGS_MPLAB += /g
# generate .LST file and no .COD file
LDFLAGS_MPLAB += /i
# do not invoke MP2COD (no .COD or .LST file)
LDFLAGS_MPLAB += /w
# link MPLAB libs
LDFLAGS_MPLAB += /l $(MPLAB_LIB_DIR)
# generate MAP file
LDFLAGS_MPLAB += /m $(EXEDIR)/$(PROJECT_NAME)_mplab.map
# set output file
LDFLAGS_MPLAB += /o $(EXEDIR)/$(PROJECT_NAME)_mplab.hex

###########################################################
# C preprocessor flags for SDCC v.3.3.0 compiler
###########################################################
# ----- processor selection -----
 CFLAGS := -m$(ARCH)
 CFLAGS += -p$(CHIP)
 
# ----- preprocessor options -----
 CFLAGS += $(INCS)
 CFLAGS += $(DEFINES)
 
# ----- verbose & dependancy generate -----
# CFLAGS += -M # generate dependencies
# CFLAGS += -E #
# CFLAGS += -C # dont discard comments
 
 CFLAGS += -c # dont link file (i.e. have multiple source files)
  
 CFLAGS += $(DEBUG)

# ----- common settings -----
#CFLAGS += --nostdinc # This will prevent the compiler from passing on the
					  # default include path to the preprocessor.
#CFLAGS += --nostdlib # This will prevent the compiler from passing on the
 					  # default library path to the linker.

#CFLAGS += --less-pedantic # Disable some of the more pedantic warnings.

 CFLAGS += --stack-auto # All functions in the source file will be compiled as reentrant.
						# It automatically implies --int-long-reent and --float-reent.
CFLAGS += --int-long-reent # Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant.
CFLAGS += --float-reent # Floating point library is compiled as reentrant.

#CFLAGS += --no-peep
#CFLAGS += --funsigned-char # The default signedness for every type will be unsigned.
#CFLAGS += --cyclomatic # This option will cause the compiler to generate an information
 						# message for each function in the source file. The message contains
 						# the number of edges and nodes the compiler detected in the
 						# control flow graph of the function, and most importantly
						# the cyclomatic complexity.

# ----- optimization options -----
#CFLAGS += --nogcse # Will not do global subexpression elimination, this option may be used
 					# when the compiler creates undesirably large stack/data spaces to store
 					# compiler temporaries.
#CFLAGS += --noinvariant # Will not do loop invariant optimizations.
#CFLAGS += --noinduction # Will not do loop induction optimizations.
#CFLAGS += --nojtbound # Will not generate boundary condition check when switch statements
 						# are implemented using jumptables.
#CFLAGS += --noloopreverse # Will not do loop reversal optimization.
#CFLAGS += --nolabelopt # Will not optimize labels (makes the dumpfiles more readable).
 CFLAGS += --nooverlay # The compiler will not overlay parameters and local variables of any function.
 CFLAGS += --peep-asm # Pass the inline assembler code through the peep hole optimizer.
 #CFLAGS += --opt-code-speed # Optimize for code speed rather than size
 #CFLAGS += --opt-code-size # Optimize for code size rather than speed
 CFLAGS += --fomit-frame-pointer # Frame pointer will be omitted when the function uses
								 # no local variables.
 CFLAGS += --use-non-free #  Search / include non-free licensed libraries and header files

# ----- special options for pic16 port of SDCC -----
 CFLAGS += --pstack-model=large	# use stack model 'small' (default) or 'large'
# don't use extended instruction set - SDCCman, $4.6.20.1 Known Bugs
#CFLAGS += -y --extended 		# enable Extended Instruction Set/Literal Offset Addressing mode
#CFLAGS += --pno-banksel        # do not generate BANKSEL assembler directives
 CFLAGS += --obanksel=2         # set banksel optimization level (default=0 no)
 CFLAGS += --denable-peeps      # explicit enable of peepholes
 CFLAGS += --no-optimize-goto   # do NOT use (conditional) BRA instead of GOTO
 CFLAGS += --optimize-cmp       # try to optimize some compares
 CFLAGS += --optimize-df        # thoroughly analyze data flow (memory and time intensive!)
#CFLAGS += --preplace-udata-with=udata_shr # Place udata variables at another section: udata_acs, udata_ovr, udata_shr
#CFLAGS += --ivt-loc=           # Set address of interrupt vector table.
#CFLAGS += --nodefaultlibs      # do not link default libraries when linking
#CFLAGS += --use-crt=           # use <crt-o> run-time initialization module
#CFLAGS += --no-crt             # do not link any default run-time initialization module
#CFLAGS += --mplab-comp         # enable compatibility mode for MPLAB utilities (MPASM/MPLINK)
#CFLAGS += --asm=               # Use alternative assembler
#CFLAGS += --link=              # Use alternative linker
 CFLAGS += --debug-xtra         # show more debug info in assembly output
 CFLAGS += --debug-ralloc       # dump register allocator debug file *.d
 CFLAGS += --pcode-verbose      # dump pcode related info
 CFLAGS += --calltree           # dump call tree in .calltree file
#CFLAGS += --gstack             # trace stack pointer push/pop to overflow

###########################################################
# linker flags
###########################################################
#gputils (GNU PIC Utils) used to link objects and libs.
 GPLINK_FLAGS	= -c -m -w -r -I $(LIBDIR) -s $(GPUTILS_BASE)/lkr/$(CHIP)_g.lkr
 
#SDCC linker not used
 #LDFLAGS := -m$(ARCH)
 #LDFLAGS += $(DEBUG)
 #LDFLAGS += --profile

 #LDFLAGS += --code-size $(FLASH_SIZE) # Code Segment size
#LDFLAGS += --code-loc $(FLASH_LOC) # The start location of the code location, default value is 0

 #LDFLAGS += --iram-size $(IRAM_SIZE) # Internal Ram size

#LDFLAGS += --xram-loc $(XRAM_LOC) # The start location of the external ram, default value is 0
#LDFLAGS += --xram-size $(XRAM_SIZE) # External Ram size

#LDFLAGS += --stack-loc $(STACK_LOC) # By default the stack is placed after the data segment.
 									 # Using this option the stack can be placed anywhere in the
 									 # internal memory space of the 8051.

##############################################################################
# MPLAB CC18 compiler - linker 
$(HEX_MPLAB): $(OBJS_MPLAB) Makefile
	@echo "--- CC18 Linking objects to $(HEX_MPLAB) ..."
	@$(LD_MPLAB) $(LDFLAGS_MPLAB)

##############################################################################
# SDCC compiler - linker 
$(HEX): $(OBJS) Makefile
	@echo "--- SDCC Linking objects to $(HEX) ..."
	$(GPLINK) $(GPLINK_FLAGS) -o $(HEX) $(OBJS) $(LIBS)
	$(GPDASM) -p$(CHIP) $(HEX) > $(DASM)

Эпилог

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

Собирая воедино все средства разработки, вот список компиляторов, которыми я пользуюсь в связке с Eclipse и получаю от этого истинное удовольствие при программировании:

• CC18 для PIC
• SDCC для C51
• gnu-arm-embedded для ARM7 и Cortex-M
• MinGW для x86

Очевидно, при необходимости список может легко дополняться.

Надеюсь, прочитав мою историю, кто-то решится наконец для себя сойти со старых IDE и освоить новые.

Дерзайте!

Среда разработки C++? — Хабр Q&A

Расскажу о прелястях vim
1) Скорость. vim запускается за пару сотен милисикунд в отличии от всяких там IDE у котороых даже есть прогрес бар загрузки. При этом ему не нужно ни памяти ни процесора, его в системе вообще не видно. Можно этих vim-ов назапускать столько, сколько сможешь во внимании удержать, системе от этотго тяжело не будет.
2) Скорость набора. Все что тебе нужно для вима — это клавиатура. даже стрелочки не нужны и numpad не нужен. Как следствие из этого руки с клавиатуры вообще не уходят и если работать на ноуте до не ощущаешь ущербности клавиатуры.
3) Удобнейший набор шоркатов для перемещения по тексту и его редактированию. После vim все обычне редакторы кажутся такими убогими, что иногда становится грустно.
4) Простота на в настроке. В идеале для настройки vim нужен только один файл ~/.vimrc (если использовать vundel то все плагины подгружаются автоматом) то есть если тебе нужно вдруг сесть за другой комп, то все что тебе нужно это только этот файл. В тех же поди еще разберись что за собой таксать нужно.
5) vim это в основном консольный редактор — работать на удаелнных серверах с IDE очень проблемотично
6) vim не привязывает тебя к какой-то конкретной системе сборки — и это насамом деле самое крутое отличие «текстовых редакторов» от всяких IDE которые в основном нормально работают только со своей системой сборки, а остальные если и поддерживаю то поддерживают для галочки.

Для старта я тебе посоветую только для плагина — vundle и YouCompleteMe
их для начала хватит с головой. Дальше сам разбирешься.

По критериям:
Основные критерии:
1.Кроссплатформенность. — есть везде (Win, Linux, OS X)
2.Удобная работа с файлами. — буферы и NERDTree делают свое дело
3. Возможность гибкой настройки. — гибче не бывает (есть встроеный скриптовый язык — можно писать свои команды и функции, но в оснвном это не надо из коробки умее все что нужно)
4.Красивый дизайн. — нет ничего кроме окна ввода, так что дизайн самый лучший его просто нет. Но шрифты и цветовые схемы можно настравить и есть готоые паки)

новейших вопросов о среде разработки — Stack overflow на русском

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

.Новые ответы

‘development-environment’ — qaru

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

Среда разработки SDSoC

Название платы	Ввод / вывод включен	Поддерживаются последние SDSoC	Примеры дизайна	Провайдер
TySOM-2-7Z045 + FMC-ADAS + HDR-CMOS Датчик камеры (192 градуса) с интерфейсом передачи данных LVDS	Интерфейс FPD-Link III LVDS, HDMI OUT, USB2.0, Ethernet 10/100/1000	2017.2 (путь к платформам github)	Обнаружение края по Собелю	Альдек
TySOM-2-7Z045 + FMC-ADAS + FMC-VISION + HDR-CMOS Датчик камеры (192 градуса) с интерфейсом передачи данных LVDS	Интерфейс FPD-Link III LVDS, HDMI OUT, USB2.0, Ethernet 10/100/1000	2017.2 (путь к платформам github)	Обнаружение края по Собелю
TySOM-2-7Z100 + FMC-ADAS + HDR-CMOS датчик камеры (192 градуса) с интерфейсом передачи данных LVDS	Интерфейс FPD-Link III LVDS, HDMI OUT, USB2.0, Ethernet 10/100/1000	2017.2 (путь к платформам github)	Обнаружение края по Собелю
TySOM-2-7Z100 + FMC-ADAS + FMC-VISION + HDR-CMOS Датчик камеры (192 градуса) с интерфейсом передачи данных LVDS	Интерфейс FPD-Link III LVDS, HDMI OUT, USB2.0, Ethernet 10/100/1000	2017.2 (путь к платформам github)	Обнаружение края по Собелю
TySOM-2A-7Z030 + FMC-ADAS + HDR-CMOS Датчик камеры (192 градуса) с интерфейсом передачи данных LVDS	Интерфейс FPD-Link III LVDS, HDMI OUT, USB2.0, Ethernet 10/100/1000	2017.2 (путь к платформам github)	Обнаружение края по Собелю
Комплект PicoZed Embedded Vision	Python 1300 вход, выход HDMI, PS DDR	2016.2	Optical Flow, Stereo Disparity, Sobel Filter, Motion Detect	Avnet
Комплект встроенного оборудования MicroZed	Python 1300 вход, выход HDMI, PS DDR	2016,2	Optical Flow, Stereo Disparity, Sobel Filter, Motion Detect	Avnet
ZC706	PL DDR, PS DDR	2016,2	Matrix Multiply с использованием PL DDR	Xilinx
PYTHON-1300-C +, HDMI IO FMC	Python 1300 вход, HDMI вход, HDMI выход, PS DDR	2015.4	Фильтр Собеля, детектор движения	Avnet
Zing2 + HDMI IO FMC	HDMI ВХОД, HDMI ВЫХОД, GPIO, PS, DDR3	2016,2	Basic Suite *, RGB2HSV, фильтр Собеля, обнаружение краев	Технология V3
SNOWLeo SVC	CMOS IN, HDMI OUT, GPIO, PS, DDR3	2016,2	Basic Suite *, RGB2HSV, фильтр Собеля, обнаружение краев	Технология V3
EMC2-Z7015	PS DDR	2015.4	Basic Suite *, фильтр Собеля, обнаружение движения	Сандэнс
БОРА	LVDS Video Out, PS DDR	2015,4	Basic Suite *, фильтр Собеля, обнаружение движения	Встраиваемые системы DAVE
BORA Xpress	LVDS Video Out, PS DDR	2015,4	Basic Suite *, фильтр Собеля, обнаружение движения	Встраиваемые системы DAVE
СВДК PicoZed 7015	Датчик СВДК в Ethernet (GigE Vision) выход HDMI выход	2015.4	Базовый пакет *, GigE-Vision1.2 Tx, OpenCV Harris Corner Detect / SDSoC Corner Detect (Harris Corner Acceleration)	OKI IDS

.

No related posts.