Menu
▾
▴
Re: [Usbpicprog-technical] [usbpicprog-technical] Difference between gcc (mingw) and msvc
|
From: Francesco <f18...@ya...> - 2010-03-01 19:01:58
|
Hi Frans,
2010/3/1 Frans Schreuder <fra...@gm...>:
> I found a problem in the usbpicprog windows version which seemed to
> exist since we moved to libusb-1.0.
> The problem was that 3 bytes of data were added to every data package
> while programming. I first thought this might be a problem with
> libusb-1.0-win32, but it is a difference between mingw and msvc. (I also
> moved from mingw to msvc 2008 at the same time).
ouch. Unfortunately I didn't have time to effectively test the
programmed PICs in a real circuits recently so I didn't notice this
problem! (I just trusted UPP when it was saying that the programming
was successful).
> The difference is the way this union was being handled:
>
> 146typedef union
> 147{
> 148 struct
> 149 {
> 150 unsigned cmd:8; /// One of the CMD_ defines above
> 151 unsigned size:8; /// Size of the datafield
> 152 unsigned addrU:8; /// The address is devided in 3 bytes, Upper, High and Low
> 153 unsigned addrH:8;
> 154 unsigned addrL:8;
> 155 unsigned blocktype:8; /// The blocktype can be middle, first or last (or first|last)
> 156 unsigned char dataField[32];
> 157 } fields;
> 158 unsigned char data[38];
> 159} UppPackage;
>
> msvc added 3 bytes between blocktype and dataField in data[],
maybe this is because of some required data alignment?
I think there exist flags which force MSVC to avoid stuffing
additional bytes in a structure but I'd need to look how they can be
used...
> so I changed it into
>
> 144typedef enum
> 145{
> 146 up_cmd,
> 147 up_size,
> 148 up_addrL,
> 149 up_addrH,
> 150 up_addrU,
> 151 up_blocktype,
> 152 up_data
> 153}UPP_INDEX;
> 154/**
> 155 UppPackage is the data header which is sent to the programmer hardware.
> 156*/
> 157typedef struct
> 158{
> 159 /*struct
> 160 {
> 161 unsigned cmd:8; /// One of the CMD_ defines above
> 162 unsigned size:8; /// Size of the datafield
> 163 unsigned addrU:8; /// The address is devided in 3 bytes, Upper, High and Low
> 164 unsigned addrH:8;
> 165 unsigned addrL:8;
> 166 unsigned blocktype:8; /// The blocktype can be middle, first or last (or first|last)
> 167 unsigned char dataField[32];
> 168 } fields;*/
> 169 unsigned char data[38];
> 170} UppPackage;
this has the drawback that basically UppPackage is seen by the
compiler as a homogeneous set of bytes; i.e. basically UppPackage is
an untyped array.
This theorically makes easier to write bugs in the code, even if I see
that the modifications in hardware.cpp are fairly straightforward...
> Also the libusb-1.0 without pthread is out now, so I updated the x86 dll in svn.
hmmm, I already updated the win\deps stuff in r832 with the new libusb
without pthread dependency (and in fact I removed pthread.lib/dll from
the repo).
I see that the libusb-1.0.dll that you committed is 599kbytes while
the one I had built was 135 kbytes. Perhaps did you build it in debug
mode?
All other deps I placed in win\deps are built in release mode because
that's the cfg to use when producing final releases for the end user
(I wrote something about the build mode used for all deps in
http://usbpicprog.svn.sourceforge.net/viewvc/usbpicprog/trunk/upp_wx/win/deps/info.txt?revision=815&view=markup).
Anyway it would be important to avoid mixing different flags (like
e.g. /MD or /MT or those regarding optimization or debug infos) in the
precompiled binaries which we provide.
Maybe we should have win\deps\release and win\deps\debug folders
containing the x86 and amd64 precompiled binaries to make it easier
also the development process instead of only the release process...
> Francesco, could you build version 834 adm64 with the new libusb-1.0?
sure. I'll do it this evening as soon as I get back home and upload
the result on the server.
Francesco
|
