НЕЕ! это только для АВРок - ёжли добавить тудыть еще ПИКи и MCS51 (а в перспективе еще чего...) то уж слищшком много времени теории в ущерб практике будет. Тем более без особой на то надобности - я ж придерживаюсь принципа использовать ассемблер как ассемблер, а си как Си (и то не более, чем в адуринкином референсе имеется). То уж пущай помоложе учебой занимаются.
Последний раз редактировалось BOB51 Пн мар 23, 2020 15:30:54, всего редактировалось 1 раз.
- если та же задача решена другим способом - неудачный вариант отметается, но задача то решена. ходы записаны:
Цитата:
Пример, который я привёл выше - всего лишь одна из разновидностей классического решения при работе под " чистым ассемблером". И таких приёмов, некорректных по отношению к "чистому Си" достаточно много встречается.
oleg110592 Это просто из желания подтвердить право на существование ассемблерных файлов в составе проекта на СИ? Тогда можно проще - разрешено подключение файла на ассемблере, напиасного в соответствии с требованиями, установленными в описании компилятора СИ. Все, что не соответствует вышеуказанным требованиям предварительно должно быть соответственно изменено.
dosikus Просто на сегодня такой вопрос не актуален. (Как в свое время и Си с адуринкой).
нет - было утверждение "всего лишь одна из разновидностей классического решения И таких приёмов,..". Мне показалось это утверждение в корне неверным, что и было доказано. Ну и txt файлы подключать некрасиво (имхо) - надо по документации - сильный удар по неокрепшим умам
Приемов чисто ассемблерных для неперемещаемого кода вполне достаточно. Однако их место именно в рамках ассемблера - для Си без модификаций (иногда достаточно кардинальной) они малопригодны. Насчет *.txt - вполне себе оправданно - не все же компиляторы однокомпонентные. А там, где присутствует линкер обработка совершенно иная, чем в рамках атмелевского ассемблера для АВРок (и его аналогии для MCS51 - c51asm.exe). Посему и ставятся *.txt как фактически текстовое расширение единственного обрабатываемого компилятором файла проекта. Посему кстати и ограничение, правда в явном виде только в документации на c51asm.exe записанное: ".... 7.1 7.1 Restrictions C51ASM only generates absolute object files instead of relocatable object modules. The entire object is built in one step without calling a linker. Therefore the entire source code of an application program must reside in a single file and its subsequent include files. The assembler directives that deal with relocatable segments or external or public symbols have not been implemented, but are still reserved. These include: PUBLIC EXTRN SEGMENT RSEG C51ASM does not support the Intel Macro Processing Language (MPL). Only standard callable macros and repeat macros are supported. ..." Но ... поскольку оба компилятора от единого разработчика и по одной схеме делались, то данное и аврасм 2 также касается (может не так заметно в рамках IDE ) А вот у ПИКов мпасм по классической схеме с линкером. Там компоновка многомодульных делается иначе. В то же время вставка инклудом *.txt работает одинаково во всех трех компиляторах.
Приемов чисто ассемблерных для неперемещаемого кода вполне достаточно. Насчет *.txt - вполне себе оправданно
1)таких приемов не встречал - просил уже показать, только не свои доморощеные, аж интересно стало. 2)тхт - тоже нигде не встречал, особенно в примерах производителей микроконтроллеров, тут имхо лучше или быть как все, или рот на замке
Вот так и хочется "заткнуть инакомыслие". Если удается получить удобный вариант, отличающийся от общеизвестного - сразу кучка "не позволямс". (тем более, что тот вариант доказал свою работоспособность по серии проектов, в том числе и открыто опубликованных на Радиокоте). Относительно вставок файлов в Си проектах... Собственно исходя из того, что компилятор Си сам распределяет ресурсы (планировка памяти, стек и прочие мелочи), а ассемблер предусматривает полную свободу действий в тех же вопросах, уже имеет место вероятный "конфликт интересов". Посему и оговорка должна быть - ассемблерные вставки (файлы) созданные с соблюдением требований компилятора Си. Самое интересное - "без цитаты на иноземный источник" доверия к высказываниям не имеется. Ну да меня сие как-то не сильно огорчает - Все равно оценка по действующему макету выполняется.
dosikus Вот и я про то же самое: .include "librus\trd2812_ma.txt" абсолютно равноценно для компилятора ассемблера avrasm2 нижеследующему .include "librus\trd2812_ma.asm" ибо выполняет ВСЕГО ЛИШЬ ПОДСТАНОВКУ ТЕКСТА содержащегося в файле. Даже при условии, что сам файл является самостоятельной компонентой (библиотечной подпрограммой/модулем). Причем именно туда, куда это подключение будет выполнено при написании файла, его содержащего! Другое дело ассемблер, содержащий раздельную обработку каждого из *.asm(*.s) файлов с последующей обработкой полученного результата редактором связей (линкером). (Вполне вероятно в компиляторе GCC/Си именно такое решение применяется) А мне ранее приводили именно вариант инклуд подключения *.asm файлов в основном файле проекта для avrasm2 как образец модульного проекта на ассемблере (не на СИ!), отличающегося от такового с использованием *.txt файлов.
Посему и обзываю свой вариант "слэнга" "многофайловый проект под ассемблером".
не в том дело - форум публичный, тут новички обитают - а у всех языков есть правила - учится бы надо правильному. В принципе мне лично все равно, но неприятный осадочек остается - на другом, более взрослом форуме, наверняка канделябром по голове. Пример, взрослый ассемблер
Код:
NCLUDE это директива, которая позволяет включать часть кода в конечную программу. Вы найдете повторяющиеся строки:
mov dx,offset Hellostr mov ah,09h int 21h mov dx,offset str2 mov ah,09h int 21h Давайте изменим этот шаге используя директиву INCLUDE. Создает файл Write.asm с кодом внутри:
mov ah,09h ; функция вывода строки int 21h И переписываем шаг используя INCLUDE - write.asm:
MODEL TINY STACK 100h DATASEG Hellostr DB 'Hello First Step Site $' str2 DB 'Step 16 $' CODESEG start: mov ax,@data mov ds,ax mov dx,offset Hellostr INCLUDE write.asm mov dx,offset str2 INCLUDE write.asm mov ah,04Ch mov al,1h int 21h
write.asm имхо в тексте понятнее и нагляднее write.txt. з.ы. на этом придираться к этой части прекращаю - не переубедить.
Зато получим "пинка" при работе с классическими многокомпонентниками, включая мпасм (мплабIDE 8.92), любимый dosikusом кейл и прочие компиляторы с линкером. Насчет начинающих - кому и "линейный примитив" достаточен, а кому поразбить "сверхлист" на кусочки... Каждый свое выбирает. Потому как те компиляторы, что с линкером вполне обоснованно могут матюкнуться на некорректно включенный файл (в опциях линкера не указанный). А так - хотя бы единство оформления имеет место быть. *.asm это самостоятельный файл, внешний по отношению к главному файлу проекта. Данный файл обрабатывается компилятором отдельно и затем весь проект "сшивается" при помощи линкера. А добавляемые (включаемые) в главный файл проекта текстовые файлы, которые затем обрабатываются как составляющая текста главного файла проекта - это обычные *.txt файлики. Кроме прочего я ставлю подключение только в главном файле проекта - а там и так все прекрасно видно... К примеру у того же "замигателя" он вот такой Спойлер
Код:
; ; hider file for ATtiny25/45/85 chip ; version 1.02 KOBRA softvare ; for version2 assembler! ;---------- ; ; Projekt _______tnX5_2812 ; Filename ______test2812.asm ; File version __ ; Autor _________ BORIS KRUTITSKIY ; ;---------- ; основная конфигурация (in shipped): ; ----- Fuse Extended Byte ----- ; SELFPRGEN = 1 Self-programming enabled (активирован=0, деактивация=1) ; самопрограммирование (команда SPM) запрещено (0-разрешено) ; ----- Fuse High Byte ----- ; RSTDISBL = 1 External reset disabled (активирован=0, деактивация=1) ; !!! после активации RSTDISBL=0 репрограммирование МК возможно ; исключительно в режиме "high-voltage serial mode" !!! ; DWEN = 1 DebugWIRE enabled (активирован=0, деактивация=1) ; Must be unprogrammed when lock bit security is required. ; SPIEN = 0 Serial program and data download (активирован=0, деактивация=1) ; по умолчанию SPIEN=0, изменение статуса с ponyprog2000 недоступно. ; WDTON = 1 Watchdog timer always on (активирован=0, деактивация=1) ; EESAVE = 1 EEPROM preserves chip erase (активирован=0, деактивация=1) ; по умолчанию EESAVE=1 (EEPROM not preserved) ; BODLEVEL2:BODLEVEL1:BODLEVEL0 = 111 Brown-out Detector trigger leve ; 111 система brown-out detection отключена ; 110 = 1,7-1,8-2,0 V ; 101 = 2,5-2,7-2,9 V ; 100 = 4,1-4,3-4,5 V ; 0xx reserved ; ----- Fuse Low Byte ----- ; CKDIV8 = 0 Clock divided by 8 (активирован=0, деактивация=1) ; CKOUT = 1 Clock output enabled (enabled=0, disabled=1) ; SUT1:SUT0 = 10 Slowly rising power, Start-up Time from Power-down = 6CK, ; Additional Delay from Reset (VCC = 5.0V) = 14CK + 64mS ; CKSEL3:CKSEL2:CKSEL1:CKSEL0 = 0010 внутренний RC генератор 8МГц ;---------- ; ВНИМАНИЕ!!! ; В области сигнатуры ATtiny25/45/85 размещаются два байта ; калибровочных констант для внутреннего RC генератора. ; Старший байт по адресу 0х01 содержит калибровочную константу ; для работы генератора на частоте 8 MHz. Данная константа ; будет автоматически загружена в OSCCAL по окончании сигнала сброса. ; по адресу 0х03 находится константа для частоты 6,4МГц (режим совместимости ; с ATtiny15. Данная константа также ; будет автоматически загружена в OSCCAL по окончании сигнала сброса. ; в соответствующем режиме. ; ;конфигурационные ячейки могут быть записаны только при помощи ;программатора,а прочитаны как программатором,так и командой LPM. ;общее стирание ИС на содержимое конфигурационных ячеек не влияет. ; ; относительно режимов внутреннего ускорения/PLL (16МГц sys & 64/32МГц PCK) ; и режима совместимости с ATtiny15 дополнительно смотреть документацию!!! ;---------- ; ; выбрана текущая конфигурация проэкта: ; ; SELFPRGEN = 1 самопрограммирование (команда SPM) запрещено ; RSTDISBL = 1 вывод RST как вход сброса ; (0- только при наличии "высоковольтного программатора!!!) ; DWEN = 1 отладка gebugWire запрещена ; SPIEN = 0 последовательное программирование разрешено ; WDTON = 1 WDT может быть включен программно ; EESAVE = 1 общее сирание и EEPROM - 1 стирает ; BODLEVEL2:BODLEVEL1:BODLEVEL0 = 111 система brown-out detection отключена ; CKDIV8 = 0 активирован режим делителя на 8 ; (clkps 3-0 = 0011 /коэффициент деления=8/) ; CKOUT = 1 вывод системной частоты на вывод РВ4 запрещен ; SUT1:SUT0 = 10 Slowly rising power, Start-up Time from Power-down = 6CK, ; Additional Delay from Reset (VCC = 5.0V) = 14CK + 64mS ; CKSEL3:CKSEL2:CKSEL1:CKSEL0 = 0001 внутренний RC генератор 8МГц на PLL ; итоговая тактовая 16МГц. Статус PLLE игнорируется ; использование LSM НЕ РЕКОМЕНДУЕТСЯ ; ;---------- .nolist .include "baseinc\tn45def.inc" ; tn45def.inc tn85def.inc .list ; ---------- .include "librus\map_def_t2812.txt" ; файл объявленных имен, бит и констант .include "librus\mac_t2812.txt" ; файл описания макросов ; вместо name project подставляется имя файла соответствующего проекта ; шаблоны имеют name project = proto ;_____ .include "librus\irq_t45.txt" ; файл описания векторов сброса и прерываний ; .include "librus\trd2812_m.txt" ; файл обработчика передачи массива ; из буфера вывода в линейку на основе WS2812B .include "librus\libr_t45_m.txt" ; файл библиотек подпрограмм общего применения .include "librus\hass.txt" ; файл библиотеки простейшего ГСЧ .include "librus\mark_t0.txt" ; файл обработчика генерации ; маркеров тайм-сетки при помощи таймер-счетчика Т/С0 .include "librus\hard_t45_m.txt" ; файл аппаратной инициализации системы .include "librus\soft2812.txt" ; файл теста дисплея WS2812 .include "librus\trd2812_m.txt" ; - - - - - - - - - - - - - - - - - - - - - - - - - - - .exit
Добавлена "шапка" из описания фузов кристалла по умолчанию и для текущего проекта. (аналогия с заголовочником ПИКовых). А дальше перечень подключаемых фрагментов.
Кстати... решил проверить мой "перемещаемый вариант"... на макетке... И таки обнаружил ошибку - не доменял данные в концовке. Еще один пинок-напоминание - ставить именованные константы вместо просто цифирек, дабы потом не выискивать - "где ж та клятая константа еще была??" (по прошествии энного времени от написания исходника). Вот работоспособный текст: Спойлер
Код:
; ; ; trd2812_m.txt ; ; файл обработчика передачи массива ; из буфера вывода в линейку на основе WS2812B ; базовый МК из линейки АТМЕЛ при тактовой частоте ; от 16 Мегагерц ( 0,000000062 S) ; ; требуемые интервалы по даташиту WS2812B ; ;Data transfer time( TH+TL=1.25µs±600ns) ; T0H 0 code ,high voltage time 0.4us ±150ns ; T1H 1 code ,high voltage time 0.8us ±150ns ; T0L 0 code ,low voltage time 0.85us ±150ns ; T1L 1 code ,low voltage time 0.45us ±150ns ; RES low voltage time Above 50µs ; исходный уровень линии связи = 0 ; данные передаются пакетами из трех байт на точку ; старшими битами вперед в последовательности ; соответствующей G - R - B цветам точки ; количество блоков должно соответствовать ; количеству точек в ленте ; ; реальные данные согласно тест - отладки дебаггером (версия1!) ; авр-студио 4.19 ; ; Data transfer time( TH+TL=1.38µs -10ns) ; T0H 0 code ,high voltage time 0.44us ±10ns ; T1H 1 code ,high voltage time 0.88us ±10ns ; T0L 0 code ,low voltage time 0.94us ±10ns ; T1L 1 code ,low voltage time 0.50us ±10ns ; RES low voltage time 192,88uS (Above 50µs) ; ; длина прерывания с пакетом загрузки (x60*3) = 2175uS (0.002175) ; интервал между прерываниями (irq t/c0) = 0.004S (4000uS) ; ; define datas ; .equ port_out = PORTB ; порт вывода (по усмотрению) ; .equ out_line = 0 ; линия вывода данных ; .equ bufout = SRAM_START ; начальный адрес буфера вывода ; .equ pixel = 60 ; количество точек в линейке/ленте ; .equ bufout_size = (pixel * 3) ; не может быть более объема ОЗУ - стек!!!
Не надо делать мешанину - в Вашем последнем примере линкер - то имеется в наличии! Тем более tasm - это борландовская версия для I8086 в нюансах коего я особо не разбирался. И опять же "требуются дополнительные настройки линкера"... А речь в случае АВРок речь идет об однокомпонентном ассемблере. Но тогда это (инклуд текста) будет простая текстовая подстановка. Зато безо всяких "дополнительных настроек". Суть разницы в том, что файл, скомпилированный отдельно может иметь свое пространство локальных имен. Общими будут лишь те, что объявлены public/extern... (Собственно модульное построение при максимальной возможной автономности каждого из модулей). А при компиляции единым текстом - все пространство имен будет ЕДИНЫМ. Да и стыковка сегментов различных областей памяти также или по заданию в опциях редактора связей или линейная, согласно последовательности размещения подключаемых фрагментов. Также возможны нюансы при объявлении именованных констант/данных. С учетом того, что при развитии тех же STM8\STM32 и иных МК, где имеется совмещенная область памяти программ/данных, снова происходит возврат к сегментированию разделов памяти в стиле I8086 (атрибуты сегмента - видимость, размерность, размещение и прочее...) приходится рассчитывать на усложнение правил работы с ассемблером в чистом виде до полного варианта к правилам МАСМ в ближайшей перспективе... (Да минует нас необходимость работы под ассемблером для STM8\STM32! АМИНЬ!!! ). Выбор как обычно за пользователем - или заниматься индивидуальными настройками компилятора конкретно в каждом из проектов или использовать единую настройку по умолчанию. Это уже у каждого по своему.
"Мне удалось соорудить вариант слэнга для организации многофайловиков под ассемблером (одинаково работающий в рамках всех трёх семейств - mcs51/avr/pic)"
Писал же:
Цитата:
"под одну гребенку не причешешь"
Ассеблер до лампочки какой "однокомпонентный" или там "многочленный" (у всего есть правильные названия и правила, слэнг не катит) - тоже написал: "если с умом подходить" - можно копилировать только один файл и линковать тоже один получившийся после компиляции один файл, тогда брюки превращаются в "однокомпонентный" - вот тут пользователь и может выбирать при создании проекта. И каждый по своему тоже не катит (слэнг), а согласно документации и примерам производителя микроконтроллера или создателя ИДЕ для оного. В Кейл, например полно примеров готовых разнообразных проектов. з.ы. однако начинаем кругам иходить по пройденому материалу, тут, пожалуй пока и остановлюсь...
Да как раз не "кругами"... Вопрос действительно заслуживает хорошей разборки. Расширение *.asm имеет право иметь файлик, исходник которого самодостаточен для автономной обработки компилятором. При том, что у данного модуля (если использхуется механизм инклуд -вставок) не будет обращений к внешним меткам/данным основного проекта. Т.е. после подключения текст файла не подвергается дополнительной ручной обработке. В случае с классикой и линкером ручная обработка не потребуется. А вот при инклуд -вставке... дело посложнее. В каждом проекте имеются секции "холодной" и "горячей" инициализации (а также секция объявленных имен для констант, данных, РСФ). Типичное расположение таких секций в начале главного файла проекта. У каждого сложного модуля (библиотечный *.asm файл) также могут имется соответствующие разделы. Допустимы два варианта... Выделение соответствующих участков из модуля с их последующим размещением в соответствующих разделах главного файла проекта (и закрытием таковых в модуле методом превращения в комментарий). После такой доработки файл модуля уже не может быть обработан компилятором автономно - и естественно не может иметь расширение *.asm - вот его и меняем на *.txt для копии размещенной в папке проекта (в папке библиотек исходный файл остается без изменений и сохраняет расширение *.asm). И второй вариант - в самом модуле добавляется флаг контроля выполнения процедуры начальной инициализации. Тогда модуль сохраняет возможность автономной обработки компилятором и ессно оставляем ему расширение *.asm... Однако... во многих случаях и лишний флаг в ОЗУ штука не слишком надежная и инициализация в произвольном месте кода программы нежелательна... Вышеуказанные проблемы - группировка разных по назначению участков кодов модулей в единых секциях (кода, данных, еепром) проекта решаются именно при раздельной обработке каждого файла с последующей передачей результатов редактору связей. К примеру в .code присутствуют сегменты hard_init, soft_init и main_soft.... Но... то уже несколько более навороченные компиляторы требуются. А в простом случае - используем заложенные в имеющихся возможности. Вобщем стоит внимательно поразмыслить/покопать и сформулировать...
ШИПЕНИЕ по поводу - "не надо заниматься" вряд-ли оправдывает возможности получить при помощи стандартного набора простых средств результат равный простому применению более навороченного софта.
Вопрос действительно заслуживает хорошей разборки.
хорошая разборка требует хорошего инструмента - лучше выбросить устаревший убогий Avrasm2 и взять нормальный ассемблер с линкером GNU-AS. Для затравки: http://www.count-zero.ru/2018/gnu_assembler/ Там поначалу рассмотрен чистый ассемблер
согласен и давно это советую всем, кто не может расстаться с ассемблером.
однако, в плане ковыряния и оптимизации вполне можно найти себе занятие и на чистом Си (GCC), например, использовать глобальные регистровые переменные... и это может дать очень интересный результат - поле для ковыряний обширнейшее! не хуже, чем на "чистом" асме
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения