[C] Werken met een byte

[Wokker]

Voor een school project moeten we programeren op een microcontroller (een pic 16). Nu moeten we ook iets met data oversturen doen.Hier moet een start en een stop frame aangeplakt worden dat is niet zo'n probleem. Maar nu moet over de data ook een bit stuffing functie gehaald worden (hier meer info over bitstuffing www.phys.uu.nl/~wwwfi/education/csn_college/lesg4 ) Bij bitstuffing moet na elke 5 enen (in ons geval) een nul toegevoegd worden. Hier zit het probleem via een tcp-ip krijgen we byte binnnen maar hoe kan ik werken met een BYTE kan het net als een string behandelen (iederen teken staat in een soort array) of niet. Over alle ander data types is genoeg te vinden maar over het type BYTE vind ik niks.
Ik hoop dat iemand mij kan helpen
Alvast bedankt 1

[.oisyn]

unsigned char.

[farlane]

Maw je kunt met een char doen wat met een integer ook kunt doen, je hebt doorgaans wat minder bits tot je beschikking.

[Verwijderd]

.oisyn schreef op donderdag 24 november 2005 @ 13:51:
unsigned char.

wat bedoel je ?

[NMe]

Verwijderd schreef op donderdag 24 november 2005 @ 22:26:
wat bedoel je ?

Dat een byte (8-bits integer) gelijk is aan een unsigned char, die ook 8-bits is?

[.oisyn]

Verwijderd schreef op donderdag 24 november 2005 @ 22:26:
[...]

wat bedoel je ?

lees de documentatie anders even?

[Lethalis]

Verwijderd schreef op donderdag 24 november 2005 @ 22:26:
[...]

wat bedoel je ?

Een unsigned char is ideaal, omdat:
- hij is unsigned, dus je hebt alle bits tot je beschikking
- hij is 8 bits, dus even groot als een byte
- hij is even groot op alle platformen

Daarnaast is een BYTE gewoon een unsigned char (typedef)

[ Voor 9% gewijzigd door Lethalis op 25-11-2005 11:16 ]

[.oisyn]

Overigens is hij niet even groot op alle platformen, maar wel op de de meeste idd

[Lethalis]

.oisyn schreef op vrijdag 25 november 2005 @ 11:27:
Overigens is hij niet even groot op alle platformen, maar wel op de de meeste idd

Voorbeeld?

[.oisyn]

Tja, er bestaat vast nog wel ergens een vaag 7 bit platform oid. Punt is dat de standaard niet zegt dat een char 8 bits moet zijn, maar dat dat implementation-defined is (en daarvoor heb je de constante CHAR_BIT)

quote: http://www.kuzbass.ru/docs/isocpp/intro.html#intro.memory

1.7 - The C++ memory model

-1- The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set and is composed of a contiguous sequence of bits, the number of which is implementation-defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. The memory available to a C++ program consists of one or more sequences of contiguous bytes. Every byte has a unique address.

[ Voor 60% gewijzigd door .oisyn op 25-11-2005 11:42 ]

[farlane]

Lethalis schreef op vrijdag 25 november 2005 @ 11:36:
[...]

Voorbeeld?

Vooral ouwe meuk, bepaalde VAX'en, meende sommige PDP systemen ook
[

[Kayshin]

Heb ik net ook een vak in gekregen
Wij moeten werken met een unsigned char. In C kun je deze HEX vullen (0x04,0xA3) en wordt dit binair opgeslagen. Ook kun je deze dingen mooi bitmasken (Ja, meteen mn nieuwe kennis in de strijd gooien )

[triet]

Binair opgeslagen? Eh, ja, in een chip wordt alles binair opgeslagen Maar ook op een (unsigned) int/long of wat dan ook kan je bitwise operators op loslaten hoor.

[Daos]

En weer ontopic:
De mogelijkheden zijn:
1) Je kan je input van bytes omzetten naar een string met 0 en 1. Met die string doe je iets en het resultaat zet je weer om in bytes. In Java is dit simpel, maar in C niet. Het gaat bovendien traag.

2) Je maakt een paar hulpfuncties voor het werken met bits en bytes. Het is handig om een functie te maken die een bit uit een byte haalt en het is ook handig om een functie te maken die van groepjes bits (maximaal 8 per groepje) weer bytes maakt en die verstuurt als ze vol zitten.

