В обычной клавиатуре "мю" нету.
Как- то никто уже не заворачивается насчёт
uF в обозначениях конденсаторов в схемах.

Расчёт для 1МГц сделан с учётом большинства
МК разных семейств "по умолчанию" - там
в подавляющем большинстве именно 0, 000001S/
одноцикловую команду встречается.
При желании можно и пересчитать.
Только не макросом с параметрами, а директивами условного ассемблирования или с использованием задаваемого в *.inc файле описания МК символическим именем соответствующего МК или параметром базовой тактовой частоты...
Это уже скорее специмя в файле дефайнов главного файла проекта закладывать надо...

Суть вложенного в "обкатке" модулей в приложении к "многофайловикам".

μLan официально таки MicroLAN
http://www.gaw.ru/html.cgi/txt/publ/_rtcs/microlan.htm
з.ы. в sPlan-е есть всяки специфичные буквочки

Было б о чем "на ЛУНУ помяукать!" (u).

Неприятие критики детектед. Было ж конечно о чем. Все ж главный то минус замалчивается:

Раз исходник выложен на всеобщее обозрение, надо критику "благодарно принимать". А ведь многие то на 8 МГц аврки обычно запускают (судя по проектам интернета) - за что ж деньги уплочены, а то и кварцы на 11.059МГц...20 МГц цепляют, а тини13 вообще не вписывается.

сколько nop-ов то надо на 20 МГц?
Вот простенько, но можно под другое легонько пересчитать:

з.ы. и никаких NOP-ов

Критика насчет "u" вместо "мю"?

По вопросу "почему 1МГц" - это не в данном случае рассматривается - мне и с такими параметрами неплохо.

Смысл выложенного касается модуля для многофайловика, подключаемого как .nclude *.* вставка.
А файл как пример подготовки модуля для последующего использования.
Кому охота изменить параметры - то уже личное дело.
Тем более, что помимо 3-проводки с "внешним питанием" существует еще и вариант "паразитного питания" - а там алгоритм несколько посложнее, с разворотом шины на вывод 1 используется.
Зачем сразу все в одну кучу то сваливать?


Работа с задержкой на основе циклов в случае с формированием при частоте в 1 МГц особого выигрыша по расходу ПЗУ не дает.
В случае обращения к подпрограмме уже 8 uS расходуется (rcall + ret). Если еще счетчик ставить - практически то же самое, что и для NOPов будет.
Остаток 15-8=7 uS = 7 NOP или набор из счетчика LDI константы, dec счетчика и brne цикл 1+1+1/2 да еще подсчет содержимого для константы досчета с учетом того 1/2 у команды условного перехода.
В итоге "сэкономится" 4 слова ПЗУ при несколько иной конструкции вызова и усложнении начального тестирования.
Кроме того не стоит забывать, что для задержки на основе счетчика потребуется дополнительный регистр.
А это, в свою очередь добавит минимум две команды для сохранения/восстановления предшествующего вызову драйвера контента в стеке.
Другое дело, что такой вариант более универсален при работе с более высокими частотами системной шины.
Или для "вылизывания" по уже проверенной на железе программе может использоваться.

Критика uLAN - в том что новичок с форума не найдет такой сети в гугле - это и ежу понятно.
А на картинке видно "лишних" там только 0.75us, что для вышеупомянутой, не правильно обозванной сети не принципиально. По крайней мере DS18B20 себя прекрасно чувствует.

а другим будет плохо, это пытаюсь донести - форум публичный, а в личном блоге это нормально, да и

причем тут тогда "uLAN ногодрыгом" - получается "здесь читать, здесь не читать, а здесь я рыбу заворачивал"(c)
https://www.youtube.com/watch?v=hOrLrLPsv1k
з.ы. до сих пор не понял разницы понятий многофайловика и однофайловика. Ведь если в один файл скопировать все инклуды, то многофайловик превращается в однофайловик - так тогда и разницы особо и нету.
По просьбе трудящегося можно ли описание "многофайловика и однофайловика" в виде картинок, лучше как алгоритм.

