Котуинко

oleg110592

[uquote="BOB51",url="/forum/viewtopic.php?p=3817629#p3817629"]Я ж и с тем, что есть вполне необходимый результат получаю[/uquote]
а разве не интересно получить результат, используя более продвинутые современные средства. Усилий потребуется совсем мало, а удовольствия будет много (человеку свойственно новое изучать - это одно из сильнейших удовольствий). Да и форуму значительная польза.

Реклама

BOB51

Классика - это уже имеющийся проверенный рабочий инструмент.
Довести до максимальной отдачи гораздо полезнее.
А изучение дополнительного материала так уже такого, который позволит чуток дальше пройти.
Та же аадуринья к примеру.
Хоть и не в абсолюте - но таки С++ там имеется, да и некая универсальность - один и тот же набор функционала для разных семейств пригоден - от АВРок до АРМ и ESP.
А там по мере переваривания можно и поглубже влезть.
Да добавить комбинированные проекты на разных кристаллах под ассемблером ("периферия с мозгами").
Другие варианты подхода и без меня в достаточном количестве рассматриваются на форуме.

Реклама

dosikus

[uquote="BOB51",url="/forum/viewtopic.php?p=3817741#p3817741"]А там по мере переваривания можно и поглубже влезть.[/uquote]

А не получится...

oleg110592

[uquote="BOB51",url="/forum/viewtopic.php?p=3817741#p3817741"]Классика - это уже имеющийся проверенный рабочий инструмент.[/uquote]
ну так GCC - это уже имеющийся отличный проверенный рабочий инструмент, классическая классика, класичней не бывает - им для Линукс ядра и программы собирают. Для AVR WinAVR чуть ли не сначала века существует - как разработчику можно было такое пропустить. Arm-none-eabi-GCC может компилировать от CortexM0 до Raspberry-PI. Для ESP на родном сайте для загрузки есть SDK с GCC. Если б кто на форуме освоил разработку ESP+GCC - памятник ему нерукотворный

Реклама

BOB51

А мне, dosikus, спешить некуда.
Когда-то уже попытки "пинаться" были...
Но по нынешним временам-штука бесполезная.

Насчёт классики я имел ввиду комплект компиляторов ассемблера от атмел и мпасм .
Вполне достаточно для комфортной работы с прикладными самоделоками.
Лезть в глубины Си пока без особой надобности.
Да и необходимость в том больше для тех, кто профессиональной разработкой занимается.

Насчёт ESP...
Трудно сказать чего там в адуринке под эту платформу понапихали... Говорил же, что разбираться в том профи надо.
Судя по матюкам при замене версии платформы там не только GCC используется... Чего-то ещё впихнули... Версия старше 2.5.0 только под семеркой/десятков устанавливается.
Но то "к сведению". Пока еспшки меня особо не увлекают - лежит "для коллекции".

Дополнительный плюсик oleg110592 за дискус относительно места расширений asm/txt в проектах под ассемблером!

Появился повод пройтись еще разок по нюансам компилятора ассемблера примененного в ST visual develop для STM8.

Реклама

BOB51

Новая версия PICPgm
http://picpgm.picprojects.net

Реклама

BOB51

Новый релиз симулятора ардуиноUNO
2.7.1
https://www.sites.google.com/site/unoardusim/

Весьма интересный контроллер клавиатуры/дисплея:
http://img.radiokot.ru/files/20529/26a31lzchb.jpg
и даташитки к нему

AN3890.pdf: (186.53 КБ) 134 скачивания

AN3892.pdf: (246.95 КБ) 147 скачиваний

AN3893.pdf: (202.38 КБ) 134 скачивания

AN3894.pdf: (192.5 КБ) 148 скачиваний

MPR121_NXP.pdf: (379.91 КБ) 155 скачиваний

BOB51

Добавлю последние две даташитки для MPR121 (за один раз не все влезло - их таки всего7 штук)

AN3889.pdf: (357.72 КБ) 137 скачиваний

это самая первая из аппноток (но не самая интересная - потому и оставил на добавку)
и второй вариант даташита от freescale

MPR121_freescale.pdf: (1.08 МБ) 139 скачиваний

ибо там чуток отличается от NXP...

BOB51

