Znikająca zmienna globalna w programie na ATmega128 przy obsłudze przerwań

Thu Oct 15, 2009 2:44 pm   

Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hb790t$bbg$1@nemesis.news.neostrada.pl...


Dokladnie, a warunkowego uzylem moze trzy razy w zyciu - kwestia wprawy.

Thu Oct 15, 2009 2:45 pm   

To pisz tak dalej, przeciwskazań nie ma.
K.

Thu Oct 15, 2009 3:25 pm   

T.M.F. pisze:

Nie no, w MOIM rozwiązaniu kolejność łatwo zmienić i jest ona
"pewna", a w polach bitowych też łatwo zmienić, ale jest ona niepewna...


Poszukam gdzieś informacji, bo na pewno gdzieś to czytałem... ale czy to
było wiarygodne źródło, to nie wiem... ale tak swoją drogą, robisz
strukturę (zapis skrócony):
Pole1 : 3
Pole2 : 4
Pole3 : 6
Pole4 : 1
Pole5 : 2

Proc o dostępie do pamięci bajtowym... jak pamięć przydzieli
kompilator?? Jak wrzuci jak leci, to Pole3 będzie podzielone pomiędzy
dwa bajty?? Czy może najstarszy bit zostanie "pusty" i Pole3 zacznie się
od drugiego bajtu - wówczas całość zajmie 3 bajty... a może kompilator w
ten 1 wolny bit pierwszego bajtu wrzuci Pole4??

Pozdrawiam
Konop

Thu Oct 15, 2009 3:52 pm   

On 2009-10-15 16:25:30 +0200, Konop <konoppo@gazeta.pl> said:


man gcc

-mbit-align

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

Thu Oct 15, 2009 4:21 pm   

Adam Dybkowski wrote:


Raczej orginalny pytacz pomylil sie z wyborem zawodu.
Moja rada brzmi :
1. Albo pogodz sie z tematem i zwiaznymi z nim problemami czyli wez sie do
nauki
2. Albo daj sobie spokoj to jest nie dla Ciebie i mam to na mysli tworzenie
kodu jako takiego (bez wzgledu na jezyk) bo zawsze bedzi pod gorke i wiatr
w oczy

Thu Oct 15, 2009 7:11 pm   

Nie zaleca się korzystać z pól bitowych jeżeli soft ma być kompilowany pod
różnymi platformami gdyż standard NIE DEFINIUJE kolejności przypisania
bitów.

W niektórych sytuacjach jest to bardzo istotna przeszkoda.


Pozdrawiam
MiSter

Thu Oct 15, 2009 7:13 pm   

In the darkest hour on Thu, 15 Oct 2009 14:47:53 +0200,
T.M.F. <tmf@nospam.mp.pl> screamed:

Zależnie od architektury CPU i od kompilatora. Jeśli zapiszesz strukturę
z polem bitowym do pliku, taki plik nie będzie przenośny.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:214B ]
[ 20:12:08 user up 12226 days, 8:07, 1 user, load average: 0.30, 0.10, 0.54 ]

God: Darwin's chief rival.

Thu Oct 15, 2009 7:16 pm   

In the darkest hour on Wed, 14 Oct 2009 23:49:13 +0200,
Adam Dybkowski <adybkows12@45wp.pl> screamed:

Bez przesady znowu z tą wydajnością. Różnice nieistotne zwłaszcza
w przypadku programów z GUI. Dużo programów napisałem w Pythonie, dla
Ciebie pewnie taki program stoi w miejscu i ani piśnie...
A dlaczego w nim? Szybciej, zwięźlej, czytelniej, przenośniej.
Ale to już na jakieś advocacy.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:233B ]
[ 20:14:39 user up 12226 days, 8:09, 1 user, load average: 0.30, 0.10, 0.54 ]

It's here at last: We've released a 26-week project in 48 weeks.

Thu Oct 15, 2009 8:56 pm   