Там не "в алгоритме" вопросы...
А в оформлении и нюансах в отношении атмелевских компиляторов (компиляторы лишены компоновщика/линкера).
Ибо "просто свалить в один файл все .include *.*" НЕ ПОЛУЧИТСЯ.
Если только это не фрагменты, включающие в себя исключительно мнемоники команд да простой комментарий.
Автономный модуль может иметь в своем составе и переразметку регистров и переразметку ОЗУ и участки начальной инициализации.
Пока еще не все ситуации выявлены ...
Посему только пробы - хотя и вполне самодостаточные (могут использоваться как вариант исполнения собственных программ).
На данный момент для тех модулей, что в проект как .include *.* подключаться могут различные варианты по сложности описывающей части рассматриваются. Без особого фанатизьму в ущерб свободного времени.
В простом случае текстовая подстановка, но в сложном - к обычному тексту добавляются и определения разметки.
С одной частью - разметкой регистров-аккумуляторов СОЗУ файла разъяснилось...
По ходу такой же вариант - разметка временной области с последующим переназначением ожидает и ОЗУ...
Там еще поработать надо над прояснением вопроса.
Пока однозначно ясно, что при наличии разметки ОЗУ в главном файле проекта вариант с
.dseg
name: .byte M
в подключаемом.include *.* не пройдет...
А вручную перетаскивать в общий раздел дефайна ВЛООМ...

Надоть чегось придумать...


Насчет "кому понятно, а у кого вопросы..."
На вопросы начинающих ответить порой проще, чем очередной "спор о курице и яйце" с "матерыми" разводить.
Тем более "в формате бесполезного флуда".
В принципе - кому нравится - тот смотрит, а кому не нравится - я ж не заставляю - можно и мимо пробежать, ёжли тема интереса не представляет.
Здесь или готовый проект как вариант возможного исполнения или вариант для самостоятельных размышлений, а не "учебный центр юного техника" с абсолютными утверждениями вида "делать только так и не иначе!!!"

получится, именно это и делает .include - уже проходили


конечно пройдет - всегда так делали, например:

и никаких проблем "в оформлении и нюансах в отношении атмелевских компиляторов"
вот этот реальный примерчик:

все просто и понятно - зачем огород городить. Отметим - Target: I2C Demo Board, 20MHz, ATmega164P.
Ну ни как не "типовой" на 1MHz (сколько все ж надо nop-ов на 20MHz почему то замалчивается).
Утверждения всякие выше, с большим количеством хаотических "умных" слов - уж очень похожи на развешивание лапши на уши неокрепших умов (например см. выше, начиная "Работа с задержкой на основе циклов..."). Пример на картинке выше, явно экономичнее и удобнее во всех смыслах (имхо).
Не мешало бы сначала произвести тестирование разных вариантов и их сравнение, прежде чем "рассуждать".
"я ж не заставляю - можно и мимо пробежать"(c)

форум вообще то создан для общения (см. п2 правил), а не как индивидуальный блокнотик (писал уже).
Каждый имеет право предложить для обсуждения свой вариант, по его разумению лучший.
И вообще если посмотреть на начало темы - обсуждение типа многофайловиков avr это и есть флуд, ведь "Котуинко это "Базовая платформа порта-расширителя ПК для любительских применений. Основано на микроконтроллере AT89S52".

Со 164мегой я не занимался - так что ничего особо сказать не могу по поводу Вашего проекта.
У моего варианта пока стадия предположений и проверок.
Как будет окончательно готово - тогда и выложится.
Спешить особо незачем.

Предложение своего варианта как дополнительного и навязчивый запрет на чужое мнение и темы - совершенно иное.
Я рассматриваю те вопросы, что представляют интерес с моей точки зрения. При том, что и иные варианты не исключаются.
А Вы приходите в эту тему с требованием её закрытия, поскольку, по Вашему мнению тема противоречит интересам форума.
Странная позиция...

Вопрос рассмотрения особенностей подключаемых файлов относится одинаково и к avrasm2 и к c51asm поскольку оба компилятора по работе с исходниками подобны.
Помимо прочего...
Платформа Котуинко предусматривает применение всех трёх семейств МК при совместной работе.

Где требовал и где навязчивый запрет ((!) кнопка ни разу) - тут народ на форуме, выпучив глаза, со всей душой предлагает как лучше (по их мнению) решать подобные задачи видя какие мучения тут происходят и постоянные топтания на месте. А для чего выкладывают обычно на всеобщее рассмотрение, еще и сырое. Свое личное, повторюсь, пишут в личном блокнотике и прячут от посторонних глаз.
Обидная позиция.

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

К продолжению...
Относительно NOPов и кольцевых счетчиков...
Применимы оба варианта в зависимости от ситуации.
Кольцевой счетчик удобен в большинстве случаев, когда интервал измерения хотя бы на 4-5 машинных циклов более длительности суммарного тела счетчика (включая предсохранение в стеке регистра счетного интервала и команды вызова/возврата).
При типовой "стандартной по умолчанию" частоте 0,000001S/одноцикловую команду интервалы в 10-15 микросекунд предпочтительно отлаживать на NOPах.
То же касается и задержек, кои я ставил в драйвере для WS2812 (при 0,0000000625S/одноцикловую команду).

