А как использовать?)

[Vadimatorik]

Добрый день. Прочел статью, перешел сюда, скачал. А как дальше? В статье сказано, что в архиве есть shell скрипт. А тут он где? Вообще хотелось бы в README.md увидеть полное описание того, как развернуть у себя из исходников под Ubuntu например. Ну и примеры сборки проекта из одного-двух файлов, как это делают для avr-gcc (в одну-две строки сборка из консоли, чтобы потом в свой makefile интегрировать).

[trol73]

Добрый. А тут его нет, архив можно в конце статьи скачать, там есть ссылка. В архиве есть несколько примеров. А самую последнию версию jar-ки можно брать тут https://github.com/trol73/avr-make/blob/master/tools/the-rat.jar Для сборки проектов я использую https://github.com/trol73/avr-make/ она умеет собирать avr-gcc проекты, где одновременно используются и c- и art-файлы. С скомпилировать из исходников можно импортировав их в проект Idea. Так как штука, мягко говоря, не супер-популярная, я не особо заморачивался документацией всего этого :) Есть еще самопальная IDE с подсветкой синтаксиса, сборкой проектов (С/ART) и возможностью видеть генерируемый ассемблерный листинг при навигации по исходному коду, но ее пока не выкладываю, т.к. с документацией там еще хуже )

[Vadimatorik]

Так как штука, мягко говоря, не супер-популярная, я не особо заморачивался документацией всего этого :)

Ну да. Всего одна звезда. Я бы просто для себя попробовал и если было бы норм, написал бы куда-нибудь статейку) На habr например)

А тут его нет, архив можно в конце статьи скачать, там есть ссылка.

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

А самую последнию версию jar-ки можно брать тут https://github.com/trol73/avr-make/blob/master/tools/the-rat.jar

Опять же. Какой-то пердолинг начался) Скачай с сайта, подмени тут, подмени там. Было бы круто просто скачать и пользоваться по инструкции)

Для сборки проектов я использую https://github.com/trol73/avr-make/ она умеет собирать avr-gcc проекты, где одновременно используются и c- и art-файлы.

Тут почитаю. Надеюсь там лучше с документацией))) У меня цель собрать проект под attiny13a. Так что было бы норм. Сейчас есть почти завершенная реализация на GCC ASM - но переписать было бы норм идея (GAS ассемблер в отличии от ассемблера AVR из Microchip Studio менее приятный... Но и когда кода уже 30 файлов - сложновато ориентироваться. Да. Для attiny13a 30 .asm файлов...). Я еще почитаю про avr-make. Надеюсь, что там можно из множества файлов собирать. А то в одном файле это будет пара тысяч строк кода... Не читаемое месиво.

С скомпилировать из исходников можно импортировав их в проект Idea.

Ну это чет вообще странно. Обычно везде дается список зависимостей для сборки (что установить) и команды для сборки и установки в систему. Можно что-то типа такого?

Есть еще самопальная IDE с подсветкой синтаксиса, сборкой проектов (С/ART) и возможностью видеть генерируемый ассемблерный листинг при навигации по исходному коду, но ее пока не выкладываю, т.к. с документацией там еще хуже )

Звучит сочно!) Готов выступить тестировщиком))) Где чо как?) Какие по ней прогнозы? Уже юзабельно?

[trol73]

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

Тут все наоборот ) Я всегда актуализирую описание на сайте, а гит не обновляю совсем. Точнее обновляю, но в другом, приватном репозитории. Суть в том, что сейчас это проект с ровно одним разработчиком и ровно одним пользователем, и это определяет все. Не нужен лично мне скрипт для сборки прямо сейчас - и его нет. А вот больше фич - нужно, и, если появляется время, добавляю их в первую очередь. Изначально в планах была компиляция котлина в нативный код (но в kotlin-native нет классов стримов для работы с файлами и кодировками). Если/когда дойдут руки - допилю и добавлю скрипт. А пока, прямо сейчас, увы..

Ну это чет вообще странно. Обычно везде дается список зависимостей для сборки (что установить) и команды для сборки и установки в систему. Можно что-то типа такого?

А там нет вообще никаких зависимостей, все с нуля написано, кроме котлина и JUnit для запуска тестов, и идея прекрасно открывает проект. Скрипт для сборки - это хорошо. Но пока, увы некогда.

Опять же. Какой-то пердолинг начался) Скачай с сайта, подмени тут, подмени там. Было бы круто просто скачать и пользоваться по инструкции)

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

Тут почитаю. Надеюсь там лучше с документацией)))

С документацией там еще хуже, наверное, т.к. это тоже проект чисто для самого себя ) Хотя, он вполне рабочий, сам активно им пользуюсь. Но для attiny13 он скорее совсем не нужен. Лично я пользуюсь им для сбора больших прошивок для Atmega128 + одновременной компиляцией из того же кода эмуляторов устройств под MacOS/Linux/Windows. Для крохотной tiny13 AVR Rat должен идеально подойти, без всяких avr-make. 30 файлов - не проблема для препроцессора (д и это, вроде, любой компилятор ассемблера умеет). Использую его в нескольких закрытых проектов, один под atmega8 написан чисто на Rat, другие используют его для ассемблерных вставок критичного по скорости кода. Среди примеров есть еще достаточно большой проект прошивки для частотомера, он целиком на Rat. Обычный ассемблер для AVR, имхо, совершенно неюзабелен для чего-то более сложного, чем мигание светодиодами. Когда куча переменных и аргументы функций хранятся в регистрах, и им нельзя сделать локальные алиасы - это прямо боль ))

Звучит сочно!) Готов выступить тестировщиком))) Где чо как?) Какие по ней прогнозы? Уже юзабельно?

Сыровато, колхозно, но вполне юзабельно, сам активно пользуюсь. Подготовлю архив. Сделана она на базе текстового редактора RText, с адаптацией под C/Asm/Rat/AVR. Несколько скриншотов:

[Vadimatorik]

Тут все наоборот ) Я всегда актуализирую описание на сайте, а гит не обновляю совсем. Точнее обновляю, но в другом, приватном репозитории.

А в чем сакральный смысл вести два репозитория для одного проекта? При этом один открытый, другой закрытый? Обычно же просто dev/master ветки и все хорошо.

И опять же, в чем причина, почему именно на сайте актуальная версия? Типа сначала пишется код в закрытый, потом из него в архив на сайт, а потом архив замещает файлы в открытом репозитории?) Оч странная тема. Я чет не понимаю в этой схеме... Буду рад пояснению)

