NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Znikająca zmienna globalna w programie na ATmega128 przy obsłudze przerwań
Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next
T.M.F.
Guest
Guest
Fri Oct 16, 2009 12:32 pm
Quote:
Przepraszam, że się odzywam w temacie na którym się kompletnie nie znam.
Na temat flag w postaci bitów w bajtach w AVR omawianych w kursie C na
AVR w EP usłyszałem przed kilku laty mniej więcej taką wypowiedź:
"Jak można podawać takie przykłady! Przecież trzeba znać maszynę, na
której program będzie chodził. Widać, że ktoś bezmyślnie przepisał
przykład z 51 na AVR. Potem ludzie tak napiszą i mamy to co mamy."
Z tego co pamiętam to chodziło o to, że przestawienie bitu w bajcie na
AVR wymaga więcej niż jednego rozkazu. No i w przykładzie przyjście
przerwania miedzy tymi rozkazami prowadziło do błędu.
Liczę na to, że ktoś piszący na AVR wypowie się na ten temat (bo nawet
nie jestem pewien, czy te pretensje były uzasadnione).
Z przebiegu wątku wygląda, że jego autor być może powstawia flagi do
bajtów co być może doprowadzi do nowych błędów.
No i chęć zapobiegnięcia temu skłoniła mnie do tej dość mętnej wypowiedzi.
Na temat flag w postaci bitów w bajtach w AVR omawianych w kursie C na
AVR w EP usłyszałem przed kilku laty mniej więcej taką wypowiedź:
"Jak można podawać takie przykłady! Przecież trzeba znać maszynę, na
której program będzie chodził. Widać, że ktoś bezmyślnie przepisał
przykład z 51 na AVR. Potem ludzie tak napiszą i mamy to co mamy."
Z tego co pamiętam to chodziło o to, że przestawienie bitu w bajcie na
AVR wymaga więcej niż jednego rozkazu. No i w przykładzie przyjście
przerwania miedzy tymi rozkazami prowadziło do błędu.
Liczę na to, że ktoś piszący na AVR wypowie się na ten temat (bo nawet
nie jestem pewien, czy te pretensje były uzasadnione).
Z przebiegu wątku wygląda, że jego autor być może powstawia flagi do
bajtów co być może doprowadzi do nowych błędów.
No i chęć zapobiegnięcia temu skłoniła mnie do tej dość mętnej wypowiedzi.
AVR ma pewne wydzielone obszary pamieci na ktorych dzialaja instrukcje
umozliwiajace atomowe ustawienie lub wyzerowanie bitu, tylko, ze nie
mozna tego zrobic w SRAM, tylko w niektorych rejestrach IO. Niektore
AVRy maja w tej przestrzeni rejestry, ktore nie maja zadnej funkcji,
poza wlasnie przechowywaniem flag. Wiec da sie to zrobic atomowo, tyle,
ze to juz nie jest standardowe C.
--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.
T.M.F.
Guest
Guest
Fri Oct 16, 2009 12:40 pm
W dniu 16.10.2009 13:24, cepu69 pisze:
Quote:
Ale to jak sadze jest raczej kwestia big/little-endian.
Nie endian mowi o kolejnosi bajtow w slowie :
http://pl.wikipedia.org/wiki/Kolejność_bajtów
Nie endian mowi o kolejnosi bajtow w slowie :
http://pl.wikipedia.org/wiki/Kolejność_bajtów
Dokladnie, a to w przypadku pol bitowych o dlugosci wiekszej niz bajt
powoduje, ze np. bity 8-15 moga byc przed lub za bitami 0-7. Natomiast w
ramach bajtu kolejnosc bedzie zachowana i w konsekwencji w programie
rowniez.
Quote:
Dla programu nie ma to znaczenia - o ile wlasnie nie przenosze pomiedzy
architekturami danych wygenerowanych na innej. Bo w samym programie
odwolanie do pola struktury zawsze bedzie jednoznaczne.
Oczywiscie dopoki nie jest to unia i odwolujesz sie do niej zarowno przez
pola bitowe jak i slowa;)
architekturami danych wygenerowanych na innej. Bo w samym programie
odwolanie do pola struktury zawsze bedzie jednoznaczne.
Oczywiscie dopoki nie jest to unia i odwolujesz sie do niej zarowno przez
pola bitowe jak i slowa;)
Owszem, zawsze znajdziesz przyklad, ktory cos zamiesza. Z tym, ze jesli
to bedzie unia pola bitowego i slowa to endian nie ma znaczenia - wplywa
tak samo na kolejnosc przechowywania bitow jak i kolejnosc
przechowywania bajtow w slowie. Gorzej, gdybys mial unie pola bitowego i
bajtow - tu juz by powstalo zamieszanie. Z drugiej strony sa biblioteki
standardowe umozliwiajace rozwiazanie tego typu problemow. Poza tym o
czym dyskutowac - programowanie nie jest dla idiotow i ktos kto robi
takie rzeczy musi sobie zdawac sprawe z konsekwencji.
Standard C definiuje kolejnosc bitow pola bitowego, co wiecej uzycie
pola bitowego :0 wyrownuje kolejne do granicy okreslanej przez design
procesora.
--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.
Piotr Gałka
Guest
Guest
Fri Oct 16, 2009 12:58 pm
Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hb9lor$hs6$1@atlantis.news.neostrada.pl...
Quote:
AVR ma pewne wydzielone obszary pamieci na ktorych dzialaja instrukcje
umozliwiajace atomowe ustawienie lub wyzerowanie bitu, tylko, ze nie mozna
tego zrobic w SRAM, tylko w niektorych rejestrach IO. Niektore AVRy maja w
tej przestrzeni rejestry, ktore nie maja zadnej funkcji, poza wlasnie
przechowywaniem flag. Wiec da sie to zrobic atomowo, tyle, ze to juz nie
jest standardowe C.
umozliwiajace atomowe ustawienie lub wyzerowanie bitu, tylko, ze nie mozna
tego zrobic w SRAM, tylko w niektorych rejestrach IO. Niektore AVRy maja w
tej przestrzeni rejestry, ktore nie maja zadnej funkcji, poza wlasnie
przechowywaniem flag. Wiec da sie to zrobic atomowo, tyle, ze to juz nie
jest standardowe C.
A da się atomowo zapamiętać w bicie flagę przeniesienia, zrobić and czy or
bitu z tą flagą czy odwrócić bit rejestru, bo to mogło też o takie rzeczy
chodzić ?
P.G.
T.M.F.
Guest
Guest
Fri Oct 16, 2009 1:49 pm
Quote:
AVR ma pewne wydzielone obszary pamieci na ktorych dzialaja instrukcje
umozliwiajace atomowe ustawienie lub wyzerowanie bitu, tylko, ze nie
mozna tego zrobic w SRAM, tylko w niektorych rejestrach IO. Niektore
AVRy maja w tej przestrzeni rejestry, ktore nie maja zadnej funkcji,
poza wlasnie przechowywaniem flag. Wiec da sie to zrobic atomowo,
tyle, ze to juz nie jest standardowe C.
A da się atomowo zapamiętać w bicie flagę przeniesienia, zrobić and czy
or bitu z tą flagą czy odwrócić bit rejestru, bo to mogło też o takie
rzeczy chodzić ?
umozliwiajace atomowe ustawienie lub wyzerowanie bitu, tylko, ze nie
mozna tego zrobic w SRAM, tylko w niektorych rejestrach IO. Niektore
AVRy maja w tej przestrzeni rejestry, ktore nie maja zadnej funkcji,
poza wlasnie przechowywaniem flag. Wiec da sie to zrobic atomowo,
tyle, ze to juz nie jest standardowe C.
A da się atomowo zapamiętać w bicie flagę przeniesienia, zrobić and czy
or bitu z tą flagą czy odwrócić bit rejestru, bo to mogło też o takie
rzeczy chodzić ?
Da sie zapamietac przeniesienie atomowo w szczegolnych przypadkach -
stosujac operacje przesuniecia z przeniesieniem, lub dodawania,
odejmowania - to jak w kazdym procesorze.
Co do OR, AND, XOR flagi C z innym rejestrem to sie nie da atomowo.
Znaczy XOR to by sie nawet dalo, z zastrzezeniem, ze w szczegolnych
przypadkach.
Nie pamietam assemblera '51, ale tam takie operacje jak sadze tez nie sa
atomowe? Zreszta nawet jesli sa to pisanie takich rzeczy w C wcale nie
gwarantuje, ze kompilator to skompiluje zgodnie z intencja autora.
Chociazby stopien optymalizacji bedzie mial wplyw na koncowa sekwencje
rozkazow.
--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.
Konop
Guest
Guest
Fri Oct 16, 2009 3:22 pm
Quote:
Z tego co pamiętam to chodziło o to, że przestawienie bitu w bajcie na
AVR wymaga więcej niż jednego rozkazu. No i w przykładzie przyjście
przerwania miedzy tymi rozkazami prowadziło do błędu.
AVR wymaga więcej niż jednego rozkazu. No i w przykładzie przyjście
przerwania miedzy tymi rozkazami prowadziło do błędu.
Niekoniecznie prowadzi do błędu... wszystko zależy od tego, co się z tym
rejestrem w międzyczasie stanie... Typowo ustawianie bitu w jakiejś
zmiennej (która siedzi w RAMie) wygląda tak:
-pobieranie zmiennej do rejestru
-operacja na rejestrze
-zapis zmiennej do RAMu
Jeśli po pobraniu i przed zapisaniem wystąpi przerwanie, które ZMIENI tę
zmienną, wówczas po powrocie z przerwania program główny skasuje zmianę
dokonaną w przerwaniu...
Pisząc program trzeba uważać na takie rzeczy
... czasem taka sytuacja
jest po prostu niegroźna. W innym wypadku trzeba rozdzielić zmienne
aktualizowane w programie od tych aktualizowanych w przerwaniach, albo
stosować CLI i SEI
...
Pozdrawiam
Konop
Piotr Gałka
Guest
Guest
Fri Oct 16, 2009 3:24 pm
Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hb9q8a$s99$1@atlantis.news.neostrada.pl...
Quote:
Nie pamietam assemblera '51, ale tam takie operacje jak sadze tez nie sa
atomowe? Zreszta nawet jesli sa to pisanie takich rzeczy w C wcale nie
gwarantuje, ze kompilator to skompiluje zgodnie z intencja autora.
Chociazby stopien optymalizacji bedzie mial wplyw na koncowa sekwencje
rozkazow.
atomowe? Zreszta nawet jesli sa to pisanie takich rzeczy w C wcale nie
gwarantuje, ze kompilator to skompiluje zgodnie z intencja autora.
Chociazby stopien optymalizacji bedzie mial wplyw na koncowa sekwencje
rozkazow.
Sprawdziłem. Niektóre są: CPL bit; MOV bit,C.
Nic więcej nie wiem, poza tym, co napisałem - że gdzieś dzwoni.
Rozumiałem, że program główny robił jakąś operację na jednej fladze bitowej
wymagającą dwu rozkazów (może ją negował), a przerwanie pisało na inną flagę
w tym samym bajcie, co podobno na 51 jest OK, a na AVR nie da się.
P.G.
Piotr Gałka
Guest
Guest
Fri Oct 16, 2009 3:39 pm
Użytkownik "Konop" <konoppo@gazeta.pl> napisał w wiadomości
news:hb9vjg$dls$1@inews.gazeta.pl...
Quote:
Pisząc program trzeba uważać na takie rzeczy ... czasem taka sytuacja
jest po prostu niegroźna. W innym wypadku trzeba rozdzielić zmienne
aktualizowane w programie od tych aktualizowanych w przerwaniach, albo
stosować CLI i SEI...
Czyli jest rozwiązanie.
... czasem taka sytuacja
jest po prostu niegroźna. W innym wypadku trzeba rozdzielić zmienne
aktualizowane w programie od tych aktualizowanych w przerwaniach, albo
stosować CLI i SEI
...
Czyli jest rozwiązanie.
Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
program.
P.G.
T.M.F.
Guest
Guest
Fri Oct 16, 2009 4:22 pm
Quote:
Czyli jest rozwiązanie.
Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
program.
Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
program.
Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
wcale nie musi tego zamienic na jedna instrukcje.
--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.
Ghost
Guest
Guest
Fri Oct 16, 2009 4:31 pm
Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hba3mb$lvp$1@nemesis.news.neostrada.pl...
Quote:
Czyli jest rozwiązanie.
Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
program.
Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
wcale nie musi tego zamienic na jedna instrukcje.
Jeśli kompilatory wykrywają taką sytuację (co wydaje się logiczne) i
otaczają modyfikację wykonaną w programie głównym przez CLI, SEI to
rozumiem, że można sobie swobodnie łączyć flagi i krytykowanie tamtego
przykładu było bezpodstawne. Jedyny problem to nieco mniej optymalny
program.
Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
wcale nie musi tego zamienic na jedna instrukcje.
Takie rzeczy robi sie gdy noz na gardle - trzeba zdazyc, a nie ma juz na
czym zaoszczedzic.
Piotr Gałka
Guest
Guest
Fri Oct 16, 2009 4:33 pm
Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hba3mb$lvp$1@nemesis.news.neostrada.pl...
Quote:
Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora)
Tego nie twierdziłem.
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora)
Tego nie twierdziłem.
Najpierw myślałem tylko o fagach bitowych w danych.
Potem jak była informacja, że są takie rejestry, w których się da atomowo,
to pomyślałem, że może tam były jakieś inne operacje.
Ja tego nie czytałem, tylko słyszałem krytykę przykładu i było to kilka lat
temu, a sam nic na procesory nie piszę.
P.G.
ELP
Guest
Guest
Fri Oct 16, 2009 9:12 pm
Quote:
A zwraca procedura powinna tylko char lub int syknalizujcego OK lub
Czepiając się
procedura nic nie zwraca, a funkcja to i owszem :-)
Pozdrawiam
ELP
Ghost
Guest
Guest
Fri Oct 16, 2009 10:08 pm
Użytkownik "ELP" <elp@poczta.neostrada.pl> napisał w wiadomości
news:op.u1ws3daazxema2@rafal...
Quote:
A zwraca procedura powinna tylko char lub int syknalizujcego OK lub
Czepiając się procedura nic nie zwraca, a funkcja to i owszem
Czepiając się
procedura nic nie zwraca, a funkcja to i owszem
W C procedury sa funkcjami, w SQL procedry zwracaja - ja trzepac to trzepac.
Konop
Guest
Guest
Fri Oct 16, 2009 10:26 pm
Quote:
Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi o
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
wcale nie musi tego zamienic na jedna instrukcje.
to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w C
(swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki blok
wcale nie musi tego zamienic na jedna instrukcje.
No ale wydaje mi się, że informacja o "dobieraniu się" do rejestru FLAG
jest małą dezinformacją... chodziło o flagi "własne", trzymane w jakiś
zmiennych
...
Pozdrawiam
Konop
T.M.F.
Guest
Guest
Sat Oct 17, 2009 11:25 am
W dniu 16.10.2009 23:26, Konop pisze:
Quote:
Tylko, ze kompilatory nie wykrywaja takiej sytuacji i programista musi
o to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w
C (swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki
blok wcale nie musi tego zamienic na jedna instrukcje.
No ale wydaje mi się, że informacja o "dobieraniu się" do rejestru FLAG
jest małą dezinformacją... chodziło o flagi "własne", trzymane w jakiś
zmiennych...
o to zadbac sam. W avr-gcc libc jest stosowne makro - ATOMIC_BLOCK.
Ja sie jednak bede upieral przy tym, ze jesli ktos robil takie cuda w
C (swoja droga ciekawe jak w C dobral sie do flag i rejestru stanu
procesora) to sam sie prosi o problemy - kompilator kompilujac taki
blok wcale nie musi tego zamienic na jedna instrukcje.
No ale wydaje mi się, że informacja o "dobieraniu się" do rejestru FLAG
jest małą dezinformacją... chodziło o flagi "własne", trzymane w jakiś
zmiennych
...
To o flagach to z innej galezi tego watku, gdzie PG pisal o fladze Carry
z rejestru stanu.
--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.
Adam Dybkowski
Guest
Guest
Sat Oct 17, 2009 11:50 pm
ELP pisze:
Quote:
A zwraca procedura powinna tylko char lub int syknalizujcego OK lub
Czepiając się procedura nic nie zwraca, a funkcja to i owszem
Czepiając się
procedura nic nie zwraca, a funkcja to i owszem
Tak to paaanie było w Pascalu. W C++ w klasach to nawet nie są funkcje
tylko metody. I mogą coś zwracać albo nie. A w zwykłym C wszystko o czym
mowa to funkcje. Tyle że niektóre zwracają daną typu void (podobnie jak
niektórych jedyny argument jest typu void, a czasem wiele argumentów
jest wskazaniami na typ void i nikt z tego powodu nie płacze).
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
elektroda NewsGroups Forum Index - Elektronika Polska - Znikająca zmienna globalna w programie na ATmega128 przy obsłudze przerwań