@RahDah06

Извините, если не в ту тему, не знал куда еще. Вопрос такой: я хотел бы попробовать себя в низкоуровневом программировании, а точнее, появилась странная (наверно) идея написать подобие ОС. Стоит ли учить для этого ассемблер, или хватит просто знаний C (у меня их сейчас нет)? И посоветуйте что еще для этого можно поизучать? Нашел несколько книг по изучению работы операционных систем (Modern Oeration System, H.Bos), пару статей. Стоит ли этим заниматься? К слову, сейчас у меня небольшой опыт в разработке на ASP.Net

0

@FFPowerMan

Думаю, да. Архитектуру проца и ассемблер соответственно надо учить.

1

ValeryS

RahDah06, найди исходники FreeRTOS(он открытый)
портирован на кучу платформ и изучай, в основном написан на Си, но есть и ассемблерные вставки

1

@Voland_

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

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

1

@COKPOWEHEU

Ассемблер придется учить хотя бы ради переключения контекстов процессов. Я не знаю другого способа получить доступ к указателю стека и точке возврата из прерывания. Плюс есть такое ощущение что в контроллерах с хотя бы защитой памяти и разделением прав (не говоря уж о камнях с виртуальной памятью) для доступа к соответствующему функционалу тоже придется использовать специфичные команды.
То есть ситуация обратная: это Си учить не обязательно, можно на чистом Асме писать. Благо он несложный, просто громоздкий.

1

@politoto

С другой стороны, если знаете платформу, на которой будет работать Ваша ОС, то, владея современным языком высокого уровня, и без ассемблера можно обойтись. Если приспичит, то написать свой.

1

@ВитГо

ну а если надумаете писать на ассемблере - то я пишу потихоньку среду :-)

0

@COKPOWEHEU

Эх, напомнили как я на первом курсе писал на Дельфях редактор ассемблера x86. Без автодополнений (хотя для трехбуквенных операторов оно особо и не нужно), отладки и прочего. Зато одно окно раздвинуто на два поля, начало слева, продолжение справа.
---
В чем киллер-фича вашей среды?

0

@ВитГо

COKPOWEHEU
никаких киллер фич.. просто редактор именно ассемблера, а не продвинутый текстовый редактор..
так что контроль символов проекта, в разрезе каждого файла с инклудами присутствует.. переход к определениям этих символов, переход в инклудные файлы...
есть впрочем и настоящий синтаксическиЙ разбор асм команд ( а не подсветка "вроде похоже" как это сделано у других сред).. так что написать mov r0, 67 lsl 5 и радоваться красивой подсветке (как у того же vscode) не получиться, ошибка будет подсвечена...
автоподбор символов кстати есть, по введенному тексту, символы кстати в виде дерева можно формировать...
еще есть и компиляция и даже отладка (правда пока без wath points)...
в общем много что есть чего нет у других редакторов... но это не киллер фичи, это просто редактор ассемблера, а не просто продвинутый редактор..

пишу кстати на лазарусе (считайте дельфи)

1

@ВитГо

видок у меня тоже простой, хотя с другой стороны- зато не ломать глаза

Миниатюры

 

0

@Rius

NIH!

0

@ВитГо

точно ! почему вы в такой отрицаловке ? :-)

0

@Rius

Вы могли бы сделать очень хороший редактор ассемблера, если бы не пилили всё сами.

0

@politoto

Почему же Вы думаете, что редактор плох?

0

@Rius

Почему плох?
Он мог бы сделать лучше (функциональнее), для большей аудитории, за меньшее время.
Вместо этого героически изобретает велосипед.

0

@ВитГо

так вы же даже не попробовали...
сейчас уже редактором можно пользоваться.. несмотря на то что он идет как "для тестов"...

сейчас реализованы:

- подсветка (как я ее вижу), причем это подсветка в разрезе ядра микроконтроллера (так что какую нить команду упаковки от stm32f4 в коде для stm32f1 написать без подсветки ошибкой точно не получиться), обработка символов для конкретного исходного файла (с учетом инклудов, глобальных символов проекта)

- обработка ld файла для определения секций

- можно использовать библиотеку кода, чтобы не писать части программы с нуля, так же можно добавлять новые модули в библиотеку - чтобы потихоньку создавать некую std lib да и вообще иметь централизованное хранилище подобного кода

- поддержка программаторов j-link (у меня это перешитый st-link v2 китаец), st-link (китайский)

- отладка, просмотр в отладчике памяти, периферии, отслеживание исполнения... причем периферия из xml читается в максимально полном формате (с расшифровкой названий отдельных бит регистров настройки)

- прошивка при помощи обоих программаторов,