Суть в том, что сейчас это проект с ровно одним разработчиком и ровно одним пользователем, и это определяет все. Не нужен лично мне скрипт для сборки прямо сейчас - и его нет. А вот больше фич - нужно, и, если появляется время, добавляю их в первую очередь. Изначально в планах была компиляция котлина в нативный код (но в kotlin-native нет классов стримов для работы с файлами и кодировками). Если/когда дойдут руки - допилю и добавлю скрипт. А пока, прямо сейчас, увы..

Да то, что мало популярный проект - это понятно. В целом, если достаточно скачать архив с сайта и пользоваться по инструкции, то в целом меня устраивает. Дорабатывать софт я все равно не собираюсь (пользоваться да, дорабатывать - нет. Тем более котлин. После работы с ним под Android еще Вьетнамские флешбеки....). Но ок. Попробую тогда с сайта. Но в целом было бы отлично, если бы появилась инструкция по сборке. Все же у некоторых людей есть вопрос, что зачем и как. Хотя бы что-то типа make command arguments. Ну и сразу непонятно из кода, что вообще есть актуальная версия, есть ли в репозитории бинарь или только исходники и что как минимально юзать.

Маленькой пояснительной записки на 5-6 абзацев с примерами бы хватило)

А там нет вообще никаких зависимостей, все с нуля написано, кроме котлина и JUnit для запуска тестов, и идея прекрасно открывает проект. Скрипт для сборки - это хорошо. Но пока, увы некогда.

Это круто, но для тех, кто с котлином не знаком - адок тот еще))) Я знаком, но только через Android Studio...

Так можно же просто скачать (с сайта) и пользоваться по инструкции ))

Пока так и поясню.

А самая последняя версия - я ее делаю чисто для себя, для решения своих конкретных текущих задач. И как только у меня появится время, сделаю следующий “официальный” релиз. А пока это чисто внутренняя версия. Но, при этом, багов в ней меньше, а фич больше )

А насчет этого можно по подробнее? Какие косяки есть и прочее? Есть где-то errata или типа того?) Или changelog. Об изменениях между версиями. Чтобы было понимание, чего опасаться))) А ту у меня автоматом страх, что например может с ссылкой закосячить или переход неверно интерепретировать... Такие баги - оч тяжко отлаживать...

С документацией там еще хуже, наверное, т.к. это тоже проект чисто для самого себя ) Хотя, он вполне рабочий, сам активно им пользуюсь.

Это прямо фишка ВСЕХ российских разработок блин))) Никто не пишет минимальную документацию, чтобы другие заценили. Я бы мог порекомендовать эту штуку нескольким знакомым, кто еще любит AVR. Они посмотрят и процитируют название треда)))

Но для attiny13 он скорее совсем не нужен. Лично я пользуюсь им для сбора больших прошивок для Atmega128 + одновременной компиляцией из того же кода эмуляторов устройств под MacOS/Linux/Windows.

Кстати насчет этого. А для Rat можно тесты писать логики? А то мой текущий девайс - программный полудуплексный UART (конечный автомат) + протокол над ним (еще один конечный автомат). И еще 90% логики можно было бы проверить тестами. Есть какая-то возможность С-- затестить? Типа готовить массивы значений, подающихся на вход функции, запускать ее, смотреть что будет на выходе в выходных регистрах.

Про эмуляторы - что за звери? Что могут? Где почитать? Очень интересный вопрос.

Для крохотной tiny13 AVR Rat должен идеально подойти, без всяких avr-make. 30 файлов - не проблема для препроцессора (д и это, вроде, любой компилятор ассемблера умеет). Использую его в нескольких закрытых проектов, один под atmega8 написан чисто на Rat, другие используют его для ассемблерных вставок критичного по скорости кода. Среди примеров есть еще достаточно большой проект прошивки для частотомера, он целиком на Rat.

Если я смогу скормит рекурсивно из директории src все файлы и получить hex - я в целом доволен буду)))

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

Я был уверен, когда начинал, что будет норм. Но у меня сейчас 400 байт прошивка весит. Чуть меньше половины реализовал. Как раз всё должно в 1 килобайт влезть - и мне уже тяжело читать. Особенно конечные автоматы и логику... Вот мой код текущий. Который портирую на Rat с радостью, как разберусь, что тут как.

Сыровато, колхозно, но вполне юзабельно, сам активно пользуюсь. Подготовлю архив. Сделана она на базе текстового редактора RText, с адаптацией под C/Asm/Rat/AVR. Несколько скриншотов:

По скринам вроде приемлемо. Если можно будет панель с ассемблером справа как второе окно открыть - то будет вообще топ. То что надо. Так не будет страха, что во что-то не то будет всё протранслировано.

[Vadimatorik]

Кстати а как дела с эмуляторами? Я пробовал запустить simavr, но потерпел неудачу (что-то не понравилось в моем elf файле, при том что hex из него прекрасно работал). Есть возможность отлаживать вообще как-то код? Мне вот едет отладчик с 1-wire. Можно ли будет им пользоваться и отлаживать код на Rat?

[trol73]

А в чем сакральный смысл вести два репозитория для одного проекта? При этом один открытый, другой закрытый?

Вопрос должен звучать скорее так "а зачем вообще нужен открытый репозиторий?" :) Открытый репозиторий сделан на случай, если кто-то вдруг захочет сделать нечто подобное для других CPU. Ну или поучаствовать в развитии компилятора под AVR, что пока крайне маловероятно. Рабочий репозиторий закрыт по всем тем же причинам:

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

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

И опять же, в чем причина, почему именно на сайте актуальная версия?

Потому, что это мой сайт :) И я ничем не ограничен на нем (например, могу сделать там подсветку синтаксиса для Rat). А гитхаб не мой. Сегодня он есть, и доступ к нему есть, а завтра - не факт, что Майкрософт вдруг не закроет к нему доступ, как она уже делала для разработчиков из Крыма, например.

А насчет этого можно по подробнее? Какие косяки есть и прочее? Есть где-то errata или типа того?) Или changelog. Об изменениях между версиями. Чтобы было понимание, чего опасаться))) А ту у меня автоматом страх, что например может с ссылкой закосячить или переход неверно интерепретировать... Такие баги - оч тяжко отлаживать...

С этим все нормально. У меня тоже был страх, что компилятор будет генерить неверный код, и код изначальнобыл покрыт тестами. Таких багов пока замечено не было. Основной вид исправленных "багов" - это когда какая-то конструкция вообще не компилируется. Ну и по мере написания кода было много изменений, когда становилось понятно, что вот такую-то конструкцию можно было бы записать более компактно/читаемо/удобно.

По поводу документации - там есть readme. Вроде, постарался описать там запуск компилятора и его командную строку. Которая до безобразия простая:

Usage: ratc [options] <source_file> [<output_file>]

