Menu
▾
▴
Re: [Usbpicprog-technical] [usbpicprog-technical] Difference between gcc (mingw) and msvc
|
From: Frans S. <fra...@gm...> - 2010-03-02 12:10:34
|
Hi Francesco,
On Tue, 2010-03-02 at 01:05 +0100, Francesco wrote:
> 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);
Looks good.
> 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 ;)
Nice, but it doesn't compile against wxWidgets 2.9.0. Are you using the
trunk again?
>
> 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
> >
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
|
