[mws]

 Сообщение от INFERION :

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

Насчёт скроллинга - ещё неизвестно где больше скроллить, макросы могут существенно уменьшить размер исходника, за счёт этого скроллить станет меньше. А то что приходится открывать текст макроса, так это только поначалу, при первой отладке, впоследствии к нему очень редко приходится обращаться. Кроме того код становится более структурированным, гораздо легче заметить ошибки.
Честно говоря не представляю как можно без макросов программить на асме. Нет ну можно конечно (сам так когда-то делал ), но с ними проще всё-таки. Я так думаю.

[INFERION]

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

[mws]

INFERION,

 Сообщение от INFERION :

Это спор о вкусах. Я попробовал и мне не понравилось.

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

 Сообщение от INFERION :

Макроассемблер мне напомнил Си, я почувствовал себя инвалидом с нехваткой ОЗУ головного мозга, которому ещё и больше текста писать приходится.

Мало общего вижу с Си, макрос это не функция, он не получает параметры через стек и не возвращает. И я абсолютно не понимаю, почему больше текста. Сначала пишется макрос, в потом везде, где без макроса было бы несколько строк текста будет одна строка. А если ещё и вложенные макросы применяются, то размер заменённого текста ещё больше.

 Сообщение от INFERION :

Ассемблер читается строка за строкой, страница за страницей, даёт возможность дописывать главы, изменять абзацы и предложения. Древовидная структура вместо этого заставляет судорожно прыгать туда-сюда, отслеживая что кого и куда вызывает/возвращает, постоянно перелистывая по пол книги, пытаясь собрать пазл, чтоб вкурить творение автора...

Макрос не нарушает линейной структуры, это не вызов функции, а всего-навсего подстановка текста. И в случае обнаружения ошибки в макросе, достаточно исправить один небольшой кусок, сам макрос. А если обнаруживается ошибка в "линейном" тексте, вот тогда приходится судорожно прыгать по всей простыне и искать, где же ещё используется подобная операция, при этом рискуя что-то пропустить, а где-то ошибиться при исправлении. Особенно весело когда операции однотипные, но отличаются какими-то параметрами, тогда исправляя несколько подряд кусков есть шанс "по инерции" исправить второй кусок так же как предыдущий, забыв что он должен обращаться к другим переменным. Если их один-два, то вероятность небольшая, а если 16?

[INFERION]

 Сообщение от mws :

Мало общего вижу с Си, макрос это не функция, он не получает параметры через стек и не возвращает.

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

 Сообщение от mws :

И я абсолютно не понимаю, почему больше текста. Сначала пишется макрос, в потом везде, где без макроса было бы несколько строк текста будет одна строка. А если ещё и вложенные макросы применяются, то размер заменённого текста ещё больше.

Под "пишется" я подразумеваю всё кроме копипаста. И вставить парой кликов готовый блок инструкций вместо макроса для меня проще, чем делать то же самое, но предварительно оформив макросом и затем ломая голову где и какие параметры менять. В голых инструкциях сразу всё видно и я могу спокойно подправить что нужно. И нет у меня задач, где код состоит из полотна с идентичными участками. Всё идентичное сбрасывается в одно место - в подпрограмму, т.к. это экономит тонну памяти. Так что макросы ситуацию нисколько не облегчают. Вообще даже своеобразный API у меня сразу же лепится в прерывание, и возня с периферией сводится к простой записи чего-то там в какой-то регистр, даже если реально на пин выводится что-то хитрое и сложное (к примеру в драйверах RGB индикатор использует весьма хитрую программную модуляцию 2-х пинов, а ШИМ так же полупрограммный и имеет разрешение 16 бит при частоте основной гармоники в 250кГц). Даже тут не требуются сложные процедуры, которые бы оправдали использование спец. макросов.

 Сообщение от mws :

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

Говорю же - был у меня 3-й случай. Пришлось заюзать макросы из-за того, что требовалось прыгнуть выше головы и написать полотно без переходов и прерываний, где каждые 32 такта выполнялись они и те же 4 инструкции (в прерывании все 11), а каждые 256 тактов выполнялся другой набор инструкций, но требования к быстродействию не позволяли засунуть это всё в прерывания. Там действительно было удобно использовать макросы, но геморрой оказался в другом - править такой код, в котором всё разбито с точностью до такта - невозможно. Необходим хитрый компилятор, который самостоятельно может порезать на части основную функцию и вставить между этими кусками то, что обычно оказывается в прерывании по переполнению таймера. А в таком случае макросы опять же уже не нужны. В остальных ситуациях, несмотря на то что я их таки изучил и попробовал, они мне показались неудобными...

 Сообщение от mws :

Макрос не нарушает линейной структуры, это не вызов функции, а всего-навсего подстановка текста.

Макрос выглядит именно как вызов функции, я не вижу с чего он слеплен в том месте, где он подставляет свой текст. Для меня это всё равно что вызов, к примеру, printf (). И как мне по этой записи понять, как именно он выводит текст, какие переменные при этом затрагивает и сколько тактов жрёт? Правильно, мне нужно лезть отдельно в его тело и изучать. В итоге объём изученного текста не меньше, но он оказывается фрагментированным, что усложняет задачу.

 Сообщение от mws :

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