OPTIONS:
  -D<macro>=<value>      Define <macro> to <value> (or 1 if <value> omitted)
  -I<dir>                Add directory to include search path
  -dev=<path>            Set path to dev-files
  -gcc                   Produce GCC Assembler file
  -help                  Show this usage screen

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

Если я смогу скормит рекурсивно из директории src все файлы и получить hex - я в целом доволен буду)))

А это же ассемблер. Как он склеит все файлы в один? Там же нет линковщика и порядок следования блоков может быть важен, и мы задаем его руками (чтобы, например, все rjmp/rcall "дотягивались" куда надо). Поэтому, тут просто include в нужном порядке. Либо использование GCC с написанием отдельных процедур на rat (с линкером жить проще, но и код будет жирнее).

По тестам - у меня оно работает так: есть девайс с дисплеем и пользовательским интерфейсом. Слой работы с железом пишется на Rat, высокоуровневая логика и пользовательский интерфейс - на Си. Для эмуляции делается пишется эмулятор низкоуровневого слоя (того же дисплея, клавиатуры и т.д.). В итоге прошивку можно скомпилировать и в hex и в исполняемый бинарник. Для отладки по-хорошему, надо simavr использовать. Правда, я с ним пока особо не работал. Отладчик с 1-wire с tiny13 - это вещи из разных миров, кмк :) Однокилобайтовый код можно отлаживать и методом пристального взгляда ) А если речь о работе с uart, то я бы делал тесты на PC. Чтобы они слали данные девайсу в uart, и проверяли результат. Для этого Можно девайсу пару временных отладочных команд добавить, которые будут возвращать его состояние.

Вот мой код текущий. Который портирую на Rat с радостью, как разберусь, что тут как.

Как будто он тоже в закрытой репе, у меня 404 показывает :)

IDE выложил сюда: http://www.trolsoft.ru/content/soft/trolcodestudio/rat-ide.tar.bz2 Для запуска нужна Java17. Если нормально запустится (пока только по макосью проверял), напишу, как ей пользоваться.. ) Листинг дизассемблера, теоретически, можно и правее поместить, хорошая идея. Но тут с этим у RText бывают глюки )

[Vadimatorik]

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

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

А насчет сайта - вероятность что он упадет и не восстанет выше, чем это сделает github))) Это большая проблема подобных проектов. Когда автор выкладывает бинари, а потом пропадает навсегда)))

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

Ну писать доку может только тот, кто знает как работает приложение))) От себя я смогу разве что личным опытом использования поделиться)

А это же ассемблер. Как он склеит все файлы в один? Там же нет линковщика и порядок следования блоков может быть важен, и мы задаем его руками (чтобы, например, все rjmp/rcall "дотягивались" куда надо). Поэтому, тут просто include в нужном порядке. Либо использование GCC с написанием отдельных процедур на rat (с линкером жить проще, но и код будет жирнее).

Аааааа... То есть тут подход как в AVR Studio с их include файлов в один? Просто в текущем проекте я делал кучу независимых и их отдельно собирал, делая переход по глобальным меткам...

Отладчик с 1-wire с tiny13 - это вещи из разных миров, кмк :) Однокилобайтовый код можно отлаживать и методом пристального взгляда )

Вообще да, но нет))) Сейчас вот отлаживал код по дерганью ножки. Вдруг sbic/sbis перепутал или еще чего такого чисто по невнимательности))) Да и спокойнее, когда он есть)

По тестам - у меня оно работает так: есть девайс с дисплеем и пользовательским интерфейсом. Слой работы с железом пишется на Rat, высокоуровневая логика и пользовательский интерфейс - на Си. Для эмуляции делается пишется эмулятор низкоуровневого слоя (того же дисплея, клавиатуры и т.д.). В итоге прошивку можно скомпилировать и в hex и в исполняемый бинарник.

А... Ну как с Си это делать - знаю. Тоже так делал. Просто думал может для Rat есть такая возможность...

Для отладки по-хорошему, надо simavr использовать. Правда, я с ним пока особо не работал.

Я пытался, у меня не сложилось с ним( Может руки кривые и надо было что-то в elf еще добавить.

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

Ну это когда есть через что возвращать))) Я-то сначала должен написать сам UART))) Светодиод мой лучший друг)

А если речь о работе с uart, то я бы делал тесты на PC. Чтобы они слали данные девайсу в uart, и проверяли результат.

Не хотелось бы С пихать... Приверженец того, что под attiny13a можно и на чем-то одном написать) Но на чистом ассемблере все равно много кода выходит...

Как будто он тоже в закрытой репе, у меня 404 показывает :)

А. Мой косяк. Не вывел из private))) Поправил. Я обычно просто в public вывожу с нормальным readme и минимально рабочей версией с описанием и инструкцией. Но пока так пусть. Пометку просто сделаю, что пока смотреть не на что)

IDE выложил сюда: http://www.trolsoft.ru/content/soft/trolcodestudio/rat-ide.tar.bz2 Для запуска нужна Java17. Если нормально запустится (пока только по макосью проверял), напишу, как ей пользоваться.. )

О, спасибо. Попробую в скором времени)

[Vadimatorik]

напишу, как ей пользоваться.. )

Внемлю))) Нифига не понятно))) Но очень интересно...

Потыкал немного, вроде не крешетася на open-jdk/jre 17.

[Vadimatorik]

[trol73]

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

А. Мой косяк. Не вывел из private))) Поправил. Я обычно просто в public вывожу с нормальным readme и минимально рабочей версией с описанием и инструкцией.

Ну собственно вот )) Ситуация аналогичная - выведу а публичный репозиторий как только приведу все в надлежащий вид )

Аааааа... То есть тут подход как в AVR Studio с их include файлов в один? Просто в текущем проекте я делал кучу независимых и их отдельно собирал, делая переход по глобальным меткам...

Ага. А как иначе? В каком порядке компилятору собирать файлы? Важен ли порядок их следования? А Если он будет меняться и сегодня компилятор упорядочит блоки из разных файлов так, а завтра по-другому? (а если это произойдет и что-то где-то сломает, причем, совсем в неожиданном месте, то у разработчика будет головная боль - "почему оно вдруг сломалась там, где я ничего уже давно не трогал")

Не хотелось бы С пихать... Приверженец того, что под attiny13a можно и на чем-то одном написать) Но на чистом ассемблере все равно много кода выходит...

Не-не, прошивка для МК - на чистом асме. А тесты пишутся отдельные, на компе большом, хоть на Си, хоть на условном питоне. Во время тестов комп подключается к девайсу по uart, шлет ему команды и проверяет ответ. Но да, для этого сначала потребуется рабочий uart )

По IDE. Там надо

