bitfield v avr-gcc

[Jan Waclawek]

Jasne. Dakujem.

Takto to samozrejme ide a som to tusim aj spomenul, ze si take nieco mozem napisat aj sam. Aj ked je otazne, ci nieco, co sa ponuka ako pomerne prirodzene rozsirenie samotneho jazyka, ma zmysel riesit externe (toto je ciste filozoficka otazka, jej prakticke rozuzlenie je jasne, hrabat sa v gcc je v priamom protiklade s potrebou zarobit si na ten chlieb kazdodenny). 

Povodna moja otazka vsak bola, ci nieco take neexistuje - mohol som to prehliadnut, gcc je mamut a dokumentacia je derava.

Tie bitfieldy by som apriori nezavrhoval - maju nico do seba, ale to je na dlhsiu debatu. Tiez by som sa snazil vyhnut nejakym rozsiahlym automaticky generovanym funkciam, davam prednost tabulkam; ale to je asi pozostatok z asemblerovania, proste stale mam nutkanie setrit miestom.

wek

PS. Nerozumiem, ako to myslite to "hore kokotom"? Napisal som nieco nevhodne?


----- Original Message ---------------
>No, tak ja budem tiez pisat hore kokotom... <g>
>
>bity.def
>---
>motor1
>motor2
>motor3
>heblo1
>heblo2
>---
>
>z toho si udelam header.h
>----
>//do not edit
>extern DWORD g_adwFlags[ 1 ];
>#define MAX_BITS 5
>
>#define LOCAL_SET_MOTOR1 ( g_adwFlags |= 1 )
>#define LOCAL_SET_MOTOR2 ( g_adwFlags |= 2 )
>.
>.
>.
>
>#define REMOTE_SET_MOTOR1 SendPacket( 1, SET )
>#define REMOTE_SET_MOTOR2 SendPacket( 2, SET )
>.
>.
>.
>---
>
>RecvPacket pak uz bude delat jen nejaky g_adwFlags[ iOffs / 32 ] |= 1 << ( iOffs 
>% 32 );