Je kan met de eerste functie de enen tellen terwijl je bytes leest. Als je dan 5 enen hebt, dan gebruikt je de tweede functie om een deel van de huidige byte te versturen en vervolgens een 0 te versturen. Aan het eind van de huidige byte gebruikt je de tweede functie weer voor het verzenden van de rest van de byte. Na het verwerken van alle input moet je niet vergeten de half afgemaakte byte (die je in een globale variabele hebt gestopt) te flushen.

Dit is prima te doen in C.

[Edit]
Het werken met bits binnen een byte doe je met de operators die voor bitjes zijn gemaakt. Deze zijn:
~, >>, <<, |, ^, en &. Zoek in een boek op wat deze doen.
De & wordt meestal gebruikt om een groepje bits te selecteren, | om deze op een (lege) plek te zetten, << en >> wordt gebruikt om de bitjes te verplaatsen naar de juiste positie.
Neem bv X = xxx1010x (met x is 0 of 1). Stel je wil die 1010 hebben en dit daarna ook nog wegstoppen in Y = y1010yyy, dan doe je dat zo:

C:

tmp = X >> 1;
stukje = tmp & 15; /* 15 DEC = 1111 BIN */
tmp = stukje << 3;
Y = Y | tmp;

dat is hetzelfde als:

C:

stukje = X >> 1 & 15;
Y |= stukje << 3;

Als je dat stukje verder niet nodig hebt, dan kan het ook zo:

C:

Y |= (X & 30) << 2;

[ Voor 31% gewijzigd door Daos op 25-11-2005 18:21 ]

[MSalters]

.oisyn schreef op vrijdag 25 november 2005 @ 11:40:
Tja, er bestaat vast nog wel ergens een vaag 7 bit platform oid. Punt is dat de standaard niet zegt dat een char 8 bits moet zijn, maar dat dat implementation-defined is (en daarvoor heb je de constante CHAR_BIT)
[...]

7 bits platforms zullen een CHAR_BIT van 14 hebben, want het minimum is 8. Gangbaarder is 16 of 32. Dat komt namelijk op DSPs voor.

[Zoijar]

Hier zijn al zo veel topics over geweest... antieke architecturen met 11 bit bytes en 14 bit characters oid, dat soort dingen

[Wokker]

Daos schreef op vrijdag 25 november 2005 @ 17:56:
Hoop leerzame blabla

Waar heb je deze wijsheid vandaan? er is veel over te vinden maar het meest is erg summier hellaas

[ Voor 82% gewijzigd door Wokker op 01-12-2005 12:55 ]

[.oisyn]

MSalters schreef op vrijdag 25 november 2005 @ 22:31:
[...]

7 bits platforms zullen een CHAR_BIT van 14 hebben, want het minimum is 8. Gangbaarder is 16 of 32. Dat komt namelijk op DSPs voor.

Waarom staan dat soort dingen eigenlijk niet in de standard specification?

[Daos]

Wokker schreef op donderdag 01 december 2005 @ 12:40:
[...]

Waar heb je deze wijsheid vandaan? er is veel over te vinden maar het meest is erg summier hellaas

Het stelt allemaal niet zo veel voor. Het enige dat je moet weten is wat de operators doen en hoe de bitjes in een byte zitten.

Als je een byte hebt en je wilt kijken wat de bit is op positie 5 (7 6 5 4 3 2 1 0) dan doe je dat zo:
Je begint bijvoorbeeld met 01101001. Als je dit 5 plaatsen naar rechts schuift, dan staat het bitje dat je wilt hebben op positie 0 (00000011). Er staat nu nog wat troep bij de andere bitjes. Als je alleen bitje (op positie) 0 wilt overhouden, dan doe je & met 00000001. De 0-en in 00000001 zorgen ervoor dat de bitjes op die plaatsen 0 wordt (x And false is altijd false). De 1 in 00000001 zorgt ervoor dat je dat bitje overhoudt (x And true is altijd x).

In C ziet dit er zo uit:

C:

data = 0x69;
temp = data >> 5; 
bitje = tmp & 0x01;

Als je de data en de positie variabel maakt dan kan je het bijvoorbeeld zo in een functie stoppen:

C:

typedef unsigned char byte;
typedef unsigned char bit;

bit getbit(byte data, byte pos) {
    return data >> pos & 1;
}

Dat is dan al de eerste hulpfunctie waar ik het in mijn vorige bericht over had.


De tweede hulpfunctie waar ik het over had is een functie die van groepje bits bytes maakt.
Voorbeeld: "010", "1110", "10110", "1", "011" => "01011101", "01101011"

