Я ж и с тем, что есть вполне необходимый результат получаю
а разве не интересно получить результат, используя более продвинутые современные средства. Усилий потребуется совсем мало, а удовольствия будет много (человеку свойственно новое изучать - это одно из сильнейших удовольствий). Да и форуму значительная польза.
Классика - это уже имеющийся проверенный рабочий инструмент. Довести до максимальной отдачи гораздо полезнее. А изучение дополнительного материала так уже такого, который позволит чуток дальше пройти. Та же аадуринья к примеру. Хоть и не в абсолюте - но таки С++ там имеется, да и некая универсальность - один и тот же набор функционала для разных семейств пригоден - от АВРок до АРМ и ESP. А там по мере переваривания можно и поглубже влезть. Да добавить комбинированные проекты на разных кристаллах под ассемблером ("периферия с мозгами"). Другие варианты подхода и без меня в достаточном количестве рассматриваются на форуме.
Классика - это уже имеющийся проверенный рабочий инструмент.
ну так GCC - это уже имеющийся отличный проверенный рабочий инструмент, классическая классика, класичней не бывает - им для Линукс ядра и программы собирают. Для AVR WinAVR чуть ли не сначала века существует - как разработчику можно было такое пропустить. Arm-none-eabi-GCC может компилировать от CortexM0 до Raspberry-PI. Для ESP на родном сайте для загрузки есть SDK с GCC. Если б кто на форуме освоил разработку ESP+GCC - памятник ему нерукотворный
А мне, dosikus, спешить некуда. Когда-то уже попытки "пинаться" были... Но по нынешним временам-штука бесполезная. Насчёт классики я имел ввиду комплект компиляторов ассемблера от атмел и мпасм . Вполне достаточно для комфортной работы с прикладными самоделоками. Лезть в глубины Си пока без особой надобности. Да и необходимость в том больше для тех, кто профессиональной разработкой занимается. Насчёт ESP... Трудно сказать чего там в адуринке под эту платформу понапихали... Говорил же, что разбираться в том профи надо. Судя по матюкам при замене версии платформы там не только GCC используется... Чего-то ещё впихнули... Версия старше 2.5.0 только под семеркой/десятков устанавливается. Но то "к сведению". Пока еспшки меня особо не увлекают - лежит "для коллекции".
Дополнительный плюсик oleg110592 за дискус относительно места расширений asm/txt в проектах под ассемблером! Появился повод пройтись еще разок по нюансам компилятора ассемблера примененного в ST visual develop для STM8.
К вопросам многофайловиков и сегментов... Вроде наметился обходной финт с применением директив условного ассемблирования... Пока "в стадии размышления"...
В принципе для обобщенных "сегментов" в разных файлах проекта предполагается не автоперенос, а автодобавка RET во фрагментах "сбиваемых в единый сегмент". При автономной отладке этот спецучасток работает как обычный фрагмент программы, а при "сборном" - как вызываемая из необходимого места главного проекта подпрограмма... Остальное пока в работе/проверке...
Затем, чтобы потом можно было использовать конструкцию типа #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
Какой такой одинаковый подход, если отец производитель Microchip показывает в многочисленных документах как надо писать для mpasm (см например документ TB094 Dimming AC Incandescent Lamps Using A PIC10F200):
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
#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
А как насчет работы с МК, имеющими только область 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 файлик разметки: Спойлер
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) ; маска инверсии зуммера ;она же и отключение зуммера
У микрощипа ДВА несовместимых варианта(стиля) написания программ
значит утверждение "такой подход действует одинаково для всех трех "базовых" компиляторов" не совсем верно - только при написании "перемещаемого кода", зачем, правда, он нужен перемещаемый для pic10f200 непонятно. Есть ссылки на код для любительского pic10/12/16 где оправдано используется перемещаемый? (создатель OSA) Виктор Тимофеев MPASM: как оформлять программы http://pic24.ru/doku.php/osa/articles/mpasm_formatting
За тем же, зачем и самоограничения по применению специфических для каждого из компиляторов директив. Однотипность подхода к написанию исходников и максимально возможное использование одинаковых по функционированию директив. Относительно той cblock у Тимофеева... У него ведь ВСЕ описания только относительно ПИКовых выполнены. В таком случае вполне объяснимо. А в случае работы с другими семействами необходимо выбирать общие позиции для ВСЕХ применяемых компиляторов. Дабы проще переходить с одного семейства на другое в случае смешанного проекта было. Да и "старая школа" любителей ПИКовых основывалась в основном на проектах не использующих директивы относительной адресации. По тем udata udata_ovr udata_shr udata_acs вообще трактовку применения найти тяжеловато.
Относительно "оправданного использования"... Проект, в котором используются модули вида .include уже подразумевает необходимость использования "перемещаемого кода". Ибо модуль может быть установлен вставкой в любом удобном месте. Для ПИКовых правда есть и другой вариант сцепки *.asm модулей с помощью IDE (используя линкер), но такой вариант "вышибает" совместимость с C51asm и avrasm2 для построения "многофайловиков". Посему и выбирается, как уже выше говорилось максимально совместимый комплект директив и правил оформления проектов.
За тем же, зачем и самоограничения по применению специфических для каждого из компиляторов директив. Однотипность подхода к написанию исходников и максимально возможное использование одинаковых
не вяжется с:
Цитата:
Вариации на тему трактования ассемблерописания В случае с абсолютной адресацией распределение ОЗУ в mpasm значительно проще и определяется единственной
директивой CBLOCK
зачем "в скафандре сено косить"(с) если есть способ ЗНАЧИТЕЛЬНО проще. Подобные конструкции делают для упрощения жизни программиста. Разве кто-то делает сразу проекты под три семейства каждый день? Несложно и проще записать в блокнотик правила для каждого примитивного ассемблера трех семейств. Уже тут писали - "для проще переходить с одного семейства на другое" придумали Си - в наше время компиляторы для всех трех семейств вполне пригодны для успешного применения. Имхо лучше потратить время на изучение Си чем на впихивание невпихуемого.
Так при всем том кроме "блокнотика" (вернее распечаток с заметками) надо выбирать наиболее общее решение. Да так, чтобы легко восстановить навык даже в случае перерыва. Чего-то "отложить" как не такое уж часто применяемое, чего-то добавить из "соседней деревушки". СИ - то уже "на закусь" в виде комплекта в адуринье применяемого (Си и С++ в режиме "многофайловика" с самостоятельной работой по созданию собственных библиотек). В принципе вполне себе неплохой наборчик - три семейства под ассемблером в качестве "скоростной периферии с мозгами" в режимах реального времени и общий обработчик данных на адуринке. Возможны и варианты. Вполне себе обосновано и экономически оправдано с точки зрения "простолюбителя".
Пока подготовка к методике перестановки секций в .include модулях в область начальной инициализации, да еще некоторые "тонкости" надо неспешно проработать - просто раньше этот вопрос особо не возникал. Сейчас интерес к автоматизации процесса переброски посредством имеющихся ресурсов (с Вашей же подачи) появился. Будет на чем обкатать/опробовать - по ходу работ выложу.
Да так, чтобы легко восстановить навык даже в случае перерыва.
Начинающий вряд ли будет использовать сразу все три семейства и ему до лампочки общее решение, лучше как можно проще. А продвинутый любитель старой закалки имеет кучку своих исходников, обычно с комментариями. Новый "забытый" проект будет создаваться из уже готовых заготовок обычным копипастом начальных установок, правкой меток-переменных и пр. и наращиванием нового мясца - при наличии блокнотика с особенностями конкретного ассемблера процесс становится тривиальным.
Обычно старый исходник читать - легче заново переписать. Особо с учетом новой информации. Да и стиль работ с течением времени меняется. Заготовки - шаблоны "в общих чертах" это более оптимально. Они сохраняют преемственность структуры проекта. Однако... все зависит от конкретики - где малый вариант, а где и полный максимум придется делать. Насчет начинающих - они тоже РАЗНЫЕ.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