1. на левой панели Projects вызвать контекстное меню правым кликом и выбрать New project
2. ввести имя проекта
3. подумать-погрустить на тему того, что в этом месте должен бы быть удобный мастер настройки проекта с указанием директории, выбором микроконтроллера и добавлением кода шаблона пустого проекта. но его пока нет
4. вызвать контекстное меню проекта и сделать Add files/Add folders, добавив все нужное
5. из контекстного меню проекта вызвать Properties. Там выбрать тип. Для AVR Rat проще всего AVR Rat. Builder - это если используется сборщик avr-make, также поддерживаются Makefile проекты.
6. Выбрать тип микроконтроллера. Помимо прочего это активирует дополнительную подсветку синтаксиса для выбранного МК (в с-, h- и art-файлах будут подсвечиваться названия портов и пинов данного МК).
7. В Main file указать путь к главному (корневому) art-файлу, который будет инклудить все остальное. Для проектов на avr-make тут указывается путь к скрипту make.builder.
8. Собственно все, теперь должна заработать сборка проекта (Project -> Build либо Ctrl+B). Upload firmware пока не работает (но надо бы сделать). Ctrl-M должно открыть вкладку с листингом, при навигации по исходному файлу будет подсвечиваться соответствующая строка в листинге. Для С-файлов листинг тоже должен бы быть, но пока вижу, что с этим все плохо и надо допиливать.

[Vadimatorik]

Так. Перед предыдущем сообщением. Я решил сначала ручками использовать RAT и собрать минимальный проект. Написал:

#define CPU "attiny13a"

use r16 as tr1

proc main() {
    SPL = tr1 = 0x60
}

Вызвал:

java -jar the-rat.jar -I/home/vadimatorik/proj/tiny_endpoint/src /home/vadimatorik/proj/tiny_endpoint/src/main.art 

И получил в том же каталоге: main.hex и main.hex.map.

При этом вывода в консоли вообще никакого. А теперь вопросы:

1. Как смотреть вес проекта и используемые ресурсы? (Сколько процентов и байт flash, сколько ram)
2. Почему в map у меня только 0000: main? Обычно же куча инфы идет о том где что как. Хотя бы вес метода узнать суммарных.
3. Как указать, что я хочу, чтобы исходники лежали в моей мусорной директории build?

[Vadimatorik]

И в догонку по -gcc вопрос. Почему он не использует equ конкретного МК? Вот мой вывод например:

#include <avr/io.h>

.global main

main:
    ldi    R16, 96
    out    61, R16

Ладно еще, что в 10-тичной системе выводит, а не в исходной (тоже кстати странно почему так). Но почему 61? Он же знает об определениях.

[Vadimatorik]

Ага. А как иначе? В каком порядке компилятору собирать файлы? Важен ли порядок их следования? А Если он будет меняться и сегодня компилятор упорядочит блоки из разных файлов так, а завтра по-другому? (а если это произойдет и что-то где-то сломает, причем, совсем в неожиданном месте, то у разработчика будет головная боль - "почему оно вдруг сломалась там, где я ничего уже давно не трогал")

Ну вот я собирал отдельными. И в какой-то момент код поломался от того, что breq больше не может дотянуться до нужной метки... Так что да. Этот метод имеет недостатки

[trol73]

Как смотреть вес проекта и используемые ресурсы? (Сколько процентов и байт flash, сколько ram)

Никак - это же ассемблер. Тут можно вообще не объявлять переменных но при этом использовать всю память.

Сколько флеша занято, можно по map/hex посмотреть. Если не используются директивы вроде org

Почему в map у меня только 0000: main? Обычно же куча инфы идет о том где что как. Хотя бы вес метода узнать суммарных.

map - это не листинг, это файл с адресами всех процедур и меток (и у последних размера нет). Емнип, даже gcc не пишет размеры методов. Ну и да, руки пока до всего не дошли )

Как указать, что я хочу, чтобы исходники лежали в моей мусорной директории build?

В смысле не исходники, а генеримые файлы? Для них можно добавить путь в конце

java -jar the-rat.jar -I/home/vadimatorik/proj/tiny_endpoint/src /home/vadimatorik/proj/tiny_endpoint/src/main.art /home/vadimatorik/proj/tiny_endpoint/build/main.hex

И в догонку по -gcc вопрос. Почему он не использует equ конкретного МК? Вот мой вывод например:

Потому, что к моменту компиляции эта информация теряется. Изначально я вообще не планировал генерировать листинг, а сразу создавать объектные файлы. Но с ними оказалось сильно сложнее, долго разбираться с форматом. Да, было бы лучше с константами и сохранением системы исчисления. А еще define-макросы не разворачивать и т.д. Но эта хотелка сильно все усложняет, поэтому не в приоритете. avr-make умеет собирать проект из совместных c- и art файлов и листинг тут создается в первую очередь для компилятора

Этот метод имеет недостатки

Тут даже не метод, а сам ассемблер ) на нем писать сложнее. но эффективнее )

[Vadimatorik]

Никак - это же ассемблер. Тут можно вообще не объявлять переменных но при этом использовать всю память.

Наверное, неверно выразился. Я когда пишу код - заранее резервирую память. Так что вижу, что в bss/data секции у меня есть кусок занятый. С flash такая же история. Вот мне бы и хотелось видеть вывод. Пример сборки avr-gcc того примера выше:

vadimatorik@vpc:~/proj/tiny_endpoint$ make
[AS] src/main.asm
Memory region         Used Size  Region Size  %age Used
           FLASH:           4 B         1 KB      0.39%
             RAM:          0 GB         64 B      0.00%
          EEPROM:          0 GB         64 B      0.00%

Что-то типа такого хотелось бы увидеть.

Сколько флеша занято, можно по map/hex посмотреть. Если не используются директивы вроде org

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

Пока что я вижу единственный выход - генерировать asm и собирать его отдельно. Но может есть вариант нативный?

map - это не листинг, это файл с адресами всех процедур и меток (и у последних размера нет). Емнип, даже gcc не пишет размеры методов. Ну и да, руки пока до всего не дошли )

Вообще не согласен. Или понял неверно. Вот вывод примера выше:

Memory Configuration

Name             Origin             Length             Attributes
FLASH            0x0000000000000000 0x0000000000000400 xr
RAM              0x0000000000800060 0x0000000000000040 rw !x
EEPROM           0x0000000000810000 0x0000000000000040 rw !x
*default*        0x0000000000000000 0xffffffffffffffff

Linker script and memory map

LOAD build/obj/./src/main.o

.irq_vector
 *(.text.irq_vector)

.text           0x0000000000000000        0x4
 *(.text)
 .text          0x0000000000000000        0x4 build/obj/./src/main.o
                0x0000000000000000                main

.trampolines    0x0000000000000004        0x0
 .trampolines   0x0000000000000004        0x0 linker stubs