Om dit te doen heb je een globale variabele nodig waarin je de groepjes verzameld. Het beste kan je een variabele nemen van 16 bits (je kan dan eerst een nieuw groepje erbij doen voordat je een volle byte verstuurt). Ook moet je het aantal bits bijhouden in een globale variabele.

Wat je moet doen is:
Als er een nieuw groepje bijkomt, dan maak je ruimte in die 16 bits en zet je het nieuwe groepje bij de laagste positie.
en
Als het totaal aantal bits 8 of meer is, dan verstuur je een byte.

Het wordt dus zoiets:

C:

unsigned remdata = 0;
byte remcount = 0;

void sendbits(byte data, byte count) {
    /* stop data in remdata */

    if (remcount >= 8) {
        /* verstuur byte */
    }
}

Waar commentaar staat moet je zelf wat bedenken. Als je problemen hebt of als je niet zeker weet of je het goed hebt dan kan je dat in dit topic melden.

Veel succes...


Nb.
Vergeet ook niet een flush te maken voor als je klaar bent met je bitstuffing. Er kunnen namelijk nog bits in die remdata blijven staan.

[igmar]

.oisyn schreef op vrijdag 25 november 2005 @ 11:40:
Tja, er bestaat vast nog wel ergens een vaag 7 bit platform oid. Punt is dat de standaard niet zegt dat een char 8 bits moet zijn, maar dat dat implementation-defined is (en daarvoor heb je de constante CHAR_BIT)

sizeof(char) is altijd 1, zonder uitzonderingen. Zie daarvoor C FAQ

Voor alle overige type verschilt het per platform.

De meeste compiler, en de C standaard gaan er vanuit dat een machine byte-addressable is, en da's eigenlijk ook altijd het geval. Uitzonderingen zijn wat antieke hardware, en DSP's, die over het algemeen bit-addressable zijn. Dit is eigenlijk ook de reden waarom GCC (praktisch) geen DSP ports heeft.

[.oisyn]

igmar schreef op vrijdag 02 december 2005 @ 11:36:
[...]


sizeof(char) is altijd 1, zonder uitzonderingen. Zie daarvoor C FAQ

DUH, sizeof(T) geeft het aantal chars dat in T past. Nogal wiedus dat het voor char dus 1 is. Dat zegt echter niets over de bitsize van char, dat simpelweg het kleinst adresseerbare element is

[igmar]

.oisyn schreef op vrijdag 02 december 2005 @ 11:58:
DUH, sizeof(T) geeft het aantal chars dat in T past. Nogal wiedus dat het voor char dus 1 is. Dat zegt echter niets over de bitsize van char, dat simpelweg het kleinst adresseerbare element is

C++ : inderdaad, maar het topic gaat over C, en de standaard daarvan zegt simpelweg dat een char iets is met 8 bits. Ook in C++ is een byte minimaal 8 bits.

Ik gebruikte op Solaris altijd http://docs.sun.com/source/806-3567/data.represent.html als leidraad.

[.oisyn]

Ten eerste was de opmerking die je net maakte geen argumentatie tegen de opmerking van mij die je in die post quootte (sizeof heeft niets met bitsize te maken)

Ten tweede is dat CHAR_BIT minstens 8 bits is idd correct, maar dat was al opgemerkt door MSalters

Ten derde is CHAR_BIT niet altijd 8:

quote: http://www.sics.se/~pd/ISO-C-FDIS.1999-04.pdf

5.2.4.2.1 Sizes of integer types <limits.h>

The values given below shall be replaced by constant expressions suitable for use in #if
preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the
following shall be replaced by expressions that have the same type as would an
expression that is an object of the corresponding type converted according to the integer
promotions. Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8

Heb het belangrijkste deel even bold gemaakt. De docs die jij quote gaan over het solaris platform, nogal logisch dat de implementation-defined values daarvoor vast staan

[igmar]

.oisyn schreef op vrijdag 02 december 2005 @ 15:02:
Ten eerste was de opmerking die je net maakte geen argumentatie tegen de opmerking van mij die je in die post quootte (sizeof heeft niets met bitsize te maken)

Inderdaad, ik haalde wat zaken door elkaar.

Ten tweede is dat CHAR_BIT minstens 8 bits is idd correct, maar dat was al opgemerkt door MSalters

Ten derde is CHAR_BIT niet altijd 8:

Heb het belangrijkste deel even bold gemaakt. De docs die jij quote gaan over het solaris platform, nogal logisch dat de implementation-defined values daarvoor vast staan

Iets anders als 8 is AFAIK exotisch, en kom je zelden tegen. Ik hou er zelf echter nooit rekening mee dat een byte != 8 bits. Waarom de standaard alleen minimun waarden voor bitsizes hanteert is mij een raadsel.

[Elijan9]

Lethalis schreef op vrijdag 25 november 2005 @ 11:36:
[...]

Voorbeeld?

[spuit 11 mode, maar wel relevant]
Een goed voorbeeld is de PIC die de TS nu net gebruikt, maar dan niet in data maar in code geheugen... Daar is de grootte in sommige gevallen 12 bits. Deze is alleen bij de (meeste?) PIC "microcontrollers" niet benaderbaar.
(Voor data is de grootte van een byte wel 8 bits en die is dus relevant.)
[/spuit 11 mode]

Overigens ken ik nog geen (echte) C-compiler voor de PIC, alleen maar interpreters die een "C" achtige macro taal kennen. Maar het komt wel in de buurt van C, dus het meeste is wel van toepassing, maar voor wat betreft int-sizes e.d. kun je nergens zomaar van uit te gaan Dat is ook nog eens PIC-model afhankelijk.

Met ANSI/ISO standaarden hoef je in elk geval niet elkaar om de oren te slaan als het om een PIC gaat Het is mijns inziens niet eens een microcontroller, eerder een nanocontroller of iets dergelijks... Één globale 16 bits variable, en je hebt bijna geen globaal geheugen meer vrij, zo erg bijna...

[ Voor 3% gewijzigd door Elijan9 op 02-12-2005 16:30 . Reden: *sommige* PIC hebben 12 bits code ]

[.oisyn]

igmar schreef op vrijdag 02 december 2005 @ 16:24:
Iets anders als 8 is AFAIK exotisch, en kom je zelden tegen. Ik hou er zelf echter nooit rekening mee dat een byte != 8 bits. Waarom de standaard alleen minimun waarden voor bitsizes hanteert is mij een raadsel.

Ik ben het overigens met je eens dat het vandaag de dag nogal onzin is om een byte ongelijk aan 8 bits (of een veelvoud daarvan) te stellen

[ Voor 3% gewijzigd door .oisyn op 02-12-2005 16:32 ]

[Soultaker]

igmar schreef op vrijdag 02 december 2005 @ 16:24:
Iets anders als 8 is AFAIK exotisch, en kom je zelden tegen. Ik hou er zelf echter nooit rekening mee dat een byte != 8 bits. Waarom de standaard alleen minimum waarden voor bitsizes hanteert is mij een raadsel.

Heb je wel eens embedded software geschreven in C? Er zijn zat microcontrollers die geen byte-addressering ondersteunen en/of geen byte-size registers hebben. Hoewel je een aantal eigenschappen van 8-bits bytes dan wel kunt emuleren met wat kunstgrepen die tenkoste van de performance gaan, is het waarschijnlijk slimmer om te accepteren dat een byte gewoon meer dan 8 bits groot kan zijn.

Nu zou je kunnen zeggen dat C compilers voor microcontrollers vaak toch allerlei concessies doen aan de standaard - wat op zich wel vaak opgaat - maar dat argument verdwijnt weer als je je realiseert dat C bedoelt is om enigzins portable applicaties in te schrijven. Zeker aangezien microcontrollers tegenwoordig vrij ingewikkelde taken moeten uitvoeren; denk alleen al aan iets gangbaars als een Sweex router van een paar tientjes, die wel gewoon een TCP/IP implementatie, HTTP server, en FTP server ingebouwd heeft. Die dingen gaan ze dan echt niet from scratch implementen als het niet nodig is; als jouw embedded FTP server alleen werkt op een platform met 8-bit bytes dan heb je mooi pech.

Processoren met vage byte sizes worden tegenwoordig denk ik niet meer gemaakt (ook omdat 8-bit-bytes in allerlei andere standaarden zoals netwerkprotocollen en data busses de standaard zijn), maar goed, dat is dus maar een klein deel van het verhaal.

[MSalters]

De hele reden dat juist in C CHAR-BIT belangrijk is, is omdat als je ergens een vreemde bitgrootte hebt, je voor zo'n processor een custom compiler nodig hebt. C is dan de logische keuze, er zijn zat compiler kits, het heeft met CHAR_BIT die flexibiliteit, en het is een vrij simpele taal. Dus ongeveer elk exotisch systeem heeft wel een C compiler.
Overigens heb je met dat soort compilers weinig zin om zelf libraries te schrijven, dus wil je graag dat je die kunt inkopen, dus wil je graag dat de compiler op z'n minst 95% C compatible is.