Форум РадиоКот

Int_13h писал(а):

DX168B писал(а):ARV прав. Откуда - то данным надо взяться в ОЗУ.
Шас выложу код....

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

ldi           YL,               Low(digits)    ; Массив данных в RAM (ОЗУ). [с 1-го адреса]
ldi           YH,               High(digits)   ;Тут умножать на 2 не надо.
ldi           ZL,               Low(ARRAY*2)   ; Массив данных в ПЗУ.
ldi           ZH,               High(ARRAY*2)  ;А тут надо умножить на 2.
ldi           count,            4
WRSTD1:
lpm           temp0,            Z+            ; Грузим из массива в ПЗУ значение
st            Y+,               temp0         ; Копируем с постинкрементом в SRAM (ОЗУ)
dec           count                           
brne          WRSTD1                          ; повторяем процедуру 4раза до 0

так чуть быстрее будет

Точно.... Затупил я немного.... Бывает.....
Этот вариант производительнее.

Народ никак немогу разобраться как спрограмирова модуль USI для работы в двухпроводном режиме(TWI). Ни укого нету кода на ассемблере для программирования Ведомого передатчика(ведоиый который передаёт данные ведущему по в ответ на адресный пакет sla+R). Также нет ли у кого подромного материала по программированию USI в двухпроводном режиме ибо в книгах это плохо описанно. Заранее спасибо.

МмМммда... Тяжёлый вопрос, я сам из USI разобрался только в трёхпроводном интерфейсе SPI и
то с горем пополам. За TWI не брался. Если честно, то мне помог только даташит на МК.

DX168B писал(а): Точно.... Затупил я немного.... Бывает.....
Этот вариант производительнее.

Оптимизация - великая вещь! Особенно, когда на ассемблере пишешь - всегда хоть 1команду да можно сократить.

nictrace писал(а):Оптимизация - великая вещь! Особенно, когда на ассемблере пишешь - всегда хоть 1команду да можно сократить.

Следуя вашей логике, через конечное число итераций оптимизации не останется вообще ни одной команды. А это уже тривиальность (как тождественный ноль в уравнении =).

Gudd-Head писал(а):Следуя вашей логике, через конечное число итераций оптимизации не останется вообще ни одной команды. А это уже тривиальность (как тождественный ноль в уравнении =).

есть два расхожих утверждения:
1. во всякой программе имеется хотя бы одна ошибка
2. всякую программу можно сократить хотя бы на одну команду.
из этого следует, что в безошибочной программе не должно быть ни одной команды

ARV писал(а):в безошибочной программе не должно быть ни одной команды

Опять же, мы пришли к тождеству вида 0 = 0

у Станислава Лема есть другое утверждение (выводится, как следствие из аксиом): бесконечно большая программа способна выполняться сама по себе, без компьютера

Как-то взялся за оптимизацию одной программы с другом под пиФфко. Где-то лишнее выкинул и чуть сократил код, да вот в одном месте не усмотрел и программа сделала загрузку массива в ОЗУ задом наперёд.
Потом сцуко, долго матерился, выискивая багу.

господа ассемблерофилы! к вам обращаюсь с предложением:
бросайте нафиг этот унылый AVRASM и юзайте GAS - GNU Assembler!!!
В комплекте WinAVR он имеется, назвывается avr-as.exe
по сравнению с ним тот ассемблер, что встроен в AVR Studio, просто УГ!!!
работать с ним очень просто: создаете в AVR Studio проект GNU C, но в сам проект вставляете файлы с расширением .S - это и будут ассемблерные файлы
учтите, что этот ассемблер не выдает готовую прошивку, поэтому компиляция будет вестись через GCC, но какая вам разница?! ведь исходник-то будет на ассемблере! только учтите 3 главные вещи:
1. таблицу векторов прерываний компилятор встроит за вас сам
2. указатель стека компилятор настроит за вас сам
3. начало программы - это функция main, т.е. вы должны объявить эту метку в своей программе.
все остальное несложно, разберетесь. но сколько возможностей в нем!!! одни макросы чего стоят!!!

я вот немного попробовал - и просто в восторге! сразу вспомнил, как раньше работал на ассемблере и ругал его за убогость (AVR-овский вариант, естественно) - но GAS ничем не уступает TASM или MASM (если кому-то эти слова что-то говорят )

4. Аналог "инициализированных переменных" в С, т.е. записи
.data
foo: .byte 5
проинициализирует сам, и при сравнительно большом количестве таких переменных это займёт меньше места во флеше, чем врукопашную делать
ldi r16,5
sts foo,r16

5. Неинициализированные переменные, т.е. записи
.bss
moo: .skip 1
обнулит сам

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

Ну и макроязык таки да гораздо мощнее, чем AVRASM*. Это надо попробовать, чтобы понять

ARV писал(а):господа ассемблерофилы! к вам обращаюсь с предложением:
бросайте нафиг этот унылый AVRASM и юзайте GAS - GNU Assembler!!!
...
я вот немного попробовал - и просто в восторге! сразу вспомнил, как раньше работал на ассемблере и ругал его за убогость (AVR-овский вариант, естественно) - но GAS ничем не уступает TASM или MASM (если кому-то эти слова что-то говорят )

А Вы попробуйте не немного, а на серьёзных вещах. GAS -- крайне убогая вещь, даже близко не лежавшая к вменяемым ассемблерам для ПК, так что, если он в чём и превосходит AVRовский, то не слишком и в непринципиальных вещах (фактически GAS -- подпорка под GCC, поскольку сей набор трансляторов генерит ассемблерный текст, а не прямо объектный код). И это не говоря о том, что в AVR Studio текстовый редактор, транслятор и отладчик "в одном флаконе", а для GAS где-то придётся набирать исходный текст программы, потом из командной строки вызывать ассемблер и компоновщик, а затем думать, как же прошить результат трансляции и сборки в микроконтроллер, а главное -- как отлаживать.

Пользуюсь AVR Studio 4.0 в связке с WinAVR и не жалуюсь.
Сейчас наделал себе кучу макросов на все, ну или почти на все случаи жизни и скошачил
заголовочник(*.inc), который включаю в проекты директивой .include
Отладчик тоже хороший, особенно изображение регистров в виде квадратиков.
Так труднее ошибиться. На счёт подгона временных характеристик в программе - есть в отладчике счётчик времени. По нему никогда не ошибался и в "железе" получались такие же временные параметры. Я не пишу в день по 20-30 разных программ и по этому мне хватает того, что есть.
Одним словом - пользуюсь тем, что предоставляет производитель МК.

DX168B писал(а):Пользуюсь AVR Studio 4.0 в связке с WinAVR и не жалуюсь.

Да вот я тоже так подумал, что человек просто AVRstudio плохо знает, раз считает, что с avr-as под ней работать не выйдет. Но, поскольку я и в windows-то давно не был, да и там студию запускал не часто, то решил промолчать, вдруг что забыл с нескольких запусков студии

Вот возникли 2 вопроса:
1. Можно ли подать контроллеру команду SLEEP в обработчике какого-нибудь прерывания, например в прерывании таймера?
2. Если на каком-нибудь ПИНе будет присутствовать лог. 1, то при входе МК в Sleep Mode ток не исчезнет на нём?
Ну например так: Будет ли присутствовать ток на выводе PA3 при спячке МК?

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

SII писал(а):А Вы попробуйте не немного, а на серьёзных вещах. GAS -- крайне убогая вещь, даже близко не лежавшая к вменяемым ассемблерам для ПК, так что, если он в чём и превосходит AVRовский, то не слишком и в непринципиальных вещах (фактически GAS -- подпорка под GCC, поскольку сей набор трансляторов генерит ассемблерный текст, а не прямо объектный код). И это не говоря о том, что в AVR Studio текстовый редактор, транслятор и отладчик "в одном флаконе", а для GAS где-то придётся набирать исходный текст программы, потом из командной строки вызывать ассемблер и компоновщик, а затем думать, как же прошить результат трансляции и сборки в микроконтроллер, а главное -- как отлаживать.

ну как вам сказать... пожалуй, вы не правы
1. кто вам сказал, что GCC не генерит прямой объектный код? генерит, еще как генерит!
2. в AVR Studio элементарно пишутся программы на ассемблере для сборки AVR-AS-ом из набора WinAVR - я уже написал минимум действий для этого. поэтому никакой отдельный редактор и отладчик не требуется. ну и прошивается все оттуда же - из студии. а если что не так - avrdude под рукой
3. я работал с ассемблером TASM, MASM, A51 ну и AVRASM. на первых двух писал в свое время неслабые программы, например, резидентный сетевой спулер печати для MS DOS. первые три ассемблера я оцениваю как очень мощные, с развитыми средствами облегчения труда программиста. последний я оцениваю как большое убожище по этим возможностям. а теперь, когда я испробовал GAS, могу сказать, что он, пожалуй, равен первым трем. конечно, времени много прошло с тех пор и я могу многое забыть, но общее впечатление: GAS - это сильная вещь!!!

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

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

ARV писал(а):ну как вам сказать... пожалуй, вы не правы
1. кто вам сказал, что GCC не генерит прямой объектный код? генерит, еще как генерит!

Нет, он не генерит прямой объектный код. Он генерит промежуточный файл на ассемблере, который скармливает ГНУсному асму. А точнее, конкретно ГЦЦ вообще ничего не генерит. Это хорошо видно, если ему задать опцию, чтобы он выводил все командные строки, которые он (ГЦЦ) выдаёт для вызова программ, собственно осуществляющих трансляцию. Ведь ГЦЦ -- это не транслятор, это всего лишь "диспетчер", разбирающийся, кто и в каком порядке должен делать заданную работу. Вот он и вызывает транслятор с соответствующего языка (Си, Си++, Фортран, Си-шарп, Жаба, Ада -- вроде как всё), который на выходе производит именно ассемблерный файл, потом передаёт его ассемблеру, а уже полученный объектник -- компоновщику. Тот факт, что от пользователя ГЦЦ процесс получения ассемблерного файла и дальнейшей его "переработки" в объектник скрыт, никак не меняет ситуацию: кодогенератор ГЦЦ не умеет производить объектники, он делает асмовские исходники.

2. в AVR Studio элементарно пишутся программы на ассемблере для сборки AVR-AS-ом из набора WinAVR - я уже написал минимум действий для этого. поэтому никакой отдельный редактор и отладчик не требуется. ну и прошивается все оттуда же - из студии. а если что не так - avrdude под рукой

Ну, так я не пробовал. Тем не менее, не вижу никакой реальной нужды использовать левый транслятор, проще использовать родной для студии, тем более что для небольших проектов (примерно до 10 тыс. строк) его возможностей вполне достаточно, а более крупные на 8-разрядных контроллерах явно экзотика, да и пишутся обычно на ЯВУ (хотя лично я предпочту писать на ассемблере, чем на Си, ну а Паскаль или Ада для АВР мне как-то не попадались, хотя и можно попытаться собрать Аду в составе ГЦЦ -- но там уже другие сложности будут, поскольку сам транслятор откровенно кривоват и имеет тенденцию падать на абсолютно корректном исходном тексте).

3. я работал с ассемблером TASM, MASM, A51 ну и AVRASM. на первых двух писал в свое время неслабые программы, например, резидентный сетевой спулер печати для MS DOS. первые три ассемблера я оцениваю как очень мощные, с развитыми средствами облегчения труда программиста. последний я оцениваю как большое убожище по этим возможностям. а теперь, когда я испробовал GAS, могу сказать, что он, пожалуй, равен первым трем. конечно, времени много прошло с тех пор и я могу многое забыть, но общее впечатление: GAS - это сильная вещь!!!

Ну, если Вам нравится, используйте на здоровье, это дело личных пристрастий (если нет приказа свыше, конечно). Однако у меня сложилось прямо противоположное ощущение. Кстати говоря, и ТАСМ с МАСМом -- так себе трансляторы, если иметь с чем сравнивать (я-то не на ПК начинал, так что в своё время долго плевался -- как от убожества и кривизны системы команд 8086, так и от недоразвитости самих трансляторов). Про А51 ничего не скажу -- то ли не знаю его, то ли просто не помню (к счастью, с 8051 иметь дело приходилось только около 20 лет назад и недолгое время). Впрочем, подобные обсуждения имеют тенденцию выливаться в холивар, поэтому не вижу смысла дискутировать.

ARV писал(а):

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

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

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