Witam
Pytanko: jak (w asemblerze) skopiowaæ bit ze zmiennej w SRAM procka do portu wyj¶ciowego. W 8051 to pryszcz: MOV A, zmienna MOV C, ACC.numer_bitu_zrodlowego MOV port_wyjsciowy.numer_bitu_docelowego, C , ale w ATmedze mam z tym powazny problem!
S³awek.
Poczytaj o bicie T s³owa stanu.
U¿ytkownik "Pawe³ Cern" snipped-for-privacy@surname.pl napisa³ w wiadomo¶ci news:e033jj$4b4$ snipped-for-privacy@nemesis.news.tpi.pl...
Chyba nic to nie da. Trzeba mieszaæ z przerwaniami. Zostaj± jedynie skoki.
U¿ytkownik "SJ" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:e034go$hdr$ snipped-for-privacy@news.onet.pl...
Leniuch. A rozkazy BLD/BST to co robi±?
Kopiuj± wskazany bit z rejestru do T lub odwrotnie (chyba ¿e mo¿na te¿ do portu DDRD, ale w takim razie o czym¶ nie wiem).
U¿ytkownik "SJ" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news:e036pl$neo$ snipped-for-privacy@news.onet.pl...
No mo¿na, trzeba ten port przeczytaæ do jakiego¶ rejestru procesora, zmieniæ bit W REJESTRZE i spowrotem zapisaæ wynik do portu.
i dlatego pisa³em ¿e trzeba wtedy mieszaæ przerwaniami - blokowaæ je, bo je¶li co¶ takiego samego wykonuje jaka¶ procedura przerwania, to miêdzy odczytem portu do rejestru a jego zapisem, procedura przerwania zrobi to samo, to mamy w rejestrze nieaktualn± warto¶æ portu - zgubimy zmiane jego zawarto¶ci przez przerwanie.
my¶la³em ¿e kto¶ ma na to jaki¶ prosty "patent"
No a ten nie jest prosty? Zablokowanie/odblokowanie przerwañ to raptem 1 rozkaz ustawienia/wyzerowania bitu w s³owie stanu.
Dnia Sat, 25 Mar 2006 11:03:09 +0100, SJ napisał(a):
Czemu z przerwaniami?
lds r0, zmienna; Załaduj do r0 z RAM bst r0, 5 ; Załaduj bit do T brtc tclear ; Jeśli T==0 -> skocz sbi IO, 5 ; ustaw bit w IO sbis IO, 5 ; ustawilim, więc opuszczamy nast. instrukcję tclear: cbi IO, 5 ; kasujemy bit cośtamcośtam...
Marcin Stanisz
i to jest to - albo blokada przerwañ, albo skoki - 6 instrukcji ¿eby skopiowaæ jeden bit. jakby nie mogli wywaliæ zdublowanego SBR/ORI i do³o¿yæ kopiowanie T do IO.
Je¶li poszczególne bity portu wyj¶ciowego mam w wielu miejscach sterowane, to wszêdzie co chwilê muszê te przerwania blokowaæ na czas trwania procedury kopiowania bitu. chyba najpro¶ciej jest jednak ze skokami
Dok³adnie tak. Tylko ¿e na '51 odk³adam sobie w przerwaniu zawsze tylko PSW i ACC a w AVR musia³bym odk³adaæ wszystkie rejestry do których chcê mieæ dostêp w przerwaniu.
Po drugie - to nie ma sensu. Jak od³o¿ê IO po wej¶ciu w przerwanie, zmieniê sobie w nim stan bitu wyj¶ciowego, po czym odtworzê IO, to co mi po zmianie tego bitu!
Po prostu - albo blokujê przerwania na czas zmiany bitu poprzez T, albo skoki.
Dnia Sat, 25 Mar 2006 11:48:34 +0100, SJ napisał(a):
Dobrą zasadą jest zachowywanie na stosie rejestrów używanych przez procedury przerwań. Równie dobrze przykład z '51 może zmienić wartość A między pierwszym i drugim rozkazem (o ile A nie było automatycznie odkładane na stos, nie pamiętam...).
Pozdrawiam Marcin Stanisz
Ale, kurde tylko JEDNA instrukcja wiêcej, i by³bym happy! Maj± SBI i CBI (czyli operacjê rmw na IO) wiêc jakby nie mogli dorzuciæ jednego BLD dla IO - ile by to upro¶ci³o rzeczy!
Dnia Sat, 25 Mar 2006 11:59:50 +0100, SJ napisał(a):
Wiesz, to jest urok RISCa... Za to każda z tych instrukcji wykona się w OIDP 1 lub 2 cyklach zegara :)
Pozdrawiam Marcin Stanisz
Ten sam port (DDRD) inne bity (3 i 4): pin PD3 w g³ównym, pin PD4 w przerwaniu.
Poza tym IO nie odk³adasz po wej¶ciu w przerwanie,
...a to jak najbardziej tak.
Pozdrawiam, S³awek
Dnia Sat, 25 Mar 2006 12:05:50 +0100, SJ napisał(a):
No nie ma, że boli :) Chciało się mieć więcej rejestrów ogólnowojskowych, to trzeba cierpieć ;)
Żebym dobrze zrozumiał - dopuszczasz zmianę tego samego bitu przez dwa różne źródła (przerwanie i program główny)?! No, to rzeczywiście musisz blokować przerwania... Poza tym IO nie odkładasz po wejściu w przerwanie, tylko r0.
Pozdrawiam Marcin Stanisz
Panie, takie rzeczy to tylko w Erze:) .... albo w ARM-ach np. Atmel AT91SAM7S64 (patrz - zestaw rejestrów do obs³ugi kontrolera I/O).
Pawe³
No to mo¿e by tak procedurkê dedykowan± zrobiæ i nie powielaæ kawa³ka kodu? Zreszt± je¶li problem nie wymaga zmiany rejestrów I/O w przerwaniach, to blokowanie mo¿na sobie darowaæ.
ATmega to nie (mikro)procesor, tylko komputer jednouk³adowy, wiêc a¿ dziw bierze ¿e nie zrobili czego¶ tak podstawowego jak sterowanie pinem wyj¶ciowym. Przecie¿ do takiego uC pod³acza siê ró¿ne rzeczy: SPI, I2C, itp gdzie sterowanie odbywa siê z u¿yciem pojedynczych linii portu.
Nie wiem czy przeoczy³em ale brakuje mu te¿ DIV? To byle '51 nawet ma. Rozumiem ¿e do DIV musia³by ju¿ byæ wielotaktowy CISC, ale ten RISC to i tak pewnie CISC z wymna¿aniem PLL, a poza tym wola³bym gdyby by³o DIV i kopiowanie T do IO choæby w kilku taktach ni¿ softwerowe kombinowanie.
Mo¿e za du¿o wymagam (przez przyzwyczajenia do innych uC) ale z brakiem sterowania bitu portu przesadzili.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required