[C++] Winsock: Hoe binaire codes doorsturen?

[D-Three]

Hallo,

Weet iemand wat je precies doorstuurt? En hoe ik een binaire code kan doorsturen? Ok, ik weet het, het is een rare vraag, maar laat het mij even verduidelijken via dit stukje code:

code:

char szBuf[256];
int nRet;

strcpy(szBuf, "From the Client");
nRet = sendto(theSocket,                // Socket
              szBuf,                    // Data buffer
              strlen(szBuf),            // Length of data
              0,                        // Flags
              (LPSOCKADDR)&saServer,    // Server address
              sizeof(struct sockaddr)); // Length of address

Ik initialiseer mijn Winsock, er wordt een UDP/IP socket aangemaakt, enz. Alles werkt dus perfect.
Aan de code hierboven zie je hoe er een buffer gedefineerd wordt:

code:

 char szBuf[256];

en dat er een string in die buffer gekopieerd wordt

code:

 strcpy(szBuf, "From the Client");

Met die sendto() ben ik dus verplicht om een string door te sturen.
Maar wat wordt er dan precies doorgestuurd? ASCII code? HEX? Binair? Worden daar bijvoorbeeld End-Of-Line of andere karakters bijgevoegd?
Ben ik verplicht om die string te gebruiken? Kan ik niet gewoon binaire code doorsturen?

Het is misschien een rare en/of moeilijke vraag, maar ik zou dit echt graag willen weten. Alvast bedankt!

edit:

typo's

[Pooh]

Een char[] (of char*) is maar een pointer naar een char (byte) hoor, niks meer of minder... Wat je dus stuurt is het eerste adres van je (binaire, als je het zo wilt noemen) data, en de lengte. Wat jij op die plek hebt staan (ascii, een plaatje, een binary of whatever) maakt niks uit...

[D-Three]

Een char is toch voor karakters? Of ben ik nu verkeerd? Ik zou eerder iets willen gebruiken als byte bijvoorbeeld

[D-Three]

dubbelpost

[Pooh]

Een char of een byte maakt niks uit voor zover ik weet.
Een char* of een byte* maakt sowieso niks uit.

[Soultaker]

Echt waar, een unsigned char is gewoon een byte =)

typedef unsigned char BYTE;

Je string wordt dus gewoon als binaire data verzonden - er worden geen tekens toegevoegd of geconverteerd. Zelfs het terminating 0-character wordt achterwege gelaten aangezien je strlen(szBuf) gebruikt als lengte.

[D-Three]

Na een soort van sniffer gebruikt te hebben, ben ik tot de volgende vaststelling gekomen:
Als ik "ABC" in die string stop, wordt 0x41 0x42 0x43 doorgestuurd. Dat is dus de hex-waarde van deze letters uit de ASCII-tabel.
Als er dus bijvoorbeeld "0001" moet doorgestuurd worden, dan wordt dit ook omgezet naar een ASCII-waarde, en dit mag dus niet.
Als ik "000 0001" doorstuur, moet er dus werkelijk 0x01 doorgestuurd worden en niet 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31.
Doe ik iets verkeerd of ik begrijp jullie verkeerd?

[Verwijderd]

Op donderdag 21 februari 2002 12:16 schreef Laagvliegerke het volgende:
Als er dus bijvoorbeeld "0001" moet doorgestuurd worden, dan wordt dit ook omgezet naar een ASCII-waarde, en dit mag dus niet.

Van wie niet? jij zet 'n string klaar met daar in "0001" dus hij stuurt "0001" door lijkt me logish?

[koffercomputer]

En als je als eerste 'karakter' een waarde van '1' opgeeft, dan zal íe netjes een binaire 1 sturen hoor.
Zoals al eerder is gezegd: een char is niets meer of minder dan een byte.

[Verwijderd]

Lekker wazige replies

Stel je wilt een byte 0x01 doorsturen, dan werkt dit dus niet: szBuf[0]= '1';
en dit ook niet: strcpy(szBuf, "1");
maar dit werkt wel: szBuf[0]= 1;.

Maw, als je een character-waarde (tussen quotes) aan een string toewijst, dan zal er logischerwijze ook een ascii-waarde geplaatst worden. Wijs je een numerieke (integer) waarde toe, dan wordt het gezien als binaire data.

[Verwijderd]

Op donderdag 21 februari 2002 12:50 schreef mietje het volgende:
Lekker wazige replies

Stel je wilt een byte 0x01 doorsturen, dan werkt dit dus niet: szBuf[0]= '1';
en dit ook niet: strcpy(szBuf, "1");
maar dit werkt wel: szBuf[0]= 1;.

Maw, als je een character-waarde (tussen quotes) aan een string toewijst, dan zal er logischerwijze ook een ascii-waarde geplaatst worden. Wijs je een numerieke (integer) waarde toe, dan wordt het gezien als binaire data.

Ik denk toch echt dat jij hier de gene bent die vaag denkt over bytes en chars.
Byte == Char.
Simpel.
Dat karakter 'A' nu pas op de 65e plaats voorkomt in de ASCII-tabel maakt toch geen hol uit?
Wil jij 0x01274E doorsturen dan stuur je dat toch gewoon als volgt:

code:

  szBuf[0] = 0x01;
  szBuf[1] = 0x27;
  szBuf[2] = 0x4E;

[D-Three]

Op donderdag 21 februari 2002 12:50 schreef mietje het volgende:
maar dit werkt wel: szBuf[0]= 1;.

Zo werkt het dus niet helemaal (cannot convert 'int' to 'char[]'). Ik heb het dan zo gedaan: char szBuf[4]= {0,0,0,1}; maar ook dit blijkt niet te werken. Als ik dan naar de sniffer kijk, wordt niks van data meegestuurd. Met char szBuf[4]= {1,0,0,0}; wordt enkel 0x01 doorgestuurd.
char szBuf[4]= {8,9,10,11}; werkt dan weer half en half, dan wordt de volgende data meegestuurd: 0x08 0x09 0x0A 0x0B 0x6C.
Die 0x6C moet er dus niet bij, maar als ik 1 getal (gelijk welk één) weg laat uit de array, blijkt het dan toch te werken. char szBuf[4]= {11,9,10}; levert dan bijvoorbeld 0x0B 0x09 0x0A op, wat dus correct is.
Het enige probleem is dus dat als er dus een 0 voorkomt in het array, dat alle getallen die volgen, niet doorgestuurd worden.
Suggesties?

[Verwijderd]

geen strlen gebruiken om de lengte van je buffer te bepalen?

[D-Three]

Op donderdag 21 februari 2002 13:46 schreef Yarvieh het volgende:
geen strlen gebruiken om de lengte van je buffer te bepalen?

