студия версии 4.xx вполне себе дружит с WinAVR, позволяя делать отладку внутри себя без танцев с бубном. WinAVR в голом виде - только компилятор. точнее, там есть и свой "отладчик" и "симулятор", но я пока не встречал героя, который бы ими пользовался новые версии студии работают так же прозрачно с "тулчейном" avr-gcc, т.к. WinAVR - устарел и не поддерживается. WinAVR - это avr-gcc версии 3.3.2, в более свежих версиях есть интересные плюшки
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
[uquote="imerlin",url="/forum/viewtopic.php?p=3529356#p3529356"]...Проблема там в том, что при организации циклом очень большие накладные расходы на сохранение флага C (он используется в многобайтных ADC, SBC, CPC, ROL/ROR и т.д., но при этом портится в DEC), поэтому перед DEC его нужно куда то сохранять, а после - восстанавливать.[/uquote]Замечу, в AVR команды INC DEC флаг C не трогают, поэтому сохранять его не нужно. Мелочь, но приятно.
Замечу, в AVR команды INC DEC флаг C не трогают, поэтому сохранять его не нужно. Мелочь, но приятно.
Хм... И правда... Почему то засело в голове, что в таблице команд указано, что меняет... Помнится матерился из-за этого долго... Толи не на ту строчку посмотрел, толи что еще... Может, в каком то из даташитов ошибка вкралась? Спасибо, что сказали, а то так бы и пребывал в заблуждении...
Но в любом случае, для сравнения все равно танцы с бубном неизбежны - на Z то ведь по любому влияет.
Добавлено after 54 seconds: [uquote="ARV",url="/forum/viewtopic.php?p=3529404#p3529404"]студия версии 4.xx вполне себе дружит с WinAVR, позволяя делать отладку внутри себя без танцев с бубном.[/uquote]
Спасибо, придется изучать...
Добавлено after 2 minutes 35 seconds: [uquote="trofim2",url="/forum/viewtopic.php?p=3529431#p3529431"]типа так:
Так в том и вопрос был, чтобы не жестко задать, а произвольно: сколько надо, столько и задано, а не именно пять. А пока примерно так и вышел из положения: прописал 8 процедур для размеров операндов от 1 до 8-ми байт.
[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3529839#p3529839"]А стоит оно того? Разворачивать подобного рода циклы... экономия порядка 16 тактов на сдвиге 8 байт.... ценой потребления памяти в 8 раз?[/uquote]
Иногда да. Например, при небольшой длине операндов (2-3 байта) может баш на баш выйти по объему за счет удаления цикла. Ну и верно AVR заметил, что случаи разные бывают, а я предпочитаю, если уж однажды сделал, сделать так чтобы потом с полочки взять и с минимальными изменениями снова использовать. Ну лень мне снова вспоминать, например, как деление сделать. А скоро потребуется - давно хочу приборчик добить для регулировки зажигания и карбюратора: тахометр, УОЗ, УЗСК, стробоскоп... Там если точно мерить, то много тактов набегает за оборот на низких оборотах, сейчас не помню, но то ли на 4 то ли аж на 6 байт, и все это надо делить для вычисления частоты в об/мин. А умножения в любом ПИД регуляторе нужно. Да и вообще, может я ошибаюсь конечно, но каждый проект индивидуален, где то по памяти лимит жестче, где то по скорости, лучше, если тяжелые базовые подпрограммы будут иметь возможность выбора: скорость за счет памяти или наоборот. Да и вообще, я задал вопрос, находясь в заблуждении о том, что команды inc/dec изменяют флаг C, и циклы получались очень уж монструозными. Сейчас перепишу версию с циклами, посчитаю такты, может и решу что не надо так уж заморачиваться.
Добавлено after 6 minutes 44 seconds: [uquote="trofim2",url="/forum/viewtopic.php?p=3529519#p3529519"]Тогда типа такого:
А через пару лет, когда уже основательно забудется как сделана эта программа, вдруг понадобится 11 байт. Не упустите, что программа может быть очень сложна, таких кусочков может быть не один десяток и с разными кратностями повторения. К тому же такой вариант слишком сложен для восприятия, не влезает целиком на экран для осмысления сути этого действия и вообще вместо облегчения работы приносит больше осложнений. Нет, судя по всему действительно, в классическом ASM для AVR эта задача не решается так как я хочу ее решить.
Формировать видеосигнал тяжелыми вычислениями? на АВР? Психушка плачет... Это несколько опрометчивые решения, там где надо каждый такт считать, нужно рассматривать другие решения - на ПЛИС например или DSP. Ведь больше времени потратите на отладку этих крох, а время дороже железа. Такие алгоритмы вы с полочки не возьмёте, они слишком специфичны и аппаратно зависимы. Через год вы уже забудете про контроллер на котором делали эту оптимизацию, а на другом эти хаки уже не работают и т.п. взять современные ARM, там уже конвеер, разные частоты ядра и периферии и уже не столь очевидно сколько тактов уходит на конкретную конструкцию а иногда быстрее будет исполняться неказистая на вид конструкция.
За те циклы/подсчеты... Я такую задачу делал когда WS2812 от АВРки запускал. Все прекрасно контролируется и исполняется. Причем с завидной стабильностью для случая программной широтной манипуляции (это помимо основного генератора случайных чисел и прочей обработки). Так что не надо "контейнер гнать" на 8-битники под ассемблером раньше времени.
Так кто гонит? Контролируется, да. Но задача для WS2812 по силам контроллеру, там не надо выжимать такты ибо не успеваешь - там такты считать надо чтобы обеспечить требуемые временные параметры импульсов, это совсем другое.
возьмите уже их и покиньте тему
Возьму, конечно, когда это надо будет - т.е. когда задача перерастёт возможности AVR или будет совсем впритык - именно для того чтобы не собирать крохи чтобы обеспечить менее 10% выигрыша по скорости.
1) А правильно ли я забираю/читаю двухбайтное из EEPROM? (tiny2313) 2) Т. к. физически двубайтных здесь нет (и адрес однобайтен и данные в общем то туда-сюда), то записывать надо в этой же последовательности? (писать Low, увеличить адрес, писать High) Спойлер.def adr=r18 ldi adr,0 ;или ldi adr,(metka_v_eeprom) ;---------- ee_read: ;cli запрет прерываний делается выше на всю операцию с кнопкой sbic EECR,eepe ;если сброшен то EEPROM готов и далее rjmp ee_read ;иначе ждать здесь out EEAR,adr ;отправить адрес sbi EECR,eere ;Start Read in r16,EEDR ;забрать данные L (лежат слева направо LL>HH)
ee_read_h: sbic EECR,eepe rjmp ee_read_h inc adr ;увеличить адрес out EEAR,adr ;отправить sbi EECR,eere ;Start Read in r17,EEDR ;забрать данные H
Для EEPROM обязательного формата для многобайтовых величин нет. Единственное условие - следовать выбранному правилу - или старшие байты затем младшие или как у Вас младшие а затем старшие. И такой же порядок при извлечении. Low или High относятся только к непосредственно загружаемым величинам. Это если допустим требуется выполнить чего-то подобного: 6071 загрузить в EEPROM тогда
загружаем начальный адрес ячейки ЕЕПРОМ (допустим 0) LDI r16,low(6071) out EEDR,r16 выполнить запись младшего байта инкремент счетчика адреса в EEADRH:EEADRL ldi r16,high(6071) out EEDR,R16 выполнить запись старшего байта инкремент счетчика адреса в EEADRH:EEADRL
а извлечение делается допустим в регистровую пару Хh:Xl
загружаем начальный адрес ячейки EEPROM (допустим 0) читаем данные (в EEDR) in Xl, EEDR инкремент счетчика адреса в EEADRH:EEADRL читаем данные (в EEDR) in Xh, EEDR
Касательно директив DW/DB относительно EEPROM (загрузка фиксированной строки программатором из файла)... Должны вроде правильно байты раскладывать - первым младший, вторым старший. Но ... склероз...
[uquote="Серый_",url="/forum/viewtopic.php?p=3540326#p3540326"]...записывать надо в этой же последовательности? (писать Low, увеличить адрес, писать High)...[/uquote]Как загрузите так и считаете. Думаю, оформить чтение/запись подпрограммой логичнее. Для примера, загрузка R16...R19 в формате младший-старший, а R20...R23 в формате старший-младший
SBI ACSR,ACD ; выключить аналоговый компаратор ;************************************************* LDI ZH,0 LDI ZL,EE_BEGIN LDI YH,0 LDI YL,16 ;---------- sbic EECR,eepe ;если сброшен то EEPROM готов и далее rjmp PC-1 ;иначе ждать здесь READ_EEPROM: RCALL EEREAD ST Y+,R0 INC ZL CPI ZL,EE_END BRLO READ_EEPROM OUT EECR,ZH RJMP PC ;ee_read: ;cli запрет прерываний делается выше на всю операцию с кнопкой ;sbic EECR,eepe ;если сброшен то EEPROM готов и далее ;rjmp ee_read ;иначе ждать здесь ;out EEAR,adr ;отправить адрес ;sbi EECR,eere ;Start Read ;in r16,EEDR ;забрать данные L (лежат слева направо LL>HH)
;ee_read_h: sbic EECR,eepe ;rjmp ee_read_h ;inc adr ;увеличить адрес ;out EEAR,adr ;отправить ;sbi EECR,eere ;Start Read ;in r17,EEDR ;забрать данные H
;ret ;выход (прерывания разрешатся выше) ;---------- EEREAD: OUT EEAR,ZL SBI EECR,EERE IN R0,EEDR RET
Ок, спс. Проворачивать что-то более сложное, с заценкой конечного адреса пока не понадобилось, но засейвил для примера. (akl, имхо метки PC-1 и PC не имеют "точек выхода"). Запустил свои варианты R/W вроде пока работают, вроде пока безглючно. И ещё вопрос о двухбайтном, в данном случае "по научному" нужно ставить "nop"?
sbiw x,1 ;минуснуть 1 из пары (выполнится за 2 такта) nop ;(поэтому пустотакт перед отправкой куда-либо) out ocr1AH,xH ;отправить out ocr1AL,xL
Офф: СпойлерИ сорян, ответившим = в карму плюсовать дают только 1 раз (и то через поиск пользователя), а поднятия рейтинга сообщения висят уже давно.