К вопросам многофайловиков и сегментов...
Вроде наметился обходной финт с применением директив условного ассемблирования...
Пока "в стадии размышления"...

BOB51

немножко подредактированная сводка по директивам

Вариации на тему трактования ассемблерописания.doc: (47 КБ) 127 скачиваний

и шаблончик дефайна АВРок, с учетом будущих поползновений:

Спойлер

Код: Выделить всё

;
;         "defname_proto.txt"  файл объявленных имен, бит и констант (шаблон)
;
;------------------------------------------------------
; variable definitions
;(таблица обьявленных имен)
;________________________
;
; в случае многофайлового проекта раскомментировать данную строку
; при однофайловом или иногофайловом с единственным определением hsi
; определение disposit не требуется
 #ifndef disposit
 #define disposit
 #endif
;------------------------------------------------------
;
;таблица обьявленных имен - пользовательские константы
;

;________________________
;таблица обьявленных имен - переназначение регистров РОН
;
;             принята базовая модель: AVR
; область ограниченного функционала
 .def mfr0 = r0 ; (математика и обмен с ПЗУ/самопрограммирование)
 .def mfr1 = r1 ; (математика и обмен с ПЗУ/самопрограммирование)
 .def ssreg = r2 ; зеркало SREG (ограниченный функционал)
 .def sspl = r3  ; зеркало SPL (ограниченный функционал)
; .def ssph = r4  ; зеркало SPH (ограниченный функционал)
 .def smartf0 = r5  ; оперативные флаги (ограниченный функционал)
; .def smartf1 = r6  ; оперативные флаги (ограниченный функционал)
; .def  = r7 ;(ограниченный функционал)
; .def  = r8 ;(ограниченный функционал)
; .def  = r9 ;(ограниченный функционал)
; .def  = r10 ;(ограниченный функционал)
; .def  = r11 ;(ограниченный функционал)
; .def  = r12 ;(ограниченный функционал)
; .def  = r13 ;(ограниченный функционал)
; .def  = r14 ;(ограниченный функционал)
; .def  = r15 ;(ограниченный функционал)
; область полного функционала
 .def tmpr0 = r16 ; рабочий регистр (полный функционал)
 .def tmpr1 = r17 ; рабочий регистр (полный функционал)
 .def tmpr2 = r18 ; рабочий регистр (полный функционал)
 .def tmpr3 = r19 ; рабочий регистр (полный функционал)
 .def tmpr4 = r20 ; рабочий регистр (полный функционал)
 .def tmpr5 = r21 ; рабочий регистр (полный функционал)
 .def tmpr6 = r22 ; рабочий регистр (полный функционал)
 .def tmpr7 = r23 ; рабочий регистр (полный функционал)
 .def bpl = r24 ; "указатель базы" (полный функционал)
 .def bph = r25 ; "указатель базы" (полный функционал)
;     Xl = r26 ; адрес сегмента Х (полный функционал)
;     Xh = r27 ; адрес сегмента Х (полный функционал)
;     Yl = r28 ; адрес сегмента Y (полный функционал)
;     Yh = r29 ; адрес сегмента Y (полный функционал)
;     Zl = r30 ; адрес сегмента Z (полный функционал ПЗУ/самопрограммирование)
;     Zh = r31 ; адрес сегмента Z (полный функционал ПЗУ/самопрограммирование)
; регистры Xh:Xl, Yh:Yl, Zh:Zl определены в дефайне изготовителя и в системе команд
; изменение их имени хотя и возможно, но нежелательно -
; возникает путаница с интегрированной абревиатурой системы команд
; регистры имеют также отображение в пространстве ОЗУ 0х0000 - 0х001F

;________________________
;таблица обьявленных имен - секция флагов пользователя
;

;________________________
;таблица обьявленных имен - секция определенных данных (ОЗУ)
;
; следует помнить, что блок регистр-аккумуляторов занимает область
; 0х0000 - 0х001F (R0 - R31)
; а блок РСФ со смещением +0x20 отображен с адреса 0х0020
; по SRAM_START -1 (имя_регистра_РСФ + 0х20)
;
  .dseg
