Комментарии 27
Ужасный, кривой UI. Не выровненные контролы. Бредовое расположение кнопок. Все это похоже на поделку школьника. Автору учить гайды по проектированию интерфейсов в Win32.
Весь мой опыт говорит, что кривой UI = кривой код проекта, поэтому даже запускать не стану.
Весь мой опыт говорит, что кривой UI = кривой код проекта, поэтому даже запускать не стану.
Весь мой опыт ( 10+ на linux) говорит, об UI думают в последнюю очередь. В первую очередь функционал. И это один из самых больших минусов прикольных свободных проектов. Все усилия направляются на функционал проекта, а UI где-то в 10 очереди. Как итог, выигрывают проекты с меньшим функционалом, но более удобным интерфейсом.
ну тут еще прямо скажем пробный камень… многие вещи что здесь реализованы я писал впервые, а по поводу дизайна — никто не задумывался что не все умеют делать красивые интерфейсы?.. у меня вот нет этого чувства гармонии и стиля… готов принять помощь…
но вообще конечно все буду переписывать наверное под WPF, сейчас интерфейс мне не нравиться, и многие задумки не знаю как реализовать на паскале
но вообще конечно все буду переписывать наверное под WPF, сейчас интерфейс мне не нравиться, и многие задумки не знаю как реализовать на паскале
Я бы попросил добавить в статью информацию о кроссплатформенности проекта — only Window, Win & Linux?
только Win, причем сама среда позволяет компилировать под линукс, но в коде много Win зависимого кода…
да и нет у меня линукса, так что проверять не на чем и коль нет человека который бы решал те или трудности — то и заморачиваться я не буду (нет времени на это)
да и нет у меня линукса, так что проверять не на чем и коль нет человека который бы решал те или трудности — то и заморачиваться я не буду (нет времени на это)
А вам, простите, шашечки или ехать?
А не быстрее бы было сделать это плагином к Visual Studio Code? Кажется, что массу типового для IDE кода можно бы было не писать
вот только что общался по поводу vscode… ничего хорошего мне в итоге не сказали… на сим я вопрос окончательно закрываю
В каком смысле ничего хорошего не сказали? Кто и почему?
Я бы, к примеру хотел бы видеть хороший плагин для подсветки синтаксисов ассемблеров (а их вагон и маленькая тележка, не только для АРМ-ов) как в VSCode, так и в QtCreator. И чтобы оно как-то автоматом подсвечивало синтаксис в зависимости от типа выбранного компилятора/архитектуры (ну, или хотя — бы был выбор как подсветить).
А то вроде плагинов много — но выбрать нечего, т.к. они или узко-спецализированные для какой-то одной архитектуры/тулчейна, или что-нибудь еще не то. :)
Тем более, что эти IDE-шки универсальные, т.к. поддерживают такие системы сборки как CMake или Qbs (Qbs — лучший выбор, т.к. поддерживает чисто железячные компиляторы, а не только GCC прямо «из коробки»). И можно создав однажды проект в этих системах сборки, открывать его в любых IDE и компилировать.
Это я к тому, что незачем (ИМХО) распалять ресурсы на пиление чего-то своего, а лучшее решение — проанализировать что уже есть и попытаться улучшить.
Я бы, к примеру хотел бы видеть хороший плагин для подсветки синтаксисов ассемблеров (а их вагон и маленькая тележка, не только для АРМ-ов) как в VSCode, так и в QtCreator. И чтобы оно как-то автоматом подсвечивало синтаксис в зависимости от типа выбранного компилятора/архитектуры (ну, или хотя — бы был выбор как подсветить).
А то вроде плагинов много — но выбрать нечего, т.к. они или узко-спецализированные для какой-то одной архитектуры/тулчейна, или что-нибудь еще не то. :)
Тем более, что эти IDE-шки универсальные, т.к. поддерживают такие системы сборки как CMake или Qbs (Qbs — лучший выбор, т.к. поддерживает чисто железячные компиляторы, а не только GCC прямо «из коробки»). И можно создав однажды проект в этих системах сборки, открывать его в любых IDE и компилировать.
Это я к тому, что незачем (ИМХО) распалять ресурсы на пиление чего-то своего, а лучшее решение — проанализировать что уже есть и попытаться улучшить.
ну так то согласен… только с кем заниматься анализом? с теми кто устриц не ел...?
это не про вас… вообще про ситуацию…
то что вы описываете делают единицы, подсказать имеют возможность еще меньшее число (да их надо найти, им надо услышать, найти время на ответ, и чтобы вопрос им совсем ламерским не показался и наконец у них было время на ответ)
так что я может быть был бы и рад, но не люблю искать ответы в абстрактном гугле (очень и очень много времени уходит, и не всегда с результатом)
да и задачу надо было как то опробовать что ли алгоритмически, посмотрите исходный код — там много всяких заготовок, пробовал десятки вариантов пока нашел то что устраивает… и для этого хорошо это все пробовать на чем то простом, что знаешь и за примитивами к которому не нужно напрягать гугл, так как итак хватает алгоритмических и оптимизационных задач, чтобы еще терять время на задачи по осваивания не совсем понятного по возможностям нового языка в рамках работы плагином к какому то редактору… :-(
просто я реалист, начинать надо с чего то простого…
это не про вас… вообще про ситуацию…
то что вы описываете делают единицы, подсказать имеют возможность еще меньшее число (да их надо найти, им надо услышать, найти время на ответ, и чтобы вопрос им совсем ламерским не показался и наконец у них было время на ответ)
так что я может быть был бы и рад, но не люблю искать ответы в абстрактном гугле (очень и очень много времени уходит, и не всегда с результатом)
да и задачу надо было как то опробовать что ли алгоритмически, посмотрите исходный код — там много всяких заготовок, пробовал десятки вариантов пока нашел то что устраивает… и для этого хорошо это все пробовать на чем то простом, что знаешь и за примитивами к которому не нужно напрягать гугл, так как итак хватает алгоритмических и оптимизационных задач, чтобы еще терять время на задачи по осваивания не совсем понятного по возможностям нового языка в рамках работы плагином к какому то редактору… :-(
просто я реалист, начинать надо с чего то простого…
Автор вы молодец. Не обращайте внимание на негатив сверху. Так обычно пишут люди которые в своей жизни ничего сложного не делали. А так — вполне приятный интерфейс.
Что касается дела — а зачем ассемблер? Я в своё время написал тысячи строк на разных ассемблерах для многих видов MK, но когда перешёл на С — он сам собой отмер, за ненадобностью.
Опять же пользовался различными студиями но насколько помню наиболее приятная была Keil. И на асме там можно был писать.
На чём пишете прогу? VS?
Что касается дела — а зачем ассемблер? Я в своё время написал тысячи строк на разных ассемблерах для многих видов MK, но когда перешёл на С — он сам собой отмер, за ненадобностью.
Опять же пользовался различными студиями но насколько помню наиболее приятная была Keil. И на асме там можно был писать.
На чём пишете прогу? VS?
Когда был карантин и особо было делать нечего, то также подумал сделать для ARM Cortex свою IDE с перфокартами и канифолью. Начал пилить на C# и WPF, но спустя некоторое время понял, что в одно лицо все хотелки будет реализовать сложно (и/или долго).
Размышляя над целесообразностью дальнейшей разработки, вспомнил, что натыкался на материалы(раз, два), где к Visual Studio Code прикручивали компилятор GCC ARM вместе с отладкой. Однако для каждого проекта требовалось создание служебных файлов как для самой среды VSCode, так и для программируемого камня: мэйкфайл, стартап, скрипт линкера.
В итоге принял решение, что, конечно, своя IDE — это хорошо, но реализовывать то, что уже существует необходимости нет. Поэтому написал свое расширение для VSCode, которое автоматизирует создание проекта под определенный контроллер, его сборку и загрузку(OpenOCD или JLink), а также дебаг с помощью другого расширения.
Примерно месяц у меня ушел на базовый, но достаточный, функционал. С учетом того, что раньше с АПИ VSCode дел не имел и не писал на TypeScript. Сейчас потихоньку дополняю — недавно добавил pdf-viewer от Мозилы для просмотра мануалов и даташитов, которые автоматически загружаются для выбранного контроллера. Это заняло у меня несколько вечеров. Если бы все писал сам, то…
В VSCode полно расширений самых разных мастей и калибров: от подсветки кода и дополнения синтаксиса до аналога Тиндера. В основном это опенсорсные проекты, расположеные на гитхабе и среди них наверняка найдутся те, которые хотя бы частично, подойдут по функционалу и, при желании, их несложно переделать под свои нужды. Кроме того, насколько я знаю, можно сделать собственную сборку этого редактора, включив в нее только то, что необходимо.
Помимо VSCode существует множество других сред, типа Sublime, VIM, о которых, Автор наверняка знает. В них уже реализован необходимый минимум для работы: GUI, работа с файлами, вкладки с исходниками и т.д. Поэтому можно сосредоточится только на недостающем функционале.
Размышляя над целесообразностью дальнейшей разработки, вспомнил, что натыкался на материалы(раз, два), где к Visual Studio Code прикручивали компилятор GCC ARM вместе с отладкой. Однако для каждого проекта требовалось создание служебных файлов как для самой среды VSCode, так и для программируемого камня: мэйкфайл, стартап, скрипт линкера.
В итоге принял решение, что, конечно, своя IDE — это хорошо, но реализовывать то, что уже существует необходимости нет. Поэтому написал свое расширение для VSCode, которое автоматизирует создание проекта под определенный контроллер, его сборку и загрузку(OpenOCD или JLink), а также дебаг с помощью другого расширения.
Примерно месяц у меня ушел на базовый, но достаточный, функционал. С учетом того, что раньше с АПИ VSCode дел не имел и не писал на TypeScript. Сейчас потихоньку дополняю — недавно добавил pdf-viewer от Мозилы для просмотра мануалов и даташитов, которые автоматически загружаются для выбранного контроллера. Это заняло у меня несколько вечеров. Если бы все писал сам, то…
В VSCode полно расширений самых разных мастей и калибров: от подсветки кода и дополнения синтаксиса до аналога Тиндера. В основном это опенсорсные проекты, расположеные на гитхабе и среди них наверняка найдутся те, которые хотя бы частично, подойдут по функционалу и, при желании, их несложно переделать под свои нужды. Кроме того, насколько я знаю, можно сделать собственную сборку этого редактора, включив в нее только то, что необходимо.
Помимо VSCode существует множество других сред, типа Sublime, VIM, о которых, Автор наверняка знает. В них уже реализован необходимый минимум для работы: GUI, работа с файлами, вкладки с исходниками и т.д. Поэтому можно сосредоточится только на недостающем функционале.
Да, согласен, у меня тоже не было скиллов с TypeScript, но посидел, и написал плагин для VSCode с поддержкой системы сборки Qbs:
* marketplace.visualstudio.com/items?itemName=qbs-community.qbs-tools
* habr.com/ru/post/526256
Чего пока не хватает — так это:
1. Нормальной подсветки файлов ассемблера (а их много разных бывает).
2. Нормальной подсветки файлов линкера (а их много разных бывает).
3. Нормальной подсветки компилеро/архитектуро специфичных ключевых слов компилятора и пр.
VitGo, Вот, было бы здорово если бы объединить усилия ;)
А то каждый лепит свой костыль (это и меня касается), а в итоге как в известной басни Крылова (про лебедя, щуку, рака). ))
* marketplace.visualstudio.com/items?itemName=qbs-community.qbs-tools
* habr.com/ru/post/526256
Чего пока не хватает — так это:
1. Нормальной подсветки файлов ассемблера (а их много разных бывает).
2. Нормальной подсветки файлов линкера (а их много разных бывает).
3. Нормальной подсветки компилеро/архитектуро специфичных ключевых слов компилятора и пр.
VitGo, Вот, было бы здорово если бы объединить усилия ;)
А то каждый лепит свой костыль (это и меня касается), а в итоге как в известной басни Крылова (про лебедя, щуку, рака). ))
ну у меня подсветка реализована за счет выбора одного из внешних файлов правил… программа содержит в себе некий компилятор правил (как бы в байт код перевожу правила) и потом уже этот байт код делает парсинг текста
по подсветке — у меня происходит полный разбор синтаксиса команды, посмотрите на варианты LDR… это далеко не фильтр по регулярным выражениям с ключевыми словами для подсветки…
про возможности VSCode + TypeScript:
у меня каждый файл проекта имеет свои символы, инклудные символы, глобальные символы (передаются в проект), спсисок инклудных файлов
соответственно, когда нужно получить список символов доступных в текущем файле идет просто запрос по инклудным файлам (соответственно запрос может быть перенаправлен глубже по инклудам) + добавляются символы текущего положения + добавляются глобальные символы с проекта
на TypeScript вы видите как это реализовать? подсказка — парсить внешний файлы с нуля при запросе списка символов — капец какая плохая идея (быстродействию капут) — я загружаю и обрабатываю все файлы проекта, и потом просто файлы обращаются друг к другу для получения имен символов, адресов, и так далее… то есть если файл отредактировали и потом перешли к другому файлу — то при обращении к нему — он никаких действий по поиску списка символов (просмотру и парсингу себя), просмотру файлов инклудов — не делает, они у него уже готовые в списках лежат…
вот в таком режиме работы — работа с символами более менее прозрачная и обеспечивает нужное быстродействие…
если вы можете написать такое на type script — то можно подумать над дальнейшим и объединять усилия… а я не хочу начать изучать новое, и потом узнать что в обработке файлов каждый файл изолирован, и нужно чесать левое уже пять раз для каждого желания правого… программируя редактор с нуля я вообще не думаю о каких то ограничениях свыше…
ну и все эти хипстерские установки и допиливания редакторов меня вечно веселят… наверное это круто… поставить редактор и потом еще допиливать и допиливать тот или иной дополнительный функциональный блок…
тут все в одном, работает из коробки, ничего ставить (кроме дров для ст-линк) не надо… но оказывается мы вдруг стали все блондинками, и нам при разработке стразы нужны обязательно, хипстерский дизайн редактора всем нужен…
нужна функциональность, и еще удобство — это то что можно и нужно обсуждать… а использование модного редактора, и крутых свистоперделок, скинов, шрифтов и прочего — это не со мной… это к блондинкам, они оценят
по подсветке — у меня происходит полный разбор синтаксиса команды, посмотрите на варианты LDR… это далеко не фильтр по регулярным выражениям с ключевыми словами для подсветки…
про возможности VSCode + TypeScript:
у меня каждый файл проекта имеет свои символы, инклудные символы, глобальные символы (передаются в проект), спсисок инклудных файлов
соответственно, когда нужно получить список символов доступных в текущем файле идет просто запрос по инклудным файлам (соответственно запрос может быть перенаправлен глубже по инклудам) + добавляются символы текущего положения + добавляются глобальные символы с проекта
на TypeScript вы видите как это реализовать? подсказка — парсить внешний файлы с нуля при запросе списка символов — капец какая плохая идея (быстродействию капут) — я загружаю и обрабатываю все файлы проекта, и потом просто файлы обращаются друг к другу для получения имен символов, адресов, и так далее… то есть если файл отредактировали и потом перешли к другому файлу — то при обращении к нему — он никаких действий по поиску списка символов (просмотру и парсингу себя), просмотру файлов инклудов — не делает, они у него уже готовые в списках лежат…
вот в таком режиме работы — работа с символами более менее прозрачная и обеспечивает нужное быстродействие…
если вы можете написать такое на type script — то можно подумать над дальнейшим и объединять усилия… а я не хочу начать изучать новое, и потом узнать что в обработке файлов каждый файл изолирован, и нужно чесать левое уже пять раз для каждого желания правого… программируя редактор с нуля я вообще не думаю о каких то ограничениях свыше…
ну и все эти хипстерские установки и допиливания редакторов меня вечно веселят… наверное это круто… поставить редактор и потом еще допиливать и допиливать тот или иной дополнительный функциональный блок…
тут все в одном, работает из коробки, ничего ставить (кроме дров для ст-линк) не надо… но оказывается мы вдруг стали все блондинками, и нам при разработке стразы нужны обязательно, хипстерский дизайн редактора всем нужен…
нужна функциональность, и еще удобство — это то что можно и нужно обсуждать… а использование модного редактора, и крутых свистоперделок, скинов, шрифтов и прочего — это не со мной… это к блондинкам, они оценят
Вот неплохое расширение для VS Code которое позволяет из проекта сформированного CubeMX сделать все нужные мэйкфайлы в один клик. Поддреживается отладка через OpenOCD.
«расширение для VSCode»
проблема тут в том что универсальное решение в виде VSCode накладывает массу ограничений на функционал. Поэтому выбор — сделать очередной недоредактор на VSCode, либо сделать максимально удобный редактор для ассемблера не ограничивая себя возможностями VSCode
проблема тут в том что универсальное решение в виде VSCode накладывает массу ограничений на функционал. Поэтому выбор — сделать очередной недоредактор на VSCode, либо сделать максимально удобный редактор для ассемблера не ограничивая себя возможностями VSCode
UI отдает приятной олдскульностью. Сразу вспомнил свои проекты почти двадцатилетней давности на Delphi. Как оказалось, здесь тоже без Паскаля не обошлось.
я с удовольствием буду писать на ассемблере в любом другом редакторе
Очень круто было бы автоматическое коментирование мнемоник (как в ida). Ибо у арма вырвиглазный ассемблер — "так блевать и кидат". Особенно если сравнить с blackfin-ами
Небольшая идея развития системы подсветки/подсказок: синтаксис/семантика отдельных команд довольно быстро запоминаются, а вот что остаётся всегда, так это проблема повторного использования регистров. Было бы удобно набрав имя регистра, тут же видеть подсвеченными (либо списком в каком-то специальном окошке) предыдущие его использования (а ещё лучше более конкретно — модификации, либо вообще чтения и записи разными стилями).
не совсем понял идею… показывать в каком виде использовался регистр последний раз?
гм… прикольная идея…
гм… прикольная идея…
Да, в достаточно длинном коде при таком количестве регистров как у ARM (да ещё и с однообразными именами) начинаешь забывать что в котором регистре было, либо берёшь значение не из того, либо наоборот — занимаешь под что-то новое регистр, предыдущее содержимое которого ещё понадобится. Удобно было бы видеть что происходило с "текущим" регистром до этого. Да хотя бы как в IDA — подсветив все появления его имени в пределах видимого кода. А с вашим углублённым разбором инструкций можно ещё и цветами выделять чтение/запись. Либо где-то (в строке состояния? в окошке-подсказке?) показать вместе с номером строки ближайшую предыдущую команду (а то и несколько), где текущий регистр использовался.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Редактор ассемблера для ARM микроконтроллеров для компилятора gnu as. Старт