.data           0x0000000000800060        0x0
 *(.data)
 .data          0x0000000000800060        0x0 build/obj/./src/main.o

.bss            0x0000000000800060        0x0
 .bss           0x0000000000800060        0x0 build/obj/./src/main.o

.eeprom
 *(.eeprom)
OUTPUT(build/tiny_endpoint.elf elf32-avr)
LOAD linker stubs

.debug_line     0x0000000000000000       0x41
 .debug_line    0x0000000000000000       0x41 build/obj/./src/main.o

.debug_info     0x0000000000000000       0x26
 .debug_info    0x0000000000000000       0x26 build/obj/./src/main.o

.debug_abbrev   0x0000000000000000       0x14
 .debug_abbrev  0x0000000000000000       0x14 build/obj/./src/main.o

.debug_aranges  0x0000000000000000       0x20
 .debug_aranges
                0x0000000000000000       0x20 build/obj/./src/main.o

.debug_str      0x0000000000000000       0x3e
 .debug_str     0x0000000000000000       0x3e build/obj/./src/main.o

Тут и адреса, секции, размеры - все указано. Были бы псевдонимы - были бы и они (equ которые).

В смысле не исходники, а генеримые файлы? Для них можно добавить путь в конце

О. Недокументированная фича. А последовательность важна, сначала одно, потом другое или он по разрешению определяет? Если я хочу например видеть все 3 файла, то какая последовательность? (map, hex, asm)

[Vadimatorik]

Потому, что к моменту компиляции эта информация теряется. Изначально я вообще не планировал генерировать листинг, а сразу создавать объектные файлы. Но с ними оказалось сильно сложнее, долго разбираться с форматом. Да, было бы лучше с константами и сохранением системы исчисления. А еще define-макросы не разворачивать и т.д. Но эта хотелка сильно все усложняет, поэтому не в приоритете. avr-make умеет собирать проект из совместных c- и art файлов и листинг тут создается в первую очередь для компилятора

Тут понятно. Принял. Но было бы все же круто, если бы такая возможность появилась.

[Vadimatorik]

Тут даже не метод, а сам ассемблер ) на нем писать сложнее. но эффективнее )

Я про то, что есть 2 способа сборки: собирать кучу asm отдельно и через .global связывать исходники компоновщиком или собирать один файл и в него включать другие.

[Vadimatorik]

Так. Попробовал воспользоваться средой. Пункты инструкции 1-3 были корректными. На 4 добавит директорию всего проекта-репозитория (опять же непонятно, почему путь мне предложили выбрать от корня файловой системы, а не от места, куда я сохранил проект по сtrl + s). А далее пошли проблемы. Я не могу выбрать device. Там только none. Потом попробовал собрать проект. И... Мне сказали, что у меня файл Шредингера. Вот фото:

[Vadimatorik]

Попробовал отдельно добавить файл вместо целой директории, но нет.

[trol73]

Что-то типа такого хотелось бы увидеть.

Кстати, да, последняя версия компилятора (она же встроена в IDE) умеет показывать объем занятого флеша.

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

А там же текстовый файл, а в нем в начале адреса и последний адрес данных показывает размер. IDE, кстати, их синтаксис умеет подсвечивать.

О. Недокументированная фича.

Очень даже документированная - оно и в usage написано и в readme :) Usage: ratc [options] <source_file> [<output_file>]

Так. А в stdout явы никаких исключений и сообщений об ошибках при этом не показывается?

[Vadimatorik]

Очень даже документированная - оно и в usage написано и в readme :)

А. Ну тут мой косяк, пропустил.

А там же текстовый файл, а в нем в начале адреса и последний адрес данных показывает размер. IDE, кстати, их синтаксис умеет подсвечивать.

Никогда ранее не читал его. Но в целом можно и научиться. Но это все равно костыль))) Табличка с процентами и размером лучше)

Так. А в stdout явы никаких исключений и сообщений об ошибках при этом не показывается?

Вот весь вывод с момента запуска до попытки Ctrl + B:

vadimatorik@vpc:~/prog/rat-ide$ java -jar rat-ide.jar 
Gtk-Message: 16:39:11.049: Failed to load module "canberra-gtk-module"
[ERROR]: Cannot locate JRE jar in /usr/lib/jvm/java-17-openjdk-amd64
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: javax.swing.text.BadLocationException: Negative line
    at org.fife.rtext.plugins.buildoutput.BuildOutputTextArea.appendText(BuildOutputTextArea.java:179)
    at org.fife.rtext.plugins.buildoutput.BuildOutputTextArea.appendImpl(BuildOutputTextArea.java:154)
    at org.fife.rtext.plugins.buildoutput.BuildOutputTextArea.lambda$appendImpl$0(BuildOutputTextArea.java:158)
    at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
    at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
    at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
    at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
    at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: javax.swing.text.BadLocationException: Negative line
    at java.desktop/javax.swing.JTextArea.getLineStartOffset(JTextArea.java:412)
    at org.fife.ui.rtextarea.LineHighlightManager.addLineHighlight(LineHighlightManager.java:54)
    at org.fife.ui.rtextarea.RTextArea.addLineHighlight(RTextArea.java:288)
    at org.fife.rtext.plugins.buildoutput.BuildOutputTextArea.appendText(BuildOutputTextArea.java:175)
    ... 15 more

[trol73]

Это не то ) Там была ошибка где он device-файлы не мог найти. Надо было jar в поддиректорию положить. Вообщем, исправил, перезалил архив (ссылка та же). Под убунтой у меня все работает. Для запуска сделал run.sh

[Vadimatorik]

О. Ща.

[Vadimatorik]

Попробовал. Начало собираться. Вывод стал таким:

Compile /home/vadimatorik/proj/tiny_endpoint/src/main.art
Size: 4
Done.
Done

Теперь такие вопросы:

1. Почему дважды Done?)
2. Как посмотреть код ассемблера прямо в среде?
3. Можно как-то настроить, чтобы видеть Flash: size byte, persent и Ram тоже самое?

[Vadimatorik]

Про RAM, это то что я пишу например так:

var current_command: byte
var video_memory: byte[32]

(это из примера) и хочу видеть 33.

[trol73]

1. это чудовищный баг IDE. и там их еще много есть )
2. для этого есть окно листинга, но, если оно чем-то не устраивает, всегда можно попробовать прикрутить внешний дизассемблер через Tools
3. по флешу он показывает количество байт, по оперативной памяти - не показывает. а у тини13 так вообще всего 64 байта памяти, такое можно и руками посчитать )

[Vadimatorik]

это чудовищный баг IDE. и там их еще много есть )

Кстати. Думаю, надо уточнить. Насколько здесь define - как define в С? Что допустимо делать? Я написал такой вот код и был послан куда подальше.