Juist! Ben echt heel slecht bezig vandaag, ik zou beter een beetje vroeger in mijn bed leren kruipen Maar ja, GoT is zo leuk hé! En MoHAA ook
Het werkt dus, bedankt iedereen voor de info!

[.oisyn]

Op donderdag 21 februari 2002 13:45 schreef Laagvliegerke het volgende:

[..]

Zo werkt het dus niet helemaal (cannot convert 'int' to 'char[]').

dan doe je toch echt zelf iets niet goed

dit werkt prima

code:

char array[10];

array[0] = 1;

ik denk dat jij deed

code:

char array[10] = 1;

of iets in die trand, want uiteraard niet werkt, want hoe kun je nou een integer toekennen aan een array

[.oisyn]

Op donderdag 21 februari 2002 13:42 schreef hvdberg het volgende:

[..]

Ik denk toch echt dat jij hier de gene bent die vaag denkt over bytes en chars.
Byte == Char.
Simpel.
Dat karakter 'A' nu pas op de 65e plaats voorkomt in de ASCII-tabel maakt toch geen hol uit?
Wil jij 0x01274E doorsturen dan stuur je dat toch gewoon als volgt:

code:

  szBuf[0] = 0x01;
  szBuf[1] = 0x27;
  szBuf[2] = 0x4E;

zijn post klopte hoor, net als die van jou overigens, en jullie zeggen precies hetzelfde

wat mietje aangaf is alleen dat als je een getal tussen quotes zet, dat het dan een string is, en dat dan dus de ascii-waarden van die decimalen in de string worden doorgestuurd, en uiteraard niet de binaire representatie van dat getal

[Korben]

Op donderdag 21 februari 2002 13:46 schreef Yarvieh het volgende:
geen strlen gebruiken om de lengte van je buffer te bepalen?

Ter verduidelijking, hier ligt het dus idd aan. Als strlen() een 0-teken ('\0') tegenkomt, stopt ie met tellen, want een string wordt normaal gesproken afgesloten met een nulteken.

Als je trouwens gewoon een getal wilt verzenden (een int of zo), doe je gewoon dit:

code:

int blaat = 0x12345678;
nRet = sendto(theSocket, &blaat, sizeof(int), 0, (LPSOCKADDR)&saServer, sizeof(struct sockaddr));

Zo wordt er weliswaar 0x78563412 verzonden, maar als je in de ontvangende app gewoon inleest in een int, dan komt het allemaal weer goed .

[kvdveer]

Op donderdag 21 februari 2002 13:46 schreef Laagvliegerke het volgende:
niet letten op deze post, ben weer een beetje heel slecht bezig

Zeg dat wel zeg...

Wat wil je nou eigenlijk?
Wat wil je dat er verstuurd wordt?

Als je de STRING "0000 0001" wilt versturen is de bovenstaande code wel redelijk coorrect
Als de de binaire waarde 00000001 wilt versturen moet je ongeveer het volgende doen:

code:

char bTeVersturen = 0x01;
nRet = sendto(theSocket,                // Socket
  *bTeVersturen ,                   / / POINTER NAAR 1e byte van Data buffer
  1,            / / Length of data (1 byte in dit geval)
  0,                        // Flags
  (LPSOCKADDR)&saServer,    // Server address
  sizeof(struct sockaddr)); // Length of address

[D-Three]

Op donderdag 21 februari 2002 13:53 schreef OiSyN het volgende:ik denk dat jij deed

code:

char array[10] = 1;

of iets in die trand, want uiteraard niet werkt, want hoe kun je nou een integer toekennen aan een array

Inderdaad, nogal logisch niet? Mijn (simpele) programmeerwerk heeft te lijden onder mijn langer uren (zie vorige post)
Nogmaals bedankt iedereen!

edit:

aiai, weeral typo's

[Verwijderd]

Op donderdag 21 februari 2002 13:56 schreef kvdveer het volgende:
*bTeVersturen // POINTER NAAR 1e byte van Data buffer

Dat moet natuurlijk &bTeVersturen zijn he?

[Korben]

Op donderdag 21 februari 2002 13:57 schreef Laagvliegerke het volgende:

edit:

aiai, weeral typo's

Best wel knap als je een typo kunt maken terwijl je zegt dat je typo's had...

[D-Three]

Op donderdag 21 februari 2002 13:55 schreef Xenophage het volgende:
.. als je in de ontvangende app gewoon inleest in een int ...

Neen, de ontvanger is geen zelfgeschreven applicatie ofzo, het is een PLC met een ethernet-module.

[Korben]

Op donderdag 21 februari 2002 14:03 schreef Laagvliegerke het volgende:

[..]

Neen, de ontvanger is geen zelfgeschreven applicatie ofzo, het is een PLC met een ethernet-module.

Dan moet je voordat je zo ints gaat doorsturen eerst controleren of de PLC big-endian of little-endian nummers hanteert. Anders gaat dat hopeloos de mist in, vertrouw me, ik spreek uit ervaring...

[D-Three]

Op donderdag 21 februari 2002 14:03 schreef Xenophage het volgende:
Best wel knap als je een typo kunt maken terwijl je zegt dat je typo's had...

Heb ik nog ergens foutjes zitten?

[D-Three]

Op donderdag 21 februari 2002 14:05 schreef Xenophage het volgende:Dan moet je voordat je zo ints gaat doorsturen eerst controleren of de PLC big-endian of little-endian nummers hanteert. Anders gaat dat hopeloos de mist in, vertrouw me, ik spreek uit ervaring...

Normaalgezien zijn alle adressen die gebruikt worden door de SAIA-PLC big-endian. Dus hoogste bit eerst zeker?

[Korben]

Op donderdag 21 februari 2002 14:15 schreef Laagvliegerke het volgende:

[..]

Normaalgezien zijn alle adressen die gebruikt worden door de SAIA-PLC big-endian. Dus hoogste bit eerst zeker?

Eerst de laagste byte. Big-endian = "hoog-eindigend-achtig" (of zoiets)

[farlane]

Als dit een robuuste applicatie gaat worden weet ik het ook niet meer.....

[Olaf van der Spek]

Big-endian is dus dat het eerste byte de meest significante bit bevat.

[D-Three]

Op donderdag 21 februari 2002 16:20 schreef farlane het volgende:
Als dit een robuuste applicatie gaat worden weet ik het ook niet meer.....

[.oisyn]

Op donderdag 21 februari 2002 15:07 schreef Xenophage het volgende:

[..]

Eerst de laagste byte. Big-endian = "hoog-eindigend-achtig" (of zoiets)

iiiiiiiiii (<-- zoemer in een kwiz )
guess again

big-endian = msb (most significant byte) first
little-endian = lsb (least significant byte) first

