przepisanie funkcji w C na Asembler

Loading thread data ...

Wiem, ze to jest bardzo duza prosba jak na zasady obowiazujace w grupie (glupio mi z tego powodu) ale zmusza mnie do tego moja sytuacja. Pozdrawiam

Jacek M.

Reply to
Jacek M.

Użytkownik Jacek M. napisał:

ldi ZL, Low(bufor) ldi ZH, High(bufor) ldi r16, 0x50 label1: sbic PIND, PIND2 rjmp label1 label2: sbis PIND, PIND2 rjmp label2

label3: sbic PIND, PIND3 rjmp label3 label4: sbis PIND, PIND3 rjmp label4

in r0, PIND st Z+, r0 dec r16 brne label3

Szybciej się już raczej nie da. Mozna jeszcze wykorzystać przerwania INT0 i INT1 ustawiając reakcje na zbocza narastające.

Pozdrawiam Grzegorz Kurczyk

Reply to
Grzegorz Kurczyk

P.S. Program pisałem z głowy na poczekaniu. Nie testowałem go, ale ogólna zasada jest jasna. "Wadą" jest to, że potrzeba 0x50 bajtów RAM-u na bufor, do którego zrzucane są całe wartości portu PIND. Po zakończeniu "próbkowania" możesz sobie wyANDować ;-) wartość interesującego bitu.

Pozdrawiam Grzegorz Kurczyk

Reply to
Grzegorz Kurczyk

Witam. Dziekuje Grzeskowi Kurczykowi za pomoc ale niestety nie umiem sobie poradzic dalej. W pliku read_Fram.S zbudowalem funkcje readFram i wkleilem do niego kod przez niego napisany. Uzupelnilem o deklaracje zmiennej zewnetrzej cos1, ktora w pliku C zdefiniowana jest jako globalna uchar cos1[80]. Oczywiscie umiescilem ten plik w makefile i skompilowalem. Niestety proba kompilacji zakonczyla sie komunikatami kompilatora o bledach. Nizej jest zawartosc pliku readFrame.S z komunikatami o bledach umieszczonymi w linii do ktorej sie odnosza. Plik frame.S: #include "avr/io.h"

.extern cos

.global readFram .func readFram

readFram: ldi ZL, Low(cos1) ; Warning: expression possibly out of 8-bit range, Error: garbage at end of line ldi ZH, High(cos1) ; Warning: expression possibly out of 8-bit range, Error: garbage at end of line ldi r16, 0x50 label1: sbic PIND, PIND2 ; Error: number must be less than 32 rjmp label1 label2: sbis PIND, PIND2 ; Error: number must be less than 32 rjmp label2

label3: sbic PIND, PIND3 ; Error: number must be less than 32 rjmp label3 label4: sbis PIND, PIND3 ; Error: number must be less than 32 rjmp label4

in r0, PIND st Z+, r0 dec r16 brne label3

.endfunc Nie moglem odnalezc makr (?) Low i High mimo poszukiwan, wiec nie moge skomentowac ostrzezen do tych lini sie odnoszacych. W ogole nie rozumiem komunikatow o bledach w liniach z instrukcjami asemblerowymi sbic i sbis. Przeciez ani port PIND, ani zaden pin z tego portu nie ma wartosci wiekszej niz 32? Z dokumentacji mikrokontrolera ATmega32 wynika, ze ta instrukcja asemblera jest uzyta dobrze. Prosze was o pomoc bo nie wiem jak wyjsc z tego. Pozdrawiam

Jacek M.

Reply to
Jacek M.

Jacek M. snipped-for-privacy@poczta.onet.pl> napisał(a): ..

Nie możesz traktować pliku *.S jak *.c , ponieważ ... sam wiesz dlaczego ;) przykład: #define OCR0 _SFR_IO8(0x31) //dla "C" i należy taki zapis zmienić na: #define OCR0 0x31 ;dla assemblera Również "low" zmień na "lo8" , a "high" na "hi8" . Wypadało by też poinformować linker , w jakiej sekcji umieścic dany obiekt. By z grubsza poznac tajniki assemblera , każ kompilatorowi "C" wygenerować pliki *.S i podejrzyj jak toto wygląda , a zobaczysz , że to kopalnia informacji.Nie pogardź dokumentacją avr-as.

Piotrek

PS Sam sie tego uczę , więc "znam ten ból" ;-)

Reply to
Piotrek Sz.

Ciekawa rzecz. Zmienilem te linie i wstawilem wartosci zdefiniowane w pliku iom32.h i kompilator juz nie zglasza bledu. Teraz ten fragmet wyglada tak: label1: sbic 10, 2 rjmp label1 label2: sbic 10, 2 rjmp label2 Tak jak pisalem poprzednio przy probie zdefiniowania na nowo tych nazw (PIND, PIND2...) kompilator generowal blad dotyczacy proby powtornego ich zdefiniowania. To juz nie mam pojecia dlaczego tak jest. Mozecie mi to wyjasnic? Pozdrawiam goraco.