; .org SRAM_START ; может не выставлться - по умолчанию равен SRAM_START
;
; блок из 16 ячеек общего пользования с вероятностью взаимозатирания
; в модулях имена могут переопределяться как
; #define new_name tmpdN
;
 tmpd0: .byte 1
 tmpd1: .byte 1
 tmpd2: .byte 1
 tmpd3: .byte 1
 tmpd4: .byte 1
 tmpd5: .byte 1
 tmpd6: .byte 1
 tmpd7: .byte 1
 tmpd8: .byte 1
 tmpd9: .byte 1
 tmpd10: .byte 1
 tmpd11: .byte 1
 tmpd12: .byte 1
 tmpd13: .byte 1
 tmpd14: .byte 1
 tmpd15: .byte 1

;________________________
;таблица обьявленных имен - секция определенных данных (EEPROM)
;
  .eseg
;________

В принципе для обобщенных "сегментов" в разных файлах проекта предполагается не автоперенос, а автодобавка RET во фрагментах "сбиваемых в единый сегмент".
При автономной отладке этот спецучасток работает как обычный фрагмент программы, а при "сборном" - как вызываемая из необходимого места главного проекта подпрограмма...
Остальное пока в работе/проверке...

oleg110592

".def tmpr0 = r16 ; рабочий регистр (полный функционал)..."
зачем так называть хорошие рабочие регистры, вот, имхо, хороший японский шаблончик

Код: Выделить всё

.def	AL	= r16
.def	AH	= r17
.def	BL	= r18
.def	BH	= r19
.def	CL	= r20
.def	CH	= r21
.def	DL	= r22
.def	DH	= r23
.def	EL	= r24
.def	EH	= r25

хорошее дополнение к XL XH YL YH ZL...
вполне наглядно в коде (практически как 16-и битный типа i8088):

Код: Выделить всё

	ldiw	A, 4		;Merge lower 12 bits and higer 24 bits
	lsr	CL		;
	rorw	B	;
	ror	AH		;
	dec	AL		;
..................
.macro	ldiw
	ldi	@0L,low(@1)
	ldi	@0H,high(@1)
.endm

.macro	rorw
	ror	@0H
	ror	@0L
.endm

з.ы. в шаблончике строку "; variable definitions" изменить на "; метка definitions"

BOB51

Затем, чтобы потом можно было использовать конструкцию типа
#define AL tmp0
#define AH tmp1
в одном модуле и затем, к примеру,
#define copi_0 tmp0
#define cnt_2 tmp1
в другом.
При условии, что оба модуля являются составной частью проекта через
.include .......
а базовое объявление делается однократно в основном файле проекта
или как в моем сленге в виде подключаемого к главному проекту
.include defname_proto.txt
делается для уменьшения текстовой нагрузки на главный файл проекта.

Кстати... такой подход действует одинаково для всех трех "базовых" компиляторов
C51asm, avrasm2 и mpasm для mplabIDE v8.92...

Там в заголовке тогда уже :
table definitions names

oleg110592

Какой такой одинаковый подход, если отец производитель Microchip показывает в многочисленных документах как надо писать для mpasm (см например документ TB094 Dimming AC Incandescent Lamps Using A PIC10F200):

Код: Выделить всё

	#include p10f206.inc

	__CONFIG _MCLRE_OFF & _CP_OFF & _WDT_ON & _IntRC_OSC

	ERRORLEVEL -306				; Get rid of banking messages...

;******************************************************************************
;***** VARIABLE DEFINITIONS

	cblock 0x08				; Define all user varables starting at location 0x7
		system_status			; byte that holds system flags
		intensity			; 3 bit number for current intensity setting
		dead_count			; counts dead cycle to zero intensity
		counter:3			; used for 4hr timer
		delay				; used for triac drive
		ir_counter			; counts time IR input is low
		dark_counter			; counts time IR input is high
		ir_minimum			; holds IR low min time for decode
		count:2				; holds time delay for triac startup
		hold				; temperary variable
	endc

;******************************************************************************
;***** CONSTANT DEFINITIONS

#define rx_ena	GPIO,0				; enables IR receiver
#define rx_dat	GPIO,1				; carries IR receiver data input
#define	triac	GPIO,2				; active low triac drive
#define z_cross	GPIO,3				; zero crossing input for Reset on Change