Да, есть такая вещь. Это если много сложных участков с однотипной задачей, которых у меня просто не бывает (иначе они все оказываются в подпрограмме). А в простых я не так уж и часто туплю, чтоб терпеть макросы.

Так что дело всё же во вкусе. Многое зависит от самого автора, от его стиля и предпочтений. Программирование ведь как искусство, одну и ту же вещь можно написать по-разному. И кому-то один и тот же код покажется красивым, кому-то не очень, кто-то скажет что он не эффективен, а кто-то - что он удобен. И пофиг что там говорят никогда не сталкивавшиеся с этим гуманитарии...

[mws]

 Сообщение от INFERION :

А дело тут не в реализации на машинном уровне, а в представлении. Макрос выглядит как функция, и ему так же передаются параметры.

Выглядит также как и инструкция, ассемблера, если не делать больше двух-трёх параметров. Больше делать нет смысла, я считаю, легко запутаться. Зато сразу понятно о чём идёт речь и можно не писать комментариев, например SelectModem1 для меня понятней, чем cbi PORTB,0. Когда начинаешь проект вроде бы всё и так понятно, а когда приходится вернуться к нему спустя год - это уже совсем другое дело.

 Сообщение от INFERION :

Под "пишется" я подразумеваю всё кроме копипаста. И вставить парой кликов готовый блок инструкций вместо макроса для меня проще, чем делать то же самое, но предварительно оформив макросом и затем ломая голову где и какие параметры менять.

Это если код идентичный, а если просто однотипный, отличающийся какими-то адресами или небольшими участками кода, то такое дело уже не прокатит, придётся просматривать весь кусок и переделывать по месту, в случае с макросом же можно просто поменять параметры. И вызов подпрограммы в этом случае не поможет, придётся проверять условия и делать ветвления, что запутает код.

Но я с тобой согласен, во многом зависит как от вкуса так и от конкретных задач.

[Tamagotchi]

Ну, блин, обсудили программаторы. ОДНА страница по теме и 10 лишних. Пора просить Админа почистить тему.

[INFERION]

Только не удалением, а переносом писанины в тему по программированию, ибо полезно...

[Tamagotchi]

INFERION,
Разумеется

[ploop]

 Сообщение от INFERION :

Только не удалением, а переносом писанины в тему по программированию, ибо полезно...

Согласен. Я за.

[027]

И пораскрывать эти чертовы спойлеры.

[Алексий]

Народ, кто пользуется упомянутыми USBASP с фасттеха от LC Technology.
Там есть джампер подачи на прошиваемый МК напряжения питания.

Вопрос по тому варианту, когда джампер на 3.3В установлен.
В этом случае во время прошивки прошивающий МК по линиям MOSI, MISO, SCK использует сигналы так же на 3.3В? Или на 5В?
А то вроде как в AVR на входах защитные диоды стоят и при превышении напряжением на входах напряжения питания более чем 0.5В (точную цифру не помню) диоды откроются и вообще прошиваемому МК может поплохеть.

P.S.: Схемотехнику разглядеть не могу, дорожки мелкие и чем-то покрыты, вижу только что на 3.3В там линейный стабилизатор стоит, а что там дальше и как - без понятия. Задал в личке вопрос топикстартеру, но он, видимо, в отпуске.

[Алексий]

В общем прочитал я руководство по программатору, которое выложено в этой теме.
Там есть схема.

По схеме получается, что прошивающий МК (ATMega в любом случае запитан от 5В (от USB линий VCC и GND) и на свои выводы, соответственно, подаёт всегда напряжение питания, либо ноль (земля). Т.е. при программировании на входях MISO, MOSI, SCK прошиваемого МК будет либо 5В, либо 0В.

Линейный стабилизатор, который там стоит, напряжение в 3.3В подаёт ТОЛЬКО на 2й пин разъёма программирования и только если установлен джампер на 3.3В.

В даташите на МК AVR (ATtiny13A, например) явно сказано, что подавать на входы МК напряжение превышающее напряжение питания более чем на 0.5В, либо ниже чем уровень земли на -0.5В НЕЛЬЗЯ. Для этого стоят защитные диоды, которые откроются. Исключение только для вывода RESET, которые держит до 12В (для высоковольтного программирования).

Попробовал всё-таки посмотреть как идёт дорожка от центрального вывода (3.3В выходного) линейника - да, получается что через пару переходных отверстий только на 2й пин разъёма программирования.

Что-то я ничего не понимаю. Получается, если я в этом варианте USB джампер поставлю на 3.3В и запитаю от этого напряжения прошиваемый МК, то МК при программировании может выйти из строя?
Зачем тогда вообще джампер на 3.3В?
Кто-нибудь шил при этом варианте?
И чего, всё нормально прошло?

P.S.: Хотя, опять же, посмотрел плату ту, что в руководстве сфотографирована, и ту, что с фасттеха. Разные они маленько, разводка дорожек и расположения переходных отверстий отличаются. Короче только с оциллом смотреть, подцепляться как-то.