big-endian is dus van hoog naar laag (dood aan de degene die dit heeft uitgevonden, want het is zo onbruikbaar als het maar zijn kan )

[Korben]

Op donderdag 21 februari 2002 18:22 schreef OiSyN het volgende:

[..]

iiiiiiiiii (<-- zoemer in een kwiz )
guess again

big-endian = lsb (least significant byte) first
little-endian = msb (most significant byte) first

big-endian is dus van laag naar hoog (dood aan de degene die dit heeft uitgevonden, want het is zo onbruikbaar als het maar zijn kan )

Euh... Jah... dat klopt met wat ik zei... What's your problem? Ik ben het alleen wel eens met dat het onhandig is...

[Verwijderd]

Op donderdag 21 februari 2002 18:22 schreef OiSyN het volgende:
big-endian is dus van laag naar hoog (dood aan de degene die dit heeft uitgevonden, want het is zo onbruikbaar als het maar zijn kan )

Eumz, als het nutteloos is, waarom vinden ze het dan uit Big-endian was in de tijd van 8-bits bussen erg handig: je hoefde geen bytes te swappen als je een returnadres van de stack popte...

[Korben]

Op vrijdag 22 februari 2002 11:02 schreef mietje het volgende:

[..]

Eumz, als het nutteloos is, waarom vinden ze het dan uit Big-endian was in de tijd van 8-bits bussen erg handig: je hoefde geen bytes te swappen als je een returnadres van de stack popte...

Hmm ik d8 dat big- en little-endian te maken had met verschillende processor-formaten (Motorola/Intel/enz.)...

[Verwijderd]

Op vrijdag 22 februari 2002 11:05 schreef Xenophage het volgende:
Hmm ik d8 dat big- en little-endian te maken had met verschillende processor-formaten (Motorola/Intel/enz.)...

Klopt, maar ik geef hier aan waarom big-endian architecturen ontworpen werden: je spaarde instructies op 8-bits cpu's.

[Korben]

Op vrijdag 22 februari 2002 11:11 schreef mietje het volgende:

[..]

Klopt, maar ik geef hier aan waarom big-endian architecturen ontworpen werden: je spaarde instructies op 8-bits cpu's.

Snap ik . Maar waarom is dan little-endian ontworpen?

[.oisyn]

Op vrijdag 22 februari 2002 10:54 schreef Xenophage het volgende:

[..]

Euh... Jah... dat klopt met wat ik zei... What's your problem? Ik ben het alleen wel eens met dat het onhandig is...

Waarom reageer je zo geergerd?

.edit: mijn fout overigens, ik herhaalde idd precies wat jij zei sorry

Anyway, je zei het wel degelijk verkeerd:

Op donderdag 21 februari 2002 15:07 schreef Xenophage het volgende:

[..]

Eerst de laagste byte. Big-endian = "hoog-eindigend-achtig" (of zoiets)

maar big-endian is eerst de hoogste byte, zoals ik al zei: msb first

little-endian is laagste byte eerst

de term big-endian heeft dan ook niets te maken met dat de biggest ends ofzoiets (want dat zou namelijk niet kloppen), maar de term komt uit Gulliver's Travels (weet ook niet precies hoe het nou zit)

[Verwijderd]

Op vrijdag 22 februari 2002 11:23 schreef Xenophage het volgende:
Snap ik . Maar waarom is dan little-endian ontworpen?

Weet ik niet zeker, maar het lijkt me dat dit voor westerlingen (die van links naar rechts lezen) het meest logische formaat is. Overigens mis ik in deze (offtopic) discussie nog bit-endianness, er waren in het verleden machines die zelfs die bits in een byte andersom opsloegen; daarom is zelfs bit-endianness vastgelegd in protocollen (zoals TCP/IP).

[.oisyn]

Op vrijdag 22 februari 2002 11:02 schreef mietje het volgende:

[..]

Eumz, als het nutteloos is, waarom vinden ze het dan uit Big-endian was in de tijd van 8-bits bussen erg handig: je hoefde geen bytes te swappen als je een returnadres van de stack popte...

ja okee, maar daar zijn natuurlijk ook wel 2 andere oplossingen voor mogelijk:
A. returnaddress geswapped op de stack gooien (is geen moeite, aangezien dit door een instructie wordt gedaan, dus is gewoon simpel aan te passen)
B. stack de andere kant op laten werken

maar ik doelde meer op het feit dat 16-bits en hogere cpu's nog steeds big-endian notatie gebruiken. Met little-endian kun je bijvoorbeeld shorts en longs via hetzelfde geheugenadres aanspreken, bij big-endian moet je gaan kloten met de addressen (2 erbij voor de short)

(ik ga hier ervan uit dat short=16 bits en long=32 bits ofcourse )

side-note: er bestaat zelfs zoiets loos als middle-endianess

[loial]

Op donderdag 21 februari 2002 18:22 schreef OiSyN het volgende:

[..]
big-endian = lsb (least significant byte) first
little-endian = msb (most significant byte) first

Op vrijdag 22 februari 2002 12:13 schreef OiSyN het volgende:

[..]
maar big-endian is eerst de hoogste byte, zoals ik al zei: msb first
little-endian is laagste byte eerst

Ehm, no offence, maar nu verspreek je je geloof ik

[.oisyn]

Op vrijdag 22 februari 2002 12:28 schreef Loial het volgende:

[..]


[..]

Ehm, no offence, maar nu verspreek je je geloof ik

you're absolutely right, effe editten
lekker lomp, iemand verbeteren en dan vervolgens precies hetzelfde zeggen Nu snap ik de reactie van Xenophage ook

[MSalters]

Op vrijdag 22 februari 2002 12:13 schreef OiSyN het volgende:

de term big-endian heeft dan ook niets te maken met dat de biggest ends ofzoiets (want dat zou namelijk niet kloppen), maar de term komt uit Gulliver's Travels (weet ook niet precies hoe het nou zit)

Big-Endian en Little-Endian waren twee stammen die een eeuwige ruzie hadden aan welke kant je een eitje moest tikken, the Big End of the Little End

[Olaf van der Spek]

Wat is middle-endian dan?

[.oisyn]

Op vrijdag 22 februari 2002 19:09 schreef OlafvdSpek het volgende:
Wat is middle-endian dan?

3-4-2-1 of 2-1-4-3 of iets in die trand

de middelste significant byte first zeg maar, erg onlogisch

de amerikaanse datum-notatie kun je in principe ook middle-endian noemen, omdat ze beginnen met de maand: mm-dd-yy, terwijl wij little-endian notatie gebruiken: dd-mm-yy

[Olaf van der Spek]

Waar wordt middle-endian dan gebruikt en waarom?

