Menu
▾
▴
usbpicprog-technical
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(13) |
Nov
(27) |
Dec
(23) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(13) |
Mar
(24) |
Apr
(4) |
May
(11) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(5) |
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
(22) |
Mar
(52) |
Apr
(7) |
May
(19) |
Jun
(12) |
Jul
(9) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(8) |
Dec
(7) |
| 2011 |
Jan
(12) |
Feb
(7) |
Mar
(10) |
Apr
(14) |
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(12) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
|
Dec
|
| 2013 |
Jan
(7) |
Feb
(6) |
Mar
(6) |
Apr
(21) |
May
(7) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Frans S. <fra...@gm...> - 2010-03-24 08:59:35
|
Hi Mark, Oops... Francesco has changed something in the .vcproj file, you have to build wxWidgets using MONOLITHIC = 0 now. Frans On 3/24/2010 8:47, Frans Schreuder wrote: > Hi Mark, > > I also used to build usbpicprog with wxDev-C++, but since we switched > over to libusb-1.0, it is also better to build the application using > Microsoft Visual Studio 2008. (A free version is available). > There is an issue with libusb-1.0 and the mingw compiler (I believe > especially for the 64 bit version) that made us switch over to MSVC. > > To build wxWidgets for msvc, you need to do these steps: > -download and extract wxWidgets-2.9.0 > -download and install MS visual studio 2008 > -edit wxWidgets-2.9.0\build\msw\config.vc and change the line > "MONOLITHIC = 1" (it used to be 0) > -start the "ms Visual Studio 2008 command prompt" which is in fact > just cmd.exe with some environment variables set > -cd wxWidgets\build\msw > -nmake -f makefile.vc > -set an environment variable WXWIN with the value c:\wxWidgets-2.9.0 > (or wherever you have compiled it) and don't forget to reboot afterwards > -now open the right usbpicprog project > (usbpicprog\trunk\upp_wx\build\win\upp_wx_vc2008.vcproj) > -you might have to set some include directories, or move around with > some files if it doesn't compile right away, but in fact it should > compile now! > > Good luck! > > Frans > > > On 3/24/2010 3:28, Mark Jones wrote: >>> 2010/3/12 Mark Jones<hel...@gm...>: >>>> Hello friends, I've been having some difficulty using the UPP in >>>> Windows 7 32-bit. The software and drivers appear to install and run >>>> correctly, and the UPP firmware can be updated and verified >>>> successfully, but I can not read or write to a target 18LF2553, >>>> 16F628, or 16F84A. I'd be happy to test and debug what I can. >>>> .... >>> Hi Mark, >>> Can you retest against latest revision of the trunk? I think r864 >>> should have fixed the programming problems... >>> >>> Francesco >> Hi Francesco, today is as good as any to learn some C++ eh? : ) I >> decided to try setting up a build environment for UsbPicProg. I >> installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be >> better-suited to developing wxWidgets-based applications), installed >> TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to >> libusb.h, but then got stuck on the wxWidgets dependency. I know it >> needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go >> where? The folder tree is rather complex, and wxWidgets can be >> compiled in an alarming number of ways. Even tried doing "configure" >> under MSYS. I'll keep plugging away at it, but any additional hints >> would be very helpful. >> >> I can also "build" wxWidgets-2.9.0 according to >> http://wxdsgn.sourceforge.net/?q=node/9 but I have not tried >> installing this as a DevPak in wxDev-C++ (and really doubt it would >> work anyways.) >> >> Mark >> >> ------------------------------------------------------------------------------ >> >> 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: Frans S. <fra...@gm...> - 2010-03-24 07:47:25
|
Hi Mark, I also used to build usbpicprog with wxDev-C++, but since we switched over to libusb-1.0, it is also better to build the application using Microsoft Visual Studio 2008. (A free version is available). There is an issue with libusb-1.0 and the mingw compiler (I believe especially for the 64 bit version) that made us switch over to MSVC. To build wxWidgets for msvc, you need to do these steps: -download and extract wxWidgets-2.9.0 -download and install MS visual studio 2008 -edit wxWidgets-2.9.0\build\msw\config.vc and change the line "MONOLITHIC = 1" (it used to be 0) -start the "ms Visual Studio 2008 command prompt" which is in fact just cmd.exe with some environment variables set -cd wxWidgets\build\msw -nmake -f makefile.vc -set an environment variable WXWIN with the value c:\wxWidgets-2.9.0 (or wherever you have compiled it) and don't forget to reboot afterwards -now open the right usbpicprog project (usbpicprog\trunk\upp_wx\build\win\upp_wx_vc2008.vcproj) -you might have to set some include directories, or move around with some files if it doesn't compile right away, but in fact it should compile now! Good luck! Frans On 3/24/2010 3:28, Mark Jones wrote: >> 2010/3/12 Mark Jones<hel...@gm...>: >> >>> Hello friends, I've been having some difficulty using the UPP in >>> Windows 7 32-bit. The software and drivers appear to install and run >>> correctly, and the UPP firmware can be updated and verified >>> successfully, but I can not read or write to a target 18LF2553, >>> 16F628, or 16F84A. I'd be happy to test and debug what I can. >>> .... >>> >> Hi Mark, >> Can you retest against latest revision of the trunk? I think r864 >> should have fixed the programming problems... >> >> Francesco >> > Hi Francesco, today is as good as any to learn some C++ eh? : ) I > decided to try setting up a build environment for UsbPicProg. I > installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be > better-suited to developing wxWidgets-based applications), installed > TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to > libusb.h, but then got stuck on the wxWidgets dependency. I know it > needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go > where? The folder tree is rather complex, and wxWidgets can be > compiled in an alarming number of ways. Even tried doing "configure" > under MSYS. I'll keep plugging away at it, but any additional hints > would be very helpful. > > I can also "build" wxWidgets-2.9.0 according to > http://wxdsgn.sourceforge.net/?q=node/9 but I have not tried > installing this as a DevPak in wxDev-C++ (and really doubt it would > work anyways.) > > Mark > > ------------------------------------------------------------------------------ > 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: Mark J. <hel...@gm...> - 2010-03-24 02:28:59
|
>2010/3/12 Mark Jones <hel...@gm...>: >> Hello friends, I've been having some difficulty using the UPP in >> Windows 7 32-bit. The software and drivers appear to install and run >> correctly, and the UPP firmware can be updated and verified >> successfully, but I can not read or write to a target 18LF2553, >> 16F628, or 16F84A. I'd be happy to test and debug what I can. >>.... > > Hi Mark, > Can you retest against latest revision of the trunk? I think r864 > should have fixed the programming problems... > > Francesco Hi Francesco, today is as good as any to learn some C++ eh? : ) I decided to try setting up a build environment for UsbPicProg. I installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be better-suited to developing wxWidgets-based applications), installed TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to libusb.h, but then got stuck on the wxWidgets dependency. I know it needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go where? The folder tree is rather complex, and wxWidgets can be compiled in an alarming number of ways. Even tried doing "configure" under MSYS. I'll keep plugging away at it, but any additional hints would be very helpful. I can also "build" wxWidgets-2.9.0 according to http://wxdsgn.sourceforge.net/?q=node/9 but I have not tried installing this as a DevPak in wxDev-C++ (and really doubt it would work anyways.) Mark |
|
From: Gustav J. <gu...@ne...> - 2010-03-23 18:27:15
|
Hi Frans, I apologize for not telling you that those two were broken. I noticed when I checked the files after I uploaded them and the libiconv.dylib is actually missing in them, and I believe the error is due to that rather than being the wrong version. The problem was the line in the script which loops through the libraries to install, it did not end with a space and thus did only install the first library. It has been fixed and both libraries are installed properly now. Since I did this, I have set up a "nightly" script that builds if the svn has been updated, but it has taken me a couple of days since I managed a careless rm * instead of rm *~... so I had to start over. Both builds *should* be uploaded tonight at about 3:45 AM CET. Hopefully, they will both work. In addition, I noticed that the cocoa-version for x86_64 did not build properly when set for 10.4 compatibility. I assume it is because 10.4 did not actually have support for 64-bit Intel. This has also been fixed now by using different compatibility settings for ppc/i386 vs. x86_64. I'll check the nightly build tomorrow morning, and if they seem to be working, I'll send you a mail and it would be great if you could check those again then to see if I managed to get everything right in the nightly scripts. Regards, Gustav On Tue, Mar 23, 2010 at 4:31 PM, Frans Schreuder <fra...@gm...> wrote: > Hi Gustav, > > I have tried your build on a clean osx 10.5 system. Both the cocoa and the > normal build give the same error about libiconv. I am affraid that the > libiconv.dylib that you have installed was either not built universal, or it > was built using gcc 4.2. > I have also built the latest revision r876 wich does seem to run on a clean > system. This version seems to work fine (I also fixed the configuration > flags appearance) > > > UsbPicProg-OSX-rexported.dmg (UsbPicProg-OSX-Cocoa-r872.dmg - buld gives > the same error report) > > Process: usbpicprog [770] > Path: > /Volumes/UsbPicProg/usbpicprog.app/Contents/MacOS/usbpicprog > Identifier: org.usbpicprog > Version: ??? (???) > Code Type: X86 (Native) > Parent Process: launchd [92] > > Date/Time: 2010-03-23 08:11:43.203 -0700 > OS Version: Mac OS X 10.5.2 (9C31) > Report Version: 6 > > Exception Type: EXC_BREAKPOINT (SIGTRAP) > Exception Codes: 0x0000000000000002, 0x0000000000000000 > Crashed Thread: 0 > > Dyld Error Message: > Library not loaded: @executable_path/../SharedSupport/libiconv.dylib > Referenced from: > /Volumes/UsbPicProg/usbpicprog.app/Contents/MacOS/usbpicprog > Reason: Incompatible library version: usbpicprog requires version 8.0.0 or > later, but libiconv.2.dylib provides version 7.0.0 > > > Regards, > > Frans > > On Fri, 2010-03-19 at 23:56 +0100, Gustav Johansson wrote: > > Hi Frans, > > tried your build now, and it seems to work fine! Although I think that > what you've added was added already. In the end of each ./configure > line I had put in the CC=gcc+4.0 and the DEPLOYMENT_TARGET is set via > the $sdk_flags. But better safe than sorry, right? ;) > > I've just uploaded two snapshot version of the r872, one carbon (named > rexported due to a typo, already fixed and commited, but I want to > test my nightly scripts, so hopfully there will be two r873 builds in > the morning) and one cocoa. Please test them and see if they work. > They do work on my Intel 10.6 and on my PPC 10.5. But they both have > MacPorts installed, so I can't (or haven't, at least) tested them for > library content... > > Cheers, > Gustav > > On Fri, Mar 19, 2010 at 5:33 PM, Gustav Johansson <gu...@ne...> wrote: >> Hi Frans, >> >> I'll try it tonight, I'm not at home at the moment... >> >> Cheers, >> Dr. Gustav Johansson >> >> >> On 19 mar 2010, at 17.23, Frans Schreuder <fra...@gm...> >> wrote: >> >>> Hi Gustav, >>> >>> As you can see in the buildmac.sh script (and also in the >>> install_wxWidgets.sh script) I have added >>> >>> export MACOSX_DEPLOYMENT_TARGET=10.4 >>> export CC="gcc-4.0" >>> >>> I also added libiconv.dylib because it wouldn't run if you didn't have >>> it installed from macports. >>> I think you will also need to build wxWidgets again with gcc-4.0 (as >>> well as some other libraries) >>> >>> Could you try 869M, the one that I have uploaded to >>> usbpicprog.org/downloads? >>> >>> Cheers, >>> >>> Frans >>> >>> >>> Gustav Johansson schreef: >>>> >>>> Hi Frans! >>>> >>>> I have not uploaded any of the "fixed" builds, I was going to >>>> yesterday but the FTP didn't work... I'll upload one of my snapshots >>>> tonight and we'll see if they work then. I've also managed to build >>>> for cocoa, so if you can test that build as well it would be great! >>>> >>>> Cheers, >>>> Dr. Gustav Johansson >>>> >>>> >>>> On 19 mar 2010, at 16.39, Frans Schreuder <fra...@gm... >>>> <mailto:fra...@gm...>> wrote: >>>> >>>>> Hi Gustav, >>>>> >>>>> I have tried the .dmg on an intel 10.5 system, and it didn't seem to >>>>> work because it was compiled using gcc 4.2. >>>>> I compiled it using gcc 4.0 and modified buildmac.sh. >>>>> I think the latest one does now run on 10.4, 10.5 and 10.6. >>>>> Also libiconv has been included in the .app now. >>>>> >>>>> Cheers, >>>>> >>>>> Frans >>>>> >>>>> On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>> Since I'm new to this mailing-list, I apologize in advance if I break >>>>>> some rules... If I do, just tell me and I won't do it again! :) >>>>>> >>>>>> I've been working on creating a universal build for OS X of the >>>>>> usbpicprog.app, and I think I've got it now. Attached are two files, >>>>>> one disk image containing a freshly built usbpicprog.app that *should* >>>>>> work on both Intel and PPC Macs, from 10.4 and up. I've tested it on >>>>>> an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not >>>>>> however have a usb-programmer yet, so I have not tested the >>>>>> programming functionality. If you can help out by testing, please do >>>>>> so and tell me about any problems. >>>>>> >>>>>> If there is an interest in it, I can setup a cron-job and built >>>>>> "nigthly" builds of usbpicprog for OS X and upload the disk images to >>>>>> wherever is suitable. >>>>>> >>>>>> The second file is a couple of scripts and a README file with >>>>>> information on how you can build this yourself. I used a lot of the >>>>>> info by Lukas Zeller, and only had to do a bit of tweaking to get it >>>>>> to work. >>>>>> >>>>>> The main problem that Lukas Zeller saw was the libiconv linking, which >>>>>> was almost correct. The problem is not with the MacPorts libiconv, but >>>>>> rather that Apple ships with a number of libiconv versions, some of >>>>>> which takes precedence over the MacPorts version. The solution is to >>>>>> force wxWidgets to use the MacPorts version by using a configure flag. >>>>>> For more information, see the install_wxWidgets.sh script. >>>>>> >>>>>> There is however another issue that can mess stuff up. libtool! Again, >>>>>> Apple ships there own "special" version of libtool/libtoolize, which >>>>>> is NOT compatible with the GNU version. Unfortunately, stuff breaks in >>>>>> OS X if you overwrite Apple's version, and thus MacPorts have solved >>>>>> this by renaming libtool to glibtool and glibtoolize. To get >>>>>> everything to compile correctly, I had to make a symlink from >>>>>> /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of >>>>>> course). This makes everything build fine, but is a bit of a hack >>>>>> since I have to remove this symlinks after the build is complete or OS >>>>>> X will mess stuff up when installing other programs. The best way >>>>>> would be to make the configure/autogen.sh scripts to realize that >>>>>> they're building on a Mac and change from libtool to glibtool... >>>>>> >>>>>> I think that was all. Hope it works for everyone else as well! >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> 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... >>>>>> <mailto:Usb...@li...> >>>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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... >>>>> <mailto:Usb...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >> > > > > > > ------------------------------------------------------------------------------ > 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 > > -- Dr. Gustav Johansson Skrantahöjdsvägen 52A, 1tr SE-691 46 Karlskoga, Sweden +46 70 654 8666 |
|
From: Frans S. <fra...@gm...> - 2010-03-23 15:33:42
|
Dear all, I think the latest version of usbpicprog 876 seems to be running quite stable on all systems (win 32 / 64, osx universal and ubuntu) What do you think, is it time for a beta release of version 0.3.1? Frans |
|
From: Frans S. <fra...@gm...> - 2010-03-23 15:31:42
|
Hi Gustav, I have tried your build on a clean osx 10.5 system. Both the cocoa and the normal build give the same error about libiconv. I am affraid that the libiconv.dylib that you have installed was either not built universal, or it was built using gcc 4.2. I have also built the latest revision r876 wich does seem to run on a clean system. This version seems to work fine (I also fixed the configuration flags appearance) UsbPicProg-OSX-rexported.dmg (UsbPicProg-OSX-Cocoa-r872.dmg - buld gives the same error report) Process: usbpicprog [770] Path: /Volumes/UsbPicProg/usbpicprog.app/Contents/MacOS/usbpicprog Identifier: org.usbpicprog Version: ??? (???) Code Type: X86 (Native) Parent Process: launchd [92] Date/Time: 2010-03-23 08:11:43.203 -0700 OS Version: Mac OS X 10.5.2 (9C31) Report Version: 6 Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Crashed Thread: 0 Dyld Error Message: Library not loaded: @executable_path/../SharedSupport/libiconv.dylib Referenced from: /Volumes/UsbPicProg/usbpicprog.app/Contents/MacOS/usbpicprog Reason: Incompatible library version: usbpicprog requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0 Regards, Frans On Fri, 2010-03-19 at 23:56 +0100, Gustav Johansson wrote: > Hi Frans, > > tried your build now, and it seems to work fine! Although I think that > what you've added was added already. In the end of each ./configure > line I had put in the CC=gcc+4.0 and the DEPLOYMENT_TARGET is set via > the $sdk_flags. But better safe than sorry, right? ;) > > I've just uploaded two snapshot version of the r872, one carbon (named > rexported due to a typo, already fixed and commited, but I want to > test my nightly scripts, so hopfully there will be two r873 builds in > the morning) and one cocoa. Please test them and see if they work. > They do work on my Intel 10.6 and on my PPC 10.5. But they both have > MacPorts installed, so I can't (or haven't, at least) tested them for > library content... > > Cheers, > Gustav > > On Fri, Mar 19, 2010 at 5:33 PM, Gustav Johansson <gu...@ne...> wrote: > > Hi Frans, > > > > I'll try it tonight, I'm not at home at the moment... > > > > Cheers, > > Dr. Gustav Johansson > > > > > > On 19 mar 2010, at 17.23, Frans Schreuder <fra...@gm...> wrote: > > > >> Hi Gustav, > >> > >> As you can see in the buildmac.sh script (and also in the > >> install_wxWidgets.sh script) I have added > >> > >> export MACOSX_DEPLOYMENT_TARGET=10.4 > >> export CC="gcc-4.0" > >> > >> I also added libiconv.dylib because it wouldn't run if you didn't have > >> it installed from macports. > >> I think you will also need to build wxWidgets again with gcc-4.0 (as > >> well as some other libraries) > >> > >> Could you try 869M, the one that I have uploaded to > >> usbpicprog.org/downloads? > >> > >> Cheers, > >> > >> Frans > >> > >> > >> Gustav Johansson schreef: > >>> > >>> Hi Frans! > >>> > >>> I have not uploaded any of the "fixed" builds, I was going to > >>> yesterday but the FTP didn't work... I'll upload one of my snapshots > >>> tonight and we'll see if they work then. I've also managed to build > >>> for cocoa, so if you can test that build as well it would be great! > >>> > >>> Cheers, > >>> Dr. Gustav Johansson > >>> > >>> > >>> On 19 mar 2010, at 16.39, Frans Schreuder <fra...@gm... > >>> <mailto:fra...@gm...>> wrote: > >>> > >>>> Hi Gustav, > >>>> > >>>> I have tried the .dmg on an intel 10.5 system, and it didn't seem to > >>>> work because it was compiled using gcc 4.2. > >>>> I compiled it using gcc 4.0 and modified buildmac.sh. > >>>> I think the latest one does now run on 10.4, 10.5 and 10.6. > >>>> Also libiconv has been included in the .app now. > >>>> > >>>> Cheers, > >>>> > >>>> Frans > >>>> > >>>> On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote: > >>>>> > >>>>> Hi! > >>>>> > >>>>> Since I'm new to this mailing-list, I apologize in advance if I break > >>>>> some rules... If I do, just tell me and I won't do it again! :) > >>>>> > >>>>> I've been working on creating a universal build for OS X of the > >>>>> usbpicprog.app, and I think I've got it now. Attached are two files, > >>>>> one disk image containing a freshly built usbpicprog.app that *should* > >>>>> work on both Intel and PPC Macs, from 10.4 and up. I've tested it on > >>>>> an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not > >>>>> however have a usb-programmer yet, so I have not tested the > >>>>> programming functionality. If you can help out by testing, please do > >>>>> so and tell me about any problems. > >>>>> > >>>>> If there is an interest in it, I can setup a cron-job and built > >>>>> "nigthly" builds of usbpicprog for OS X and upload the disk images to > >>>>> wherever is suitable. > >>>>> > >>>>> The second file is a couple of scripts and a README file with > >>>>> information on how you can build this yourself. I used a lot of the > >>>>> info by Lukas Zeller, and only had to do a bit of tweaking to get it > >>>>> to work. > >>>>> > >>>>> The main problem that Lukas Zeller saw was the libiconv linking, which > >>>>> was almost correct. The problem is not with the MacPorts libiconv, but > >>>>> rather that Apple ships with a number of libiconv versions, some of > >>>>> which takes precedence over the MacPorts version. The solution is to > >>>>> force wxWidgets to use the MacPorts version by using a configure flag. > >>>>> For more information, see the install_wxWidgets.sh script. > >>>>> > >>>>> There is however another issue that can mess stuff up. libtool! Again, > >>>>> Apple ships there own "special" version of libtool/libtoolize, which > >>>>> is NOT compatible with the GNU version. Unfortunately, stuff breaks in > >>>>> OS X if you overwrite Apple's version, and thus MacPorts have solved > >>>>> this by renaming libtool to glibtool and glibtoolize. To get > >>>>> everything to compile correctly, I had to make a symlink from > >>>>> /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of > >>>>> course). This makes everything build fine, but is a bit of a hack > >>>>> since I have to remove this symlinks after the build is complete or OS > >>>>> X will mess stuff up when installing other programs. The best way > >>>>> would be to make the configure/autogen.sh scripts to realize that > >>>>> they're building on a Mac and change from libtool to glibtool... > >>>>> > >>>>> I think that was all. Hope it works for everyone else as well! > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------------------ > >>>>> 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... > >>>>> <mailto:Usb...@li...> > >>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > >>>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> 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... > >>>> <mailto:Usb...@li...> > >>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> > >>> ------------------------------------------------------------------------------ > >>> 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 > >>> > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> 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: Gustav J. <gu...@ne...> - 2010-03-19 16:59:08
|
Hi Frans, I'll try it tonight, I'm not at home at the moment... Cheers, Dr. Gustav Johansson On 19 mar 2010, at 17.23, Frans Schreuder <fra...@gm...> wrote: > Hi Gustav, > > As you can see in the buildmac.sh script (and also in the > install_wxWidgets.sh script) I have added > > export MACOSX_DEPLOYMENT_TARGET=10.4 > export CC="gcc-4.0" > > I also added libiconv.dylib because it wouldn't run if you didn't have > it installed from macports. > I think you will also need to build wxWidgets again with gcc-4.0 (as > well as some other libraries) > > Could you try 869M, the one that I have uploaded to > usbpicprog.org/downloads? > > Cheers, > > Frans > > > Gustav Johansson schreef: >> Hi Frans! >> >> I have not uploaded any of the "fixed" builds, I was going to >> yesterday but the FTP didn't work... I'll upload one of my snapshots >> tonight and we'll see if they work then. I've also managed to build >> for cocoa, so if you can test that build as well it would be great! >> >> Cheers, >> Dr. Gustav Johansson >> >> >> On 19 mar 2010, at 16.39, Frans Schreuder <fra...@gm... >> <mailto:fra...@gm...>> wrote: >> >>> Hi Gustav, >>> >>> I have tried the .dmg on an intel 10.5 system, and it didn't seem to >>> work because it was compiled using gcc 4.2. >>> I compiled it using gcc 4.0 and modified buildmac.sh. >>> I think the latest one does now run on 10.4, 10.5 and 10.6. >>> Also libiconv has been included in the .app now. >>> >>> Cheers, >>> >>> Frans >>> >>> On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote: >>>> Hi! >>>> >>>> Since I'm new to this mailing-list, I apologize in advance if I >>>> break >>>> some rules... If I do, just tell me and I won't do it again! :) >>>> >>>> I've been working on creating a universal build for OS X of the >>>> usbpicprog.app, and I think I've got it now. Attached are two >>>> files, >>>> one disk image containing a freshly built usbpicprog.app that >>>> *should* >>>> work on both Intel and PPC Macs, from 10.4 and up. I've tested it >>>> on >>>> an Intel 10.6 and an PPC 10.5, and they both work just fine. I do >>>> not >>>> however have a usb-programmer yet, so I have not tested the >>>> programming functionality. If you can help out by testing, please >>>> do >>>> so and tell me about any problems. >>>> >>>> If there is an interest in it, I can setup a cron-job and built >>>> "nigthly" builds of usbpicprog for OS X and upload the disk >>>> images to >>>> wherever is suitable. >>>> >>>> The second file is a couple of scripts and a README file with >>>> information on how you can build this yourself. I used a lot of the >>>> info by Lukas Zeller, and only had to do a bit of tweaking to get >>>> it >>>> to work. >>>> >>>> The main problem that Lukas Zeller saw was the libiconv linking, >>>> which >>>> was almost correct. The problem is not with the MacPorts >>>> libiconv, but >>>> rather that Apple ships with a number of libiconv versions, some of >>>> which takes precedence over the MacPorts version. The solution is >>>> to >>>> force wxWidgets to use the MacPorts version by using a configure >>>> flag. >>>> For more information, see the install_wxWidgets.sh script. >>>> >>>> There is however another issue that can mess stuff up. libtool! >>>> Again, >>>> Apple ships there own "special" version of libtool/libtoolize, >>>> which >>>> is NOT compatible with the GNU version. Unfortunately, stuff >>>> breaks in >>>> OS X if you overwrite Apple's version, and thus MacPorts have >>>> solved >>>> this by renaming libtool to glibtool and glibtoolize. To get >>>> everything to compile correctly, I had to make a symlink from >>>> /opt/local/bin/glibtool to /opt/local/bin/libtool (and >>>> glibtoolize of >>>> course). This makes everything build fine, but is a bit of a hack >>>> since I have to remove this symlinks after the build is complete >>>> or OS >>>> X will mess stuff up when installing other programs. The best way >>>> would be to make the configure/autogen.sh scripts to realize that >>>> they're building on a Mac and change from libtool to glibtool... >>>> >>>> I think that was all. Hope it works for everyone else as well! >>>> >>>> --- >>>> --- >>>> --- >>>> --- >>>> ------------------------------------------------------------------ >>>> 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... >>>> <mailto:Usb...@li...> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >>>> >>> >>> --- >>> --- >>> --- >>> --- >>> ------------------------------------------------------------------ >>> 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... >>> <mailto:Usb...@li...> >>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >> --- >> --------------------------------------------------------------------- >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> 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 >> > > > --- > --- > --- > --------------------------------------------------------------------- > 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: Frans S. <fra...@gm...> - 2010-03-19 16:23:50
|
Hi Gustav, As you can see in the buildmac.sh script (and also in the install_wxWidgets.sh script) I have added export MACOSX_DEPLOYMENT_TARGET=10.4 export CC="gcc-4.0" I also added libiconv.dylib because it wouldn't run if you didn't have it installed from macports. I think you will also need to build wxWidgets again with gcc-4.0 (as well as some other libraries) Could you try 869M, the one that I have uploaded to usbpicprog.org/downloads? Cheers, Frans Gustav Johansson schreef: > Hi Frans! > > I have not uploaded any of the "fixed" builds, I was going to > yesterday but the FTP didn't work... I'll upload one of my snapshots > tonight and we'll see if they work then. I've also managed to build > for cocoa, so if you can test that build as well it would be great! > > Cheers, > Dr. Gustav Johansson > > > On 19 mar 2010, at 16.39, Frans Schreuder <fra...@gm... > <mailto:fra...@gm...>> wrote: > >> Hi Gustav, >> >> I have tried the .dmg on an intel 10.5 system, and it didn't seem to >> work because it was compiled using gcc 4.2. >> I compiled it using gcc 4.0 and modified buildmac.sh. >> I think the latest one does now run on 10.4, 10.5 and 10.6. >> Also libiconv has been included in the .app now. >> >> Cheers, >> >> Frans >> >> On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote: >>> Hi! >>> >>> Since I'm new to this mailing-list, I apologize in advance if I break >>> some rules... If I do, just tell me and I won't do it again! :) >>> >>> I've been working on creating a universal build for OS X of the >>> usbpicprog.app, and I think I've got it now. Attached are two files, >>> one disk image containing a freshly built usbpicprog.app that *should* >>> work on both Intel and PPC Macs, from 10.4 and up. I've tested it on >>> an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not >>> however have a usb-programmer yet, so I have not tested the >>> programming functionality. If you can help out by testing, please do >>> so and tell me about any problems. >>> >>> If there is an interest in it, I can setup a cron-job and built >>> "nigthly" builds of usbpicprog for OS X and upload the disk images to >>> wherever is suitable. >>> >>> The second file is a couple of scripts and a README file with >>> information on how you can build this yourself. I used a lot of the >>> info by Lukas Zeller, and only had to do a bit of tweaking to get it >>> to work. >>> >>> The main problem that Lukas Zeller saw was the libiconv linking, which >>> was almost correct. The problem is not with the MacPorts libiconv, but >>> rather that Apple ships with a number of libiconv versions, some of >>> which takes precedence over the MacPorts version. The solution is to >>> force wxWidgets to use the MacPorts version by using a configure flag. >>> For more information, see the install_wxWidgets.sh script. >>> >>> There is however another issue that can mess stuff up. libtool! Again, >>> Apple ships there own "special" version of libtool/libtoolize, which >>> is NOT compatible with the GNU version. Unfortunately, stuff breaks in >>> OS X if you overwrite Apple's version, and thus MacPorts have solved >>> this by renaming libtool to glibtool and glibtoolize. To get >>> everything to compile correctly, I had to make a symlink from >>> /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of >>> course). This makes everything build fine, but is a bit of a hack >>> since I have to remove this symlinks after the build is complete or OS >>> X will mess stuff up when installing other programs. The best way >>> would be to make the configure/autogen.sh scripts to realize that >>> they're building on a Mac and change from libtool to glibtool... >>> >>> I think that was all. Hope it works for everyone else as well! >>> >>> ------------------------------------------------------------------------------ >>> 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... <mailto:Usb...@li...> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >>> >> >> ------------------------------------------------------------------------------ >> 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... >> <mailto:Usb...@li...> >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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: Gustav J. <gu...@ne...> - 2010-03-19 16:18:44
|
Hi Frans! I have not uploaded any of the "fixed" builds, I was going to yesterday but the FTP didn't work... I'll upload one of my snapshots tonight and we'll see if they work then. I've also managed to build for cocoa, so if you can test that build as well it would be great! Cheers, Dr. Gustav Johansson On 19 mar 2010, at 16.39, Frans Schreuder <fra...@gm...> wrote: > Hi Gustav, > > I have tried the .dmg on an intel 10.5 system, and it didn't seem to > work because it was compiled using gcc 4.2. > I compiled it using gcc 4.0 and modified buildmac.sh. > I think the latest one does now run on 10.4, 10.5 and 10.6. > Also libiconv has been included in the .app now. > > Cheers, > > Frans > > On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote: >> >> Hi! >> >> Since I'm new to this mailing-list, I apologize in advance if I break >> some rules... If I do, just tell me and I won't do it again! :) >> >> I've been working on creating a universal build for OS X of the >> usbpicprog.app, and I think I've got it now. Attached are two files, >> one disk image containing a freshly built usbpicprog.app that >> *should* >> work on both Intel and PPC Macs, from 10.4 and up. I've tested it on >> an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not >> however have a usb-programmer yet, so I have not tested the >> programming functionality. If you can help out by testing, please do >> so and tell me about any problems. >> >> If there is an interest in it, I can setup a cron-job and built >> "nigthly" builds of usbpicprog for OS X and upload the disk images to >> wherever is suitable. >> >> The second file is a couple of scripts and a README file with >> information on how you can build this yourself. I used a lot of the >> info by Lukas Zeller, and only had to do a bit of tweaking to get it >> to work. >> >> The main problem that Lukas Zeller saw was the libiconv linking, >> which >> was almost correct. The problem is not with the MacPorts libiconv, >> but >> rather that Apple ships with a number of libiconv versions, some of >> which takes precedence over the MacPorts version. The solution is to >> force wxWidgets to use the MacPorts version by using a configure >> flag. >> For more information, see the install_wxWidgets.sh script. >> >> There is however another issue that can mess stuff up. libtool! >> Again, >> Apple ships there own "special" version of libtool/libtoolize, which >> is NOT compatible with the GNU version. Unfortunately, stuff breaks >> in >> OS X if you overwrite Apple's version, and thus MacPorts have solved >> this by renaming libtool to glibtool and glibtoolize. To get >> everything to compile correctly, I had to make a symlink from >> /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of >> course). This makes everything build fine, but is a bit of a hack >> since I have to remove this symlinks after the build is complete or >> OS >> X will mess stuff up when installing other programs. The best way >> would be to make the configure/autogen.sh scripts to realize that >> they're building on a Mac and change from libtool to glibtool... >> >> I think that was all. Hope it works for everyone else as well! >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> 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 > > --- > --- > --- > --------------------------------------------------------------------- > 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: Frans S. <fra...@gm...> - 2010-03-19 15:39:48
|
Hi Gustav, I have tried the .dmg on an intel 10.5 system, and it didn't seem to work because it was compiled using gcc 4.2. I compiled it using gcc 4.0 and modified buildmac.sh. I think the latest one does now run on 10.4, 10.5 and 10.6. Also libiconv has been included in the .app now. Cheers, Frans On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote: > Hi! > > Since I'm new to this mailing-list, I apologize in advance if I break > some rules... If I do, just tell me and I won't do it again! :) > > I've been working on creating a universal build for OS X of the > usbpicprog.app, and I think I've got it now. Attached are two files, > one disk image containing a freshly built usbpicprog.app that *should* > work on both Intel and PPC Macs, from 10.4 and up. I've tested it on > an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not > however have a usb-programmer yet, so I have not tested the > programming functionality. If you can help out by testing, please do > so and tell me about any problems. > > If there is an interest in it, I can setup a cron-job and built > "nigthly" builds of usbpicprog for OS X and upload the disk images to > wherever is suitable. > > The second file is a couple of scripts and a README file with > information on how you can build this yourself. I used a lot of the > info by Lukas Zeller, and only had to do a bit of tweaking to get it > to work. > > The main problem that Lukas Zeller saw was the libiconv linking, which > was almost correct. The problem is not with the MacPorts libiconv, but > rather that Apple ships with a number of libiconv versions, some of > which takes precedence over the MacPorts version. The solution is to > force wxWidgets to use the MacPorts version by using a configure flag. > For more information, see the install_wxWidgets.sh script. > > There is however another issue that can mess stuff up. libtool! Again, > Apple ships there own "special" version of libtool/libtoolize, which > is NOT compatible with the GNU version. Unfortunately, stuff breaks in > OS X if you overwrite Apple's version, and thus MacPorts have solved > this by renaming libtool to glibtool and glibtoolize. To get > everything to compile correctly, I had to make a symlink from > /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of > course). This makes everything build fine, but is a bit of a hack > since I have to remove this symlinks after the build is complete or OS > X will mess stuff up when installing other programs. The best way > would be to make the configure/autogen.sh scripts to realize that > they're building on a Mac and change from libtool to glibtool... > > I think that was all. Hope it works for everyone else as well! > > ------------------------------------------------------------------------------ > 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-18 19:24:15
|
Hi Mark, 2010/3/12 Mark Jones <hel...@gm...>: > Hello friends, I've been having some difficulty using the UPP in > Windows 7 32-bit. The software and drivers appear to install and run > correctly, and the UPP firmware can be updated and verified > successfully, but I can not read or write to a target 18LF2553, > 16F628, or 16F84A. I'd be happy to test and debug what I can, but > admittedly, C++ is not my forté. >.... can you retest against latest revision of the trunk? I think r864 should have fixed the programming problems... Francesco |
|
From: Francesco <f18...@ya...> - 2010-03-14 21:34:42
|
Hi, 2010/3/10 Mark Jones <hel...@gm...>: > Hi Francesco, > >> [code snippet] >> this means that your system seems not supported by WinUSB (or >> incorrectly detected maybe). >> If you open an MSDOS prompt and type "ver", what do you get? > > In the Win XP x32 VM, ver reports "Microsoft Windows XP [Version > 5.1.2600]" and it is XP Pro (2004) /w SP3. strange... in that case libusb should set windows_version = WINDOWS_XP; and skip the return LIBUSB_ERROR_NOT_SUPPORTED... I'll test on more Windows XPs btw... > ok, so you can confirm that it works under a Win7 x32 ? ;) > > Yes, I just cloned two clean and freshly updated Windows 7 32-bit (and > 64-bit) VMs, and the latest UPP builds install and run successfully on > both. :) great ;) > Oh, one last thing, it looks like the uninstaller does not > remove the start menu shortcuts yet. I think I've just fixed this. As soon as Frans says he's ready for a new release I can produce updated installers (for both 32 and 64 bit Windows).... Francesco |
|
From: Mark J. <hel...@gm...> - 2010-03-12 20:16:56
|
Hello friends, I've been having some difficulty using the UPP in Windows 7 32-bit. The software and drivers appear to install and run correctly, and the UPP firmware can be updated and verified successfully, but I can not read or write to a target 18LF2553, 16F628, or 16F84A. I'd be happy to test and debug what I can, but admittedly, C++ is not my forté. What happens is, when writing a device, programming always stops near the end of the code block. The hardware freezes with the green and red LEDs lit, and after about four seconds, the following error is displayed: http://img101.imageshack.us/img101/6571/usberror.png At this point, the UPP must be unplugged, the software "Disconnected", the UPP reconnected, and the software "Connected" to re-establish communication. Oddly, "Autodetect" was able to determine every connected PIC. For a read example, this is what happens when I tried reading a working 16F84A. The target "coffee machine" circuit is fully functional and can be ICSP-updated using my old programmer, a PICALL from www.picallw.com. UPP correctly identifies the 16F84A and gives no error reading it, yet returns the following .hex file: :020000040000FA :10000000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F00 :10001000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FF0 :10002000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FE0 ... many more lines following this pattern ... :1001F000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F0F :10020000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FFE :10021000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FEE :1002200000000000000000000000000000000000CE :1002300000000000000000000000000000000000BE :1002400000000000000000000000000000000000AE ... many more lines, etc ... :1003100000000000000000000000000000000000DD :1003200000000000000000000000000000000000CD :1003300000000000000000000000000000000000BD :100340000000000000000030003FFF3FFF3FFF3F84 :10035000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FAD :10036000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F9D :10037000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F8D ... etc ... :1006D000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F2A :1006E000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F1A :1006F000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F0A :1007000000000000000000000000000000000000E9 :1007100000000000000000000000000000000000D9 :1007200000000000000000000000000000000000C9 ... etc ... :1007D0000000000000000000000000000000000019 :1007E0000000000000000000000000000000000009 :1007F00000000000000000000000000000000000F9 :020000040000FA :1042000048004F005400200043004F004600460085 :1042100045004500200048004500520045002100AF :10422000000020004F006E006C007900200031007B :1042300035002000430065006E007400730020000C :1042400020000000200020004600520045005300DE :10425000480020004200520045005700450044003D :104260002000200000002000200049006E007300A4 :10427000650072007400200043006F0069006E004A :020000040000FA :02400E000F00A1 :00000001FF Note that the EEDATA was read correctly! "HOT COFFEE HERE!,0" etc. Below is part of the original .hex file for comparison: :020000040000FA ... legitimate code here ... :0407E000AE20E32B39 :02400E00F93F78 :1042000048004F005400200043004F004600460085 :1042100045004500200048004500520045002100AF :10422000000020004F006E006C007900200031007B :1042300035002000430065006E007400730020000C :1042400020000000200020004600520045005300DE :10425000480020004200520045005700450044003D :104260002000200000002000200049006E007300A4 :10427000650072007400200043006F0069006E004A :00000001FF Any ideas? This is using an ICSP cable about 2cm long, and a quality shielded USB2.0 cable about 2m long. Thanks! Regards, Mark |
|
From: Frans S. <fra...@gm...> - 2010-03-12 09:14:21
|
Hi Gustav, Thank you very much for your great contribution to usbpicprog - osx! Especially the scripts make it very easy for other mac developers to build the application. I have put them in the subversion repository under upp_wx/osx. (maybe we still need to change some cd commands in the scripts in order to run them from there). I have put the .dmg file on usbpicprog.org/downloads. Please everybody with a mac (intel or ppc), test it and report back to the mailing list! You are not breaking any rules, except that I have to accept the big attachments manually :P Maybe next time it is better if you put them on usbpicprog/downloads directly. I will send you the password, but better not through this mailin list... If you send me your sourceforge username, I can also add you to the project so that you have write access to the subversion repository in case anything needs to change for the osx build. (and of course for the official releases). Great work! Frans On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote: > Hi! > > Since I'm new to this mailing-list, I apologize in advance if I break > some rules... If I do, just tell me and I won't do it again! :) > > I've been working on creating a universal build for OS X of the > usbpicprog.app, and I think I've got it now. Attached are two files, > one disk image containing a freshly built usbpicprog.app that *should* > work on both Intel and PPC Macs, from 10.4 and up. I've tested it on > an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not > however have a usb-programmer yet, so I have not tested the > programming functionality. If you can help out by testing, please do > so and tell me about any problems. > > If there is an interest in it, I can setup a cron-job and built > "nigthly" builds of usbpicprog for OS X and upload the disk images to > wherever is suitable. > > The second file is a couple of scripts and a README file with > information on how you can build this yourself. I used a lot of the > info by Lukas Zeller, and only had to do a bit of tweaking to get it > to work. > > The main problem that Lukas Zeller saw was the libiconv linking, which > was almost correct. The problem is not with the MacPorts libiconv, but > rather that Apple ships with a number of libiconv versions, some of > which takes precedence over the MacPorts version. The solution is to > force wxWidgets to use the MacPorts version by using a configure flag. > For more information, see the install_wxWidgets.sh script. > > There is however another issue that can mess stuff up. libtool! Again, > Apple ships there own "special" version of libtool/libtoolize, which > is NOT compatible with the GNU version. Unfortunately, stuff breaks in > OS X if you overwrite Apple's version, and thus MacPorts have solved > this by renaming libtool to glibtool and glibtoolize. To get > everything to compile correctly, I had to make a symlink from > /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of > course). This makes everything build fine, but is a bit of a hack > since I have to remove this symlinks after the build is complete or OS > X will mess stuff up when installing other programs. The best way > would be to make the configure/autogen.sh scripts to realize that > they're building on a Mac and change from libtool to glibtool... > > I think that was all. Hope it works for everyone else as well! > > ------------------------------------------------------------------------------ > 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: Gustav J. <gu...@ne...> - 2010-03-11 19:34:44
|
Hi! Since I'm new to this mailing-list, I apologize in advance if I break some rules... If I do, just tell me and I won't do it again! :) I've been working on creating a universal build for OS X of the usbpicprog.app, and I think I've got it now. Attached are two files, one disk image containing a freshly built usbpicprog.app that *should* work on both Intel and PPC Macs, from 10.4 and up. I've tested it on an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not however have a usb-programmer yet, so I have not tested the programming functionality. If you can help out by testing, please do so and tell me about any problems. If there is an interest in it, I can setup a cron-job and built "nigthly" builds of usbpicprog for OS X and upload the disk images to wherever is suitable. The second file is a couple of scripts and a README file with information on how you can build this yourself. I used a lot of the info by Lukas Zeller, and only had to do a bit of tweaking to get it to work. The main problem that Lukas Zeller saw was the libiconv linking, which was almost correct. The problem is not with the MacPorts libiconv, but rather that Apple ships with a number of libiconv versions, some of which takes precedence over the MacPorts version. The solution is to force wxWidgets to use the MacPorts version by using a configure flag. For more information, see the install_wxWidgets.sh script. There is however another issue that can mess stuff up. libtool! Again, Apple ships there own "special" version of libtool/libtoolize, which is NOT compatible with the GNU version. Unfortunately, stuff breaks in OS X if you overwrite Apple's version, and thus MacPorts have solved this by renaming libtool to glibtool and glibtoolize. To get everything to compile correctly, I had to make a symlink from /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of course). This makes everything build fine, but is a bit of a hack since I have to remove this symlinks after the build is complete or OS X will mess stuff up when installing other programs. The best way would be to make the configure/autogen.sh scripts to realize that they're building on a Mac and change from libtool to glibtool... I think that was all. Hope it works for everyone else as well! -- Dr. Gustav Johansson Skrantahöjdsvägen 52A, 1tr SE-691 46 Karlskoga, Sweden +46 70 654 8666 |
|
From: Mark J. <hel...@gm...> - 2010-03-10 05:36:15
|
Hi Francesco, > [code snippet] > this means that your system seems not supported by WinUSB (or > incorrectly detected maybe). > If you open an MSDOS prompt and type "ver", what do you get? In the Win XP x32 VM, ver reports "Microsoft Windows XP [Version 5.1.2600]" and it is XP Pro (2004) /w SP3. The only C compiler I have setup is Pelle's C (ANSI C) so that's of little help. >> HOWEVER... I am not convinced that it is even possible to run >> UsbPicProg in a Sun VirtualBox VM, because the VirtualBox USB filter >> is not passing the connected UPP hardware to the VM. (It doesn't "see" >> it.) > strange. Btw I'm using Vmware Player (which is free) and under that > system UsbPicProg works fine in a virtual WinXP SP3 and is also able > to connect to the hardware since Vmware can forward the USB traffic to > the virtual machine. Interesting, yes I think this is an issue with the current build of Sun VirtualBox. I can't downgrade it to a previous version at the moment, so am waiting for their next release. > This is for both the Win7 x32 > host and XP x32 guest OSes. ok, so you can confirm that it works under a Win7 x32 ? ;) Yes, I just cloned two clean and freshly updated Windows 7 32-bit (and 64-bit) VMs, and the latest UPP builds install and run successfully on both. :) Oh, one last thing, it looks like the uninstaller does not remove the start menu shortcuts yet. Regards, Mark |
|
From: Francesco <f18...@ya...> - 2010-03-08 23:50:39
|
Hi Mark,
2010/3/9 Mark Jones <hel...@gm...>:
> Hello Francesco, I have tried your recommendations (and the new r848
> installer) on the Sun VirtualBox Windows XP x32 virtual machine. This
> results in "Usbpicprog Error: Could not initialize libusb: Operation
> not supported or unimplemented on this platform".
good. At least this gives a clear indication of what's failing inside
the windows_init() function of libusb; the relevant snippet of code
corresponding to the LIBUSB_ERROR_NOT_SUPPORTED code (which in turns
corresponds to the error description you got) is:
// Detect OS version
memset(&os_version, 0, sizeof(OSVERSIONINFO));
os_version.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
windows_version = WINDOWS_UNSUPPORTED;
if ((GetVersionEx(&os_version) != 0) && (os_version.dwPlatformId ==
VER_PLATFORM_WIN32_NT)) {
if ((os_version.dwMajorVersion == 5) && (os_version.dwMinorVersion == 1)) {
windows_version = WINDOWS_XP;
} else if (os_version.dwMajorVersion >= 6) {
windows_version = WINDOWS_VISTA_AND_LATER;
}
}
if (windows_version == WINDOWS_UNSUPPORTED) {
usbi_err(ctx, "This version of Windows is NOT supported");
r = LIBUSB_ERROR_NOT_SUPPORTED;
goto init_exit;
}
this means that your system seems not supported by WinUSB (or
incorrectly detected maybe).
If you open an MSDOS prompt and type "ver", what do you get?
Are you sure that your virtual machine is WinXP and not Win2000 ?
> Note that the r778 software will run, on a new XP x32 VM, even without
> libusb-win32 installed, but only if the libusb0.dll file was copied
> into the same folder as usbpicprog.exe.
ok but this doesn't help now since we have completely moved away from
libusb-win32 0.1 and the libusb-1.0 (which is what we're using now)
windows support was written from scratch and uses a completely
different approach from libusb-win32 0.1.
> HOWEVER... I am not convinced that it is even possible to run
> UsbPicProg in a Sun VirtualBox VM, because the VirtualBox USB filter
> is not passing the connected UPP hardware to the VM. (It doesn't "see"
> it.)
strange. Btw I'm using Vmware Player (which is free) and under that
system UsbPicProg works fine in a virtual WinXP SP3 and is also able
to connect to the hardware since Vmware can forward the USB traffic to
the virtual machine.
> Thus, even if the UPP software would install properly in the VM,
> at this time, the hardware cannot be accessed. I will gladly help in
> testing the installer further, however.
ok, many thanks!
> P.S. The uninstall.exe file will work to uninstall UPP if manually
> executed, but so far, I have not seen any uninstall entries created in
> Control Panel --> Add/Remove Programs.
good point. An entry is missing. I'll look into fixing this.
> This is for both the Win7 x32
> host and XP x32 guest OSes.
ok, so you can confirm that it works under a Win7 x32 ? ;)
Thanks,
Francesco
|
|
From: Mark J. <hel...@gm...> - 2010-03-08 23:00:52
|
Hello Francesco, I have tried your recommendations (and the new r848 installer) on the Sun VirtualBox Windows XP x32 virtual machine. This results in "Usbpicprog Error: Could not initialize libusb: Operation not supported or unimplemented on this platform". Note that the r778 software will run, on a new XP x32 VM, even without libusb-win32 installed, but only if the libusb0.dll file was copied into the same folder as usbpicprog.exe. HOWEVER... I am not convinced that it is even possible to run UsbPicProg in a Sun VirtualBox VM, because the VirtualBox USB filter is not passing the connected UPP hardware to the VM. (It doesn't "see" it.) Thus, even if the UPP software would install properly in the VM, at this time, the hardware cannot be accessed. I will gladly help in testing the installer further, however. Kindest Regards, Mark P.S. The uninstall.exe file will work to uninstall UPP if manually executed, but so far, I have not seen any uninstall entries created in Control Panel --> Add/Remove Programs. This is for both the Win7 x32 host and XP x32 guest OSes. |
|
From: Frans S. <fra...@gm...> - 2010-03-08 15:28:06
|
Dear Jordan, You have to create an empty project with target: 18F2550. Include all the .c and .h files and add the .lkr file from the source directory as a linker script. (no .o or .lib files). Make sure that the directories c:\mcc18\h and the project directory are included as "include directories" and that c:\mcc18\lib is included as library directory. Also make sure that you have the latest MCC18 compiler, you can get a free update from Microchip.com Kind regards, Frans Schreuder On Mon, 2010-03-08 at 12:26 +0100, Xantra wrote: > Hello, > > We are 2 french students and we want make your usbpicprog. > We have made the PCB, but we can't build the boot in MPLAB whith C18. > We have this error : > Error - could not find definition of symbol '_stack' in file > 'C:\MCC18\lib\c018i.o'. > Anybody have a fix? > We have included in the project : 18f2550_g.lkr, > P18F2550.LIB, clib.lib, c018i.o, p18f2550.h > Thanks, and sorry for my bad english. > > Jordan. > > French : > Bonjour, > > Nous sommes 2 étudiants de l'IUT de Grenoble et nous voudrions faire > fonctionner votre projet usbpicprog. > Nous avons réalisé la carte, mais impossible de compiler le boot > sous MPLAB avec C18, nous avons l'erreur suivante : > Error - could not find definition of symbol '_stack' in file > 'C:\MCC18\lib\c018i.o'. > Comment résoudre ce probleme? > Nous avons liée au projet les fichiers suivants : 18f2550_g.lkr, > P18F2550.LIB, clib.lib, c018i.o, p18f2550.h > Merci d'avance pour votre aide. > > Jordan. > > > ------------------------------------------------------------------------------ > 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: Xantra <xa...@or...> - 2010-03-08 11:26:58
|
Hello, We are 2 french students and we want make your usbpicprog. We have made the PCB, but we can't build the boot in MPLAB whith C18. We have this error : Error - could not find definition of symbol '_stack' in file 'C:\MCC18\lib\c018i.o'. Anybody have a fix? We have included in the project : 18f2550_g.lkr, P18F2550.LIB, clib.lib, c018i.o, p18f2550.h Thanks, and sorry for my bad english. Jordan. French : Bonjour, Nous sommes 2 étudiants de l'IUT de Grenoble et nous voudrions faire fonctionner votre projet usbpicprog. Nous avons réalisé la carte, mais impossible de compiler le boot sous MPLAB avec C18, nous avons l'erreur suivante : Error - could not find definition of symbol '_stack' in file 'C:\MCC18\lib\c018i.o'. Comment résoudre ce probleme? Nous avons liée au projet les fichiers suivants : 18f2550_g.lkr, P18F2550.LIB, clib.lib, c018i.o, p18f2550.h Merci d'avance pour votre aide. Jordan. |
|
From: Francesco <f18...@ya...> - 2010-03-07 22:11:35
|
Hi Mark,
I suggest you to take the following steps:
0) uninstall the UsbPicProg application, if you have it installed
1) go in Control Panel -> system -> device manager
2) plug-in the upp hardware
3) right click on the upp icon of the device manager and choose "Uninstall"
4) unplug and plug the upp hardware again; Windows should ask you for a driver
5) click cancel and unplug the hw
6) download and install the latest release:
http://usbpicprog.org/downloads/UsbPicProg-x86-r848-release.exe
7) plug the hw; Windows should _still_ ask you for a driver; point it
to the Programs\UsbPicProg\driver folder
8) run usbpicprog; it should start and work fine (hopefully ;))
HTH,
Francesco
> On 03/06/2010 07:34 PM, Mark Jones wrote:
>>> On Fri, Mar 5, 2010 at 10:37 PM, Mark Jones<hel...@gm...> wrote:
>>>
>>>> Hi, the r834 was installed successfully in a Windows XP x32 VM,
>>>> however it seems to be confused about libusb. The libusb-1.0.dll file
>>>> is loaded, but UPP responds with "Could not initialize libusb!"
>>>>
>>>> http://img693.imageshack.us/img693/7118/834winxpx32.png
>>>>
>>>>
>>> Hi,
>>>
>>> I think you do need to reinstall the driver from Program
>>> Files\UsbPicProg\driver
>>>
>>> Regards,
>>> Frans Schreuder
>>>
>>>
>> Good day Frans, when I run the DPInst.exe file in \UsbPicProg\driver
>> (or right-click either .INF files and choose "Install", the drivers
>> seem to install properly, and the DPInst.log file looks ok. I must be
>> missing something, the r834 version of UPP no longer requires
>> libusb-win32, correct? To test, I installed that also, and even after
>> a reboot of the VM and reinstall of UPP, it still reports the same
>> message. When this happened before (in earlier versions of UPP which
>> required libusb-win32), I remember copying libusb0.dll into the
>> UsbPicProg folder would allow it to run, but this no longer works, as
>> UPP only has imports from libusb-1.0.dll.
>>
>> Kind regards,
>> Mark
>>
>> http://img689.imageshack.us/img689/5836/834winxpx32b.png
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
> ------------------------------------------------------------------------------
> 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-07 19:44:12
|
Hi Frans, 2010/3/4 Frans Schreuder <fra...@gm...>: > Because the way it was, only the gui part was connecting to the programmer, > when the command line interface was invoked, usbpicprog gave a seg fault. Of > course it is also possible to initialize libusb twice, but I think from > hardware is more charming... I've re-tested upp_wx on WinXP and indeed I was able to reproduce the problem recently reported by Mark Jones on a vanilla installation. IMO the best solution in case libusb fails to initialize is to immediately stop the application. That's why I moved libusb initialization back to main.cpp again but this time I made sure that libusb is initialized also when running in console mode. I hope the change is ok for you... Francesco |
|
From: Frans S. <fra...@gm...> - 2010-03-06 19:10:32
|
Dear Mark Jones, I think the sollution might be to completely uninstall libusb-win32 since this is an incompatible version with 1.0 (it's still 0.1.12 as far as I know). Regards, Frans Schreuder On 03/06/2010 07:34 PM, Mark Jones wrote: >> On Fri, Mar 5, 2010 at 10:37 PM, Mark Jones<hel...@gm...> wrote: >> >>> Hi, the r834 was installed successfully in a Windows XP x32 VM, >>> however it seems to be confused about libusb. The libusb-1.0.dll file >>> is loaded, but UPP responds with "Could not initialize libusb!" >>> >>> http://img693.imageshack.us/img693/7118/834winxpx32.png >>> >>> >> Hi, >> >> I think you do need to reinstall the driver from Program >> Files\UsbPicProg\driver >> >> Regards, >> Frans Schreuder >> >> > Good day Frans, when I run the DPInst.exe file in \UsbPicProg\driver > (or right-click either .INF files and choose "Install", the drivers > seem to install properly, and the DPInst.log file looks ok. I must be > missing something, the r834 version of UPP no longer requires > libusb-win32, correct? To test, I installed that also, and even after > a reboot of the VM and reinstall of UPP, it still reports the same > message. When this happened before (in earlier versions of UPP which > required libusb-win32), I remember copying libusb0.dll into the > UsbPicProg folder would allow it to run, but this no longer works, as > UPP only has imports from libusb-1.0.dll. > > Kind regards, > Mark > > http://img689.imageshack.us/img689/5836/834winxpx32b.png > > ------------------------------------------------------------------------------ > 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: Mark J. <hel...@gm...> - 2010-03-06 18:34:30
|
>On Fri, Mar 5, 2010 at 10:37 PM, Mark Jones <hel...@gm...> wrote: >> Hi, the r834 was installed successfully in a Windows XP x32 VM, >> however it seems to be confused about libusb. The libusb-1.0.dll file >> is loaded, but UPP responds with "Could not initialize libusb!" >> >> http://img693.imageshack.us/img693/7118/834winxpx32.png >> > > Hi, > > I think you do need to reinstall the driver from Program > Files\UsbPicProg\driver > > Regards, > Frans Schreuder > Good day Frans, when I run the DPInst.exe file in \UsbPicProg\driver (or right-click either .INF files and choose "Install", the drivers seem to install properly, and the DPInst.log file looks ok. I must be missing something, the r834 version of UPP no longer requires libusb-win32, correct? To test, I installed that also, and even after a reboot of the VM and reinstall of UPP, it still reports the same message. When this happened before (in earlier versions of UPP which required libusb-win32), I remember copying libusb0.dll into the UsbPicProg folder would allow it to run, but this no longer works, as UPP only has imports from libusb-1.0.dll. Kind regards, Mark http://img689.imageshack.us/img689/5836/834winxpx32b.png |
|
From: Frans S. <fra...@gm...> - 2010-03-06 08:01:44
|
Hi, I think you do need to reinstall the driver from Program Files\UsbPicProg\driver Regards, Frans Schreuder On 03/06/2010 04:37 AM, Mark Jones wrote: > Hi, the r834 was installed successfully in a Windows XP x32 VM, > however it seems to be confused about libusb. The libusb-1.0.dll file > is loaded, but UPP responds with "Could not initialize libusb!" > > http://img693.imageshack.us/img693/7118/834winxpx32.png > > ------------------------------------------------------------------------------ > 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 > |
6 messages has been excluded from this view by a project administrator.
