Dlaczego ATmega128 przekłamuje?

Użytkownik "T.M.F." snipped-for-privacy@nospam.mp.pl> napisał w wiadomości news:hb9q8a$s99$ snipped-for-privacy@atlantis.news.neostrada.pl...

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.

Reply to
Piotr Gałka
Loading thread data ...

Użytkownik "Konop" snipped-for-privacy@gazeta.pl napisał w wiadomości news:hb9vjg$dls$ snipped-for-privacy@inews.gazeta.pl...

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.

Reply to
Piotr Gałka

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.

Reply to
T.M.F.

Użytkownik "T.M.F." snipped-for-privacy@nospam.mp.pl> napisał w wiadomości news:hba3mb$lvp$ snipped-for-privacy@nemesis.news.neostrada.pl...

Takie rzeczy robi sie gdy noz na gardle - trzeba zdazyc, a nie ma juz na czym zaoszczedzic.

Reply to
Ghost

Użytkownik "T.M.F." snipped-for-privacy@nospam.mp.pl> napisał w wiadomości news:hba3mb$lvp$ snipped-for-privacy@nemesis.news.neostrada.pl...

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.

Reply to
Piotr Gałka

Czepiając się :-) procedura nic nie zwraca, a funkcja to i owszem :-)

Pozdrawiam ELP

Reply to
ELP

Użytkownik "ELP" snipped-for-privacy@poczta.neostrada.pl> napisał w wiadomości news:op.u1ws3daazxema2@rafal...

W C procedury sa funkcjami, w SQL procedry zwracaja - ja trzepac to trzepac.

Reply to
Ghost

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

Reply to
Konop

W dniu 16.10.2009 23:26, Konop pisze:

To o flagach to z innej galezi tego watku, gdzie PG pisal o fladze Carry z rejestru stanu.

Reply to
T.M.F.

ELP pisze:

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).

Reply to
Adam Dybkowski

He, he. Ale włożyłem kij w mrowisko. Dyskusja na 100 fajerek. A tak wracając do początkowego problemu zamazywania flagi, zdaje się że znalazłem przyczynę. Pewne parametry pamiętane są w tablicy zadeklarowanej uchar parametr[8]; W ferworze poprawek w programie zaczął być używany nowy parametr któremu przydzielono komórkę parametr[8]; O powiększeniu tablicy do 9-ciu elementów niestety się zapomniało. Czyli typowe przekroczenie rozmiaru tablicy. Takie banalne. W jednej z początkowych operacji feralnej procedury było: parametr[8] = cos_tam; Jeżeli cos_tam było zerem, to pewnie kasowało feralną flagę, która sobie zamieszkała w tym miejscu. Czasami cuda i duchy są, ale teraz chyba jeszcze nie. Dziękuję wszystkim za chęć pomocy.

Reply to
Darkac

Użytkownik "Darkac" snipped-for-privacy@wp.pl napisał w wiadomości news:hbh4eh$o6a$ snipped-for-privacy@news.task.gda.pl...

Czyli tak jak pare osob wskazalo.

99,99% cudow to bledy programistow, byc moze ta liczba powinna byc wieksza.
Reply to
Ghost

Użytkownik "Ghost" snipped-for-privacy@everywhere.pl napisał w wiadomości news:hbhchd$58j$ snipped-for-privacy@news.onet.pl...

Jakby programista był chodzącym datascheetem to wartość ta znacznie by spadła.

A zresztą... prawdziwy programista wiesza się wraz ze swoim programem :) A jak się to ma do majkrosoftu?

Marek

Reply to
marko1a

Ten przywilej (wieszania się razem z programem) przerzucono na użytkowników. Nie czytałeś EULA? ;o)))

Reply to
DJ

Użytkownik "marko1a" snipped-for-privacy@lycos.de napisał w wiadomości news:hbhgto$qs4$ snipped-for-privacy@atlantis.news.neostrada.pl...

Dataszit dataszitem, tu bardziej chodzi o zapetlenie sie w mysleniu - jak cos nie kopnie czlowieka w głowe to nie ruszy z miejsca. Najtrudniejsza sytuacje maja goscie podatni na (auto)sugestie "to pewnie blad kompilatora, albo procesora" itp.

Reply to
Ghost

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.