[.oisyn]

Op zaterdag 23 februari 2002 13:57 schreef OlafvdSpek het volgende:
Waar wordt middle-endian dan gebruikt en waarom?

http://info.astrian.net/jargon/terms/m/middle-endian.html

Not big-endian or little-endian. Used of perverse byte orders such as 3-4-1-2 or 2-1-4-3, occasionally found in the packed-decimal formats of minicomputer manufacturers who shall remain nameless. See NUXI problem. Non-US hackers use this term to describe the American mm/dd/yy style of writing dates (Europeans write little-endian dd/mm/yy, and Japanese use big-endian yy/mm/dd for Western dates).

[Korben]

Op vrijdag 22 februari 2002 12:13 schreef OiSyN het volgende:

[..]

Waarom reageer je zo geergerd?

.edit: mijn fout overigens, ik herhaalde idd precies wat jij zei sorry

Anyway, je zei het wel degelijk verkeerd:
[..]

maar big-endian is eerst de hoogste byte, zoals ik al zei: msb first

little-endian is laagste byte eerst

de term big-endian heeft dan ook niets te maken met dat de biggest ends ofzoiets (want dat zou namelijk niet kloppen), maar de term komt uit Gulliver's Travels (weet ook niet precies hoe het nou zit)

Op vrijdag 22 februari 2002 12:30 schreef OiSyN het volgende:

[..]


you're absolutely right, effe editten
lekker lomp, iemand verbeteren en dan vervolgens precies hetzelfde zeggen Nu snap ik de reactie van Xenophage ook

Kwas niet geërgerd, ik was verbaasd om te zien dat je mij herhaalde en zei dat wat ik zei verkeerd was. Dat ":r" was om aan te geven dat big-endian onhandig is.

[Olaf van der Spek]

Zo onhandig is big-endian ook niet hoor. Het leest een stuk makkelijk in een hex editor dan little-endian.

Zoveel voordeel is het zonder rekenen kunnen lezen van words als bytes ook niet. En als je het zonder rekenen wilt kunnen, zou je als adres het adres van het rechter byte in plaats van het linker byte kunnen gebruiken.

[Korben]

Op maandag 25 februari 2002 14:01 schreef OlafvdSpek het volgende:
Zo onhandig is big-endian ook niet hoor. Het leest een stuk makkelijk in een hex editor dan little-endian.

Zoveel voordeel is het zonder rekenen kunnen lezen van words als bytes ook niet. En als je het zonder rekenen wilt kunnen, zou je als adres het adres van het rechter byte in plaats van het linker byte kunnen gebruiken.

Euh... jah, dan moet je wel toevallig van rechts naar links kunnen inlezen...

[Olaf van der Spek]

Over het algemeen wordt het binnen een of twee keer ingelezen en niet per byte.

[Korben]

Op dinsdag 26 februari 2002 19:32 schreef OlafvdSpek het volgende:
Over het algemeen wordt het binnen een of twee keer ingelezen en niet per byte.

Ja, maar het wordt wel van links naar rechts (zullen we maar even zeggen) ingelezen. En daar ging het om. Dus moet je een functie/macro schrijven om je ingelezen nummer van little-endian (dat komt voor) naar big-endian (windhoos) te converteren.
Wat jij zei van het adres van de laatste byte pakken (ik neem aan dat je in het geheugen bedoelt) leidt zowiezo tot compleet verneukte gegevens (hij schrijft in geheugen buiten het geheugen van de variabele) en misschien (oh joy) tot een kresj.

[.oisyn]

Op woensdag 27 februari 2002 14:45 schreef Xenophage het volgende:

[..]

Ja, maar het wordt wel van links naar rechts (zullen we maar even zeggen) ingelezen. En daar ging het om. Dus moet je een functie/macro schrijven om je ingelezen nummer van little-endian (dat komt voor) naar big-endian (windhoos) te converteren.

nou draai je het alweer om
_{effe extra oppassen dat ik het deze keer wel goed zeg}

intel x86 = little-endian
en bijvoorbeeld motorola = big-endian

verder snap ik niet helemaal waar jullie het over hebben

anyway, big-endian is vervelend voor het converteren van grotere elementen naar kleinere, bijvoorbeeld word naar bytes.

code:

word w = 15;
byte * b = (byte *) &w;

je zou verwachten dat *b nu 15 is, maar het is 0, aangezien ie de most significant byte pakt ipv de least significant byte.

Hmmm nu ik er zo over denk weet ik trouwens niet hoe de compiler dit afhandelt... misschien convert ie dat adres automatisch door er 1 bij op te tellen. Ik denk het eerlijk gezegd niet, want dan zijn deze 2 statements niet hetzelfde:

code:

byte * b = (byte *) &w;
byte * c = (byte *) ((void *) &w);

dus om het goed te krijgen zul je dit moeten doen

code:

byte * b = ((byte * ) &w) + 1;

conclusie: big-endian sucks

[D-Three]

Ok, little-, big- en middle-endian begrijp ik. Dat van die twee stammen begrijp ik ook nog. Maar de rest wordt al wat moeilijker.
Ik wou enkel maar zeggen dat, na het schrijven van een stukje code waarmee ik de CRC van mijn data kan berekenen, de communicatie met de PLC lukt(ongeveer toch ), dus nogmaals bedankt iedereen!

[Korben]

Op woensdag 27 februari 2002 15:51 schreef OiSyN het volgende:

[..]

nou draai je het alweer om
_{effe extra oppassen dat ik het deze keer wel goed zeg}

intel x86 = little-endian
en bijvoorbeeld motorola = big-endian

verder snap ik niet helemaal waar jullie het over hebben

anyway, big-endian is vervelend voor het converteren van grotere elementen naar kleinere, bijvoorbeeld word naar bytes.

code:

word w = 15;
byte * b = (byte *) &w;

je zou verwachten dat *b nu 15 is, maar het is 0, aangezien ie de most significant byte pakt ipv de least significant byte.

Hmmm nu ik er zo over denk weet ik trouwens niet hoe de compiler dit afhandelt... misschien convert ie dat adres automatisch door er 1 bij op te tellen. Ik denk het eerlijk gezegd niet, want dan zijn deze 2 statements niet hetzelfde:

code:

byte * b = (byte *) &w;
byte * c = (byte *) ((void *) &w);

dus om het goed te krijgen zul je dit moeten doen

code:

byte * b = ((byte * ) &w) + 1;

conclusie: big-endian sucks

Not quite.

Intel x86 = little-endian? Misschien wel, maar Windows is toch echt big-endian dan. Want als ik in een TTF-bestand de eerste vier bytes (een DWORD dus) inlees, wat de versie op zou moeten leveren, zie ik in een hex-editor staan:

code:

00 01 00 00

Wat goed is, het zou 0x00010000 moeten zijn, maar als ik met ReadFile() inlees, en dan hexadecimaal weergeef, krijg ik toch echt dit:

code:

00 00 01 00

Dus... dat bestand is little-endian (begint met de msb, en eindigt met de lsb) en Windows is big-endian (lsb eerst, eindigt met msb).

Hum, ik weet nou niet meer of ik msb/lsb niet door elkaar haal, maar voor de duidelijkheid, zo zie ik m/lsb:

• msb = hoogste byte
• lsb = laagste byte

[.oisyn]

Op donderdag 28 februari 2002 11:21 schreef Xenophage het volgende:

[..]

Not quite.

wel hoor

Intel x86 = little-endian?

yup

Misschien wel, maar Windows is toch echt big-endian dan.

uhm, hoe kan het OS in hemelsnaam de endianness bepalen? Is dus ook niet zo

Want als ik in een TTF-bestand de eerste vier bytes (een DWORD dus) inlees, wat de versie op zou moeten leveren, zie ik in een hex-editor staan:

code:

00 01 00 00

Wat goed is, het zou 0x00010000 moeten zijn, maar als ik met ReadFile() inlees, en dan hexadecimaal weergeef, krijg ik toch echt dit:

code:

00 00 01 00

Dus... dat bestand is little-endian (begint met de msb, en eindigt met de lsb) en Windows is big-endian (lsb eerst, eindigt met msb).

nou draai je het alweer om
little-endian begint met lsb, en eindigt met msb en big-endian is eerst msb en dan lsb. Als jij in een bestand 00 01 00 00 hebt staan, en je leest dit in als dword, dan krijgt die dword de waarde 0x00000100 (little-endian dus)

Hum, ik weet nou niet meer of ik msb/lsb niet door elkaar haal, maar voor de duidelijkheid, zo zie ik m/lsb:

• msb = hoogste byte
• lsb = laagste byte

dat zie je goed

msb = most significant byte, dus de byte met de grootste waarde (is dus de linker decimaal als je een getal in decimalen zou opschrijven)
lsb = least significant byte, dus de byte met de kleinste waarde (is dus de rechter decimaal als je een getal in decimalen zou opschrijven)

[D-Three]

Nog een klein vraagje als ik bijvoorbeeld send doe, dit dus bijvoorbeeld:

code:

int nRet;
nRet = send(theSocket,
        szBuf,
        lengte_data,
        0);

Dan moet ik normaal in nRet een 0 krijgen als het gelukt is of een andere code waneer er een fout opgetreden is. Maar als de ontvanger nu bijvoorbeeld niet aangesloten is op het netwerk, dan krijg ik ook 0 als antwoord???

Als ik dan bijvoorbeeld iets probeer te ontvangen, dan blijft het programma dus gewoon hangen. Ik dacht dat er dan een time-out zou optreden, maar niet dus:

code:

recv(theSocket,
     szBuf,
     sizeof(szBuf),
     0);

Is dit op te vangen? Hoe kan ik nu weten of de PLC wel verbonden is met het netwerk? Of als mijn bericht wel aangekomen is? Eventueel met connect:

code:

error = connect(theSocket,
            (LPSOCKADDR)&saServer,
            sizeof(struct sockaddr));

Nog even dit, ik gebruik dus UDP en niet TCP.

[D-Three]

Op donderdag 28 februari 2002 14:33 schreef OiSyN het volgende:
nou draai je het alweer om
little-endian begint met lsb, en eindigt met msb en big-endian is eerst msb en dan lsb. Als jij in een bestand 00 01 00 00 hebt staan, en je leest dit in als dword, dan krijgt die dword de waarde 0x00000100 (little-endian dus)
[..]

dat zie je goed

msb = most significant byte, dus de byte met de grootste waarde (is dus de linker decimaal als je een getal in decimalen zou opschrijven)
lsb = least significant byte, dus de byte met de kleinste waarde (is dus de rechter decimaal als je een getal in decimalen zou opschrijven)

sorry hoor, is dit niet:
msb = most significant bit
lsb = least significant bit

1 byte:

7 6 5 4 3 2 1 0 Bit Nummer
+---+---+---+---+---+---+---+---+
| | | | | | | | |
+---+---+---+---+---+---+---+---+
128 64 32 16 8 4 2 1 Decimal Waarde
MSB LSB

"endian" slaat dan op de rangschikking van de bytes:
big-endian = byte met hooste waarde in het laagste geheugenadres. De grootste byte wordt dus eerst bewaard, vandaar big-endian, grootste einde eerst.
little-endian = byte met laagste waarde in het laagste geheugenadres. Hier wordt de kleinste byte dus eerst bewaard, vandaar dus little-endian, laagste einde eerst.

De notatie is nu afhankelijk van welk geheugenadres je eerst plaats, maar logisch gezien begin je altijd met het laagste geheugenadres (van links naar rechts). De notatie voor bijvoorbeeld het decimale getal 2748 (= ABC Hex) is dus:
big-endian = 00 00 0A BC
little-endian = BC 0A 00 00

edit:
typo

[.oisyn]

Op donderdag 28 februari 2002 15:30 schreef Laagvliegerke het volgende:

[..]

sorry hoor, is dit niet:
msb = most significant bit
lsb = least significant bit

kan allebei, het is maar net wat je bedoelt... bovendien maakt het niet uit of je over bits of bytes praat, aangezien het kleinst adresseerbare element de byte is. Maw, als je de least significat bit eerst doet, moet je dus ook automatisch de least significant byte eerst doen, aangezien je niet de volgorde van de bits onderling kunt veranderen (kan wel, maar het heeft geen nut)

verder schrijf je wat al 10x is gezegd in dit topic

[D-Three]

Op donderdag 28 februari 2002 16:10 schreef OiSyN het volgende:
kan allebei, het is maar net wat je bedoelt... bovendien maakt het niet uit of je over bits of bytes praat, aangezien het kleinst adresseerbare element de byte is. Maw, als je de least significat bit eerst doet, moet je dus ook automatisch de least significant byte eerst doen, aangezien je niet de volgorde van de bits onderling kunt veranderen (kan wel, maar het heeft geen nut)

verder schrijf je wat al 10x is gezegd in dit topic

Ah zo, dacht dat men msb en lsb enkel gebruikt bij bits.
Maar bij al die "endians" staat de most significant bit toch altijd eerst? Gelijk in welke byte, zelfs al is het de least, de most of een andere byte en gelijk waar de byte staat (vooraan of achteraan)?

Nu ja, terug voor een beetje on-topic, kan iemand mijn probleem oplossen? Hoe detecteer ik wanneer een client niet bereikbaar is?

[Olaf van der Spek]

Op donderdag 28 februari 2002 16:10 schreef OiSyN het volgende:
kan allebei, het is maar net wat je bedoelt... bovendien maakt het niet uit of je over bits of bytes praat, aangezien het kleinst adresseerbare element de byte is. Maw, als je de least significat bit eerst doet, moet je dus ook automatisch de least significant byte eerst doen, aangezien je niet de volgorde van de bits onderling kunt veranderen (kan wel, maar het heeft geen nut)

Volgens mij maakt het wel uit. De endianess op byte niveau is onafhankelijk van de endianess op bit niveau.

Dus als je lsb op zowel bit- als byte niveau hebt, wordt een 32-bit 1 als 10000000 00000000 00000000 00000000 geschreven.

[Olaf van der Spek]

Op donderdag 28 februari 2002 16:13 schreef Laagvliegerke het volgende:Nu ja, terug voor een beetje on-topic, kan iemand mijn probleem oplossen? Hoe detecteer ik wanneer een client niet bereikbaar is?

Als jij UDP wilt gebruiken moet je dat dus zelf doen, UDP levert die service niet.

[Olaf van der Spek]

Op woensdag 27 februari 2002 15:51 schreef OiSyN het volgende:
anyway, big-endian is vervelend voor het converteren van grotere elementen naar kleinere, bijvoorbeeld word naar bytes.

code:

word w = 15;
byte * b = (byte *) &w;

je zou verwachten dat *b nu 15 is, maar het is 0, aangezien ie de most significant byte pakt ipv de least significant byte.

Maar is dat vervelend of gewoon een ontwerp-fout? Want hoe vaak wil je zoiets doen? Je kunt natuurlijk ook gewoon v & 0xff gebruiken en niet met casts goochelen.

Hmmm nu ik er zo over denk weet ik trouwens niet hoe de compiler dit afhandelt...

Ik denk dat de compiler niks speciaals doet.

[D-Three]

Op donderdag 28 februari 2002 16:21 schreef OlafvdSpek het volgende:
Als jij UDP wilt gebruiken moet je dat dus zelf doen, UDP levert die service niet.

Ja, maar hoe? Als UDP dat niet ondersteunt, dan kan ik dat toch niet controleren met UDP? Ik verstuur iets (terwijl de ontvanger niet aangesloten is) en ik krijg geen fout.
Als ik iets probeer te ontvangen, hangt het programma gewoon. Kan ik niet ergens een time-out voorzien ofzo?

[Olaf van der Spek]

Je moet kunnen kijken of er iets te ontvangen valt, welke functie je daarvoor kunt gebruiken weet ik niet.

[.oisyn]

Op donderdag 28 februari 2002 16:30 schreef Laagvliegerke het volgende:

[..]

Ja, maar hoe? Als UDP dat niet ondersteunt, dan kan ik dat toch niet controleren met UDP? Ik verstuur iets (terwijl de ontvanger niet aangesloten is) en ik krijg geen fout.
Als ik iets probeer te ontvangen, hangt het programma gewoon. Kan ik niet ergens een time-out voorzien ofzo?

als je iets stuurt zul je een bevestiging moeten krijgen. Als dat niet binnen een bepaalde tijd gebeurd, kan er dus iets fout gegaan zijn (data corruption, packet loss, of de client is dood). De client hoeft niet persee niet meer connected te zijn, dus het is verstanding om het pakketje nog een keer te versturen. Als de server na een aantal pakketjes geen antwoord binnen een bepaalde tijd heeft gehad, kan ie de conclusie trekken dat de client er dus niet meer is.

Het gedrag van recv hangt af van hoe je je socket in hebt gesteld. Bij niet-blocking retourneert ie gelijk als er niets te lezen is, en krijg je een errorwaarde terug. Bij blocking sockets retourneert ie als er data binnen. Je zult dus non-blocking sockets moeten gebruiken, en zelf bijhouden hoeveel tijd er is verstreken

sockets kun je zo blocking maken:

code:

ioctlsocket (sock, FIONBIO, (u_long *)1);

[.oisyn]

Op donderdag 28 februari 2002 16:20 schreef OlafvdSpek het volgende:

[..]

Volgens mij maakt het wel uit. De endianess op byte niveau is onafhankelijk van de endianess op bit niveau.

Dus als je lsb op zowel bit- als byte niveau hebt, wordt een 32-bit 1 als 10000000 00000000 00000000 00000000 geschreven.

ja dat is idd zo, maar dat maakt niet uit, omdat je de bits afzonderlijk niet kan adresseren Aangezien het cpu bytes als 1 blokje van 8 bits leest, maakt het voor jou als programmeur niet uit of ze little of big-endian zijn, ze worden altijd goed ingelezen

[D-Three]

Op donderdag 28 februari 2002 18:56 schreef OiSyN het volgende:
als je iets stuurt zul je een bevestiging moeten krijgen. Als dat niet binnen een bepaalde tijd gebeurd, kan er dus iets fout gegaan zijn (data corruption, packet loss, of de client is dood). De client hoeft niet persee niet meer connected te zijn, dus het is verstanding om het pakketje nog een keer te versturen. Als de server na een aantal pakketjes geen antwoord binnen een bepaalde tijd heeft gehad, kan ie de conclusie trekken dat de client er dus niet meer is.

Als antwoord krijg ik bij het zenden enkel 0 (zelfs als ik de netwerkplug van de PLC uit trek). Dit betekent dus dat er geen foutmelding is. Of doe ik iets verkeerd?

Op donderdag 28 februari 2002 18:56 schreef OiSyN het volgende:
Het gedrag van recv hangt af van hoe je je socket in hebt gesteld. Bij niet-blocking retourneert ie gelijk als er niets te lezen is, en krijg je een errorwaarde terug. Bij blocking sockets retourneert ie als er data binnen. Je zult dus non-blocking sockets moeten gebruiken, en zelf bijhouden hoeveel tijd er is verstreken

sockets kun je zo blocking maken:

code:

ioctlsocket (sock, FIONBIO, (u_long *)1);

Dat met die blocking had ik al geprobeerd, maar dit lukt echter niet zo goed. Kan ik de timeout van UDP iets groter maken, ik denk dat het probleem dan opgelost zou zijn.

[.oisyn]

Op donderdag 28 februari 2002 20:05 schreef Laagvliegerke het volgende:

[..]

Als antwoord krijg ik bij het zenden enkel 0 (zelfs als ik de netwerkplug van de PLC uit trek). Dit betekent dus dat er geen foutmelding is. Of doe ik iets verkeerd?

bij het zenden wel ja. Het zenden gaat toch goed? De data is verstuurd... Als de data idd ontvangen is aan de andere kant van de lijn, dan zal ie een acknowlegdement terug moeten sturen, dus dat de data idd ontvangen is

