Menu
▾
▴
usbpicprog-technical
|
From: Frans S. <fra...@gm...> - 2010-03-01 15:30:44
|
Hi,
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).
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[], 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;
The pre-834 versions of usbpicprog are thus completely useless.
Also the libusb-1.0 without pthread is out now, so I updated the x86 dll in svn.
Francesco, could you build version 834 adm64 with the new libusb-1.0?
Frans
|
|
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
|
|
From: Francesco <f18...@ya...> - 2010-03-02 00:05:59
|
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
>
|
|
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
|
|
From: Francesco <f18...@ya...> - 2010-03-02 19:36:31
|
2010/3/2 Frans Schreuder <fra...@gm...>: > 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? sorry! I built it against wx trunk (unfortunately wx2.9.1 is not out yet but I hope it will be soon). In the meanwhile I committed a small fix (which disables the new nice features of wxStatusBar like tooltips and ellipsization) for building against wx2.9.0. Francesco |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X