#define dunflg	system_status,7			; interlock to prevent repeat of commands
#define phase	system_status,0			; used to determined if zerocross or IR data change
.....

для так называемых "table definitions names" тут четко используется cblock адрес...endc, а для констант #define, хотя директива cblock это определение блока констант.
В pic10f206 начиная с адреса 0x08 находятся General Purpose Registers
з.ы. в заголовке таки VARIABLE DEFINITIONS

BOB51

А как насчет работы с МК, имеющими только область udata_shr?

Я ж про подобную ситуацию в отношении микрощиповских среднемладших подробненько в
"Вариации на тему трактования ассемблерописания.doc"
чуток повыше разжевал.
И не путайте абсолютную адресацию (cblock) у микрощипа с относительной!
У микрощипа ДВА несовместимых варианта(стиля) написания программ - для перемещаемого кода (относительная адресация) и для фиксированных адресов (абсолютная).
Там в заготовках два вида шаблонов указываются
C:\Program Files\Microchip\MPASM Suite\Template\Code - заготовки для абсолютной адресации
и
C:\Program Files\Microchip\MPASM Suite\Template\Object - заготовки для относительной.
В этом отношении мпасм весьма коварен (у c51asm и avrasm2 в едином тексте допускается применение директив для обеих видов адресации - то уж на усмотрение программиста).
Я же рассматриваю систему исключительно для работы с перемещаемым кодом (относительная адресация)
В мпасме это директивы разметки
udata
udata_ovr
udata_shr
и для 18-х
udata_acs
применение cblock для констант в данном случае некорректно и вполне спокойненько заменяется на общеприменяемое equ.
Отдельного рассмотрения требует idata поскольку резервирует косвенную адресацию, а у c51asm такой механизм блокирует доступ для обычной адресации. Вобщем... лучше без надобности idata не трогать.

Вот, к примеру, для ранее приведенного в этой ветке проекта "кухонного таймера "KTP"" на PIC16F628 файлик разметки:

Спойлер

Код: Выделить всё

;
;         "def_ktp.txt"  файл объявленных имен, бит и констант (шаблон)
;
;------------------------------------------------------
; variable definitions
;(таблица обьявленных имен)
;________________________
;таблица обьявленных имен - пользовательские константы
;  /equ, set/
zero     equ 0
mrak     equ 0xFF

tmm_m60  equ .60 ; модуль секунд и минут
tmm_m24  equ .24 ; модуль часов
;
; константы управления
;    для подпрограммы дисплея KD
;
bblok       equ 56 ; количество бит в блоке (2 блока в пакете)
L_INH       equ 3 ; позиционный номер линии /INH (RA3)
L_DN        equ 0 ; позиционный номер линии DN (RA0)
L_SCL       equ 1 ; позиционный номер линии SCL (RA1)
L_CE        equ 2 ; позиционный номер линии CE (RA2)
s_ter0      equ b'00110000' ; служебная тетрада битового блока 0
;        0b00110000 for ks0035p, 0b00010000 for nju6432bf
; однако 0b00110000 применимо и для ks0035p и для nju6432bf
s_ter1      equ b'10010000' ; служебная тетрада битового блока 1
s_mask      equ 0x0F ; маска для обслуживания/загрузки служебных тетрад
;  размещено в kd_flags
c_tmp       equ 0 ; рвх содержимого для передачи в блок1
ksdd_w      equ 1 ; триггер-переключатель обслуживания вывода/обработки данных
ksdd_sf     equ 2 ; семафор запроса готовности данных для загрузки дисплея/
mark        equ 3 ; повторитель таймер-маркера
; определения имен сегментов
s_A    equ 1
s_B    equ 7
s_C    equ 5
s_D    equ 4
s_E    equ 2
s_F    equ 0
s_G    equ 3
s_H    equ 6