- сделал 2 маленьких библиотеки работы с дисплеями pcd8544 и st7735, валяется еще ini9341c, руки до него не доходят.. так что "для начать" вывод уже возможен не в стиле "помигать светодиодом"

- сделал начальные файлы для sm32f1 (сам пишу для stm32f4), но пока никто не пожелал для него начать писать, так что его библиотеку подпрограмм по остаточному принципу накидываю к сожалению

- сделал импорт бинарных файлов в исходный код, импорт шрифтов для lcd из mcu font generator, чтобы руками не править шрифты..

сейчас работаю над интерфейсом чтобы по минимуму нужно было использовать мышь и работать только при помощи клавиатуры, ну и ошибки отлавливаю, кои еще попадаются, но уже значительно реже чем было раньше

косяки, куда же без них:

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

- для исходных файлов правда пока не сделал обработку макросов - не нашел более менее полное руководство по их написанию, правилам и прочему :-(

- пока нет калькулятора значений символов - все никак руки до него не дойдут, все для него есть, а его до сих пор нет (конкретный косяк) - из за него не проверяются допустимые значения параметров в командах ассемблера (все для этого уже есть)


по итогу:

интерфейс программы не поразит, с другой стороны я стараюсь делать упор именно на те функции редактора которые нужны для написания программ на языке ассемблера, а не на общие текстовые навороты которые чаще мешают и отвлекают чем помогают.
причем если все таки подняться над ситуацией - то увидите, что альтернативных редакторов со схожей функциональностью просто нет (ну конечно, и даже наверняка ЕСТЬ !, но я не нашел, везде асм в лучшем случае просто подсвечивают, да и то криво...)


по поводу того лучше бы написал или хуже если бы писал плагин для какого нить известного редактора:

самое главное для меня - это полный контроль над процессом написания программы,

всем хорошо написание расширений для какого нить редактора, но это пока делаешь элементарные вещи..

как только сталкиваешься с действительно сложными вещами (а у меня их достаточно) - то будет очень обидно выяснить что: никто так никогда не делал, и данная функциональность каким нить базовым редактором (vscode?) не поддерживается в плагинах.., а таких узких мест у меня в редакторе куча... даже более того, многие вещи приходилось переписывать не по одному (и далеко не по 5 раз) чтобы получать необходимое быстродействие.
к кому можно обратиться с такими вопросами ? кто хорошо знает интерфейс плагинов внешнего редактора ? - на форумы идти (с абсолютной не ясностью результата) или саппорт писать (еще веселее) ?

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

как это делать для vscode я не знаю, и внятных док не встречал (да, я лох, и английский не учил ни в школе, ни в институте, а со словарем, да еще без примеров, разбирать что то не просто, а тем более искать "там не знамо где", то что "примерно представляю как должно быть")

может быть в будущем попробую написать такое расширение, но еще раз повторюсь - мне нужна очень понятная документация, тем более что на С# я не писал никогда (хотя чую что надо учить уже), но тут опять проблема внятной документации или наставника (про курсы о том как вывести hello word даже писать не буду, такое ощущение что преподающие одну книгу прочитали, и теперь отбивают ее стоимость на других)

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

1

@COKPOWEHEU

Смотря какая задача стоит. Изобретение велосипедов - отличный способ разобраться в теме самому, при этом конечный продукт не очень-то важен.
Опыт подсказывает, что продукт, который писали профессиональные программисты не один год, обычно оказывается лучше написанного для изучения материала.
Этот пункт не понял. Если речь о прошивке, то тут и поддерживать нечего - вызвал openocd и все дела. То есть у меня это делается командой make prog, в какой-нибудь IDE можно повесить на горячую клавишу. С отладкой чуть сложнее - надо ковырять gdb.
Но ни там ни там нет строгой привязки к конкретному программатору.
Вы смешиваете среду разработки и библиотеки? Так делать не стоит. То есть их можно туда положить, но по сути это разные продукты и разрабатываться должны независимо. В том числе должны быть возможность подключить библиотеку без вашей IDE, так и использовать IDE без библиотеки.
P.S. я не знаю какого качества у вас библиотеки. Вдруг это что-то уровня некоторых библиотек Ардуины, которое людям показать стыдно. Но если хорошие, то привязка точно не нужна.
Руками или все же воспользовались стандартными средствами линковки? Потому что стандартными средствами подключить бинарный блоб - дело двух-трех команд. Как раз недавно эту задачу решал, подключал образ флешки к контроллеру:
Последняя строчка используется чтобы образ писался не в оперативку, а в ПЗУ.

1

@ВитГо

ну это тоже.

абсолютно согласен, вот только где этот продукт ? я начал писать только из за того что не нашел нормального редактора для асма... понятно что есть блокнот, но для ассемблера этот редактор мягко говоря не подходит

угу, но и его надо как то использовать.. кстати именно к openOCD я и пришел в итоге...

про gdb - а он для асма нужен ? для высокоуровневых языков да, иначе не разобрать какая переменная или команда языка исполняется, а для асма ?
наверное получилось так что я пошел другим путем, и тут изобрел велосипед :-(

вообще эту тему еще изучаю, но пока особых подвижек нет
тот же elf после компиляции при помощи gnu as у меня для gdb ничего полезного не содержит..
где бы найти исчерпывающую документацию по интерфейсам gdb, форматам обмена и прочему ?
где найти инфу по содержанию elf ?

а привязок и нет. вообще тот код который генерирует редактор прекрасно собирается и без него, хоть из командной строки, хоть при помощи батника
библиотеки - это просто наборы подпрограмм, определений, в формате gnu as (у armasm другой формат немного)
и я сделал нечто вроде централизованной библиотеки кода, которая копируется в проект буквально за 3-5 кликов мышкой
взять ту же настройку gpio, согласитесь что это рутина, которую каждый раз делать это геморрой... при помощи редактора и библиотек это делается значительно проще, я бы даже сказал почти при помощи одной лишь мыши как в том же кубе


да, я знаю, буквально одной строчкой в ld файле можно добавить... но задачи ведь бывают разные, и иногда и эта функциональность нужна

0

@COKPOWEHEU

Мне хватило обычного kwrite. Подсветка синтаксиса есть, автодополнение есть. Это ведь не ЯВУ, там многого не требуется.
А компиляция и прошивка так и так в консоли, а не в редакторе кода делается.
оО а от чего ушли? То есть openocd это первое что попадается при необходимости что-то прошить. Ну не считая stm32flash или dfu-utils, которые все-таки не про программаторы. То есть просто интересно какие еще рассматривали программы.
Он не для асма или других языков, а для отладки. Вот написали вы код, а он работает неправильно. Значит надо либо ставить отладочный вывод (это самый простой и универсальный вариант), либо лезть непосредственно в мозги контроллера и смотреть в какие ячейки памяти что записалось и на какой он вообще инструкции завис.
А что он может содержать? Разве что комментарии из исходного кода. Ну и можете попробовать добавить флаг -gdwarf-2, вдруг да сработает.
Вот тут не помогу. Как после школы слез с IDE, так пошаговой отладкой и не занимался. makefile как-то проще и удобнее, чем монструозные проекты в накрученных средах разработки.
Тогда и в описании следовало это разделить. Мол, по разработке IDE сделано вот это, это и это. Потом, когда перечисление закончено, добавить: "Также пилю библиотеки для такого-то, такого-то и такого-то".
Лучше бы сделать в виде компилируемого кода + заголовочника. Ну там *.c + *.h или *.S + *.inc. Но если бы я писал библиотеку чисто на асме, сделал бы *.S + *.h или даже *.c + *.h, причем Си-шный код состоял бы из ассемблерных вставок.
У меня для этого есть файл pinmacro.h (avr / stm32f103 / stm32L151 / riscv:gd32vf103), благодаря которому любой пин настраивается в одно действие. Бывают гуру С++, которые такое же заворачивают в вырвиглазные шаблоны, которые делают это еще эффективнее, но для восприятия ужасно. Макросы в Си тоже ужасны, но они хотя бы дубовые и разворачиваются в один и тот же код.
Ну а с автоконфигараторами поосторожнее. Заранее продумайте что будет если понадобится переконфигурировтаь готовый проект. Куда денутся внесенные пользователем строки кода.
Вы не заметили, что у меня это кусок makefile, а вовсе не скрипт ld? То есть двумя командами любой бинарный файл превращается в обычный *.o, а уж его слинковать элементарно.
Кстати, вы используете make или что-то самописное для хранения настроек проекта?

0

@ВитГо

ну сначала я долго лелеял надежду использовать st-link_cli.. но к сожалению это не возможно :-(
даже не смотря на то что описано в его документации :-( хотя там все что нужно казалось бы есть :-(



Добавлено через 1 час 0 минут
заметил, почему не заметил, я же написал что способы могут быть разные

Добавлено через 2 минуты
ну это еще надо все обдумывать конечно,
время оно все таки конечно, поэтому иногда кажется что работа идет медленно, хотя редактор в существующем виде в итоге собрался за примерно 3 месяца

Добавлено через 55 секунд
ну это можно делать, просто я не стыкуюсь с си сейчас...

0