Jacek M.

Reply to
Jacek M.

Jacek M. snipped-for-privacy@poczta.onet.pl> napisał(a): ..

To nie chce działać :( ..

Nie chodzi mi o plik *.lss a dokładnie o plik *.s (z małym "s") Tak kompiluję *.c do *.s

avr-gcc -S -mmcu=atmega32 -I. -gdwarf-2 -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes

-Wa,-adhlns=main.lst -std=gnu99 -DF_OSC=8000000 -MD -MP -MF .dep/main.s.d main.c -o main.s

..

Nie wiem (jeszcze ;) ) dlaczego tak się dzieje , ale asm "nie łyka" plików nagłówkowych kompilatora "C".Wczytałem assemblerowy includ "m32def.inc" do edytora, zamieniłem hurtowo wszystkie ".equ" na "#define" ,"$" na "0x" , jeszcze kilka kosmetycznych poprawek , zapisałem w kalatogu projektu jako "m32def.h" i działa ;-) Zrobiłem nawet test dla Ciebie ;)

#include "m32def.h" globl Fonts globl funkcja section .progmem.data Fonts: byte 1,2,3,4,5,6 byte 11,22,33,44,55,66 section .text func funkcja funkcja: push r16 sbic PIND,PIND2 out PIOTR,r16 // dla #define PIOTR _SFR_IO8(0x1e) - błąd // dla #define PIOTR 0x1e - OK

pop r16 ret

Należy byc baaaaaaardzo dociekliwym ;-)

Piotrek

Reply to
Piotrek Sz.

.. #include "m32def.h" .globl Fonts .globl funkcja .section .progmem.data Fonts: .byte 1,2,3,4,5,6 .byte 11,22,33,44,55,66 .section .text .func funkcja funkcja: push r16 sbic PIND,PIND2 out PIOTR,r16 // dla #define PIOTR _SFR_IO8(0x1e) - błąd // dla #define PIOTR 0x1e - OK

pop r16 ret

Kurde! "wcięło" kropki przy dyrektywach

Piotrek

Reply to
Piotrek Sz.

Sun, 18 Dec 2005 10:42:01 +0100, na pl.misc.elektronika, Jacek M. napisał(a):

To jest normalne - wynika ze sposobu definiowania SFR. Rejestry IO są w nim traktowane jako obszar pamięci - bez offsetu 0x20, a assembler tego nie wie. Wstaw zamiast PIND _SFR_IO_ADDR(PIND) i powinno zadziałać. Alternatywny sposób to zdefiniowanie #define __SFR_OFFSET 0 na początku pliku ale autorzy avr-libc raczej nie zalecają. Wszelkie takie szczegóły w avr/include/avr/sfr_defs.h

Reply to
Jurek Szczesiul

Jurek Szczesiul snipped-for-privacy@wycin.ep.com.pl> napisał(a):

Z tego wynika , ze sposobów jest ... hoho ;) W ramach eksperymentu , wstawiłem sbic PIND -__SFR_OFFSET,PIND2 i też działa ;)

Dzięki

Reply to
Piotrek Sz.

W koncu doszedlem do wniosku, ze najlepiej bedzie jak przesymuluje projekt z plikiem asemblerowym i wtedy usune bledy. Chcialem uzyc do tego AVR Studio

  1. Projekt skompilowal sie bez bledow ale przy probie symulowania w pracy krokowej nie "wchodzi mi" do funkcji z pliku *.S. Projekt zawiera dwa pliki napisane dla GCC i jeden w asemblerze. Nie widze nic w ustawieniach co mogloby wymagac ustawienia by uruchomic to. Czy nie mozna symulatora uzywac do symulowania asemblera z GCC? Prosze o pomoc.

Jacek M.

Reply to
Jacek M.

Prosze o pomoc nie wiem jak przesymulowac plik asemblerowy w AVR Studio4. Caly projek kompiluje sie bez bledow ale tak jak pisalem wyzej w trakcie symulacji (praca krokowa) nie wchodzi mi (z mozliwoscia sledzenia) do pliku asemblerowego *.S. Wszystko jest kompilowane w GCC. Poszukiwanie w necie doprowadzily mnie instrukcji kompilacji i symulacji w takiej konfiguracji jak moja ale bez plikow pisanych w asemblerze. Pewnie jest ktos, kto ma juz za soba ten problem. Pozdrawiam

Jacek M.

Reply to
Jacek M.

Jacek M. snipped-for-privacy@poczta.onet.pl> napisał(a): ..

Opiszę łopatologicznie ;-) a)uruchom debugger b)wybierz menu->view->disassember c)uaktywnij myszką okno z kodem źródłowym *.c (lub menu->window->źródło.c) i klikaj "step over" d)jak dojedziesz do miejsca wywołania interesującej Cię funkcji , to uaktywnij myszką okienko disassembler(lub menu->window->disassembler) e)klikaj "step into" i .... podziwiaj , niestety nie będzie Twoje źródło *.s :(

Piotrek

Reply to
Piotrek Sz.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.