;----------- ------------- ------------
;
; ------------ константы termo.txt ------------
;  для подпрограммы обработчика данных MT
;
mt_e4  equ 0x2710 ; 10000 десять тысяч
mt_e3  equ 0x3E8  ;  1000 тысяча
mt_e2  equ 0x64   ;   100 сто
mt_e1  equ 0x0A   ;    10 десять
mt_sz  equ 0      ; сегментный код пробела
mt_smi equ (1<<s_G) ; сегментный код знака минус
;
;  размещено в mt_flags
;
ZFI       equ 0 ; несовпадение с предыдущими данными
mins      equ 1 ; статус отрицательной температуры
fobl      equ 2 ; статус обработчика лидирующих незначащих нулей
shot      equ 3 ; сокращенная форма (только от сотен)
shot_ck   equ 4 ; сокращенная форма для часов/таймеров (только десятки)
;
;----------- ------------- ------------
;
;   размещено в tmm_flags
tmm_apdnf   equ 0 ; флаг направления счёта 0=вверх, 1=вниз
tmm_tmoff   equ 1 ; отсчет окончен
tmm_dissn   equ 2 ; запрет исполнения дополнительных кнопок
               ; управления при счете времени
tmm_zud     equ 3 ; флаг использования счетчика длительности
               ; cnt_zum+2 для остановки исполнения зуммера
tmm_ino     equ 4 ; запрет сброса счетчиков TMR1H:TMR1L
     ; при повторно-многокартных пусках/остановах счета времени
;
;----------- ------------- ------------
; общее определение выводов
ZUM0        equ 6 ; вывод пушпула зуммера 0 (RA6)
ZUM1        equ 7 ; вывод пушпула зуммера 1 (RA7)
EXT_ln0     equ 4 ; линия "внешнего интерфейса" разъём EXT_MODE:7
                  ; порт RA4
EXT_ln1     equ 1 ; линия "внешнего интерфейса" разъём EXT_MODE:5
                  ; порт RB1/RxD
EXT_ln2     equ 2 ; линия "внешнего интерфейса" разъём EXT_MODE:3
                  ; порт RB2/TxD
EXT_ln3     equ 3 ; линия "внешнего интерфейса" разъём EXT_MODE:1
                  ; порт RB3/CCP1
L_Sn1       equ 4 ; ЛВК кнопки S1 (GREEN) порт RB4
L_Sn2       equ 5 ; ЛВК кнопки S2 (RED) порт RB5
L_Sn3       equ 0 ; ЛВК кнопки S3 (GREY) порт RB0


;________________________
;
;
;----------- ------------- ------------
TEMPO     udata_ovr 0x20
tmp_0 res 1
tmp_1 res 1
tmp_2 res 1
tmp_3 res 1
tmp_4 res 1
tmp_5 res 1
tmp_6 res 1
tmp_7 res 1
tmp_8 res 1
tmp_9 res 1
tmp_a res 1
tmp_b res 1
tmp_c res 1
tmp_d res 1
tmp_e res 1
tmp_f res 1
;-----------
TEMPO    udata_ovr  0x20 ; kd_tmp буферобработчика вывода на дисплей
d_blok0     res 6 ; битовый блок 0 из 6 байт
ub_bl0      res 1 ; служебная тетрада битового блока 0 из 1 байта
d_blok1     res 6 ; битовый блок 1 из 6 байт
ub_bl1      res 1 ; служебная тетрада битового блока 1 из 1 байта
gape_0      res 1 ; резерв для совместимости
;-----------
TEMPO    udata_ovr  0x20 ; vid_ram буфер строки сегментного кода для вывода на дисплей
kd_pos1     res 1 ; буфер сегментного кода для позиции 1
kd_pos2     res 1 ; буфер сегментного кода для позиции 2
kd_pos3     res 1 ; буфер сегментного кода для позиции 3
kd_pos4     res 1 ; буфер сегментного кода для позиции 4
kd_pos5     res 1 ; буфер сегментного кода для позиции 5
kd_pos6     res 1 ; буфер сегментного кода для позиции 6
kd_pos7     res 1 ; буфер сегментного кода для позиции 7
kd_pos8     res 1 ; буфер сегментного кода для позиции 8
kd_pos9     res 1 ; буфер сегментного кода для позиции 9
kd_pos10    res 1 ; буфер сегментного кода для позиции 10
;
kd_tempo   udata 0x30 ; [adres] основное ОЗУ вывода, RB0
kd_cnt_bit  res 1 ; счётчик бит
kd_cnt_byt  res 1 ; счётчик байт блока
kd_flags    res 1 ; tmp_e & tmp_f
kd_tmp_fsr  res 1 ; РВХ содержимого fsr на время выполнения модулей kd_
             ; он же и  РВХ содержимого pclath для загрузчика сообщения
