[elektro] 8bit->32bit

[Móczik Gábor]

2013.05.08. 10:42 keltezéssel, Arnold Fuzesi írta:
> (Segito szandekot koszonom, ertekelem, de nem arra iranyult a kerdes, h mi a big es a little endian. Veszekedes ide vagy oda, a C bitfield bit sorrendnek nincs hivatalos koze az "endianess"-hez, es erre probaltam felhivni a figyelmet, nem veszekedesnek szantam....... )

Hát ha leteszel egy bitfield-et, arra unionnal egy multibyte változót, 
akkor a változó értéke függeni fog az endianness-től. Persze ha a 
compiler jófejségből megfordítja és a definiálttal átellenes sorrendben 
osztja ki a területet, akkor lehetne jó, de _szerintem_ ilyen nincs.

Ezzel az auto-forgatással jó nagyot lehetne szopni, ha teszel egymásra 
egy 32x bitfield, 2x uint16, 1x uint32 változót unionnal.

Nyugodtan maradhatsz abban, hogy procifüggő emellett még compiler függő is.

Ezek a bitfield deklarációk sajnos nem jók hw közeli programozásra, 
bármennyire is jól nézne ki a kód, már egy sima struct-tal is annyi a 
szívás, hogy netovább. (packed, nem packed, aligned, stb...)

Sajnos csak a bit buzerálós makró a biztos.

#define RELAY1    0x80
#define RELAY2    0x40
...

#define SET_RELAY(rly)  (port_latch |= rly)
#define CLR_RELAY(rly)  (port_latch &= rly^0xFF)

Általános célú újrafelhasználásra tervezett (pl. kijelző) hardver 
drivert pedig úgy szoktam írni, hogy:

#define LCD_INIT_CS  ... // port adatirány, stb. beállítás
#define LCD_SET_CS   ... // CS bit beállítása
#define LCD_CLR_CS   ... // CS bit törlése

és a driverben ezeket a makrókat hívom.

A sokak által használt megoldás:
#define LCD_CS_TRIS_BIT ...
#define LCD_CS_LAT_BIT  ...

Az előbbi esetén akár SPI portbővítőre, osztott adatbuszra, akármire 
kötheted, majd definiálod a projekthez a hw környezetet, az utóbbi 
esetben meg ha nem portbitre kötötted, vagy esetleg invertált egy bit, 
akkor szopó van. Nem beszélve arról, hogy komolyabb procin (pl. ARM) pl. 
van bit set, bit clear regiszter, a fentivel esetleg optimálisabb vagy 
jobban optimalizálható kódot lehet írni.