Котуинко

[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 КБ) 133 скачивания

AN3892.pdf

(246.95 КБ) 145 скачиваний

AN3893.pdf

(202.38 КБ) 133 скачивания

AN3894.pdf

(192.5 КБ) 146 скачиваний

MPR121_NXP.pdf

(379.91 КБ) 154 скачивания

[BOB51]

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

AN3889.pdf

(357.72 КБ) 136 скачиваний

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

MPR121_freescale.pdf

(1.08 МБ) 138 скачиваний

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

[BOB51]

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

[BOB51]

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

Вариации на тему трактования ассемблерописания.doc

(47 КБ) 126 скачиваний

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

Спойлер

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

;
;         "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]

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