[C] u16 'verspreid' in een char* krijgen

[LauPro]

De volgende situatie:

C:

unsigned char * data;
u16 value;
[..]
data[0] = 0x02;
data[1] = (u8)u16;
data[2] = ?;

In de code wordt een char* gebruikt als 'packet'. Deze wordt opgebouwd afhankelijk van de situatie om een interface aan te sturen. Nu is het zo dat dit vrij 'hardcore' is en de bits op de juiste plek moeten staan. Echter nu moet op ple #1 en #2 van data de waarde van de u16 komen. Nu ben ik al aan het spelen geweest met bitwise operators, maar dat werd niet veel soeps. Andere optie zou zijn om het geheel in een struct te duwen met een u8 en een u16. Maar dan heb ik erg veel structs nodig. Is er een eenvoudige manier om de u16 over de twee 'chars' te spreiden?

[ Voor 4% gewijzigd door LauPro op 18-07-2006 21:32 ]

[NMe]

8 bits naar rechts shiften?

C:

data[2] = (u8)(u16 >> 8);

[LauPro]

Ik heb het idee dat dat de helft is? Als ik het volgende doe:

C:

value = 1024;
data[1] = (u8)(value);
data[2] = (u8)(value >> 8);

Dan komt er resp data[1]=4 en data[2]=4 uit. Ipv 66 04?

[NMe]

1024 = 0b10000000000
Dat opsplitsen in groepen van 8 levert 00000000 voor data[1] en 00000100 voor data[2]. Je zou dus zeggen dat er de waarden 0 en 4 in moeten staan.

[LauPro]

Het verschil zie ik geloof ik al, er moet nog little endian decoding overheen.

[MLM]

dit zou ik doen

C++:

data[0] = 0x02;
memcpy(data + 1, &value, 2);

[LauPro]

Probleem is op zich deels opgelost, echter heb ik nu een nieuwe probleem. Het volgende is namelijk het geval: er moet een packet worden gegenereerd waar data {0x03,0xff} is. Dit staat gelijk aan 1024 echter dan met little endian decoding (afaik op dit moment).

Als ik over de hele u16 cpu_to_be16 los laat (we zijn in kernel space dus) dan krijg ik 4. Dit klopt op zich echter wil ik geen 4 (resp. {0x00,0x04}) maar {0x03,0xff} . Ben het spoor een beetje beister nu .

[Super_ik]

ik denk dat je little endian niet heltzelfde is als wat jij bedoelt, volgens mij bedoel je 2=complement ofzo

[DroogKloot]

Je lijkt er om de een of andere reden vrij gebrand op te zijn om niet je data-ushort bitwise te splitsen maar om de hexadecimale representatie ervan letterlijk in twee even lange delen te breken (0x03ff ==> 0x03 0xff), en daar zul je toch net iets creatievers voor moeten bedenken.

[ Voor 23% gewijzigd door DroogKloot op 18-07-2006 23:09 ]

[Soultaker]

LauPro schreef op dinsdag 18 juli 2006 @ 22:38:
Probleem is op zich deels opgelost, echter heb ik nu een nieuwe probleem. Het volgende is namelijk het geval: er moet een packet worden gegenereerd waar data {0x03,0xff} is. Dit staat gelijk aan 1024 echter dan met little endian decoding (afaik op dit moment).

Je verhaal klopt voor geen meter. 1024 is echt gewoon 0x0400; in little endian dus 0x04 gevolgd door 0x00. 0x03ff is gewoon 1023. Als je 1023 little-endian wil opslaan kan je gewoon de suggestie van -NMe- toepassen.

Als ik over de hele u16 cpu_to_be16 los laat (we zijn in kernel space dus) dan krijg ik 4. Dit klopt op zich echter wil ik geen 4 (resp. {0x00,0x04}) maar {0x03,0xff} . Ben het spoor een beetje beister nu .

Anders wij wel. Als je nu bedenkt wat je wil (en dat is blijkbaar niet een 16-bits integer opslaan in twee bytes) dan kunnen wij misschien helpen.

[Verwijderd]

LauPro schreef op dinsdag 18 juli 2006 @ 21:59:
Het verschil zie ik geloof ik al, er moet nog little endian decoding overheen.

Als dat 't geval is, moet je gewoon de toewijzing van data[1] en data[2] omdraaien.

Edit: had de rest nog niet gelezen, maar {0x03,0xff} is doodgewoon big endian, alleen is 't geen 1024...

[ Voor 18% gewijzigd door Verwijderd op 18-07-2006 23:42 ]

[LauPro]

Ok, zal het verhaal wat verduidelijken (zitten idd wat onregelmatigheden in mijn verhaal):

Ik heb de volgende gegevens:
Input 0; te zenden: {0x00,0x00}
Input 887; te zenden: {0x03,0x77}
Input 1023; te zenden: {0x03,0xff}

Echter nu heb ik dus bijvoorbeeld de waarde 1023 en deze moet dus in een char* komen te staan (niet de hex-waarde natuurlijk). Maar eigenlijk heb ik het idee dat ik met de info uit dit topic er wel zou moeten komen.

[Verwijderd]

Ik ben geen C-kenner (als in: nog nooit een regel C geschreven), maar 't zou iets worden als:

C:

data[1] = (u8)(value >> 8);
data[2] = (u8)(value);

[ Voor 16% gewijzigd door Verwijderd op 18-07-2006 23:55 ]

[LauPro]

Het zat hem dus toch in de 1023, wat Afterlife zegt is correct. Maar omdat ik er telkens 1024 in gooide ging de char over de kop en werd bij weer 0x00 ipv 0xff .

Inmiddels werkt het uitstekend, mijn dank .

[ Voor 5% gewijzigd door LauPro op 19-07-2006 00:03 ]

[Soultaker]

Dat zei -NMe- dus al in de eerste reactie, maar toch fijn dat je Afterlife even bedankt voor zijn reactie die niets bijdroeg aan het topic.

[LauPro]

Ik weet dat -NME- dat ook al (min of meer, de volgorde is anders) zei, alleen het zat hem dus in de combinatie van de 1023 en de oplossing van -NME-. Overigens wilde ik iedereen bedanken met mijn laatste regel van mijn vorige bericht .

[ Voor 9% gewijzigd door LauPro op 19-07-2006 00:20 ]

[farlane]

Je zou em ook in een union + struct kunnen zetten en de bytes eruit halen ( al dan niet omgedraaid ).

[ Voor 11% gewijzigd door farlane op 19-07-2006 01:15 ]

[LauPro]

Probleem is dat er verschillende formaten van packets zijn. Het lijkt me wat overkill om dat per type een struct te gaan maken voor slechts 2 variabelen. Maar mocht ik het in de toekomst nodig hebben zeker een aanrader idd.

[Verwijderd]

Soultaker schreef op woensdag 19 juli 2006 @ 00:11:
maar toch fijn dat je Afterlife even bedankt voor zijn reactie die niets bijdroeg aan het topic.

Was inderdaad niet zo'n zinvolle bijdrage: ik was meer bezig met het uitvogelen van hoe 't in C werkt dan met het volgen van 't topic. Mijn excuses daarvoor.

[farlane]

LauPro schreef op woensdag 19 juli 2006 @ 12:39:
Probleem is dat er verschillende formaten van packets zijn. Het lijkt me wat overkill om dat per type een struct te gaan maken voor slechts 2 variabelen. Maar mocht ik het in de toekomst nodig hebben zeker een aanrader idd.

Afhankelijk van de structuur van je protocol kunnen alle verschillende packets kwijt in 1 struct/union.