kd_strn_h   res 1 ; старший адрес строки для загрузчика сообщения
kd_strn_l   res 1 ; младший адрес строки для загрузчика сообщения
; termoto_mt udata ; обработчик данных/математика
mt_didl     res 1 ; делимое младший байт
mt_didh     res 1 ; делимое старший байт
mt_disl     res 1 ; константа делителя младший байт
mt_dish     res 1 ; константа делителя старший байт
mt_tmp      res 1 ; контрольные биты проверки несовпадения (двухбайтовой)
mt_re4      res 1 ; результат *10000
mt_re3      res 1 ; результат *1000
mt_re2      res 1 ; результат *100
mt_re1      res 1 ; результат *10
mt_re0      res 1 ; результат *1
mt_datl     res 1 ; двоичный результат для автоматики младший байт
mt_dath     res 1 ; двоичный результат для автоматики старший байт
mt_flags    res 1 ; флаги пользователя
mt_tmp_fsr  res 1 ; РВХ содержимого fsr на время выполнения модулей mt_
;
t_mk_tct    res 1 ; регистр тайм аута задержки времени t_slot
;
;timers   udata ; [adres] ; регистры таймеров
tmm_flags   res 1 ; регистр флагов таймеров
tmm_sek     res 1 ; счетчик секунд
tmm_min     res 1 ; счетчик минут
tmm_hors    res 1 ; счетчик часов
tmm_m_adj   res 1 ; счетчик минут задано пользователем
tmm_h_adj   res 1 ; счетчик часов задано пользователем
;
cnt_zum  res 4 ; счетчики интервала
zumout   res 1 ; буфер вывода сигнала зуммера для порта RA
sni_buf  res 1 ; буфер чтения ЛВК
sni_mask res 3 ; буфер масок ЛВК
;
;----------- ------------- ------------
;
;________________________
;таблица обьявленных имен - секция флагов пользователя
;  /equ, set/
;----------- ------------- ------------
; для регистра 

;
;
;----------- ------------- ------------
; данные с одинаковыми именами и адресами в разных регистровых банках
PROG_STECK    udata_shr  0x70 ; 0x70 - 0x7F = 16  byts
w_temp         res     1        ; variable used for context saving
status_temp    res     1        ; variable used for context saving
gtmp_fsr       res     1        ; главный РВХ для FSR при прерывании
gtmp_pclath    res     1        ; главный РВХ для PCLATH при прерывании
zntmp          res     2        ; для kaznak и подобных ***

;
;------------------------------------------------------
; таблица обьявленных имен - переназначение регистров РОН/РСФ
;  по директиве
; #define expr name
;    для подпрограммы дисплея KD
 #define port_ksd PORTA ; переприсвоение порта вывода
 #define blok_ra  ~(1<<L_DN | 1<<L_SCL | 1<<L_CE) ; состояние покоя для порта А
           ; при простое обмена с индикатором и отсутствии активности зуммера
					 ; и линии RA4(EXT_ln0)
 #define zumask   (1<<ZUM1 | 1<<ZUM0) ; маска инверсии зуммера
                  ;она же и отключение зуммера

oleg110592

У микрощипа ДВА несовместимых варианта(стиля) написания программ

значит утверждение "такой подход действует одинаково для всех трех "базовых" компиляторов" не совсем верно - только при написании "перемещаемого кода", зачем, правда, он нужен перемещаемый для pic10f200 непонятно. Есть ссылки на код для любительского pic10/12/16 где оправдано используется перемещаемый?
(создатель OSA) Виктор Тимофеев
MPASM: как оформлять программы
http://pic24.ru/doku.php/osa/articles/mpasm_formatting

BOB51

За тем же, зачем и самоограничения по применению специфических для каждого из компиляторов директив.
Однотипность подхода к написанию исходников и максимально возможное использование одинаковых
по функционированию директив.