Относительно .dseg во "вкладных файлах"...
Не путайте вкладыши для ассемблерных вставок при работе под СИ (или иным компилятором) и работу под "чистым ассемблером" в AVRстудио!!!
Ибо в одном случае таки есть линкер (хоть и скрытый) который используется компилятором Си, а во втором - "чистый" двупроходный ассемблер...

Так воть...
Ниже примерчик... тестовый (к самим прожкам нет смысла придираться - ибо таки работают, хоть и не "заоптимизированы").

Ежли мы закомментируем в заголовке test.asm определение:



и откроем в заголовке файла mul24.txt соответственно эти строчки:



то AVRstudio 4.19 выдаст нижеследующее сообщение:



т.е имеют место три ошибки, запрещающие дальнейшую работу.

Если вернем все на старое место - определения ячеек ОЗУ будет выполнено в заголовке основного файла проекта (test.asm),
а в mul24.txt закомментируем все назад, то компиляция пройдет без замечаний.
Причем такое действо абсолютно не зависит был ли файл умножителя назван mul24.txt или mul24.asm...

Ну и при желании можно будет протестироват в дебаггере работу умножителя и делителя, вводя значения во вкладке карты регистров ОЗУ.
Единственно чего там нету - предпроверки правильности данных и переполнения результата в делителе.

Причины таких "нюансов" разбирать... Это уже вопрос разработки компилятора...
А мне интереснее, как такую бяку без особого заморачивания обойти - вот потому и разговор о применении во "вкладных файлах" переразметки через #define.
Тем более, что такой прием одинаково работает и для avrasm2 и для c51asm и для mpasm.

oleg110592
Приходится признать, что мое высказывание по вопросу .dseg , построенное на моем варианте теста не является верным...

Однако есть ФАКыть - тест-проект "склейку" сегмента данных НЕ ПРОПУСКАЕТ.
(В отличии от Вашего варианта).
Остается разобрать причину, по которой возникают ошибки.
Ибо факт наличия ошибок в исходном варианте и отсутствия ошибок при его "разбиении на мелкие фрагменты" с их последующим выносом в дополнительные .include*.* таки имеет место.
Предполагаю что проблема в компоновке заголовка - но вот на каком участке происходит блокировка норамаьной обработки - это придется "методом научного тыка" смотреть.
Ведь заголовок главного тест-файла с точки зрения компоновки "стандартного" файла собран правильно.

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


А вот собственно и причина ошибок -
место вставки обязательного файла комплекта поставки
в моем случае

в главном файле проекта.
Прозевал, установив после блока определений/разметки вместо вставки в самом начале текста.

Самое интересное, что некорректная версия размещения таки скомпилируется, но при добавлении дополнительных
.dseg определений ниже того .include "tn2313def.inc" будет выбрасывать ошибки.
Перемещение в самое начало главного файла все расставило по местам.

Вопрос к тем, кто использовал директивы:
.IFDEF name
и/или
#IFDEF name
(и аналогичных для атмелевских компиляторов ассемблера avrasm2 и c51asm
для обработки условной трансляции части кода в зависимости от условия)
в чем возможная разница (кроме банального "#-директива препроцессора")
в применении по отношению к объявленным меткам/константам?
Да и особенности размещения объявления и блока условной обработки того объявления в тексте исходника
весьма интересны...
Эти вопросы обычно для большинства типовых проектов не возникают.
Однако ежли уж лезть в изврат (от нефиг делать) то стоит им также внимание уделить.


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

по идее директивы условной компиляции служат для возможности вариантной сборки проектов.
например, у вас есть код поддержки USART в одном файле, и есть код поддержки USI в другом. вы называете функции одинаково типа send_byte в обоих файлах, а уж в "главном" модуле при помощи директив условной компиляции подключаете либо тот, либо другой файл. я не уверен, как к этому отнесется avrasm, но как-то так:разумеется, выше этого кода должен быть подключен заголовок с описаниями регистров конкретного МК...

P.S. BOB51, вы выражаетесь таким "высокопарным" слогом а-ля Михайло Ломоносов, что понять, что вы хотите, среднему уму невозможно. поэтому я не уверен, что ответил "в тему".

То, что для болков условной трансляции компилятором понятно...
Однако там всплывает кучка "мелких неприятностей"... Да еще и "разнобой" с ПИКовыми в отношении количества и применяемости директив имеется...
У АВРковых помимо
#define со слэшем и директивы условной трансляции...
Вобщем... пока мучаю тест-заготовку, чтоб чего прояснить...

