Co to za instrukcja - dw $ffff (AVR asm)?

Zapewne tutaj:

To nie jest instrukcja tylko dyrektywa asemblera. Chyba najlepiej szukać w jakimś helpie do kompilatora bo dyrektywy mogą się różnić od siebie między kompilatorami.

Q snipped-for-privacy@gazeta.gov.pl> napisał(a):

Zdaje mi się ,że "zdisassemblowałeś" jakiś HEX lub BIN :) Jeśli tak , to co masz powyżej i poniżej .dw $ffff to też nie muszą być instrukcje tylko dane.Żeby się o tym przekonać to trzeba troszku poruszać głową bo inaczej nici ze źródełka :-)

U¿ytkownik "Q" snipped-for-privacy@gazeta.gov.pl> napisa³ w wiadomo¶ci news:cm3efo$fd2$ snipped-for-privacy@nemesis.news.tpi.pl...

A to dzia³a?

AVR-ki nie znaj± instrukcji o kodzie 0xFFFF. SPM zajmuje jedno s³owo, wiêc to te¿ nie jego. Sk±d to wzi±³e¶? Uk³ad traktuje to pewnie jako nop, bo jako¶ musi. ;)

Pzdr, Raf.

a nie jest to definicja DefineWord? czyli umeisc w pameici programu stala? do ktorej sie potem odwolujesz? byc moze to co zdisassemblerowales to byl obszar danych, np jakas tablica..i niektre dane ci rozpoznal jako instrukcje, ktore raczej sensu nei beda maily razem..a czesc jako .DW niestety, tutaj na to madrych dekompilatorow nie ma chyba.trzeba usiasc i zaczac myslec jak procek trawiac slowo rozkaz po rozkazie..:) albo wrzucic na symulator, ale wraz trzeba myslec:)

To jest dyrektywa wstawiaj±ca s³owo 0xffff Te¿ siê zastanawia³em nad tym przyk³adem. Nie wiem w jakim celu Atmel zaleca tak robiæ. Program dzia³a z tym .dw jak i bez niego.

Pawe³

U¿ytkownik "Pawe³" snipped-for-privacy@neostrada.pl napisa³ w wiadomo¶ci news:cm3qko$8aq$ snipped-for-privacy@atlantis.news.tpi.pl...

Czy mo¿esz zdradziæ gdzie to zalecaj±? Nigdzie nie znajdujê.

Pzdr, Raf.

dzieki :)

wiem, ze to nie jest wprost instrukcja; na me oko to po prostu wsadzenie slowa 0xFFFF w kod;

tyle, ze jak, czemu, i dlaczego dziala? :)

zle Ci sie zdaje :)

dziala!

przykladowy kod boot loadera;

w boot loader'ze :)

ps. znalazlem tylko taki, 'lajkoniczny' opis :(

.word 0xFFFF ; for future part compatibility, instruction alignment

"for future part compatibility, ..."

ciekawe...

najpierw myślałem, że to samo co NOP (po ustawieniu bitu SPMEN, program ma 4 cykle na wywołanie instrukcji SPM i możliwe, że w ten sposób Atmel się zabezpiecza przed katastrofą, jeśli program pójdzie w maliny), ale potem znalazłem wzmiankę, że Atmel zaleca to ze względu na pipelining. pewnie łatwiej by było, gdybyś podał skąd wziąłeś ten plik.

w.

Pewnie znalazłeś to w swoim kodzie w wyniku doczepienia standardowego (w WinAVR) pliku nagłówkowego boot.h i wykorzystania tamtejszych funkcji. Z punktu widzenia boot.h cytat wygląda następująco (przykładowy kod funkcji kasowania strony pamięci programu):

#define __boot_page_erase_alternate(address) \ ({ \ boot_spm_busy_wait(); \ eeprom_busy_wait(); \ __asm__ __volatile__ \ ( \ "movw r30, %2\n\t" \ "sts %0, %1\n\t" \ "spm\n\t" \ ".word 0xffff\n\t" \ "nop\n\t" \ : "=m" (__SPM_REG) \ : "r" ((uint8_t)__BOOT_PAGE_ERASE), \ "r" ((uint16_t)address) \ : "r30", "r31" \ ); \ })

Tutaj właśnie występuje ten magiczny rozkaz FFFF. Wersje funkcji z "alternate" w nazwie wykorzystywane są przy kompilacji dla procesorów ATmega161/163/323:

"Alternate versions of the macros use 16-bit addresses and require special instruction sequences after SPM."

A dokładną receptę na te zawiłości przytacza sam Atmel, w PDFie do ATmegi 323, strona 180:

"To ensure proper instruction pipelining after programming action (Page Erase, Page Write, or Lock bit write), the SPM instruction must be followed with the sequence (.dw $FFFF - NOP) as shown below: spm .dw $FFFF nop If not, the instruction following SPM might fail. It is not necessary to add this sequence when the SPM instruction only loads the temporary buffer.

Teraz już chyba wszystko jasne.

no pewnie! :)

dzieki;