Относительно той cblock у Тимофеева...
У него ведь ВСЕ описания только относительно ПИКовых выполнены.
В таком случае вполне объяснимо.
А в случае работы с другими семействами необходимо выбирать общие позиции для ВСЕХ
применяемых компиляторов.
Дабы проще переходить с одного семейства на другое в случае смешанного проекта было.
Да и "старая школа" любителей ПИКовых основывалась в основном на проектах не использующих
директивы относительной адресации.
По тем
udata
udata_ovr
udata_shr
udata_acs
вообще трактовку применения найти тяжеловато.

Относительно "оправданного использования"...
Проект, в котором используются модули вида .include уже подразумевает необходимость использования "перемещаемого кода".
Ибо модуль может быть установлен вставкой в любом удобном месте.
Для ПИКовых правда есть и другой вариант сцепки *.asm модулей с помощью IDE (используя линкер), но такой вариант "вышибает" совместимость с C51asm и avrasm2 для построения "многофайловиков".
Посему и выбирается, как уже выше говорилось максимально совместимый комплект директив и правил оформления проектов.

oleg110592

[uquote="BOB51",url="/forum/viewtopic.php?p=3833588#p3833588"]За тем же, зачем и самоограничения по применению специфических для каждого из компиляторов директив.
Однотипность подхода к написанию исходников и максимально возможное использование одинаковых[/uquote]
не вяжется с:

Вариации на тему трактования ассемблерописания
В случае с абсолютной адресацией распределение ОЗУ в mpasm значительно проще и определяется единственной

директивой CBLOCK

зачем "в скафандре сено косить"(с) если есть способ ЗНАЧИТЕЛЬНО проще. Подобные конструкции делают для упрощения жизни программиста.
Разве кто-то делает сразу проекты под три семейства каждый день?

Несложно и проще записать в блокнотик правила для каждого примитивного ассемблера трех семейств.
Уже тут писали - "для проще переходить с одного семейства на другое" придумали Си - в наше время компиляторы для всех трех семейств вполне пригодны для успешного применения. Имхо лучше потратить время на изучение Си чем на впихивание невпихуемого.

BOB51

Так при всем том кроме "блокнотика" (вернее распечаток с заметками) надо выбирать наиболее общее решение.
Да так, чтобы легко восстановить навык даже в случае перерыва.
Чего-то "отложить" как не такое уж часто применяемое, чего-то добавить из "соседней деревушки".
СИ - то уже "на закусь" в виде комплекта в адуринье применяемого (Си и С++ в режиме "многофайловика" с самостоятельной работой по созданию собственных библиотек).
В принципе вполне себе неплохой наборчик -
три семейства под ассемблером в качестве "скоростной периферии с мозгами" в режимах реального времени и общий обработчик данных на адуринке.
Возможны и варианты.
Вполне себе обосновано и экономически оправдано с точки зрения "простолюбителя".

Пока подготовка к методике перестановки секций в .include модулях в область начальной инициализации,
да еще некоторые "тонкости" надо неспешно проработать - просто раньше этот вопрос особо не возникал.
Сейчас интерес к автоматизации процесса переброски посредством имеющихся ресурсов (с Вашей же подачи) появился.
Будет на чем обкатать/опробовать - по ходу работ выложу.

oleg110592

[uquote="BOB51",url="/forum/viewtopic.php?p=3833698#p3833698"]Да так, чтобы легко восстановить навык даже в случае перерыва.[/uquote]
Начинающий вряд ли будет использовать сразу все три семейства и ему до лампочки общее решение, лучше как можно проще. А продвинутый любитель старой закалки имеет кучку своих исходников, обычно с комментариями. Новый "забытый" проект будет создаваться из уже готовых заготовок обычным копипастом начальных установок, правкой меток-переменных и пр. и наращиванием нового мясца - при наличии блокнотика с особенностями конкретного ассемблера процесс становится тривиальным.

BOB51

Обычно старый исходник читать - легче заново переписать.
Особо с учетом новой информации.
Да и стиль работ с течением времени меняется.
Заготовки - шаблоны "в общих чертах" это более оптимально.
Они сохраняют преемственность структуры проекта.
Однако... все зависит от конкретики - где малый вариант, а где и полный максимум придется делать.
Насчет начинающих - они тоже РАЗНЫЕ.