use r16 as tr1

#define SET_STACK_POINTER() SPL = tr1 = 0x60

proc main() {
    SET_STACK_POINTER()
}

Так и должно быть? Или это баг? Просто вся документация на С-- - это одна статья.

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

Открыл. Вроде норм. Пока устраивает.

по флешу он показывает количество байт, по оперативной памяти - не показывает. а у тини13 так вообще всего 64 байта памяти, такое можно и руками посчитать )

Можно, но все же))) Хотелось бы цифарки)

[trol73]

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

use r16 as tr1

inline proc setStackPointer() {
   SPL = tr1 = 0x60
}

proc main() {
   setStackPointer()
}

[Vadimatorik]

Ооооооо! Тут inline есть!) Чет забыл про это, пока читал. Да. так даже лучше)

Насчет извращения. SPL = tr1 - собирается tr1 = 0x60 - нет) Это если макрос кастрировать с одной их сторон)

[Vadimatorik]

Вопрос по оформления. Я привык использовать clang-format, чтобы форматировать код после каждого сохранения. Есть ли тут возможность как в CLion или прочих редакторах привязать нажатие на Ctrl + s к вызову clang-format с передачей нужных аргументов? Пример из CLion: Там правда надо File Watchers после установки сконфигурировать как на картинке. И написать:

program: clang-format  
arguments: -style=file -i $FileDir$/$FileName$  
Output path to refrash: $FileDir$/$FileName$

Но вот тут чет типа такого можно? Синтаксис очень похож на С. Так что могло бы вполне прокатить)

[Vadimatorik]

Вот пример компиляции с Done, но без листинга и целом оно походу не собирается:

#define CPU "attiny13a"

#define LED        PB2

inline proc gpio_rx_cfg_set() {
    DDRB = tr1 = ((1 << LED))
}

proc main() {
    gpio_rx_cfg_set()
}

При этом если PB2 заменю на 2 - то соберется. Та же тема с этим участком:

inline proc gpio_rx_cfg_set() {
    DDRB = ((1 << 2))
}

Но если напишу правильно, через регистр, то соберется:

inline proc gpio_rx_cfg_set() {
    DDRB = tr1 = ((1 << LED))
}

Но при этом ошибок никаких не выдает. Просто нет вывода. Странно.

[Vadimatorik]

Уточнение. Так, похоже, со всеми define-ами из описания регистров attiny13a. Может и других МК:

inline proc exti_init() {
    MCUCR = tr1 = (1 << SE2) | (1 << ISC01)
    PCMSK = tr1 = (1 << UART_TX_RX)
}

Тут первая строка соберется только если я заменю SE2 и ISC01 на константы сам. Есть мысли по этому поводу?

[trol73]

По поводу #define - это баг препроцессора, конструкция выглядит валидной, хотя такие штуки лучше не делать.

По автоформату кода - подозреваю, что так не получится сейчас сделать.

Далее в коде ошибки, оставил комменты

#define CPU "attiny13a"                   ; макрос CPU должен определяться автоматически, это писать не надо. но в IDE почему-то баг

;#define LED        PB2                     ; синтаксическая ошибка - PB2 - не числовая константа
pin LED = B2       ; надо так

use r16 as tr1

inline proc gpio_rx_cfg_set() {
;    DDRB = tr1 = ((1 << LED))   ; тут ошибка в (1 << LED), т.к. LED - не число

    ; правильно - так (всего одна машинная команда будет)
    LED->ddr = 1

    ; а еще можно так
    DDRB = tr1 = bitmask(LED)
}

proc main() {
    gpio_rx_cfg_set()    
}

Во втором примере тоже неверные константы. Кстати, их в студии даже по цвету видно - правильные названия портов и битов подсвечиваются особо. Смотрим определения в файле devices/avr/attiny13a.dev

MCUCR(0x35) {           ; MCU Control Register
        ISC00 = 0               ; Interrupt Sense Control 0 Bit 0
        ISC00 = 0               ; Interrupt Sense Control 0 bits bit 0
        ISC01 = 1               ; Interrupt Sense Control 0 Bit 1
        ISC01 = 1               ; Interrupt Sense Control 0 bits bit 1
        SM0 = 3                 ; Sleep Mode Select Bits bit 0
        SM1 = 4                 ; Sleep Mode Select Bits bit 1
        SE = 5                  ; Sleep Enable
        PUD = 6                 ; Pull-up Disable
}

Компилятор не знает значений для SE2 и UART_TX_RX

А ещё можно записать так: MCUCR = tr1 = bitmask(SE, ISC01) Оно и лаконичнее и компилятор проверит, что биты справа принадлежат одному и тому же порту

И да, наблюдается баг в студии - некоторые ошибки она не выдает, только в консоль выводит. И Done при этом пишется только один раз

[Vadimatorik]

define CPU "attiny13a" ; макрос CPU должен определяться автоматически, это писать не надо. но в IDE почему-то баг

Ну значит пока пусть остается. Раз IDE пока не может.

По автоформату кода - подозреваю, что так не получится сейчас сделать.

Жаль, но не критично. Пока и из консоли могу вызывать.

;#define LED PB2 ; синтаксическая ошибка - PB2 - не числовая константа

А должна быть ею. Или тут не используются стандартные файлы с чем-то типа: equ PB2, 2? Типа тут все свои определения из файла конкретно компилятора своего, или и из стандартного берутся? Я просто был уверен, что есть свои описания МК, а есть еще глубже стандартные из gcc. В которых описано все по-классике.

; DDRB = tr1 = ((1 << LED)) ; тут ошибка в (1 << LED), т.к. LED - не число

Ну я изначально предполагал что LED == PB2 == 2. Думал, что будет взято число из стандартного файла gcc для МК, который включен. Но, видимо, это не так.

LED->ddr = 1 ; правильно - так (всего одна машинная команда будет)

Когда только 1 бит, да. Я это для port пользую. Классная штука. Я впервые подобное увидел в MicroPascal. Там можно было писать PORTA.5 = 1. Тут чуть иной синтаксис, но тоже норм.

DDRB = tr1 = bitmask(LED)

Прикольная штука) А получить индекс можно какой-то командой? Чтобы например bitmask дал мне 0x04, а bitindex (примерное название команды) дал бы 2? Это было бы полезно, когда настраиваешь прерывание для нужного входа. Хотя конкретно там и маска в целом норм. Но метод был бы полезный)

Смотрим определения в файле devices/avr/attiny13a.dev

Выходит, кроме них нет никаких определений? Я думал, что он просто дополняют)

MCUCR = tr1 = bitmask(SE, ISC01)

О, а это полезно, да. То что надо, я бы даже сказал.

