Re: [Usbpicprog-technical] [usbpicprog-technical] Difference between gcc (mingw) and msvc

[Francesco <f18...@ya...>]

Hi,
   I've pushed a few other commits which
1) adds debug precompiled binaries to the win\deps folder, so that
testing & debugging the Windows port of upp should now be easier (by
building upp_wx using the "Static Debug" configuration of MSVC project
files);
2) introduces some done-by-hand changes in uppmainwindow_base.cpp
which theorically is wxFormBuilder-generated; this fixes a resizing
problem I noticed since a long time ago ;)

I've also uploaded the r836 releases on the usbpicprog server but
unfortunately I had few time to test them... anyway hopefully we
should be very near to perfection now :)
Tomorrow I'll test these releases on my virtualized WinXP and I'll try
to get my hands on a copy of Windows Vista (thanks MSDNAA!) to test
the installation on that OS, too.

Francesco


2010/3/1 Francesco <f18...@ya...>:
> 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
>