krijg je niet binnen zoveel tijd een acknowledgement, dan zul je het pakketje dus opnieuw moeten versturen, en na meerdere pogingen kun je dus de conclusie trekken dat de andere kant van de lijn helemaal niet aan het luisteren is naar data

Dat met die blocking had ik al geprobeerd, maar dit lukt echter niet zo goed. Kan ik de timeout van UDP iets groter maken, ik denk dat het probleem dan opgelost zou zijn.

UDP heeft voor versturen en ontvangen geen timeout bij mijn weten...

[farlane]

Op donderdag 28 februari 2002 20:05 schreef Laagvliegerke het volgende:
Kan ik de timeout van UDP iets groter maken, ik denk dat het probleem dan opgelost zou zijn.

Aangezien UDP een connectionless protocol is heeft het geen zin om een timeout te implementeren.

Als je een 'betrouwbare' verbinding wilt hebben moet je stream sockets gebruiken, of zoals eerder al aangegeven werd zelf een timeout implementeren. (Maar dan kun je beter met TCP gaan werken volgens mij, daar is dat allemaal al geregeld)

[D-Three]

Op donderdag 28 februari 2002 20:11 schreef OiSyN het volgende:
bij het zenden wel ja. Het zenden gaat toch goed? De data is verstuurd... Als de data idd ontvangen is aan de andere kant van de lijn, dan zal ie een acknowlegdement terug moeten sturen, dus dat de data idd ontvangen is

Inderdaad ja, hier was ik even verkeerd. Natuurlijk krijg ik geen foutmelding, de data is verstuurd. En meer interesseert UDP natuurlijk niet.

Op donderdag 28 februari 2002 21:20 schreef farlane het volgende:
Aangezien UDP een connectionless protocol is heeft het geen zin om een timeout te implementeren.

Als je een 'betrouwbare' verbinding wilt hebben moet je stream sockets gebruiken, of zoals eerder al aangegeven werd zelf een timeout implementeren. (Maar dan kun je beter met TCP gaan werken volgens mij, daar is dat allemaal al geregeld)

Ik denk dat er toch een soort van timeout mogelijk is. We hebben net dit gevonden:

code:

char testBuffer[10]="20";
int status = setsockopt (theSocket, SOL_SOCKET, SO_RCVTIMEO, testBuffer, 10);

Dit blijkt ongeveer te werken. Morgen even beter bekijken.

Op donderdag 28 februari 2002 20:11 schreef OiSyN het volgende:
krijg je niet binnen zoveel tijd een acknowledgement, dan zul je het pakketje dus opnieuw moeten versturen, en na meerdere pogingen kun je dus de conclusie trekken dat de andere kant van de lijn helemaal niet aan het luisteren is naar data

Ik denk om het zo te doen als bovenstaande oplossing werkt:
1. We verzenden de data naar de PLC.
2. We wachten op info (kunnen we aanzien als ACK) van de PLC:
a. we krijgen die informatie: geen probleem
b. we krijgen die niet en dus springen we terug naar 1. Dit kunnen we dan enkele keren doen. Is het bijvoorbeeld na 3 keer nog niet gelukt, dan geven we een foutmelding op het scherm.
Wat denken jullie? Ik denk dat het zo wel ruw opgelost zou zijn, nog even bijschaven dan en het zou wel werken.

[Korben]

OiSyN:
uhm, hoe kan het OS in hemelsnaam de endianness bepalen? Is dus ook niet zo

nou draai je het alweer om
little-endian begint met lsb, en eindigt met msb en big-endian is eerst msb en dan lsb. Als jij in een bestand 00 01 00 00 hebt staan, en je leest dit in als dword, dan krijgt die dword de waarde 0x00000100 (little-endian dus)

msb = most significant byte, dus de byte met de grootste waarde (is dus de linker decimaal als je een getal in decimalen zou opschrijven)
lsb = least significant byte, dus de byte met de kleinste waarde (is dus de rechter decimaal als je een getal in decimalen zou opschrijven)

Ik weet nou echt wel het verschil tussen little- en big-endian. En euh... je spreekt jezelf enorm tegen, weet je dat?

big-endian = lsb (least significant byte) first
little-endian = msb (most significant byte) first

big-endian is dus van laag naar hoog (dood aan de degene die dit heeft uitgevonden, want het is zo onbruikbaar als het maar zijn kan )

Okee, dus 00 01 00 00 voor 0x00010000 is little-endian. Punt. Maar als ik 0x00010000 in Windows uitlees, krijg ik 0x00000100. Big-endian.

Laten we dit ff zo vastleggen, dan kunnen daar iig geen misverstanden meer over komen.

[.oisyn]

Op donderdag 28 februari 2002 22:30 schreef Xenophage het volgende:

[..]

Ik weet nou echt wel het verschil tussen little- en big-endian. En euh... je spreekt jezelf enorm tegen, weet je dat?

mijn eerste post was fout ja, maar dat heb ik allang verbeterd... en je weet het dus nog niet, want je doet het nog steeds andersom (lees nou eens effe terug, dan zie je het)

Okee, dus 00 01 00 00 voor 0x00010000 is little-endian. Punt. Maar als ik 0x00010000 in Windows uitlees, krijg ik 0x00000100. Big-endian.

neeheeeej, als je 00 01 00 00 inleest als little-endian dan krijg je 0x00000100

.edit: wat een gezeur over endianness trouwens... laten we het gewoon vergeten en verder gaan met het topic

[D-Three]

Op donderdag 28 februari 2002 22:49 schreef OiSyN het volgende:
neeheeeej, als je 00 01 00 00 inleest als little-endian dan krijg je 0x00000100

Juist, ja.

Op donderdag 28 februari 2002 22:49 schreef OiSyN het volgende:
wat een gezeur over endianness trouwens... laten we het gewoon vergeten en verder gaan met het topic

Inderdaad, ja!

Het lukt ongeveer op de manier die ik in mijn vorige post vermeld heb. Mochten jullie nog betere voorstellen hebben, hou jullie dan zeker niet in!!

[curry684]

Op donderdag 28 februari 2002 22:30 schreef Xenophage het volgende:
Okee, dus 00 01 00 00 voor 0x00010000 is little-endian. Punt. Maar als ik 0x00010000 in Windows uitlees, krijg ik 0x00000100. Big-endian.

Laten we dit ff zo vastleggen, dan kunnen daar iig geen misverstanden meer over komen.

Je hebt zojuist een stevig misverstand vastgelegd dan, want als je Windows op de Alpha draait krijg je daar wel degelijk een ander resultaat uit dan op de x86

(nu hoop ik dat de Alpha idd net als de 680x0 een andere endianness aanhoudt dan de x86

[Olaf van der Spek]

Op donderdag 28 februari 2002 18:56 schreef OiSyN het volgende:
sockets kun je zo blocking maken:

code:

ioctlsocket (sock, FIONBIO, (u_long *)1);

Werkt dat echt zo met die cast?

[Olaf van der Spek]

Op donderdag 28 februari 2002 19:03 schreef OiSyN het volgende:

[..]

ja dat is idd zo, maar dat maakt niet uit, omdat je de bits afzonderlijk niet kan adresseren Aangezien het cpu bytes als 1 blokje van 8 bits leest, maakt het voor jou als programmeur niet uit of ze little of big-endian zijn, ze worden altijd goed ingelezen

Tuurlijk maakt dat wel uit op dezelfde manier als byte endianess uitmaakt. Als je die data bijvoorbeeld naar een andere computer transporteert.

[Olaf van der Spek]

Op donderdag 28 februari 2002 22:28 schreef Laagvliegerke het volgende:
Ik denk om het zo te doen als bovenstaande oplossing werkt:
1. We verzenden de data naar de PLC.
2. We wachten op info (kunnen we aanzien als ACK) van de PLC:
a. we krijgen die informatie: geen probleem
b. we krijgen die niet en dus springen we terug naar 1. Dit kunnen we dan enkele keren doen. Is het bijvoorbeeld na 3 keer nog niet gelukt, dan geven we een foutmelding op het scherm.
Wat denken jullie? Ik denk dat het zo wel ruw opgelost zou zijn, nog even bijschaven dan en het zou wel werken.

Als er geen reden is voor packet loss hoef je in principe niet opnieuw te versturen.

[curry684]

Op vrijdag 01 maart 2002 12:10 schreef OlafvdSpek het volgende:
Werkt dat echt zo met die cast?

Toevalligerwijs kan het werken. Die functie wil een pointer naar een niet-NULL waarde, en adres 1 zal vrijwel altijd naar een niet-NULL waarde wijzen. Je zou daarentegen ook een access violation verwachten. Correct dus zou zijn:

code:

u_long    l_Value = TRUE;

ioctlsocket(sock, FIONBIO, &l_Value);

[curry684]

Op vrijdag 01 maart 2002 12:11 schreef OlafvdSpek het volgende:
Tuurlijk maakt dat wel uit op dezelfde manier als byte endianess uitmaakt. Als je die data bijvoorbeeld naar een andere computer transporteert.

Waarvoor dan ook de standaard functies ntohl en htonl zijn uitgevonden... in principe niet voor deze specifieke toepassing maar wel bruikbaar.

[MSalters]

Op donderdag 28 februari 2002 14:33 schreef OiSyN het volgende:

uhm, hoe kan het OS in hemelsnaam de endianness bepalen? Is dus ook niet zo

De PowerPC CPUs kunnen run-time van endianness veranderen, dacht ik. In elk geval tijdens de boot.

[.oisyn]

Op vrijdag 01 maart 2002 12:21 schreef curry684 het volgende:

[..]

Toevalligerwijs kan het werken. Die functie wil een pointer naar een niet-NULL waarde, en adres 1 zal vrijwel altijd naar een niet-NULL waarde wijzen. Je zou daarentegen ook een access violation verwachten. Correct dus zou zijn:

code:

u_long    l_Value = TRUE;

ioctlsocket(sock, FIONBIO, &l_Value);

oh dan heb ik de docs verkeerd begrepen denk ik... ik dacht eigenlijk dat ie gewoon NULL wilde voor blocking, en niet-NULL voor niet-blocking, en omdat die parameter een pointer naar u_long is moet je m even casten...

uit de MSDN:

Use with a nonzero argp parameter to enable the nonblocking mode of socket s. The argp parameter is zero if nonblocking is to be disabled. The argp parameter points to an unsigned long value. When a socket is created, it operates in blocking mode by default (nonblocking mode is disabled). This is consistent with BSD sockets.

hmmm ja naar 100x gelezen te hebben zou het inderdaad wel zo kunnen zijn dat je m naar een u_long moet pointen die vervolgens TRUE of FALSE geeft of iets dergelijks...

[D-Three]

Nog een vraagje, nadat de CRC berekend is, wordt de CRC in twee gesplitst en opgeslagen in de twee laatste plaatsen van een array.
Nu heb ik daar twee manieren voor, maar ik vraag mij af hoe ik te weten kan komen wat de snelste manier is.

Ok, dit was de eerste manier omdat ik deze manier al gebruikt had om meerder plaatsen in te vullen in plaats van 2:

code:

    for (i=1; i < 3; i++)
    {
      temp = crc & 0xFF;
      sendBuf[grootteArray - i] = temp;
      crc -= temp;
      crc /= 0x100;
    }

Hierboven worden enkele bewerking uitgevoerd die niet nodig zijn, dus heb ik toen dit genomen:

code:

    sendBuf[grootteArray - 1] = crc & 0xFF;
    temp = crc - sendBuf[grootteArray - 1];
    sendBuf[grootteArray - 2] = temp / 0x100;

Maar toen dacht ik ook plots aan dit:

code:

    sendBuf[grootteArray - 1] = crc & 0xFF;
    sendBuf[grootteArray - 2] = crc >> 16;

De code lijkt wel korter, maar kan het bijvoorbeeld niet zijn dat het schuiven van de bits traag gaat?

edit:
Foutje in code en quote gebruikt ipv code

[D-Three]

Gelieve niet op voorgaande post te letten.
De laatste code werkt niet (dunno why). Ik kan jammergenoeg mijn post niet meer editen: "Helaas, je bericht is al gewijzigd door een moderator. Je kunt dit bericht niet meer wijzigen."
Pfff, heb dit bijna altijd als ik mijn post ge-edit heb.

[Olaf van der Spek]

Je moet ook >> 8 doen en niet >> 16.

[D-Three]

Op vrijdag 01 maart 2002 15:43 schreef OlafvdSpek het volgende:
Je moet ook >> 8 doen en niet >> 16.

Ik zou zelfs gezworen hebben dat het met 16 moest...
Pff, het is mijn dagje niet vandaag! Nu ja, enig idee of dit sneller is? Ik heb zelfs nog gehoord dat je het schuiven van bits nog kunt opsplitsen zodat het nog sneller gaat.

[.oisyn]

schuiven van bits is veel sneller dan een deling idd (hoewel het tegenwoordig niet eens zoveel meer uitmaakt )

Maar bitsschuiven kun je met elk beschikbaar register doen, terwijl je bij een deling altijd bepaalde registers moet gebruiken, dus wat dat betreft is het ook beter te optimaliseren