In the darkest hour on Wed, 14 Oct 2009 15:17:47 +0200,
Konop <konoppo@gazeta.pl> screamed:

Z punktu widzenia programisty piszącego program w C jest to jedynie
upierdliwe (mam tu na myśli tablice z const char *).


Zużywa na ARV niepotrzebnie RAM dla vtable w przypadku C++.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:227B ]
[ 21:54:16 user up 12226 days, 9:49, 1 user, load average: 0.30, 0.10, 0.54 ]

Death is life's way of telling you you've been fired.

Thu Oct 15, 2009 9:36 pm   

Użytkownik "Artur M. Piwko" <milusi.pysiaczek@buziaczek.pl> napisał w
wiadomości news:slrnhdepht.6fu.milusi.pysiaczek@buziaczek.pl...

Podobnie jak swobodny strumien swiadomosci jest slabo przenosny, ale
przeciez zdajemy sobie z tego sprawe, wiec bez przesady.

Thu Oct 15, 2009 9:41 pm   

W dniu 15.10.2009 20:11, MiSTER pisze:

Ale to jak sadze jest raczej kwestia big/little-endian.
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.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

Thu Oct 15, 2009 10:04 pm   

To akurat jest wada implementacji AVR w gcc i nie ma nic wspolnego z
typami - implementacja funkcji wirtualnych i pokrewnych tematow jest
calkowicie w gestii kompilatora. Nawet w jakims akcie desperacji
probowalem wygenerowac stosowny patch dla gcc ale ciagle umieram w
gaszczu kodu zrodlowego, poza tym w przyszlych wersjach ma to byc
poprawione.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

Fri Oct 16, 2009 7:31 am   

In the darkest hour on Thu, 15 Oct 2009 22:36:27 +0200,
Ghost <ghost@everywhere.pl> screamed:

Nie wszyscy sobie z tego zdają sprawę. Usenet to nie tylko Ty i ja.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:237B ]
[ 08:31:25 user up 12227 days, 20:26, 1 user, load average: 0.18, 0.04, 0.45 ]

Bigamy is having one wife too many. Monogamy is the same. -- Oscar Wilde

Fri Oct 16, 2009 10:49 am   

Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hb4gsl$bd$1@atlantis.news.neostrada.pl...

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.
P.G.

Fri Oct 16, 2009 12:24 pm   

T.M.F. wrote:


compiler:
typedef union {
unsigned short word;
#ifndef __GNUC__
struct
{
unsigned short :1; /* reserved */
unsigned short CodeAssertLine :13;
unsigned short EventOverflowTrigger :1;
unsigned short EventCodeAssertTrigger :1;
} bit;
#else
struct
{
unsigned short EventCodeAssertTrigger :1;
unsigned short EventOverflowTrigger :1;
unsigned short CodeAssertLine :13;
unsigned short :1; /* reserved */
} bit;
#endif

aczkolwiek GCC dostarcza makra __BIG_ENDIAN_BITFIELD oraz
__LITTLE_ENDIAN_BITFIELD informujace o ukladzie bitow w slowie

struct atapi_mechstat_header {
#if defined(__BIG_ENDIAN_BITFIELD)
__u8 fault : 1;
__u8 changer_state : 2;
__u8 curslot : 5;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 curslot : 5;
__u8 changer_state : 2;
__u8 fault : 1;
#else
#error "Please fix <asm/byteorder.h>"
#endif

#if defined(__BIG_ENDIAN_BITFIELD)
__u8 mech_state : 3;
__u8 door_open : 1;
__u8 reserved1 : 4;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 reserved1 : 4;
__u8 door_open : 1;
__u8 mech_state : 3;
#else
#error "Please fix <asm/byteorder.h>"
#endif

byte curlba[3];
byte nslots;
__u8 short slot_tablelen;
};


http://pl.wikipedia.org/wiki/Kolejność_bajtów


pola bitowe jak i slowa