Те среды которые есть в настоящий момент заточены больше для языка Си и программирование в них на ассемблере не сильно отличается от программирования в блокноте, ну может быть только многооконность удобна, да еще компиляция (если настроить все так как любит среда).
Некоторое время назад (всего 2 года прошло) я сетовал о том что нужен программист для ее написания, но дело с тех пор не сдвинулось…
Поэтому вспомнив знаменитую поговорку: «Если гора не идет к Магомеду, Магомед идет к горе» — решил в итоге начать писать самостоятельно…
Дальше под катом (будут картинки!!)
В общем, решил начать с тех функций которые используются больше всего и отсутствие которых больше всего напрягает в разработке.
1. Многооконность, ее очень не хватает в FAR, Блокноте и так далее, понятно что 2, 3, 4 окна открытые и размещенные на экране решают проблему, но иногда и этого мало, да и функциональность у них должна быть другая…
Поэтому был написан простенький редактор в SDI интерфейсе с вкладками:
Далее, можете создать новый файл из меню: Файл: Новый, или открыть существующий…
Я создал для примера новый:
2. Для автоматизации некоторых рутиных действий я создал в меню: Мастер некоторые процедуры, которые реализуют их.
3. На этом казалось бы простом шаге я столкнулся с особенностью новых систем Windows — а именно кодировке текста UTF8… И несмотря на первый порыв забить на это и писать все файлы в кодировке cp1251, подумал что в дальнейшем возможно редактор будет интересен и для Линуксоидов (надеюсь не обидное прозвище?) и кодировки возможно у кого то будут KOI8 или еще какие и реализовал работу с теми кодировками которые позволяет стандартная библиотека Лазаруса.
Ну, а для того чтобы редактор знал в какой кодировке будет файл ввел директиву редактора которая указывает в какой кодировке создан файл. В этой кодировке он будет сохраняться на диск, учитывая ее он будет и загружать файлы
Кодировки задаются в меню: Мастер: Задать кодировку
В текст файла добавится управляющая строка, главное чтобы она была в файле, не важно в каком месте (так что если кому мозолит глаза — ставьте ее хоть в конец)
4. Далее идет обычно обязательное указание директив компилятора, тоже легко автоматизируется и снимает головную боль с поиском места откуда их можно скопировать в новый файл.
Меню: Мастер: Задать ядро процессора
пока у меня частично готовы только файлы для Cortex-M4
получаем в нашем файле:
5. Работа с файлами констант (или определений, кому как больше нравится) знать ядро процессора недостаточно, необходимо задать микроконтроллер, это делается в меню: Мастер: Задать микроконтроллер
в нашем файле:
6. Создание заголовка файла. Не то чтобы нужно, но иногда хочется написать какой то комментарий… Меню: Мастер: Добавить описание
Чтобы добавить строку описания просто поставьте галочку и напишите то, что Вам нужно
Причем ширину описания можно менять, например, вот так выглядит на 70 символах ширины (текст для вывода будет переформатирован)
В наш файл добавится:
7. Дальше, наверное самое интересное.
Программирование микроконтроллера это постоянный поиск регистров, и их значений… Все таки искать каждый раз, как я это делал в первых публикациях про программирование STM32 на ассемблере, занятие муторное, понятно, что и на другом языке мы скорее всего будем делать тоже самое, только искать придется в каком нить RM0090 Reference Manual, но мы то пишем редактор с нуля, а значит почему бы не попробовать автоматизировать этот процесс.
Меню: Константы — Добавить константу
Тут все дерево констант, выбирайте нужную!
Вставить можно как выбранную константу (кнопка «Только константу») так и весь пусть констант как выражение для компилятора (кнопка Полный адрес)
В позицию курсора сразу будет добавлена вся строка… Тут правда скриншот при добавлении другой константы (RCC_AHB1ENR)
Демо-файл редактора доступен по ссылке yadi.sk/d/EWrZacT3Oi15ZQ
Сейчас я нахожусь на шаге описания значений констант (определений) и решил что помощники бы не помешали…
Если кто заинтересовался — прошу в личку. Работа особой квалификации не требует, но времени уходит много…
p.s. редактор пишется дальше, так что будут и другие плюшки (объединение в проект, работа с модулями и т.д.)
p.p.s. теперь мне не нужно объяснять, как я провел новогодние праздники? :-)
Комментарии (64)
oisee
15.01.2019 15:59TL;DR :)
Тупой вопрос: модуль/плагин для того же VSCode/Atom (whatever) настолько занудно писать, что проще свой редактор сделать, или есть непереносимость электроноподобных редакторов?
(или отпугнула недостаточная гибкость таковых?)
VitGo Автор
15.01.2019 16:051. Не знаю о чем вы говорите
2. программирование на асме имеет некоторые гм… особенности…
то есть писать придется скорее всего не один плагин… и не два… и боюсь что и не три…
то что реализовано сейчас — это как верхушка айсберга. то что можно делать и руками с той же степенью эффективности, но список хотелок (которые буду делать) намного больше… так что проще писать свое чем подстраиваться под другой продукт десятком плагинов (еще не зная что можно реализовать плагином, а что нет...)rstepanov
15.01.2019 16:36VitGo Автор
15.01.2019 20:01-3ARM assembly highlighting for Visual Studio Code
и что там от редактора? подсветка кода ?!
и судя по подсветке addnes — правильно не работает…rstepanov
15.01.2019 20:33+1Внезапно там VS Code в качестве редактора :) С соответствующими плагинами оно даже для отладки годится, live variables, memory view, svd-файлы и все такое…
Если подсветка не устраивает — ее же поправить можно, разве нет?
checkpoint
16.01.2019 11:55Так Вы бы и раскрыли тему этих особенностей, показали бы другим в чем причина острой необходимости создавать новый текстовый редактор.
Я сам пишу много кода для STM32 на Си со вставками ассемблерного кода. Считаю такой подход наиболее оптимальным. Писать вчистую на ассемблере имеет смысл только из академического интереса.
Shtucer
15.01.2019 16:33Вижу какую-то фигню+сниппеты. Вот бы заменить какую-то фигню на хоть какой-нибудь редактор… Нет, серьёзно....
Amomum
15.01.2019 16:35+1Основной вопрос такой — а вам действительно нужно в 2019 году писать на ассемблере под достаточно мощный и быстрый STM32, вместо того, чтобы писать на С и С++? Т.е. есть какие-то задачи, где С/C++ не подходит? Если так, то не могли бы вы немножко рассказать о своих задачах?
Или вам просто хочется/нравится писать на ассемблере? Если так, то вопросов более не имею :)kuza2000
15.01.2019 17:05Хотя бы для того, что бы узнать как устроено то, под чего пишеться на C )
Amomum
15.01.2019 17:19Мне кажется, это можно понять и не программируя на ассемблере самостоятельно :) Например, читать дизассемблерный листинг, который любая IDE для С умеет показывать. Конечно, этот листинг сильно отличается от рукописаного кода на асме, но если все же программировать на С, то навык чтения этого листинга оказывается достаточно полезен сам по себе.
Это я все к тому, что даже с самым божественно-крутым редактором для ассемблера, писать на С все равно проще и легче; а если очень хочется, то можно ассемблерную вставку сделать.
WhisperingOak
16.01.2019 10:20Зарегистрировался чтобы ответить. Иногда действительно нужно. Достаточно быстрые STM32 (да и любые другие ARM контроллеры) все же не DSP, и если нужна нетривиальная обработка сигналов (что не такое уж редкое явление), то производительности уже впритык. Использование ассемблера позволяет раскрыть все возможности архитектуры.
Кто-то может затянуть известную песню про то, что современные компиляторы умные, они сами всё оптимизируют, лучше тебя, бросай ты это дело. Ничего подобного! Компиляторы тупы как пробка. Как то мне понадобилось синус вычислить. В начале вычисления возникал некий признак, который использовался в самом конце. Соответственно его нужно было где-то хранить. Я его засунул во флаг переноса, причем мне это ничего не стоило: попадал он туда как побочный эффект операции битового сдвига, лежал там тихонько, и в самом конце использовался посредством условной инструкции. Компилятор никогда бы до такого не додумался, выделил бы место где-нибудь на стеке (потому что свободных регистров не осталось). Это бы увеличило время выполнения функции процентов на 20 наверное. Вот такие вот дела.
Конечно это не значит, что приходится постоянно использовать ассемблер, нет. Просто ты используешь разные математические библиотеки, а вот они уже написаны на ассемблере. У TI, например, что fixed-point библиотека, что motor control, написаны как раз на нем.Amomum
16.01.2019 12:51Ну, я же не говорю, что никогда вообще не нужно на ассемблере писать, порой и правда приходится. Вот только мне кажется, что это происходит настолько редко, что ради этого писать свой редактор — это очень сильно перебор. Мне вот, натурально, это требовалось раза 3-4 за всю жизнь, причем и тогда можно было выехать на интрисинках компилятора, просто я об этом еще не знал.
Компилятор компилятору рознь, тут по всякому бывает в зависимости от множества факторов. Но в большинстве случаев вроде все хорошо. Разумеется, это еще и от задач зависит, у нас хитрой обработки сигналов как-то не попадалось, видимо.
Но вот синус мы уже считаем на этапе компиляции :)
kuza2000
15.01.2019 17:01Первый вопрос сразу — а на чем пишется редактор?
И второй — а рассматривался вариант взять готовое, например notepad++ и допилить плагинами? Тем более, у него исходный код открытый...
alex-open-plc
15.01.2019 20:02Да и у EmBitz код открытый… И «допиливать» меньше прийдется. В EmBitz не мешало бы интегрировать загрузчики от STM (консольный Flash loader и loader из состава ST-Link)… Писан на wxWidgets, так, что теоретически кросс-платформенный.
www.embitz.org/svn/listing.php?repname=EmBitz
DJtell
15.01.2019 20:02Почему yandex, почему на git не ведете? Может быть кто и подключился с помощью…
Как по мне, asm не совсем то на чем можно писать что-то большое (стоящее)
Драйвер работы с дисплеем, меню с 2-мя десятками подпрограмм. Каждая из которых переконфигурирует не только пины, но и NVIC и DMA…
Это слегка не тот инструмент для борьбы со сложностью…
P.S. лет эдак 7-8 один знакомый собирался прошивку писать для универских часов(с календарем и расписанием пар, дисплей 32?100 точек) на asm… короче не поднял…
года 2 назад похожий проект собирали другие студенты на Ардуине месяца за 4… оставив только дисплей…VitGo Автор
15.01.2019 20:04ну не знаю… я как то писал программу управления радиоуправляемыми моделями на асме… правда там был авр…
у меня есть задача где мне 168 мгц такта на stm32f4 на асме по расчетом хватит в притык :-(( но я пока не хочу о ней говорить…
ianzag
15.01.2019 21:43+3Бог с ним, с ассемблером. Нужно так нужно.
Но вот писать свой редактор? «Для ассемблера»? С нуля? Странный. Странный выбор…
PS: Ну возьмите хотя бы уже готовый и накидайте того, чего не хватает. Тот же QtCreator. Нарисуйте к нему свой плагин с синтаксисом и прочим и будет счастье. Опять же — людям польза. Вот это вот все никто в трезвом уме даже запускать не будет. Лениво т.к. результат очевиден. А вот плагинчик под уже обсосанной вдоль и поперек IDE включить — это вполне себе пожалуйста.alex-open-plc
15.01.2019 22:07-1Qt это — RAD…
ianzag
15.01.2019 22:22QtCreator — это среда разработки. К RAD он имеет опосредованное отношение. Да, в него встроен Designer (опять же как плагин) в котором можно рисовать Qt-шные формочки. Собственно на этом RAD заканчивается. В остальном и в основном это хорошо продуманный комбайн в т.ч. редактор кода с возможностью расширения.
Ну да бог с ним с креатором. Дело вкуса. Возьмите любой другой приличный редактор и расширьте его. Зачем тратить драгоценное время на бессмысленный мартышкин труд пытаясь реализовать то, что другие уже десять раз сделали по-определению лучше на порядок :-?
longtolik
16.01.2019 10:58На всякий случай, есть еще FASMARM, добавка для FASM.
И да, EmBitz работает с Ассемблером, (я, например, подключил aarch64-linux-gnu для работы с 64 битной архитектурой, RPI 3 B+,A+). Для «голого железа» без Ассемблера не попишешь.
Кстати, FASMARM транслирует некоторые команды в код, для которых в GNU надо 2-3 команды вставлять или машинный код.
Картинка для FASMARM в текст не вставляется, вот её ссылка:
physicalcomputing.ru/images/Em2.jpg
(почему нельзя выбрать изображение на компьютере, а надо его в сеть сначала выгружать, да ещё и не вставляется?)…
Больше не буду тратить время на Хабро-комментарии.
VitGo Автор
16.01.2019 18:37посмотрел FASMARM — ну я конечно понимаю что мы сравниваем все бачки унитазов которые смогли найти… но там просто редактор…
на счет emBlitz ничего не буду писать, не использовал сам, по скриншотам неплохо, но я пишу для того чтобы максимально автоматизировать процесс…
сейчас вот закончил мастер поиска и вставки констант — я не знаю может конечно это где то реализовано (не в виде ручного поиска по инклудам) — пока не видел…
буду потихоньку писать ту функциональность которую сам использую, и посмотрим что получиться…
math_coder
16.01.2019 16:29+1CP1251, KOI-8
Забудьте вы уже про эту дикость. Мы живём в счастливое время, когда всем и везде хватает UTF-8. И кто знает, когда оно закончится? Пользуйтесь пока можно. А ещё одна опция — это вовсе не всегда хорошо.
jaiprakash
16.01.2019 16:40всем и везде хватает
В эмбеде эта дикость используется для вывода на символьный дисплей, например. Тут или городитькостылиобёртки в коде, или использовать однобайтные кодировки.
Многие, если не все, IDE это позволяют.math_coder
16.01.2019 16:59Или делать конвертацию в процессе сборки. Я бы сделал именно так, но специалистам, конечно, виднее, как им удобнее работать.
VitGo Автор
16.01.2019 18:34Ну дикость или нет, а когда сталкиваешься с файлами в другой кодировке, то приходиться «выплясывать»… так что проще иметь этот инструмент, чем придумывать каждый раз костыли для решения
Kremonia
17.01.2019 07:36Я дико извиняюсь, ценю душевный порыв автора. Настолько что даже восстановил пароль.
Во-первых интересует roadmap.
Скажите, а вы отдаете себе отчет в том что в итоге придется реализовать?
Т.е. как минимум, чтобы не быть просто блокнотом, нужно хотя бы прикрутить туда компилятор, дебаггер и флэшер, это не говоря уже о парсинге, подсветке, авто-дополнении и каком-то маломальском статическом анализаторе. А там еще веселее будет когда пойдет HAL для всего зоопарка решений от STM (хотя бы), CMCIS… Особенно имея опыт работы с самой STM как подрядчик. У самой STM их софт и некоторые аппаратные решения не работают как нужно. У меня уже дергается глаз, шевелятся волосы в бороде и свитер нервно скукоживается.VitGo Автор
17.01.2019 07:42Ну каких то планов по срокам не существует…
а по задачам — в прошлых статьях я писал что хотелось бы иметь в редакторе…
На счет прикрутить «компилятор» — это не сложно
На счет дебаггера — еще не знаю, буду искать
прошивка по DFU в планах
на счет парсинга — был проект который парсил строки, причем парсил именно команды ассемблера, а не делал тупую подсветку без разбора написанного… так что тоже в планах…
а вот с подсветкой пока ничего не получилось… RichEdit очень тормозно работает (или я так и не смог с ним совладать), а другие варианты (например те которые есть в Lazarus) — несмотря на казалось бы имеющуюся функциональность — не подходят…
авто-дополнение — в планах
что такое статический анализатор не знаю :-( расскажите — подумаю
HAL запланирован, правда в виде модулей с возможностью визуальной настройки…
так что зря вы так…
то что я пишу однозначно лучше блокнота, и ничем не хуже тех решений что уже есть (потому что те решения что есть — являются, в лучшем случае, просто редакторами кода)…
сейчас я занимаюсь добавлением тех плюшек которыми реально пользуюсь сам…
проект медленно, но двигается — банально не хватает времени на создание некоторых инклудов, но этот вопрос решиться желающими помочь…
Сюдя я выложил одну из первых демок именно из попытки найти единомышленников и помощников…
так что сроки в наших руках, а проект все равно в моих (потому что для продолжения работы мне ничего не нужно, будут помощники — хорошо, не будут — вчерашний день убил на инклуды, просто затрачу больше времени и ничего плохого)Shtucer
17.01.2019 11:27+1то что я пишу однозначно лучше блокнота, и ничем не хуже тех решений что уже есть (потому что те решения что есть — являются, в лучшем случае, просто редакторами кода)
Гм… смелое заявление, смелое.
В качестве примера, вот вам экстеншен для VSCode. Полагаю, это вас как-то вдохновит пересмотреть свою точку зрения.
VitGo Автор
17.01.2019 11:32спасибо за ссылку, посмотрю…
тем не менее, я пишу в первую очередь для себя.
это не моя профессия, и не способ заработать денег…
я пишу тот инструмент который мне нужен…
если он заинтересует кого то еще — с радостью поделюсь или приму помощь, если же Великий_all решит что есть более удобные инструменты — ну что же, я не буду никоим способом оспаривать чужой выбор…
VitGo Автор
17.01.2019 11:41Отладка конечно классно отображается… ничего не сказать…
интересно для ARM есть такой эмулятор? у амиги FS_AUE…
отладкой позже займусь, сейчас есть текущие задачи…
а вот с редактором с цветовыми схемами — я не нашел компонентов которые могли бы сделать то что я хочу, я тут некоторое время назад писал статью о попытках сделать на RichEdit — у меня анализировалась строка с коммандой ассемблера, и сразу проверялись параметры команды… но как заставить RichEdit работать быстро на больших файлах я не понял… на файле в 3000 строк тормоза были такие что о работе говорить не приходилось :-(
если интересно вот ссылка на демку yadi.sk/d/f8oMujxVqBiMz просто откройте файл из SampleCode, например main.asm и попробуйте что то добавить или убавить… — вот такое редактирование файла я хотел сделать, чтобы сразу получать ошибку если команда не верна или метки нет или еще что то не так… на глюки и недоработки в остальном не смотрите, я не смог победить объем поэтому завершил разработку на этот компоненте
свой редактор тоже пробовал писать (на базе TImage) -но мне не хватает быстродействия, видать должен быть другой подход для вывода текста… — пока есть только идея как переписать, чуть позже займусь (у меня в редакторе используется ТМемо, так что заменить один компонент на другой много времени не займет)jaiprakash
17.01.2019 13:44Если комфортно писать именно на паскале, то почему бы не покопать сам Lazarus, как они там сделали.
(Брать его самого за основу, наверное, не спортивно.)VitGo Автор
17.01.2019 14:39может быть так и сделаю.
Сейчас задача минимум запустить редактор.
Да у него не будет подсветки кода, но должны быть функции позволяющие удобно писать программы, добавлять сторонние модули, настраивать их…
Компилировать и разбирать ошибки чтобы потом показать в редакторе юзеру.
А вот визуализацию кода пока отодвинул — потому что решения не вижу… как увижу — заменю компонент TMemo в проекте и будет подсветка…
Shtucer
17.01.2019 13:51Вот ещё немножечко вдохновительного монстра.
Эту вашу штуку я кое-как запустил под wine. Кошмарный ужас! :))
По поводу ошибок, ну редкий "просто редактор кода" не умеет подсвечивать ошибки на основе выхлопа компилятора. По крайней мере мой Eclipse это делает. Я специально создал проект для stm32f1x, и вместо реализации main() в main.c сделал простенький main.s (кстати, о расширениях файла: так уж повелось, что ассемблерные исходники либо .s, либо .S). Ошибки подсвечиваются, но не налету, а после компиляции.
Так что я всё ещё думаю, что лучшим приложением ваших усилий было бы написание расширения для любого из редакторов, т.к. я уверен, что вы слабо представляете что скрывается за словами "просто редактор кода". Поверьте, красивой подсветкой синтаксиса дело не ограничивается. А даже она у вас вызывает трудности. А если захочется фолдинга? А поиск-замена? А переходы к определениям? А ....? profit? Поищите, на хабре есть статья от Jet Brains о написании редактора кода.
Ошибки в вашем недоредакторе неотличимы от ключевых слов, подсвечиваются одинаково.
Про эмулятор конкретно стмовских камней не уверен, но, если не ошибаюсь, qemu умеет эмулировать armы. Да и зачем? Например: OpenOCD tool and Cortex-Debug VS Code plugin is used for debug purposes. Да и в эклипсе есть дебаггер.
VitGo Автор
17.01.2019 14:34Еще раз повторю — проект ссылку на который я дал в комментарии выше — это проба пера в подсветке кода… не получилось работать с объемными файлами — поэтому функциональность и не писалась дальше…
подсвечивать ошибки после компиляции как раз просто… компилятор все их выведет… пропарсить вывод и показать — это задачка для студента курса так 2го :-)
идея как раз в том, чтобы подсказывать сразу, не дожидаясь компилятора.
И вообще по поводу подсветки кода — как раз сейчас на ней я не заморачиваюсь
а все что вы пишите: фолдинг, поиск-замена, переходы к определениям — это как раз много проще для меня…
на счет qemu смотрел, помоему там нет ARMv7 :-( но инструментом отладки пока не занимался, так что нужно смотреть… а пока рано еще :-)Shtucer
17.01.2019 14:53подсвечивать ошибки после компиляции как раз просто… компилятор все их выведет… пропарсить вывод и показать — это задачка для студента курса так 2го :-)
Поэтому все так делают, кроме я? :)
идея как раз в том, чтобы подсказывать сразу, не дожидаясь компилятора
Имхо, странная идея. Компилятор лучше знает скомпилируется ли исходник, и почему — нет. А подсвечивать ошибки в коде без компилятора… ну… это написать свой компилятор с вот этим вот, и этими как их.
VitGo Автор
17.01.2019 15:00ну просто ошибки бывают разные, какие то обнаружит компилятор, какие то видны еще на этапе редактирования… часто ведь бывают банальные ошибки, где то что то перепутал, не так написал…
Kremonia
17.01.2019 14:05Ну каких то планов по срокам не существует…
а по задачам — в прошлых статьях я писал что хотелось бы иметь в редакторе…
Смотрите, вы делаете публикацию о том что пишите свой редактор кода и ищите единомышленников. Причем конечную цель описываете довольно пространно и общо: «Хочу свой редактор». По функциональности вы отсылаете читать свои статьи и ни одна из них кроме этой никак явно не указывает на то что в ней есть какие-то рассуждения о функционале вашего редактора. Было бы замечательно, если бы все это было расписано в начале статьи, пусть и без жесткой привязки к срокам.
RichEdit очень тормозно работает
Скорее всего вы пересчитываете тэги при каждом инпуте и вероятнее всего храните весь текст в виде строк поля Text. Я бы посоветовал разобраться в паттерне MVP или MVVM и, например представлении документа в виде дерева.
что такое статический анализатор не знаю :-( расскажите — подумаю
Стати?ческий ана?лиз ко?да (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ.
Это все было без оценки целесообразности вашего начинания. Так исходя из личного опыта я могу сказать что вас ожидает большой кусок работы и бесчисленные велосипеды, в чем я пока не вижу особого смысла. Потому что то что уже есть можно совершенно точно реализовать в виде расширения к Visual Studio Code. Например.VitGo Автор
17.01.2019 15:05+1да, возможно вы правы — я не раскрыл задач в этой статье… может быть удалю ее, тем более что и проект уже двинулся еще вперед…
по richEdit — да, я правил Strings… причем пробовал отключать обновление, но все равно медленно работает…
Представление документа я прорабатывал, и строил даже структуры как раз в виде дерева… вопрос как потом это дерево быстро в richEdit передать, с сохранением форматирования… в общем у меня особо не получилось…
в MVP разбирался, правда для php использовал…
p.s. дайте мне построить свой велосипед! я не понимаю негатива, 99% проектов которые мы пишем (если это хобби, а не профессия) — все равно в стол… но почему то всегда найдется тот кто хочет по указывать что на каком столе делать…Kremonia
17.01.2019 15:16Представление документа я прорабатывал, и строил даже структуры как раз в виде дерева… вопрос как потом это дерево быстро в richEdit передать, с сохранением форматирования… в общем у меня особо не получилось…
Сереализация — десереализация?
p.s. дайте мне построить свой велосипед! я не понимаю негатива, 99% проектов которые мы пишем (если это хобби, а не профессия) — все равно в стол… но почему то всегда найдется тот кто хочет по указывать что на каком столе делать…
Почему негатив? В принципе я за замену Keil на то что не будет обходится, скажем мне, в $3800 в год. Но мне лично жаль ваших усилий, потому что вы явно идете не туда, еще и неправильным путем. И что-то мне подсказывает что пока вас в конце ждет разочарование и и сожаление о куче потраченного времени. А еще я вижу что вы на самом деле плохо понимаете с какими проблемами вы еще столкнетесь. Поэтому и решил вас предостеречь, только и всего.
Zenitchik
17.01.2019 15:22я не понимаю негатива, 99% проектов которые мы пишем (если это хобби, а не профессия) — все равно в стол…
Я своими велосипедами не делюсь. Поэтому понимаю негатив.
Я, правда, в данном случае нейтрален — мне Ваш проект ни для чего не пригодится.
jaiprakash
17.01.2019 15:26я не понимаю негатива
Это же интернеты, тут так принято.
Хорошо хоть перестали постить троллейбус из буханки. Массовое производство и величие корпораций — это хорошо, но часто человеку хочется заморочиться и построить АЛУ на реле или прочее странное. И такие статьи, как ваша, делают хабр тортее.
VitGo Автор
Ура! первый минус получен (причем файл даже не скачен)
Хабр, я в тебя верил!
:-)
kolu4iy
Тут какая штука… Отчего-то этот эффект очень заметен в последние полгода: как только статья появилась, она набирает несколько минусов. По прошествию дня внезапно баланс становится соответствующим статье, и как правило плюсовым. Не расстраивайтесь, просто наберите терпения.
P.S. Минусы под статьями — восстание роботов? :)
VitGo Автор
да не, я не напрягаюсь, я же 10 статей уже написал (типа «плавал, знаю» :-) )… всегда есть тот кто пишет на Си и всегда выскажется по поводу программированию на ассемблере… Причем не читая и не задумываясь :-))
мне вот если не интересно я и не минусую, но видать есть те кто по другому не может :-))
Zenitchik
Кому-то не жалко заряда на минусование статей, которые они не читают.
Arbane
Может дело в IDE Keil (у них платно) и EmBitz (бесплатно). А минусы как реакция на «негде».
VitGo Автор
а в EmBitz разве на асме писать можно? вроде как под Си заточена…?
rstepanov
EmBitz какой то не очень живой. Автор уже почти год молчит. Вроде бы где то было упоминание, что его попросили прекратить разработку и он согласился, но подробностей уже не помню.
Polaris99
И это очень печально, потому что как по мне — среда наиболее оптимальная, особенно в условиях ноутбука. Eclipse — это же просто катастрофа, не понимаю, как его можно для нормальной разработки под контроллеры использовать. И да, я его использовал, а не просто одним глазом посмотрел. Постоянные тормоза и глюки достали.
checkpoint
Не нужно пробовать г… но на вкус, что бы понять, что это г… но, как тот заяц в бородатом анекдоте.
Программировать нужно в VIM, все остальное от лукавого!
rstepanov
Ниже в комментах есть поклонник emacs, драка будет?