Пока только следующее проявилось -
1. блоки условной трансляции ВСЕГДА должны быть ниже по тексту, чем определения используемых в них констант/меток;
2. то, что определено в тексте как #define name proto может быть использовано только ниже по тексту (никак не в более ранних участках исходника);
3. если метка/константа определена в программе как обычная метка в .dseg или .cseg или директивами .def .equ .set то
используются директивы условной компиляции (avrasm2/c51asm) с префиксной точкой . ;
4. если определение сделано как #define name proto то для нее требуется использовать директивы условной компиляции (avrasm2/c51asm) с префиксным #
То же касается и директив самодельных служебных сообщений - префикс у них ставим такой же как и у остальных директив в блоке обработки условий. (к примеру #warning info или .warning info соответственно)
А вот у ПИКовых такого разделения вроде нету (требуется таки при возможности уточнить...)

Может у кого еще какие мысли/наработки на эту тему были?

в документации и в родных примерах обычно и мысли и наработки

Однако кроме обычных директив с префиксной точкой там и со слешем применяются.
А они - разных "сущностей" касаются...
Да и второй нюанс - объявить используемое имя надо только до применения директив.
Ибо применение не только в макросах интересно.

Кстати...
.ifdef mark отлично подходит относительно ранее определенной метки/имени подпрограммы (вероятно и имени ячейки памяти, определенной как именованны элемент в .dseg надо посмотреть...)...
А вот #ованные работают похоже только относительно того, что определено с помощюь #define (*только для avrasm2/c51asm).

Разница в применении представляет интерес именно относительно проектов с применением .include вставок при "перекрестных" запросах о наличии/отсутствии определенных частей программы к примеру...

Продолжение садомазохизма...
Зачесалось мне заставить условный блок обработать сущность, определение которой сделано ниже по тексту, чем сам блок...
вот такая врезка контроля в файле av_mlan.txt анализирует наличие подпрограммы обработки ошибок

Спойлер

Код:

m_error:
   m_stop_pak
#ifdef red_error_proc

  rjmp red_error_proc ;red_error ; внешний обработчик аварийного останва

#else

#warning "not defined EXTERN red_error for uLan libr"


 m_error_s:
   rjmp m_error_s ; пока заблокировано для тест-отладки
   ; в рабочей программе тут устанавливается переход
    ; на немедленную обработку ошибки "датчик не отвечает"

#endif

но сама подпрограмма расположена в главном файле ниже по тексту, чем подключение содержащего анализатор условной компиляции .include "av_ulan.txt"

Спойлер

Код:

 nop
 rjmp stop
#define red_error_proc red_error
; red_error:
 nop
;
;----------
.include "av_ulan.txt"

;
;----------
.include "mul24.txt"

;----------
.include "div24a.txt"

;----------
.include "av_i2c.txt"

;----------
;
 red_error:
 nop

Воть...
поставил вверху (или в главном блоке определений) основного файла строчку
#define red_error_proc red_error - определена сущность red_error_proc равная адресу подпрограммы red_error
К сожалению подтвердилось предположение, что корректно с сущностью, определенной как #define у АРВок (avrasm2)
корректно работают только директивы со #(слэш-префиксом)...

В то же время по сути проверяется наличие адреса red_error, находящегося ниже размещения модуля av_mlan.txt
И возможность перехода по команде, содержащей синоним red_error_proc...
Хотя в данном случае компилятор вполне спокойно и прямой переход на red_error выполняет, но вот директивы условной компиляции потребуют некоторого шаманизма...
Если же фрагмента с адресом red_error не окажется в пределах проекта
Ошибку вида
...\test\av_ulan.txt(437): error: Undefined symbol: red_error
отловит сам компилятор.

Залез поосмотреться на
https://www.microchipdirect.com
насчет чего там новенько-хреновенького...
относительно АВРок...

ПОПЛОХЕЛО...

Новая редакция AVR-Instruction-Set-Manual-DS40002198A

Относительно самих кристаллов...
Как Вам вот такое чудо:
"The AVR128DA28/32/48/64 microcontrollers of the AVR-DA family are using the AVR® CPU with hardware multiplier,
running at up to 24 MHz, with 128 KB of Flash, 16 KB of SRAM, and 512B of EEPROM in 28-, 32-, 48- or 64-pin
packages. The AVR-DA family uses the latest technologies from Microchip Technology, with a flexible and low-power
architecture including Event System, intelligent analog features, advanced digital peripherals and Peripheral Touch
Controller (PTC)."
...??
И маркировка не мега не тинька, не Хмега, а AVR128DA32....

Ну и моного подобного...

Похоже также что идет работа над приведением всех МК под единый мплаб Х...

так это хорошо или плохо?