И да, наблюдается баг в студии - некоторые ошибки она не выдает, только в консоль выводит. И Done при этом пишется только один раз

Это как уровни "запрещено", "строго запрещено", "ужасно запрещено", только для "сделано"))) Орнул с этого)

[Vadimatorik]

Еще немного молчания об ошибках. Добрался до векторов и там если написать rjmp и не написать сам метод - то тоже не соберется. Типа такого:

vectors {
PCINT0: 
  rjmp   pc_int_0_irq_handler

default:
  reti
}

При этом не описать pc_int_0_irq_handler.

[Vadimatorik]

Хм... Еще интересный момент, а в IDE возможно настроить, чтобы она рекурсивно передавала директории ниже выбранной компилятору? А то приходится явно в include писать пути.

[trol73]

А должна быть ею. Или тут не используются стандартные файлы с чем-то типа: equ PB2, 2?

Не должна, т.к. нет такого в dev-файле (а их я по атмеловским xml-кам генерил)

А получить индекс можно какой-то командой?

Неа. А зачем? Индекс же обычно первичен, а маска вторична. Не могу представить себе случая, где оно надо.

Багу с замалчиванием ошибок исправил, обновил the-rat.jar (но не архив с IDE!), его надо в libs обновить https://github.com/trol73/avr-make/blob/master/tools/the-rat.jar

С рекурсивными путями для include оно ничего такого нет

[Vadimatorik]

Не должна, т.к. нет такого в dev-файле (а их я по атмеловским xml-кам генерил)

Понял-принял. Вопросов тут нет.

Неа. А зачем? Индекс же обычно первичен, а маска вторична. Не могу представить себе случая, где оно надо.

Ну вообще я подумал, в целом да. Не надо. Ну по крайней мере сейчас.

Багу с замалчиванием ошибок исправил, обновил the-rat.jar (но не архив с IDE!), его надо в libs обновить

Попробую, спасибо за оперативность)

С рекурсивными путями для include оно ничего такого нет

А планируется?

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

Еще об IDE: есть ли возможность как-то включить переходы по методам? Как в CLion ctrl + ЛКМ по методу-использованию уводит к реализации.

[Vadimatorik]

Также пара вопросов:

1. Можно ли как-то в IDE настроить, куда будут файлы генерироваться?
2. Все файлы целиком перисобираются при сборке или только измененные?

[Vadimatorik]

Багу с замалчиванием ошибок исправил, обновил the-rat.jar (но не архив с IDE!), его надо в libs обновить https://github.com/trol73/avr-make/blob/master/tools/the-rat.jar

В IDE в lib лежит только файл rat-ide.jar. Мне в его внутреннастях рыться и там заменять?

[Vadimatorik]

Я наткнулся на магию в этом участке:

use r16 as tr1

inline proc tim_period_set(period: tr1) {
    OCR0A = period          
}

inline proc uart_fsm_state_set(state: tr1) {
    ; Сам факт вызова присвоит значение tr1.
}

Метод tim_period_set - выкинет:

Compile /home/vadimatorik/proj/tiny_endpoint/src/main.art
ERROR: /home/vadimatorik/proj/tiny_endpoint/src/mcu/tim.art:25:36: Unknown identifier: tr1
Compilation error
Done

Тогда как uart_fsm_state_set будет успешно заменен на ldi r16, значение.

Что из этого недоработка?) Просто на вид одно и тоже же.

[Vadimatorik]

И еще заметил, что если я пишу что-то типа:

inline proc uart_fsm_state_set(state: tr1) {
    ; Сам факт вызова присвоит значение tr1.
}

И пишу uart_fsm_state_set(20), то оно будет преобразовано в ldi. А если uart_fsm_state_set(0), то в clr. Так и положено? В целом-то всё верно. Просто интересно. Они же весят и кушают одинаково.

Кстати avr-gcc почему-то никогда clr не использует. Он заменяет на xor r16, r16 зачем-то.

[trol73]

А планируется?

Возможно, не совсем понял проблему. А в препроцессоре Си такое есть? Кмк, такая штука не выглядит сильно приоритетной. И, как вариант, можно директивой -I подобавлять все директории с заголовками. Либо в каждой директории создать файл, в котором инклюдить все остальные, а потом инклюдить его. Но вообще пока не сталкивался с такой проблемой, если не класть каждую функцию в свой собственный файл )

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

По багам в Rat можно заводить сразу. Баги надо фиксить. По фичам - лично мне дидятся приоритетными те, которые сделать проще и при этом от них будет максимальная польза (будут часто использоваться и делать код лучше/проще/читабельнее).

Еще об IDE: есть ли возможность как-то включить переходы по методам? Как в CLion ctrl + ЛКМ по методу-использованию уводит к реализации.

С IDE такая штука.. Она основана на RText и функционал в нем не сильно богатый. Переходы по меткам в принципе сделать можно. Хотя и не прям очень просто. Но лично мне сейчас не хватает функционала рефакторинга и автодополнения кода. И тут вопрос - стоит ли вообще сильно развивать IDE в таком виде, или же использовать другую основу (Idea, NetBeans, Eclipse, Visual Studio Code)..

Можно ли как-то в IDE настроить, куда будут файлы генерироваться?

Как вариант, можно использовать сборку через Makefile с кастомизацией нужных параметров.

Все файлы целиком перисобираются при сборке или только измененные?

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

В IDE в lib лежит только файл rat-ide.jar. Мне в его внутреннастях рыться и там заменять?

Упс, забыл, что оно там внутри. Сюда буду выкладывать последнюю jar-ку http://www.trolsoft.ru/content/soft/trolcodestudio/rat-ide.jar

Что из этого недоработка?) Просто на вид одно и тоже же.

Выглядит как бага ) Не везде происходит подстановка алиасов, хотя inline-вызывалка тоже должна бы это делать. Никогда не использовал их таким образом и не заметил )

И пишу uart_fsm_state_set(20), то оно будет преобразовано в ldi. А если uart_fsm_state_set(0), то в clr. Так и положено? В целом-то всё верно. Просто интересно. Они же весят и кушают одинаково.

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

Кстати avr-gcc почему-то никогда clr не использует. Он заменяет на xor r16, r16 зачем-то.

На самом деле, никакой clr не существует ) Это просто синоним для eor r, r (https://trolsoft.ru/ru/avr-assembler?cmd=clr) придуманный маркетологами, чтобы сказать, как много существует разных команд в AVR ) А байткод у них одинаковый, и разные декомпиляторы могут по-разному показывать

[Vadimatorik]

Возможно, не совсем понял проблему. А в препроцессоре Си такое есть? Кмк, такая штука не выглядит сильно приоритетной. И, как вариант, можно директивой -I подобавлять все директории с заголовками. Либо в каждой директории создать файл, в котором инклюдить все остальные, а потом инклюдить его. Но вообще пока не сталкивался с такой проблемой, если не класть каждую функцию в свой собственный файл )

Ну вообще это решается системой сборки обычно. В том же CMake или Makefile в avr-gcc через -I передается список каталогов проекта. Тут это можно сделать? Имею ввиду в среде. Из консоли-то понятно что можно.

По багам в Rat можно заводить сразу.

Пройдусь по треду чуть позже тогда и открою карточки. По тем вопросам, что еще не решены.

С IDE такая штука.. Она основана на RText и функционал в нем не сильно богатый. Переходы по меткам в принципе сделать можно. Хотя и не прям очень просто.

Ну это здорово бы ускорило написание кода и его чтение-сверку...

Но лично мне сейчас не хватает функционала рефакторинга и автодополнения кода.

Вот да. Я уже автоматом нажал комбинацию из CLion для рефактоинга и автодополнения, а там ничего... Удивился. Взгрустнул.

И тут вопрос - стоит ли вообще сильно развивать IDE в таком виде, или же использовать другую основу (Idea, NetBeans, Eclipse, Visual Studio Code).

Ну вот вопрос, да. Может логичнее просто плагин для той же Visual Studio Code сделать. Она сейчас в тренде. Idea тоже норм. Eclipse как-то не хотелось бы возвращаться... Я слишком часто его вижу, когда работаю с QNX и китайскими чипами (среды над ним). Но это вкусовщина. В целом текущий редактор и стиль мне нравится.

Как вариант, можно использовать сборку через Makefile с кастомизацией нужных параметров.

Ок. У меня в целом есть мой Makefile с версии под asm. Так что попробую притянуть сюда.

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

Да. Сталкивался с этой проблемой, когда собрал отдельные файлы. А тут по сути идет сборка одного, включающего другие. Так что в целом тут в любом случае один файл. Просто непонятно было, как в среде это проихсодит. Ну 1 кб прошивки-то собрать не проблема, да) Даже 64 не проблема)))

Упс, забыл, что оно там внутри. Сюда буду выкладывать последнюю jar-ку http://www.trolsoft.ru/content/soft/trolcodestudio/rat-ide.jar

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

Выглядит как бага ) Не везде происходит подстановка алиасов, хотя inline-вызывалка тоже должна бы это делать. Никогда не использовал их таким образом и не заметил )

Тогда баг. Поставлю issue. Я просто не люблю использовать r16 там и прочие имена явные. Лучше так. Меньше рефакторить. А когда рефактора в целом нет - спасает. Я вот перепутал назначение r0 и r1 в ABI для С-GCC. Щас бы весь код руками пошел исправлять. А так в одном месте поправил и успех)

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

Да мне просто понять, почему так сделано. Это не баг. Все корректно) Просто так и запишем "так исторически сложилось")

На самом деле, никакой clr не существует ) Это просто синоним для eor r, r (https://trolsoft.ru/ru/avr-assembler?cmd=clr) придуманный маркетологами, чтобы сказать, как много существует разных команд в AVR ) А байткод у них одинаковый, и разные декомпиляторы могут по-разному показывать

Ну я всегда подозревал, а усидчивости дочитать до этого пояснения не хватило...

[Vadimatorik]

Еще вопрос по не оптимальной реализации ветвлений, когда нет else. Вот пример метода, который принимает бит данных uart-а и помещает в программный сдвиговый регистр как старший бит. Предварительно сдвинув прошлое значение вправо:

inline proc rx_data_bit() {
    udr >>= 1                        ; Биты идут от младшего к старшему.
    if (tx->pin) {                   ; Если 1 на входе, то он теперь
        udr[7] = 1                   ; самый старший.
    }                                ; А 0 и так после сдвига.
}

Тут по сути можно не делать ветвления как такового. А сделать "пропустить если 0". Тогда никаких переходов по сути писать не нужно было бы. Есть в планах проработать эту конструкцию?

Сейчас она перетекает в:

0000006a: sbis  22, 0
0000006c: rjmp  tim_0_ovf_irq_handler_in_in_in_in_in_in_in_in_in_in_inl_inl_in_in_in_in_in_i_inl_i_inl@if_end@29 (tim_0_ovf_irq_handler@tim_0_ovf_irq_handler_in_in_in_in_in_in_in_in_in_in_inl_inl_in_in_in_in_in_i_inl_i_inl@if_end@29)
0000006e: sbr   R21, 128

Что кушает больше кода, чем хотелось бы)

[Vadimatorik]

И сразу вопрос. Что с названиями меток?) Оно же нечитаемо))) tim_0_ovf_irq_handler_in_in_in_in_in_in_in_in_in_in_inl_inl_in_in_in_in_in_i_inl_i_inl@if_end@29 (tim_0_ovf_irq_handler@tim_0_ovf_irq_handler_in_in_in_in_in_in_in_in_in_in_inl_inl_in_in_in_in_in_i_inl_i_inl@if_end@29. Это же просто жесть)

[Vadimatorik]

Поставил отдельные issue о том, что тут обсуждали. Вроде бы всё перечислил. Чтобы не потерялось.

[trol73]

"Горшочек, не вари!" )) IDE - это отдельный, даже не особо публичный проект, к этой репе он не относится, и я сильно не уверен, что буду развивать его в таком виде. А такие штуки, как рефакторинг сделать с нуля будет не просто. Правильнее было бы использовать что-то более продвинутое для базы и дополнить плагинами.

[trol73]

Еще вопрос по не оптимальной реализации ветвлений, когда нет else.

Кстати, да. Не уверен, что это достаточно отображено в документации, но тут скобки имеют значение. Если нужно оптимальным образом скомпилировать условие, то пишется в одну строчку: if (tx->pin) udr[7] = 1 Но так не все конструкции получится скомпилировать. Если код со скобками, то будет jmp. Не утверждаю, что это прям хорошее решение, но оно простое в реализации и позволяет решать все задачи. Так что пока так.

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

Принял, пропатчу. А кроме ручного счета MD5 есть способ узнать, что версия новее?

Пока весь мир не начал массово кодить под AVR на Rat-е, буду отписываться об обновлениях, например, тут )

[Vadimatorik]

"Горшочек, не вари!" )) IDE - это отдельный, даже не особо публичный проект, к этой репе он не относится, и я сильно не уверен, что буду развивать его в таком виде. А такие штуки, как рефакторинг сделать с нуля будет не просто. Правильнее было бы использовать что-то более продвинутое для базы и дополнить плагинами.

Поставил тут, чтобы не забыть. И не потерять. Если будет перенос на другую среду - просто закрыть с пояснением, почему да и все можно потом)