Mail Archives: cygwin/2009/03/26/05:12:21
I addedd __attrubute__((packed)) to both structures and that made it
all work as supposed to. Adding "packed" to the sample_pkg_t only
saved 2 bytes, adding it to sample_t saved the rest down to 396 so
obviously that structure is poorly aligned.
The ultimate solution would be to use an aligned structure intstead of
working around the problem like above, but this is good enough for me
at this point.
Best Regards
Mikael
2009/3/26 Mikael Normark <normark DOT mikael AT gmail DOT com>:
> Endianness seemed a bit unlikely to begin with and after checking the
> first three values (type, pkg_nr, nr_samples) I found that they were
> the same, and correct, on both systems so endianness is not the
> problem.
> I checked the size of int and long long on both systems and found that
> they were the same but when I checked sizeof(struct sample_pkt_t) it
> returned 396 on Ubuntu and 528 on Cygwin so I need to find a
> workaround for the adressing issue, perhaps that solves the problem.
>
>
> 2009/3/26 Mikael Normark <normark DOT mikael AT gmail DOT com>:
>> Hi,
>> I have an application which reads data from TCP/IP packets and writes
>> it to a file. The program works fine on Ubuntu but now I need it to
>> run on my laptop (Vista) so I built it in Cygwin (without problems).
>>
>> The packet data is read into a struct:
>>
>> ------------------------------------------------------------------------=
--------
>> // Holdning the raw sample data and timestamp when
>> // the sample was fetched.
>> struct sample_t{
>> =A0 =A0int sample;
>> =A0 =A0long long timestamp;
>> };
>>
>> // A package that will hold samples data over
>> // the TCP transfer.
>> struct sample_pkg_t{
>> =A0 =A0unsigned int type; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0//Should always be PKG_SAMPLES
>> =A0 =A0unsigned int pkg_nr; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0//Counter increased for each package
>> =A0 =A0unsigned int nr_samples; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 // Shouldbe same as ADC_SAMPLES_IN_PKG
>> =A0 =A0struct sample_t sample[SAMPLES_IN_PKG]; // The samples data
>> };
>> ------------------------------------------------------------------------=
--------
>>
>> And the code where the data is written looks like this:
>>
>> for(si =3D 0; si < sample_pkg->nr_samples; si++){
>> =A0 =A0 =A0 timestamp =3D sample_pkg->sample[si].timestamp;
>>
>> =A0 =A0 =A0 unsigned int secs =3D (timestamp>>32);
>> =A0 =A0 =A0 long long nsecs =3D ((timestamp>>17 & 0x7FFF) * 1000000000)/=
3277; //32768
>>
>> =A0 =A0 =A0 // Save as a line with format (channel <tab> timestamp <tab>=
sample)
>> =A0 =A0 =A0 // timestamp is NTP format e.g. seconds since 1 Jan 1900
>> =A0 =A0 =A0 sprintf(buf, "%d\t%u%010llu\t%d\n", i, secs, nsecs,
>> sample_pkg->sample[si].sample);
>> =A0 =A0 =A0 fwrite (buf , 1 , strlen(buf) , pFile );
>> }
>>
>> The program works fine on Ubuntu but when I run it in Cygwin (yes,
>> built in Cygwin from source ;) the secs and nsecs values make no sense
>> whatsoever. Typical Ubuntu output:
>>
>> 0 =A0 =A0 =A0 34451499217497700000 =A0 =A024215
>> 0 =A0 =A0 =A0 34451499217689300000 =A0 =A023418
>> 0 =A0 =A0 =A0 34451499217908100000 =A0 =A023022
>> 0 =A0 =A0 =A0 34451499218099400000 =A0 =A022887
>> 0 =A0 =A0 =A0 34451499218291100000 =A0 =A023083
>> 0 =A0 =A0 =A0 34451499218482400000 =A0 =A023956
>> 0 =A0 =A0 =A0 34451499218701200000 =A0 =A022929
>> 0 =A0 =A0 =A0 34451499218892500000 =A0 =A023706
>>
>> Typical Cygwin output:
>>
>> 0 =A0 =A0 =A0 20601241600000000000 =A0 =A01883963392
>> 0 =A0 =A0 =A0 14987793713 =A0 =A0 1
>> 0 =A0 =A0 =A0 256220000000000 25221
>> 0 =A0 =A0 =A0 24007802880000000000 =A0 =A0-1976369152
>> 0 =A0 =A0 =A0 15780897162 =A0 =A0 1
>> 0 =A0 =A0 =A0 257650000000000 23954
>> 0 =A0 =A0 =A0 27414364160000000000 =A0 =A0-1635713024
>> 0 =A0 =A0 =A0 16574000610 =A0 =A0 1
>> 0 =A0 =A0 =A0 250970000000000 24616
>>
>> First thing that came to my mind was endianness, after doing a simple
>> test I determined that both computers are little endian as expected.
>> As the data in the IP packet is big endian (right?) I wonder if there
>> is any difference between Ubuntu/Cygwin in how (or IF) they handle the
>> transition before the data reaches the application?
>>
>> Any input on what the problem could be, or on how to determine what
>> the problem is, is greatly appreciated.
>>
>> Best Regards,
>> Mikael Normark
>>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -