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: Mark J. <hel...@gm...> - 2010-03-06 03:38:12
|
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 |
|
From: Francesco <f18...@ya...> - 2010-03-05 22:55:55
|
2010/3/5 Frans Schreuder <fra...@gm...>: > Already did it, pleas check out rev 843 > m_hardware is now a member of main and referenced to uppmainwindow great! I've done some cleanup and fix to make it work on MSVC on Windows. Now it looks much better to me ;) The final exe seems also somewhat faster at startup but probably the greatest delay is due to the GUI part (creation of the configuration flags panel, of the PIC bitmap, initialization of the grids and parsing of a couple XML files). I may have a look at optimizing this (e.g. initializing all tabs except the first one only when the user selects them) in the future. Francesco |
|
From: Frans S. <fra...@gm...> - 2010-03-05 08:04:37
|
> I think this would be: > 1) a better design from a OOP point of view. > 2) more efficient design => reduce startup time of upp_wx. > Already did it, pleas check out rev 843 m_hardware is now a member of main and referenced to uppmainwindow > If you agree I can do such modifications in the weekend... > > 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: Frans S. <fra...@gm...> - 2010-03-05 07:30:12
|
Dear Aleksej, On Thu, 2010-03-04 at 17:05 +0100, Aleksej Horvat wrote: > Dear Frans, > > Attached is the compiled app, with libraries included. I would also > be willing to compile future versions for the website if you like. Thank you very much. I have put it on usbpicprog.org/downloads, so that other people having a ppc mac can test it as well. > > Regarding the language issue, I resolved it by manually deleting the > NL files, however this is actually a bug, at least on OS X. My system > language is correctly set to English as primary language, however my > region settings are for Nederland because this matches my keyboard and > date settings here in Holland. While this may not be the case for > everyone to mix and match, it is an independent setting, and programs > running on Mac should respect the system language preference, and then > optionally regional date or number formatting where appropriate > (calendar, spreadsheets, etc.) I haven't checked the code yet to see > how the language is determined. This is just one line of code in usbpicprog and it is determined by wxWidgets. If it is a bug, it must be in wxWidgets. > > Also, I'm not sure if this is a known bug, or mac specific, but the > frame with program/memory space display, etc. does not resize with the > window. Apparently it is calculated on at launch based on the last > known window size. While easy to work around, still rather annoying. Yes, I know about this and there is a workaround, but you will need the next wxWidgets (2.9.1) for it to compile. > > Lastly, I was curious about the firmware. As stated is based on the > picdem bootloader, so I naively attempted to let piklab recognize it, > and failed. Is that possible? There are two pieces of firmware, the bootloader and the usbpicprog firmware. piklab can communicate with the bootloader which is indeed the picdem bootloader with a few modifications. (you have to put just one of the two jumpers in order to run the bootloader in stead of the usbpicprog-firmware) > > Anyway, thanks sincerely for all you help getting this running. > Aleksej Horvat Thanks, Frans Schreuder > On 3 mrt 2010, at 16:16, Frans Schreuder wrote: > > > Dear Aleksej, > > > > Yes, I would like to have the binary. Could you zip the .app file > > with the right version information? > > eg: > > usbpicprog-831-20100303-osx-ppc.app.zip > > > > The program runs in Dutch only if you have a flag set somewhere that > > your system should run programs in Dutch. > > Probably something like LC_LANG = nl_NL.UTF-8 or LC_ALL=nl_NL.UTF-8 > > I don't exactly know how to do this setting in osx, but it must be > > defined somewhere. > > If you can't find the setting, you can always delete the nl.mo file > > from the .app file to run it in English. > > > > Kind regards, > > > > Frans Schreuder > > > > > > On 3/3/2010 15:18, Aleksej Horvat wrote: > >> Dear Frans, > >> > >> I have finally suceded in compiling on my system. It seems that > >> even after your changes, there were some problems on system > >> regarding the correct flags for wxwidgets. I could send you a > >> compiled binary to add to the project page if you like, just let me > >> know. > >> > >> One last question, the version I compiled defaults to Dutch, even > >> though my system is set to English language. I don't see a setting > >> to change this value. Must I pass a flag at compile time? > >> > >> Thanks > >> Aleksej > >> > >> On 28 feb 2010, at 12:54, Frans Schreuder wrote: > >> > >>> Aleksej Horvat schreef: > >>> > >>> Dear Aleksej, > >>> > >>> I have committed them to SVN and also here: http://usbpicprog.org/downloads/usbpicprog-831-20100226.tar.gz > >>> Also buildmac.sh is changed, so you should just be able to run it > >>> as it is! > >>> > >>> Kind regards, > >>> > >>> Frans Schreuder > >>>> Dear Frans, > >>>> > >>>> Thank you for taking the time to look into the problem. I'm glad > >>>> to hear that you were able to compile successfully. > >>>> Unfortunately, I am not able to use the package because I am > >>>> running a PPC mac. The changes you mentioned, have you committed > >>>> them to the svn? or do have to change them manually? > >>>> > >>>> Thanks again, > >>>> Aleksej > >>>> > >>>> On 26 feb 2010, at 14:25, Frans Schreuder wrote: > >>>> > >>>>> Dear Aleksej, > >>>>> > >>>>> I have succeeded to build the latest snapshot (831) with osx > >>>>> 10.5, you can find the package here (I hope it works on your mac > >>>>> too): > >>>>> http://usbpicprog.org/downloads/usbpicprog-831-20100226- > >>>>> osx.app.zip > >>>>> > >>>>> There were some things that I had to change in the usbpicprog > >>>>> archive: > >>>>> -There were some cout<<wxString statements in the source code. > >>>>> This works in Linux and Windows, but the osx gcc compiler has > >>>>> some problems with it, so I had to change it to wxString.mb_str() > >>>>> -on Windows, there was a function in libusb called > >>>>> "libusb_strerror", but it didn't exist in Linux so I included it > >>>>> in hardware.cpp inside #ifdef __WXGTK__, this had to be changed > >>>>> in #ifndef __WXMSW__ > >>>>> -The makefile installed /etc/udev/rules.d/26-microchip.rules by > >>>>> default. This is a Linux thing only, so it had to be removed for > >>>>> osx > >>>>> -some things in buildmac.sh have been updated to build > >>>>> successfully. > >>>>> > >>>>> I think it should build now on your system as well! > >>>>> > >>>>> Kind regards, > >>>>> > >>>>> Frans Schreuder > >>>>> > >>>>> On 25-2-2010 17:09, Aleksej Horvat wrote: > >>>>>> Dear Frans, > >>>>>> > >>>>>> Thank you for your continuing support. Removing the line did > >>>>>> clear up the libusb error. Unfortunately just past that line, > >>>>>> I receive many errors relating to wxwidgets, although I also > >>>>>> have that installed. I will look into that, but I am curious > >>>>>> what you will find this weekend. Sorry that I have to ask for > >>>>>> this level of support, but configure and make are still a bit > >>>>>> of a mystery for me. I'll keep you informed if I find anything. > >>>>>> > >>>>>> Sincerely, > >>>>>> Aleksej > >>>>>> > >>>>>> On 25 feb 2010, at 08:25, Frans Schreuder wrote: > >>>>>> > >>>>>>> Dear Aleksej, > >>>>>>> > >>>>>>> This weekend, I can borrow a mac from someone, I will try it > >>>>>>> myself. > >>>>>>> It was indeed using some old configuration files, in order to > >>>>>>> be able to run from the subversion tree. > >>>>>>> if you remove the line cp -R osx/* . from configure.sh, this > >>>>>>> might help, but I will try further. (you will need to extract > >>>>>>> the fresh archive before). > >>>>>>> > >>>>>>> Kind regards, > >>>>>>> > >>>>>>> Frans Schreuder > >>>>>>> > >>>>>>> On 24-2-2010 22:38, Aleksej Horvat wrote: > >>>>>>>> Dear Frans, > >>>>>>>> > >>>>>>>> Thank you for your help. I was in fact trying to install the > >>>>>>>> version 0.3.0. I have tried following your advice and > >>>>>>>> dowloaded the newer branch you mentioned below. > >>>>>>>> Unfotunately, the build fails at exactly the same point, even > >>>>>>>> though I have libusb 1.0.6 installed. Perhaps there is > >>>>>>>> something outdated in the buildmac.sh file as the error I > >>>>>>>> receive still refers to libusb 0.1.x > >>>>>>>> > >>>>>>>> Could you please provide some instructions as to how I can > >>>>>>>> change this, or perhaps copy libusb to where the script > >>>>>>>> expects to find it. Included below is my terminal outpout. > >>>>>>>> > >>>>>>>> Thanks sincerely, > >>>>>>>> Aleksej > >>>>>>>> > >>>>>>>> Renovatio:usbpicprog-823-20100219 ahorvat$ ./buildmac.sh > >>>>>>>> make: *** No rule to make target `clean'. Stop. > >>>>>>>> checking for a BSD-compatible install... /usr/bin/install -c > >>>>>>>> checking whether build environment is sane... yes > >>>>>>>> checking for a thread-safe mkdir -p... ./install-sh -c -d > >>>>>>>> checking for gawk... no > >>>>>>>> checking for mawk... no > >>>>>>>> checking for nawk... no > >>>>>>>> checking for awk... awk > >>>>>>>> checking whether make sets $(MAKE)... yes > >>>>>>>> checking whether to enable maintainer-specific portions of > >>>>>>>> Makefiles... no > >>>>>>>> checking for style of include used by make... GNU > >>>>>>>> checking for gcc... gcc > >>>>>>>> checking for C compiler default output file name... a.out > >>>>>>>> checking whether the C compiler works... yes > >>>>>>>> checking whether we are cross compiling... no > >>>>>>>> checking for suffix of executables... > >>>>>>>> checking for suffix of object files... o > >>>>>>>> checking whether we are using the GNU C compiler... yes > >>>>>>>> checking whether gcc accepts -g... yes > >>>>>>>> checking for gcc option to accept ISO C89... none needed > >>>>>>>> checking dependency style of gcc... gcc3 > >>>>>>>> checking for library containing strerror... none required > >>>>>>>> checking for gcc... (cached) gcc > >>>>>>>> checking whether we are using the GNU C compiler... (cached) > >>>>>>>> yes > >>>>>>>> checking whether gcc accepts -g... (cached) yes > >>>>>>>> checking for gcc option to accept ISO C89... (cached) none > >>>>>>>> needed > >>>>>>>> checking dependency style of gcc... (cached) gcc3 > >>>>>>>> checking for gcc... (cached) gcc > >>>>>>>> checking whether we are using the GNU C compiler... (cached) > >>>>>>>> yes > >>>>>>>> checking whether gcc accepts -g... (cached) yes > >>>>>>>> checking for gcc option to accept ISO C89... (cached) none > >>>>>>>> needed > >>>>>>>> checking dependency style of gcc... (cached) gcc3 > >>>>>>>> checking how to run the C preprocessor... gcc -E > >>>>>>>> checking for grep that handles long lines and -e... /usr/bin/ > >>>>>>>> grep > >>>>>>>> checking for egrep... /usr/bin/grep -E > >>>>>>>> checking for ANSI C header files... yes > >>>>>>>> checking how to run the C preprocessor... gcc -E > >>>>>>>> checking for g++... g++ > >>>>>>>> checking whether we are using the GNU C++ compiler... yes > >>>>>>>> checking whether g++ accepts -g... yes > >>>>>>>> checking dependency style of g++... gcc3 > >>>>>>>> checking build system type... powerpc-apple-darwin9.8.0 > >>>>>>>> checking host system type... powerpc-apple-darwin9.8.0 > >>>>>>>> checking for a sed that does not truncate output... /usr/bin/ > >>>>>>>> sed > >>>>>>>> checking for fgrep... /usr/bin/grep -F > >>>>>>>> checking for ld used by gcc... /usr/libexec/gcc/powerpc-apple- > >>>>>>>> darwin9/4.0.1/ld > >>>>>>>> checking if the linker (/usr/libexec/gcc/powerpc-apple- > >>>>>>>> darwin9/4.0.1/ld) is GNU ld... no > >>>>>>>> checking for BSD- or MS-compatible name lister (nm)... /usr/ > >>>>>>>> bin/nm -p > >>>>>>>> checking the name lister (/usr/bin/nm -p) interface... BSD nm > >>>>>>>> checking whether ln -s works... yes > >>>>>>>> checking the maximum length of command line arguments... 196608 > >>>>>>>> checking whether the shell understands some XSI constructs... > >>>>>>>> yes > >>>>>>>> checking whether the shell understands "+="... yes > >>>>>>>> checking for /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld > >>>>>>>> option to reload object files... -r > >>>>>>>> checking for objdump... no > >>>>>>>> checking how to recognize dependent libraries... pass_all > >>>>>>>> checking for ar... ar > >>>>>>>> checking for strip... strip > >>>>>>>> checking for ranlib... ranlib > >>>>>>>> checking command to parse /usr/bin/nm -p output from gcc > >>>>>>>> object... ok > >>>>>>>> checking for dsymutil... dsymutil > >>>>>>>> checking for nmedit... nmedit > >>>>>>>> checking for lipo... lipo > >>>>>>>> checking for otool... otool > >>>>>>>> checking for otool64... no > >>>>>>>> checking for -single_module linker flag... yes > >>>>>>>> checking for -exported_symbols_list linker flag... yes > >>>>>>>> checking for sys/types.h... yes > >>>>>>>> checking for sys/stat.h... yes > >>>>>>>> checking for stdlib.h... yes > >>>>>>>> checking for string.h... yes > >>>>>>>> checking for memory.h... yes > >>>>>>>> checking for strings.h... yes > >>>>>>>> checking for inttypes.h... yes > >>>>>>>> checking for stdint.h... yes > >>>>>>>> checking for unistd.h... yes > >>>>>>>> checking for dlfcn.h... yes > >>>>>>>> checking whether we are using the GNU C++ compiler... > >>>>>>>> (cached) yes > >>>>>>>> checking whether g++ accepts -g... (cached) yes > >>>>>>>> checking dependency style of g++... (cached) gcc3 > >>>>>>>> checking how to run the C++ preprocessor... g++ -E > >>>>>>>> checking for objdir... .libs > >>>>>>>> checking if gcc supports -fno-rtti -fno-exceptions... no > >>>>>>>> checking for gcc option to produce PIC... -fno-common -DPIC > >>>>>>>> checking if gcc PIC flag -fno-common -DPIC works... yes > >>>>>>>> checking if gcc static flag -static works... no > >>>>>>>> checking if gcc supports -c -o file.o... yes > >>>>>>>> checking if gcc supports -c -o file.o... (cached) yes > >>>>>>>> checking whether the gcc linker (/usr/libexec/gcc/powerpc- > >>>>>>>> apple-darwin9/4.0.1/ld) supports shared libraries... yes > >>>>>>>> checking dynamic linker characteristics... darwin9.8.0 dyld > >>>>>>>> checking how to hardcode library paths into programs... > >>>>>>>> immediate > >>>>>>>> checking whether stripping libraries is possible... yes > >>>>>>>> checking if libtool supports shared libraries... yes > >>>>>>>> checking whether to build shared libraries... yes > >>>>>>>> checking whether to build static libraries... yes > >>>>>>>> checking for ld used by g++... /usr/libexec/gcc/powerpc-apple- > >>>>>>>> darwin9/4.0.1/ld > >>>>>>>> checking if the linker (/usr/libexec/gcc/powerpc-apple- > >>>>>>>> darwin9/4.0.1/ld) is GNU ld... no > >>>>>>>> checking whether the g++ linker (/usr/libexec/gcc/powerpc- > >>>>>>>> apple-darwin9/4.0.1/ld) supports shared libraries... yes > >>>>>>>> checking for g++ option to produce PIC... -fno-common -DPIC > >>>>>>>> checking if g++ PIC flag -fno-common -DPIC works... yes > >>>>>>>> checking if g++ static flag -static works... no > >>>>>>>> checking if g++ supports -c -o file.o... yes > >>>>>>>> checking if g++ supports -c -o file.o... (cached) yes > >>>>>>>> checking whether the g++ linker (/usr/libexec/gcc/powerpc- > >>>>>>>> apple-darwin9/4.0.1/ld) supports shared libraries... yes > >>>>>>>> checking dynamic linker characteristics... darwin9.8.0 dyld > >>>>>>>> checking how to hardcode library paths into programs... > >>>>>>>> immediate > >>>>>>>> checking locale.h usability... yes > >>>>>>>> checking locale.h presence... yes > >>>>>>>> checking for locale.h... yes > >>>>>>>> checking for LC_MESSAGES... yes > >>>>>>>> checking libintl.h usability... no > >>>>>>>> checking libintl.h presence... no > >>>>>>>> checking for libintl.h... no > >>>>>>>> checking whether NLS is requested... yes > >>>>>>>> checking for intltool >= 0.35.0... 0.40.6 found > >>>>>>>> checking for intltool-update... /opt/local/bin/intltool-update > >>>>>>>> checking for intltool-merge... /opt/local/bin/intltool-merge > >>>>>>>> checking for intltool-extract... /opt/local/bin/intltool- > >>>>>>>> extract > >>>>>>>> checking for xgettext... /opt/local/bin/xgettext > >>>>>>>> checking for msgmerge... /opt/local/bin/msgmerge > >>>>>>>> checking for msgfmt... /opt/local/bin/msgfmt > >>>>>>>> checking for gmsgfmt... /opt/local/bin/msgfmt > >>>>>>>> checking for perl... /opt/local/bin/perl > >>>>>>>> checking for perl >= 5.8.1... 5.8.9 > >>>>>>>> checking for XML::Parser... ok > >>>>>>>> checking for wx-config... /usr/local/bin/wx-config > >>>>>>>> checking for wxWidgets version >= 2.8.0... yes (version 2.9.0) > >>>>>>>> checking for wxWidgets static library... yes > >>>>>>>> checking for usb_bulk_write in -lusb... no > >>>>>>>> configure: error: > >>>>>>>> Libusb 0.1.x is required. > >>>>>>>> > >>>>>>>> Please install it from your package manager. > >>>>>>>> > >>>>>>>> make: *** No targets specified and no makefile found. Stop. > >>>>>>>> make: Nothing to be done for `install'. > >>>>>>>> cp: src/usbpicprog.app/Contents/MacOS/output/bin/usbpicprog: > >>>>>>>> No such file or directory > >>>>>>>> cp: src/usbpicprog.app/Contents/MacOS/output/lib/locale: No > >>>>>>>> such file or directory > >>>>>>>> cp: libs//libusb.dylib: No such file or directory > >>>>>>>> otool: can't open file: libs//libusb.dylib (No such file or > >>>>>>>> directory) > >>>>>>>> install_name_tool: can't open file: src/usbpicprog.app/ > >>>>>>>> Contents/SharedSupport/libusb.dylib (No such file or directory) > >>>>>>>> Usage: install_name_tool [-change old new] ... [-id name] input > >>>>>>>> > >>>>>>>> > >>>>>>>> On 22 feb 2010, at 08:53, Frans Schreuder wrote: > >>>>>>>> > >>>>>>>>> Dear Aleksej, > >>>>>>>>> > >>>>>>>>> I am sorry that I have missed your message. > >>>>>>>>> the forums have been deleted because usbpicprog had too many > >>>>>>>>> channels of > >>>>>>>>> getting support, we have now chosen to use the mailing list > >>>>>>>>> usb...@li... as the main > >>>>>>>>> support channel. > >>>>>>>>> > >>>>>>>>> I think the problem you are facing is the version of libusb > >>>>>>>>> that > >>>>>>>>> usbpicprog demands, and this is also related to the version of > >>>>>>>>> usbpicprog that you are trying to compile. > >>>>>>>>> I think you have tried to compile version 0.3.0 which needs > >>>>>>>>> libusb-0.1. > >>>>>>>>> However, we recently switched to the newer version of libusb; > >>>>>>>>> libusb-1.0, this is true for any development branch of > >>>>>>>>> usbpicprog > 803. > >>>>>>>>> I suggest that you try downloading > >>>>>>>>> http://usbpicprog.org/downloads/ > >>>>>>>>> usbpicprog-823-20100219.tar.gz and build > >>>>>>>>> it. > >>>>>>>>> You will also need the development version of wxWidgets, 2.9.0 > >>>>>>>>> installed. > >>>>>>>>> > >>>>>>>>> Kind regards, > >>>>>>>>> > >>>>>>>>> Frans Schreuder > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Sun, 2010-02-21 at 18:41 +0100, Aleksej Horvat wrote: > >>>>>>>>>> Name: Aleksej Horvat > >>>>>>>>>> > >>>>>>>>>> Email: ah...@ma... > >>>>>>>>>> > >>>>>>>>>> Subject: Mac OS X PPC Compile > >>>>>>>>>> > >>>>>>>>>> Message: Hello, > >>>>>>>>>> A few days ago I posted a request for advice in the forum on > >>>>>>>>>> SourceForge. As of now I see that the forum has This leads > >>>>>>>>>> me to > >>>>>>>>>> believe that I won't be receiving any advice. > >>>>>>>>>> I am running OS X 10.5.8 on PPC Mac, however, I have > >>>>>>>>>> attempted the > >>>>>>>>>> buildmac.sh on an Intel Mac I have access to and it fails > >>>>>>>>>> at the same > >>>>>>>>>> point. I have installed the latest wxwidgets and libusb > >>>>>>>>>> (through fink, > >>>>>>>>>> although that shouldn't matter). The problem is related to > >>>>>>>>>> the 'has > >>>>>>>>>> libusb' check in the makefile, relating to the > >>>>>>>>>> usb_bulk_write command. > >>>>>>>>>> I have checked my installation and I do have libusb in my > >>>>>>>>>> path. > >>>>>>>>>> I have basic programming experience, but I am unfortunately > >>>>>>>>>> not > >>>>>>>>>> terribly familiar with the make syntax at this moment. > >>>>>>>>>> Which means I > >>>>>>>>>> am not able to immediately debug the makefile. Perhaps if > >>>>>>>>>> you gave me > >>>>>>>>>> some advice, I could try and let you know what happens. > >>>>>>>>>> Terminal > >>>>>>>>>> output does not fit the character limit here. > >>>>>>>>>> Any help would be greatly appreciated, > >>>>>>>>>> Aleksej > >>>>>>>>>> > >>>>>>>>>> IP: 85.146.126.46 > >>>>>>>>>> HOST: s55927e2e.adsl.wanadoo.nl > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>> > >> > |
|
From: Frans S. <fra...@gm...> - 2010-03-04 13:31:36
|
Hi Francesco, On Thu, 2010-03-04 at 10:44 +0100, Francesco wrote: > Hi Frans, > > 2010/3/4 Frans Schreuder <fra...@gm...>: > > I saw that in your modifications, you called libusb_init() from > main.cpp (as > > well ass libusb_exit). > > I think it is better to move this to the hardware constructor and > > destructor. > hmmm, why? 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 already tested this in linux, but I don't know if it works out > > well on all systems? > on Windows it didn't work well with the earlier versions of the libusb > windows port. I didn't test recently but in any case I think that the > initialization is a bit slow because the windows port needs to > internally enumerate the USB hubs AFAIR. > > > What was the reason for you to call these functions from main? > in general the initialization of all libraries is done in the main() > of a program and never repeated (as it shouldn't really be > necessary!). The initialization routines usually allocate memory and > perform many operations which maybe time-consuming. I don't think we > should repeat them multiple times unless absolutely necessary. > > In fact, I think that also the current organization of the Hardware > class, which gets allocated and deleted multiple times should also be > avoided: upp_wx currently is very slow to start up and IIRC this is > because Hardware is created and deleted 2-3 times at the startup. > I'd really like much more to have a > Hardware m_hw; > member in UsbPicProg class definition and then have just a > bool Connect(HardwareType hwToTryToConnect); > member in the Hardware class which would be used by UppMainWindow > (only when necessary). > > I think this would be: > 1) a better design from a OOP point of view. > 2) more efficient design => reduce startup time of upp_wx. That's ok, in that case we can still init libusb from hardware, but only init hardware once. > > If you agree I can do such modifications in the weekend... I will do it myself, but I think it's a good idea. Frans |
|
From: Francesco <f18...@ya...> - 2010-03-04 09:44:25
|
Hi Frans, 2010/3/4 Frans Schreuder <fra...@gm...>: > I saw that in your modifications, you called libusb_init() from main.cpp (as > well ass libusb_exit). > I think it is better to move this to the hardware constructor and > destructor. hmmm, why? > I already tested this in linux, but I don't know if it works out > well on all systems? on Windows it didn't work well with the earlier versions of the libusb windows port. I didn't test recently but in any case I think that the initialization is a bit slow because the windows port needs to internally enumerate the USB hubs AFAIR. > What was the reason for you to call these functions from main? in general the initialization of all libraries is done in the main() of a program and never repeated (as it shouldn't really be necessary!). The initialization routines usually allocate memory and perform many operations which maybe time-consuming. I don't think we should repeat them multiple times unless absolutely necessary. In fact, I think that also the current organization of the Hardware class, which gets allocated and deleted multiple times should also be avoided: upp_wx currently is very slow to start up and IIRC this is because Hardware is created and deleted 2-3 times at the startup. I'd really like much more to have a Hardware m_hw; member in UsbPicProg class definition and then have just a bool Connect(HardwareType hwToTryToConnect); member in the Hardware class which would be used by UppMainWindow (only when necessary). I think this would be: 1) a better design from a OOP point of view. 2) more efficient design => reduce startup time of upp_wx. If you agree I can do such modifications in the weekend... Francesco |
|
From: Frans S. <fra...@gm...> - 2010-03-04 08:05:55
|
Hi Francesco, I saw that in your modifications, you called libusb_init() from main.cpp (as well ass libusb_exit). I think it is better to move this to the hardware constructor and destructor. I already tested this in linux, but I don't know if it works out well on all systems? What was the reason for you to call these functions from main? Frans |
|
From: Mark J. <hel...@gm...> - 2010-03-04 02:38:21
|
Thank you Frans, the changes in r836 allow the UPP to work again in Windows 7 32-bit. Soon I'll have a chance to actually test the UPP on a few projects. In my parts box are three chips which are not on the verified list. They will be tested soon. :) Regards, Mark |
|
From: Frans S. <fra...@gm...> - 2010-03-03 15:17:13
|
Dear Aleksej, Yes, I would like to have the binary. Could you zip the .app file with the right version information? eg: usbpicprog-831-20100303-osx-ppc.app.zip The program runs in Dutch only if you have a flag set somewhere that your system should run programs in Dutch. Probably something like LC_LANG = nl_NL.UTF-8 or LC_ALL=nl_NL.UTF-8 I don't exactly know how to do this setting in osx, but it must be defined somewhere. If you can't find the setting, you can always delete the nl.mo file from the .app file to run it in English. Kind regards, Frans Schreuder On 3/3/2010 15:18, Aleksej Horvat wrote: > Dear Frans, > > I have finally suceded in compiling on my system. It seems that even > after your changes, there were some problems on system regarding the > correct flags for wxwidgets. I could send you a compiled binary to > add to the project page if you like, just let me know. > > One last question, the version I compiled defaults to Dutch, even > though my system is set to English language. I don't see a setting to > change this value. Must I pass a flag at compile time? > > Thanks > Aleksej > > On 28 feb 2010, at 12:54, Frans Schreuder wrote: > >> Aleksej Horvat schreef: >> >> Dear Aleksej, >> >> I have committed them to SVN and also here: >> http://usbpicprog.org/downloads/usbpicprog-831-20100226.tar.gz >> Also buildmac.sh is changed, so you should just be able to run it as >> it is! >> >> Kind regards, >> >> Frans Schreuder >>> Dear Frans, >>> >>> Thank you for taking the time to look into the problem. I'm glad to >>> hear that you were able to compile successfully. Unfortunately, I >>> am not able to use the package because I am running a PPC mac. The >>> changes you mentioned, have you committed them to the svn? or do >>> have to change them manually? >>> >>> Thanks again, >>> Aleksej >>> >>> On 26 feb 2010, at 14:25, Frans Schreuder wrote: >>> >>>> Dear Aleksej, >>>> >>>> I have succeeded to build the latest snapshot (831) with osx 10.5, >>>> you can find the package here (I hope it works on your mac too): >>>> http://usbpicprog.org/downloads/usbpicprog-831-20100226-osx.app.zip >>>> >>>> There were some things that I had to change in the usbpicprog archive: >>>> -There were some cout<<wxString statements in the source code. This >>>> works in Linux and Windows, but the osx gcc compiler has some >>>> problems with it, so I had to change it to wxString.mb_str() >>>> -on Windows, there was a function in libusb called >>>> "libusb_strerror", but it didn't exist in Linux so I included it in >>>> hardware.cpp inside #ifdef __WXGTK__, this had to be changed in >>>> #ifndef __WXMSW__ >>>> -The makefile installed /etc/udev/rules.d/26-microchip.rules by >>>> default. This is a Linux thing only, so it had to be removed for osx >>>> -some things in buildmac.sh have been updated to build successfully. >>>> >>>> I think it should build now on your system as well! >>>> >>>> Kind regards, >>>> >>>> Frans Schreuder >>>> >>>> On 25-2-2010 17:09, Aleksej Horvat wrote: >>>>> Dear Frans, >>>>> >>>>> Thank you for your continuing support. Removing the line did >>>>> clear up the libusb error. Unfortunately just past that line, I >>>>> receive many errors relating to wxwidgets, although I also have >>>>> that installed. I will look into that, but I am curious what you >>>>> will find this weekend. Sorry that I have to ask for this level >>>>> of support, but configure and make are still a bit of a mystery >>>>> for me. I'll keep you informed if I find anything. >>>>> >>>>> Sincerely, >>>>> Aleksej >>>>> >>>>> On 25 feb 2010, at 08:25, Frans Schreuder wrote: >>>>> >>>>>> Dear Aleksej, >>>>>> >>>>>> This weekend, I can borrow a mac from someone, I will try it myself. >>>>>> It was indeed using some old configuration files, in order to be >>>>>> able to run from the subversion tree. >>>>>> if you remove the line cp -R osx/* . from configure.sh, this >>>>>> might help, but I will try further. (you will need to extract the >>>>>> fresh archive before). >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Frans Schreuder >>>>>> >>>>>> On 24-2-2010 22:38, Aleksej Horvat wrote: >>>>>>> Dear Frans, >>>>>>> >>>>>>> Thank you for your help. I was in fact trying to install the >>>>>>> version 0.3.0. I have tried following your advice and dowloaded >>>>>>> the newer branch you mentioned below. Unfotunately, the build >>>>>>> fails at exactly the same point, even though I have libusb 1.0.6 >>>>>>> installed. Perhaps there is something outdated in the >>>>>>> buildmac.sh file as the error I receive still refers to libusb >>>>>>> 0.1.x >>>>>>> >>>>>>> Could you please provide some instructions as to how I can >>>>>>> change this, or perhaps copy libusb to where the script expects >>>>>>> to find it. Included below is my terminal outpout. >>>>>>> >>>>>>> Thanks sincerely, >>>>>>> Aleksej >>>>>>> >>>>>>> Renovatio:usbpicprog-823-20100219 ahorvat$ ./buildmac.sh make: >>>>>>> *** No rule to make target `clean'. Stop. >>>>>>> checking for a BSD-compatible install... /usr/bin/install -c >>>>>>> checking whether build environment is sane... yes >>>>>>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>>>>>> checking for gawk... no >>>>>>> checking for mawk... no >>>>>>> checking for nawk... no >>>>>>> checking for awk... awk >>>>>>> checking whether make sets $(MAKE)... yes >>>>>>> checking whether to enable maintainer-specific portions of >>>>>>> Makefiles... no >>>>>>> checking for style of include used by make... GNU >>>>>>> checking for gcc... gcc >>>>>>> checking for C compiler default output file name... a.out >>>>>>> checking whether the C compiler works... yes >>>>>>> checking whether we are cross compiling... no >>>>>>> checking for suffix of executables... >>>>>>> checking for suffix of object files... o >>>>>>> checking whether we are using the GNU C compiler... yes >>>>>>> checking whether gcc accepts -g... yes >>>>>>> checking for gcc option to accept ISO C89... none needed >>>>>>> checking dependency style of gcc... gcc3 >>>>>>> checking for library containing strerror... none required >>>>>>> checking for gcc... (cached) gcc >>>>>>> checking whether we are using the GNU C compiler... (cached) yes >>>>>>> checking whether gcc accepts -g... (cached) yes >>>>>>> checking for gcc option to accept ISO C89... (cached) none needed >>>>>>> checking dependency style of gcc... (cached) gcc3 >>>>>>> checking for gcc... (cached) gcc >>>>>>> checking whether we are using the GNU C compiler... (cached) yes >>>>>>> checking whether gcc accepts -g... (cached) yes >>>>>>> checking for gcc option to accept ISO C89... (cached) none needed >>>>>>> checking dependency style of gcc... (cached) gcc3 >>>>>>> checking how to run the C preprocessor... gcc -E >>>>>>> checking for grep that handles long lines and -e... /usr/bin/grep >>>>>>> checking for egrep... /usr/bin/grep -E >>>>>>> checking for ANSI C header files... yes >>>>>>> checking how to run the C preprocessor... gcc -E >>>>>>> checking for g++... g++ >>>>>>> checking whether we are using the GNU C++ compiler... yes >>>>>>> checking whether g++ accepts -g... yes >>>>>>> checking dependency style of g++... gcc3 >>>>>>> checking build system type... powerpc-apple-darwin9.8.0 >>>>>>> checking host system type... powerpc-apple-darwin9.8.0 >>>>>>> checking for a sed that does not truncate output... /usr/bin/sed >>>>>>> checking for fgrep... /usr/bin/grep -F >>>>>>> checking for ld used by gcc... >>>>>>> /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld >>>>>>> checking if the linker >>>>>>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) is GNU ld... no >>>>>>> checking for BSD- or MS-compatible name lister (nm)... >>>>>>> /usr/bin/nm -p >>>>>>> checking the name lister (/usr/bin/nm -p) interface... BSD nm >>>>>>> checking whether ln -s works... yes >>>>>>> checking the maximum length of command line arguments... 196608 >>>>>>> checking whether the shell understands some XSI constructs... yes >>>>>>> checking whether the shell understands "+="... yes >>>>>>> checking for /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld >>>>>>> option to reload object files... -r >>>>>>> checking for objdump... no >>>>>>> checking how to recognize dependent libraries... pass_all >>>>>>> checking for ar... ar >>>>>>> checking for strip... strip >>>>>>> checking for ranlib... ranlib >>>>>>> checking command to parse /usr/bin/nm -p output from gcc >>>>>>> object... ok >>>>>>> checking for dsymutil... dsymutil >>>>>>> checking for nmedit... nmedit >>>>>>> checking for lipo... lipo >>>>>>> checking for otool... otool >>>>>>> checking for otool64... no >>>>>>> checking for -single_module linker flag... yes >>>>>>> checking for -exported_symbols_list linker flag... yes >>>>>>> checking for sys/types.h... yes >>>>>>> checking for sys/stat.h... yes >>>>>>> checking for stdlib.h... yes >>>>>>> checking for string.h... yes >>>>>>> checking for memory.h... yes >>>>>>> checking for strings.h... yes >>>>>>> checking for inttypes.h... yes >>>>>>> checking for stdint.h... yes >>>>>>> checking for unistd.h... yes >>>>>>> checking for dlfcn.h... yes >>>>>>> checking whether we are using the GNU C++ compiler... (cached) yes >>>>>>> checking whether g++ accepts -g... (cached) yes >>>>>>> checking dependency style of g++... (cached) gcc3 >>>>>>> checking how to run the C++ preprocessor... g++ -E >>>>>>> checking for objdir... .libs >>>>>>> checking if gcc supports -fno-rtti -fno-exceptions... no >>>>>>> checking for gcc option to produce PIC... -fno-common -DPIC >>>>>>> checking if gcc PIC flag -fno-common -DPIC works... yes >>>>>>> checking if gcc static flag -static works... no >>>>>>> checking if gcc supports -c -o file.o... yes >>>>>>> checking if gcc supports -c -o file.o... (cached) yes >>>>>>> checking whether the gcc linker >>>>>>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) supports >>>>>>> shared libraries... yes >>>>>>> checking dynamic linker characteristics... darwin9.8.0 dyld >>>>>>> checking how to hardcode library paths into programs... immediate >>>>>>> checking whether stripping libraries is possible... yes >>>>>>> checking if libtool supports shared libraries... yes >>>>>>> checking whether to build shared libraries... yes >>>>>>> checking whether to build static libraries... yes >>>>>>> checking for ld used by g++... >>>>>>> /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld >>>>>>> checking if the linker >>>>>>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) is GNU ld... no >>>>>>> checking whether the g++ linker >>>>>>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) supports >>>>>>> shared libraries... yes >>>>>>> checking for g++ option to produce PIC... -fno-common -DPIC >>>>>>> checking if g++ PIC flag -fno-common -DPIC works... yes >>>>>>> checking if g++ static flag -static works... no >>>>>>> checking if g++ supports -c -o file.o... yes >>>>>>> checking if g++ supports -c -o file.o... (cached) yes >>>>>>> checking whether the g++ linker >>>>>>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) supports >>>>>>> shared libraries... yes >>>>>>> checking dynamic linker characteristics... darwin9.8.0 dyld >>>>>>> checking how to hardcode library paths into programs... immediate >>>>>>> checking locale.h usability... yes >>>>>>> checking locale.h presence... yes >>>>>>> checking for locale.h... yes >>>>>>> checking for LC_MESSAGES... yes >>>>>>> checking libintl.h usability... no >>>>>>> checking libintl.h presence... no >>>>>>> checking for libintl.h... no >>>>>>> checking whether NLS is requested... yes >>>>>>> checking for intltool >= 0.35.0... 0.40.6 found >>>>>>> checking for intltool-update... /opt/local/bin/intltool-update >>>>>>> checking for intltool-merge... /opt/local/bin/intltool-merge >>>>>>> checking for intltool-extract... /opt/local/bin/intltool-extract >>>>>>> checking for xgettext... /opt/local/bin/xgettext >>>>>>> checking for msgmerge... /opt/local/bin/msgmerge >>>>>>> checking for msgfmt... /opt/local/bin/msgfmt >>>>>>> checking for gmsgfmt... /opt/local/bin/msgfmt >>>>>>> checking for perl... /opt/local/bin/perl >>>>>>> checking for perl >= 5.8.1... 5.8.9 >>>>>>> checking for XML::Parser... ok >>>>>>> checking for wx-config... /usr/local/bin/wx-config >>>>>>> checking for wxWidgets version >= 2.8.0... yes (version 2.9.0) >>>>>>> checking for wxWidgets static library... yes >>>>>>> checking for usb_bulk_write in -lusb... no >>>>>>> configure: error: >>>>>>> Libusb 0.1.x is required. >>>>>>> >>>>>>> Please install it from your package manager. >>>>>>> >>>>>>> make: *** No targets specified and no makefile found. Stop. >>>>>>> make: Nothing to be done for `install'. >>>>>>> cp: src/usbpicprog.app/Contents/MacOS/output/bin/usbpicprog: No >>>>>>> such file or directory >>>>>>> cp: src/usbpicprog.app/Contents/MacOS/output/lib/locale: No such >>>>>>> file or directory >>>>>>> cp: libs//libusb.dylib: No such file or directory >>>>>>> otool: can't open file: libs//libusb.dylib (No such file or >>>>>>> directory) >>>>>>> install_name_tool: can't open file: >>>>>>> src/usbpicprog.app/Contents/SharedSupport/libusb.dylib (No such >>>>>>> file or directory) >>>>>>> Usage: install_name_tool [-change old new] ... [-id name] input >>>>>>> >>>>>>> >>>>>>> On 22 feb 2010, at 08:53, Frans Schreuder wrote: >>>>>>> >>>>>>>> Dear Aleksej, >>>>>>>> >>>>>>>> I am sorry that I have missed your message. >>>>>>>> the forums have been deleted because usbpicprog had too many >>>>>>>> channels of >>>>>>>> getting support, we have now chosen to use the mailing list >>>>>>>> usb...@li... as the main support >>>>>>>> channel. >>>>>>>> >>>>>>>> I think the problem you are facing is the version of libusb that >>>>>>>> usbpicprog demands, and this is also related to the version of >>>>>>>> usbpicprog that you are trying to compile. >>>>>>>> I think you have tried to compile version 0.3.0 which needs >>>>>>>> libusb-0.1. >>>>>>>> However, we recently switched to the newer version of libusb; >>>>>>>> libusb-1.0, this is true for any development branch of >>>>>>>> usbpicprog > 803. >>>>>>>> I suggest that you try downloading >>>>>>>> http://usbpicprog.org/downloads/usbpicprog-823-20100219.tar.gz >>>>>>>> and build >>>>>>>> it. >>>>>>>> You will also need the development version of wxWidgets, 2.9.0 >>>>>>>> installed. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Frans Schreuder >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, 2010-02-21 at 18:41 +0100, Aleksej Horvat wrote: >>>>>>>>> Name: Aleksej Horvat >>>>>>>>> >>>>>>>>> Email: ah...@ma... >>>>>>>>> >>>>>>>>> Subject: Mac OS X PPC Compile >>>>>>>>> >>>>>>>>> Message: Hello, >>>>>>>>> A few days ago I posted a request for advice in the forum on >>>>>>>>> SourceForge. As of now I see that the forum has This leads me to >>>>>>>>> believe that I won't be receiving any advice. >>>>>>>>> I am running OS X 10.5.8 on PPC Mac, however, I have attempted >>>>>>>>> the >>>>>>>>> buildmac.sh on an Intel Mac I have access to and it fails at >>>>>>>>> the same >>>>>>>>> point. I have installed the latest wxwidgets and libusb >>>>>>>>> (through fink, >>>>>>>>> although that shouldn't matter). The problem is related to the >>>>>>>>> 'has >>>>>>>>> libusb' check in the makefile, relating to the usb_bulk_write >>>>>>>>> command. >>>>>>>>> I have checked my installation and I do have libusb in my path. >>>>>>>>> I have basic programming experience, but I am unfortunately not >>>>>>>>> terribly familiar with the make syntax at this moment. Which >>>>>>>>> means I >>>>>>>>> am not able to immediately debug the makefile. Perhaps if you >>>>>>>>> gave me >>>>>>>>> some advice, I could try and let you know what happens. Terminal >>>>>>>>> output does not fit the character limit here. >>>>>>>>> Any help would be greatly appreciated, >>>>>>>>> Aleksej >>>>>>>>> >>>>>>>>> IP: 85.146.126.46 >>>>>>>>> HOST: s55927e2e.adsl.wanadoo.nl >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >> > |
|
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 |
|
From: Frans S. <fra...@gm...> - 2010-03-02 14:42:47
|
Well, your .zip doesn't seem to run on an intel mac with 10.5. I have found a workaround for the libiconv problem. Just delete the /opt/local/lib/libiconv.dylib file (or move it somewhere else). now you can make a symbolic link: ln -s /usr/lib/libiconv.dylib /opt/local/lib/libiconv.dylib I also had to build gettext myself now from source and of course wxWidgets 2.9.0. Kind regards, Frans Schreuder On Tue, 2010-03-02 at 09:05 +0100, Lukas Zeller wrote: > Good morning! > > On Mar 2, 2010, at 8:31 , Frans Schreuder wrote: > > > This information might be interesting for other people as well, so I > > forwarded it to the mailing list as well... > > I will have a look on how to generate the right makefiles to load the > > libiconv from /usr/lib, but I am very happy that you have succeeded! > > > > I still have one question: > > the version you built, was it version 831 or 818? (you call it 818). > > Sorry, my fault (it was late yesterday). Of course, it's the 831, only the name of the .zip is wrong. The About box reads: > > > Best Regards, > > Lukas > > > > > -----Original Message----- > > From: Lukas Zeller <lu...@ha...> > > To: fra...@gm... > > Subject: Re: usbpicprog software for mac - I might be able to build > > these but also need help.. > > Date: Tue, 2 Mar 2010 00:41:25 +0100 > > > > Hello, > > > > good news: I managed to compile usbpicprog-831 on my Snow Leopard Intel Mac, and it runs fine (inlcluding the Bangap bit reset feature I desperately needed to recover my 12F629). I sent the .app to a colleague with a non-develper mac, where it runs as well. > > > > However there were a few obstacles: > > > > 1) All ports need to be installed in the "universal" variant on Snow Leopard. Otherwise, only the 64bit versions are installed, but as wx needs carbon and carbon is 32-bit only, the entire build must be forced to 32bit, including libusb. > > > > 2) The build instructions your gave me for wx must be adapted for Snow Leopard to force 32bit compilation: > > > >> first you need to get wxWidgets 2.9.0 from http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.9.0.tar.gz > >> extract the source package, and run the following commands from the wxWidgets-2.9.0 folder: > >> mkdir build-mac > >> cd build-mac > >> ../configure --disable-shared > >> make > >> sudo make install > > > > luz version: > > > >> mkdir build-mac > >> cd build-mac > >> arch_flags="-arch i386" > >> ../configure CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags" --disable-shared > >> make > >> sudo make install > > > > > > 3) buildmac.sh needs some tweaks: > > > > a) To force 32-bit compilation: instead of > > > > ./configure --prefix=${OUTPUTPATH}/src/usbpicprog.app/Contents/MacOS/output > > > > use > > > > arch_flags="-arch i386" > > ./configure CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags" --prefix=${OUTPUTPATH}/src/usbpicprog.app/Contents/MacOS/output > > > > > > b) Because wx is not created as a dylib at all, but apparently used statically (--disable-shared), libwx_osx_carbonu-2.9.dylib does not exist and can't be copied. So, instead of > > > > TARGETS="libusb-1.0.dylib "\ > > "libwx_osx_carbonu-2.9.dylib" > > > > use > > > > TARGETS="libusb-1.0.dylib" > > > > > > 4) Apparently, a copy of libusb-1.0.dylib needs to be present in libs/ - so I copied the one from MacPorts: > > > > cp /opt/local/lib/libusb-1.0.dylib libs > > > > > > 5) The most difficult part: it seems that something with Macport's libiconv is wrong (found some other refs on google to this problem), so when linking the binary, the linker should use the libiconv provided by Apple (in /usr/lib). If I put "-L/usr/lib" before "-liconv" in src/Makefile, the "make all" in src/ works. However, as Makefile/Makefile.in is autogen'ed and the WX_LIBS macros come from wx-config output, this is not easily fixable. > > My ugly hack was to pause the ./buildmac.sh in the right moment with Ctrl-S in the console, and then manually edit src/Makefile ;-/ > > Probably the solution would be to compile wx differently rather than hacking wx-config's output that way... > > > > > > I hope all this is useful for you. At least, the built app is attached. > > > > Of course, for the longer term it'll be great if the build could be refined such that one can pull the head from your svn and run a build script to create new Mac versions. > > > > For now, I'm happy as this now revived my 12F629 project that was stalled in a permanent reset condition due to BG=00 :-) > > > > Best Regards, > > > > Lukas Zeller (lu...@ha...) > > > > > > > Lukas Zeller (lu...@ha...) > |
|
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: Frans S. <fra...@gm...> - 2010-03-02 07:31:40
|
Dear Lukas Zeller, This information might be interesting for other people as well, so I forwarded it to the mailing list as well... I will have a look on how to generate the right makefiles to load the libiconv from /usr/lib, but I am very happy that you have succeeded! I still have one question: the version you built, was it version 831 or 818? (you call it 818). Kind regards, Frans Schreuder usbpicprog.org -----Original Message----- From: Lukas Zeller <lu...@ha...> To: fra...@gm... Subject: Re: usbpicprog software for mac - I might be able to build these but also need help.. Date: Tue, 2 Mar 2010 00:41:25 +0100 Hello, good news: I managed to compile usbpicprog-831 on my Snow Leopard Intel Mac, and it runs fine (inlcluding the Bangap bit reset feature I desperately needed to recover my 12F629). I sent the .app to a colleague with a non-develper mac, where it runs as well. However there were a few obstacles: 1) All ports need to be installed in the "universal" variant on Snow Leopard. Otherwise, only the 64bit versions are installed, but as wx needs carbon and carbon is 32-bit only, the entire build must be forced to 32bit, including libusb. 2) The build instructions your gave me for wx must be adapted for Snow Leopard to force 32bit compilation: > first you need to get wxWidgets 2.9.0 from http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.9.0.tar.gz > extract the source package, and run the following commands from the wxWidgets-2.9.0 folder: > mkdir build-mac > cd build-mac > ../configure --disable-shared > make > sudo make install luz version: > mkdir build-mac > cd build-mac > arch_flags="-arch i386" > ../configure CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags" --disable-shared > make > sudo make install 3) buildmac.sh needs some tweaks: a) To force 32-bit compilation: instead of ./configure --prefix=${OUTPUTPATH}/src/usbpicprog.app/Contents/MacOS/output use arch_flags="-arch i386" ./configure CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags" --prefix=${OUTPUTPATH}/src/usbpicprog.app/Contents/MacOS/output b) Because wx is not created as a dylib at all, but apparently used statically (--disable-shared), libwx_osx_carbonu-2.9.dylib does not exist and can't be copied. So, instead of TARGETS="libusb-1.0.dylib "\ "libwx_osx_carbonu-2.9.dylib" use TARGETS="libusb-1.0.dylib" 4) Apparently, a copy of libusb-1.0.dylib needs to be present in libs/ - so I copied the one from MacPorts: cp /opt/local/lib/libusb-1.0.dylib libs 5) The most difficult part: it seems that something with Macport's libiconv is wrong (found some other refs on google to this problem), so when linking the binary, the linker should use the libiconv provided by Apple (in /usr/lib). If I put "-L/usr/lib" before "-liconv" in src/Makefile, the "make all" in src/ works. However, as Makefile/Makefile.in is autogen'ed and the WX_LIBS macros come from wx-config output, this is not easily fixable. My ugly hack was to pause the ./buildmac.sh in the right moment with Ctrl-S in the console, and then manually edit src/Makefile ;-/ Probably the solution would be to compile wx differently rather than hacking wx-config's output that way... I hope all this is useful for you. At least, the built app is attached. Of course, for the longer term it'll be great if the build could be refined such that one can pull the head from your svn and run a build script to create new Mac versions. For now, I'm happy as this now revived my 12F629 project that was stalled in a permanent reset condition due to BG=00 :-) Best Regards, Lukas Zeller (lu...@ha...) |
|
From: Frans S. <fra...@gm...> - 2010-03-02 07:08:41
|
Dear Mark, I think I have fixed the problem in revision 834. The problem had nothing to do with libusb-1.0, but with the fact that we switched from the mingw compiler to microsoft virtual C++. Thank yo for your report. Kind regards, Frans Schreuder On Mon, 2010-03-01 at 11:13 -0500, Mark Jones wrote: > Hi Frans, here's a new link for that image: > http://img651.imageshack.us/img651/7246/824noprogrambootloader1.png > > I've also tried installing the software package in a Sun VirtualBox > guest, (Windows XP Pro x32), where it does seem to install well, > however (unrelated to UsbPicProg) the VirtualBox USB filter does not > pickup the UsbPicProg device at all, so does not pass it to the VM > guest. I'm assuming this is due to the type of USB device it is, since > other USB devices can be connected successfully (mouse, keyboard, > camera, etc.) I'd be interested to hear if others have gotten > VirtualBox to work with UsbPicProg; it could be an issue with the > latest version of VirtualBox, as their forums have several posts about > USB devices no longer working. > > Regards, > 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: 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: 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: Mark J. <hel...@gm...> - 2010-03-01 16:19:07
|
Hi Frans, here's a new link for that image: http://img651.imageshack.us/img651/7246/824noprogrambootloader1.png I've also tried installing the software package in a Sun VirtualBox guest, (Windows XP Pro x32), where it does seem to install well, however (unrelated to UsbPicProg) the VirtualBox USB filter does not pickup the UsbPicProg device at all, so does not pass it to the VM guest. I'm assuming this is due to the type of USB device it is, since other USB devices can be connected successfully (mouse, keyboard, camera, etc.) I'd be interested to hear if others have gotten VirtualBox to work with UsbPicProg; it could be an issue with the latest version of VirtualBox, as their forums have several posts about USB devices no longer working. Regards, Mark |
|
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: Frans S. <fra...@gm...> - 2010-03-01 10:00:22
|
Hi Mark, could you upload the first image again? I can't view it. Let me try it on a win32 machine with the same version. ....REBOOTING.... Kind regards, Frans On Sat, 2010-02-27 at 17:26 -0500, Mark Jones wrote: > Hi, I had installed UPP in Windows XP x64 in December, more-or-less > successfully. I was able to update the boot code and firmware, however > didn't have a cable for programming other chips. Since then, I changed > this PC to Win7 x32 and made a cable. So I installed the 824 software > (R822M) (flawless), and it found the attached 788 hardware perfectly. > > However, then I upgraded boot1.0.hex to the latest 823 revision and > tried to upgrade the firmware as well, and it always stops with this: > http://img256.imageshack.us/img256/7246/824noprogrambootloader1.png > > The error is always at "0x800" with a read of "0x38." > > It appears as though the "libusb 1.0" driver was installed successfully, see: > http://img26.imageshack.us/img26/8011/824usbdrivergood.png > > Any ideas? > > Regards, > 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-02-27 22:27:07
|
Hi, I had installed UPP in Windows XP x64 in December, more-or-less successfully. I was able to update the boot code and firmware, however didn't have a cable for programming other chips. Since then, I changed this PC to Win7 x32 and made a cable. So I installed the 824 software (R822M) (flawless), and it found the attached 788 hardware perfectly. However, then I upgraded boot1.0.hex to the latest 823 revision and tried to upgrade the firmware as well, and it always stops with this: http://img256.imageshack.us/img256/7246/824noprogrambootloader1.png The error is always at "0x800" with a read of "0x38." It appears as though the "libusb 1.0" driver was installed successfully, see: http://img26.imageshack.us/img26/8011/824usbdrivergood.png Any ideas? Regards, Mark |
|
From: Frans S. <fra...@gm...> - 2010-02-26 14:31:34
|
Dear Aleksej, I have succeeded to build the latest snapshot (831) with osx 10.5, you can find the package here (I hope it works on your mac too): http://usbpicprog.org/downloads/usbpicprog-831-20100226-osx.app.zip There were some things that I had to change in the usbpicprog archive: -There were some cout<<wxString statements in the source code. This works in Linux and Windows, but the osx gcc compiler has some problems with it, so I had to change it to wxString.mb_str() -on Windows, there was a function in libusb called "libusb_strerror", but it didn't exist in Linux so I included it in hardware.cpp inside #ifdef __WXGTK__, this had to be changed in #ifndef __WXMSW__ -The makefile installed /etc/udev/rules.d/26-microchip.rules by default. This is a Linux thing only, so it had to be removed for osx -some things in buildmac.sh have been updated to build successfully. I think it should build now on your system as well! Kind regards, Frans Schreuder On 25-2-2010 17:09, Aleksej Horvat wrote: > Dear Frans, > > Thank you for your continuing support. Removing the line did clear up > the libusb error. Unfortunately just past that line, I receive many > errors relating to wxwidgets, although I also have that installed. I > will look into that, but I am curious what you will find this > weekend. Sorry that I have to ask for this level of support, but > configure and make are still a bit of a mystery for me. I'll keep you > informed if I find anything. > > Sincerely, > Aleksej > > On 25 feb 2010, at 08:25, Frans Schreuder wrote: > >> Dear Aleksej, >> >> This weekend, I can borrow a mac from someone, I will try it myself. >> It was indeed using some old configuration files, in order to be able >> to run from the subversion tree. >> if you remove the line cp -R osx/* . from configure.sh, this might >> help, but I will try further. (you will need to extract the fresh >> archive before). >> >> Kind regards, >> >> Frans Schreuder >> >> On 24-2-2010 22:38, Aleksej Horvat wrote: >>> Dear Frans, >>> >>> Thank you for your help. I was in fact trying to install the >>> version 0.3.0. I have tried following your advice and dowloaded the >>> newer branch you mentioned below. Unfotunately, the build fails at >>> exactly the same point, even though I have libusb 1.0.6 installed. >>> Perhaps there is something outdated in the buildmac.sh file as the >>> error I receive still refers to libusb 0.1.x >>> >>> Could you please provide some instructions as to how I can change >>> this, or perhaps copy libusb to where the script expects to find >>> it. Included below is my terminal outpout. >>> >>> Thanks sincerely, >>> Aleksej >>> >>> Renovatio:usbpicprog-823-20100219 ahorvat$ ./buildmac.sh make: *** >>> No rule to make target `clean'. Stop. >>> checking for a BSD-compatible install... /usr/bin/install -c >>> checking whether build environment is sane... yes >>> checking for a thread-safe mkdir -p... ./install-sh -c -d >>> checking for gawk... no >>> checking for mawk... no >>> checking for nawk... no >>> checking for awk... awk >>> checking whether make sets $(MAKE)... yes >>> checking whether to enable maintainer-specific portions of >>> Makefiles... no >>> checking for style of include used by make... GNU >>> checking for gcc... gcc >>> checking for C compiler default output file name... a.out >>> checking whether the C compiler works... yes >>> checking whether we are cross compiling... no >>> checking for suffix of executables... >>> checking for suffix of object files... o >>> checking whether we are using the GNU C compiler... yes >>> checking whether gcc accepts -g... yes >>> checking for gcc option to accept ISO C89... none needed >>> checking dependency style of gcc... gcc3 >>> checking for library containing strerror... none required >>> checking for gcc... (cached) gcc >>> checking whether we are using the GNU C compiler... (cached) yes >>> checking whether gcc accepts -g... (cached) yes >>> checking for gcc option to accept ISO C89... (cached) none needed >>> checking dependency style of gcc... (cached) gcc3 >>> checking for gcc... (cached) gcc >>> checking whether we are using the GNU C compiler... (cached) yes >>> checking whether gcc accepts -g... (cached) yes >>> checking for gcc option to accept ISO C89... (cached) none needed >>> checking dependency style of gcc... (cached) gcc3 >>> checking how to run the C preprocessor... gcc -E >>> checking for grep that handles long lines and -e... /usr/bin/grep >>> checking for egrep... /usr/bin/grep -E >>> checking for ANSI C header files... yes >>> checking how to run the C preprocessor... gcc -E >>> checking for g++... g++ >>> checking whether we are using the GNU C++ compiler... yes >>> checking whether g++ accepts -g... yes >>> checking dependency style of g++... gcc3 >>> checking build system type... powerpc-apple-darwin9.8.0 >>> checking host system type... powerpc-apple-darwin9.8.0 >>> checking for a sed that does not truncate output... /usr/bin/sed >>> checking for fgrep... /usr/bin/grep -F >>> checking for ld used by gcc... >>> /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld >>> checking if the linker >>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) is GNU ld... no >>> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p >>> checking the name lister (/usr/bin/nm -p) interface... BSD nm >>> checking whether ln -s works... yes >>> checking the maximum length of command line arguments... 196608 >>> checking whether the shell understands some XSI constructs... yes >>> checking whether the shell understands "+="... yes >>> checking for /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld option >>> to reload object files... -r >>> checking for objdump... no >>> checking how to recognize dependent libraries... pass_all >>> checking for ar... ar >>> checking for strip... strip >>> checking for ranlib... ranlib >>> checking command to parse /usr/bin/nm -p output from gcc object... ok >>> checking for dsymutil... dsymutil >>> checking for nmedit... nmedit >>> checking for lipo... lipo >>> checking for otool... otool >>> checking for otool64... no >>> checking for -single_module linker flag... yes >>> checking for -exported_symbols_list linker flag... yes >>> checking for sys/types.h... yes >>> checking for sys/stat.h... yes >>> checking for stdlib.h... yes >>> checking for string.h... yes >>> checking for memory.h... yes >>> checking for strings.h... yes >>> checking for inttypes.h... yes >>> checking for stdint.h... yes >>> checking for unistd.h... yes >>> checking for dlfcn.h... yes >>> checking whether we are using the GNU C++ compiler... (cached) yes >>> checking whether g++ accepts -g... (cached) yes >>> checking dependency style of g++... (cached) gcc3 >>> checking how to run the C++ preprocessor... g++ -E >>> checking for objdir... .libs >>> checking if gcc supports -fno-rtti -fno-exceptions... no >>> checking for gcc option to produce PIC... -fno-common -DPIC >>> checking if gcc PIC flag -fno-common -DPIC works... yes >>> checking if gcc static flag -static works... no >>> checking if gcc supports -c -o file.o... yes >>> checking if gcc supports -c -o file.o... (cached) yes >>> checking whether the gcc linker >>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) supports shared >>> libraries... yes >>> checking dynamic linker characteristics... darwin9.8.0 dyld >>> checking how to hardcode library paths into programs... immediate >>> checking whether stripping libraries is possible... yes >>> checking if libtool supports shared libraries... yes >>> checking whether to build shared libraries... yes >>> checking whether to build static libraries... yes >>> checking for ld used by g++... >>> /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld >>> checking if the linker >>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) is GNU ld... no >>> checking whether the g++ linker >>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) supports shared >>> libraries... yes >>> checking for g++ option to produce PIC... -fno-common -DPIC >>> checking if g++ PIC flag -fno-common -DPIC works... yes >>> checking if g++ static flag -static works... no >>> checking if g++ supports -c -o file.o... yes >>> checking if g++ supports -c -o file.o... (cached) yes >>> checking whether the g++ linker >>> (/usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/ld) supports shared >>> libraries... yes >>> checking dynamic linker characteristics... darwin9.8.0 dyld >>> checking how to hardcode library paths into programs... immediate >>> checking locale.h usability... yes >>> checking locale.h presence... yes >>> checking for locale.h... yes >>> checking for LC_MESSAGES... yes >>> checking libintl.h usability... no >>> checking libintl.h presence... no >>> checking for libintl.h... no >>> checking whether NLS is requested... yes >>> checking for intltool >= 0.35.0... 0.40.6 found >>> checking for intltool-update... /opt/local/bin/intltool-update >>> checking for intltool-merge... /opt/local/bin/intltool-merge >>> checking for intltool-extract... /opt/local/bin/intltool-extract >>> checking for xgettext... /opt/local/bin/xgettext >>> checking for msgmerge... /opt/local/bin/msgmerge >>> checking for msgfmt... /opt/local/bin/msgfmt >>> checking for gmsgfmt... /opt/local/bin/msgfmt >>> checking for perl... /opt/local/bin/perl >>> checking for perl >= 5.8.1... 5.8.9 >>> checking for XML::Parser... ok >>> checking for wx-config... /usr/local/bin/wx-config >>> checking for wxWidgets version >= 2.8.0... yes (version 2.9.0) >>> checking for wxWidgets static library... yes >>> checking for usb_bulk_write in -lusb... no >>> configure: error: >>> Libusb 0.1.x is required. >>> >>> Please install it from your package manager. >>> >>> make: *** No targets specified and no makefile found. Stop. >>> make: Nothing to be done for `install'. >>> cp: src/usbpicprog.app/Contents/MacOS/output/bin/usbpicprog: No such >>> file or directory >>> cp: src/usbpicprog.app/Contents/MacOS/output/lib/locale: No such >>> file or directory >>> cp: libs//libusb.dylib: No such file or directory >>> otool: can't open file: libs//libusb.dylib (No such file or directory) >>> install_name_tool: can't open file: >>> src/usbpicprog.app/Contents/SharedSupport/libusb.dylib (No such file >>> or directory) >>> Usage: install_name_tool [-change old new] ... [-id name] input >>> >>> >>> On 22 feb 2010, at 08:53, Frans Schreuder wrote: >>> >>>> Dear Aleksej, >>>> >>>> I am sorry that I have missed your message. >>>> the forums have been deleted because usbpicprog had too many >>>> channels of >>>> getting support, we have now chosen to use the mailing list >>>> usb...@li... as the main support >>>> channel. >>>> >>>> I think the problem you are facing is the version of libusb that >>>> usbpicprog demands, and this is also related to the version of >>>> usbpicprog that you are trying to compile. >>>> I think you have tried to compile version 0.3.0 which needs >>>> libusb-0.1. >>>> However, we recently switched to the newer version of libusb; >>>> libusb-1.0, this is true for any development branch of usbpicprog > >>>> 803. >>>> I suggest that you try downloading >>>> http://usbpicprog.org/downloads/usbpicprog-823-20100219.tar.gz and >>>> build >>>> it. >>>> You will also need the development version of wxWidgets, 2.9.0 >>>> installed. >>>> >>>> Kind regards, >>>> >>>> Frans Schreuder >>>> >>>> >>>> >>>> On Sun, 2010-02-21 at 18:41 +0100, Aleksej Horvat wrote: >>>>> Name: Aleksej Horvat >>>>> >>>>> Email: ah...@ma... >>>>> >>>>> Subject: Mac OS X PPC Compile >>>>> >>>>> Message: Hello, >>>>> A few days ago I posted a request for advice in the forum on >>>>> SourceForge. As of now I see that the forum has This leads me to >>>>> believe that I won't be receiving any advice. >>>>> I am running OS X 10.5.8 on PPC Mac, however, I have attempted the >>>>> buildmac.sh on an Intel Mac I have access to and it fails at the same >>>>> point. I have installed the latest wxwidgets and libusb (through >>>>> fink, >>>>> although that shouldn't matter). The problem is related to the 'has >>>>> libusb' check in the makefile, relating to the usb_bulk_write >>>>> command. >>>>> I have checked my installation and I do have libusb in my path. >>>>> I have basic programming experience, but I am unfortunately not >>>>> terribly familiar with the make syntax at this moment. Which means I >>>>> am not able to immediately debug the makefile. Perhaps if you gave me >>>>> some advice, I could try and let you know what happens. Terminal >>>>> output does not fit the character limit here. >>>>> Any help would be greatly appreciated, >>>>> Aleksej >>>>> >>>>> IP: 85.146.126.46 >>>>> HOST: s55927e2e.adsl.wanadoo.nl >>>>> >>>>> >>>> >>> > |
|
From: Frans S. <fra...@gm...> - 2010-02-22 07:54:01
|
Dear Aleksej, I am sorry that I have missed your message. the forums have been deleted because usbpicprog had too many channels of getting support, we have now chosen to use the mailing list usb...@li... as the main support channel. I think the problem you are facing is the version of libusb that usbpicprog demands, and this is also related to the version of usbpicprog that you are trying to compile. I think you have tried to compile version 0.3.0 which needs libusb-0.1. However, we recently switched to the newer version of libusb; libusb-1.0, this is true for any development branch of usbpicprog > 803. I suggest that you try downloading http://usbpicprog.org/downloads/usbpicprog-823-20100219.tar.gz and build it. You will also need the development version of wxWidgets, 2.9.0 installed. Kind regards, Frans Schreuder On Sun, 2010-02-21 at 18:41 +0100, Aleksej Horvat wrote: > Name: Aleksej Horvat > > Email: ah...@ma... > > Subject: Mac OS X PPC Compile > > Message: Hello, > A few days ago I posted a request for advice in the forum on > SourceForge. As of now I see that the forum has This leads me to > believe that I won't be receiving any advice. > I am running OS X 10.5.8 on PPC Mac, however, I have attempted the > buildmac.sh on an Intel Mac I have access to and it fails at the same > point. I have installed the latest wxwidgets and libusb (through fink, > although that shouldn't matter). The problem is related to the 'has > libusb' check in the makefile, relating to the usb_bulk_write command. > I have checked my installation and I do have libusb in my path. > I have basic programming experience, but I am unfortunately not > terribly familiar with the make syntax at this moment. Which means I > am not able to immediately debug the makefile. Perhaps if you gave me > some advice, I could try and let you know what happens. Terminal > output does not fit the character limit here. > Any help would be greatly appreciated, > Aleksej > > IP: 85.146.126.46 > HOST: s55927e2e.adsl.wanadoo.nl > > |
|
From: Francesco <f18...@ya...> - 2010-02-20 11:39:55
|
Hi all, UsbPicProg has recently switched from libusb0.1 to libusb1.0 and is now using, on Windows platforms, a driver developed by Microsoft itself for USB communications. This has the big advantage that the driver is safer than the one provided by libusb-win32 (which works in kernel mode) and supports all recent Windows systems (WinXP and newer) both in 32bit and 64bit variants. Since the UsbPicProg developers have access to limited hw resources I'm asking you to kindly test the new UsbPicProg installer on your system and report here the results: step #1) download the installer suitable for your system (x86 or amd64) from: http://usbpicprog.org/downloads/UsbPicProg-x86-r824-debug.exe http://usbpicprog.org/downloads/UsbPicProg-amd64-r824-debug.exe step #2) run it step #3) report here if the installation was ok and if not which message you got (in this case please attach also your C:\windows\dpinst.log log file) Users with Windows Vista (both 32 and 64 bits) are very much welcome ;) Thanks a lot! Francesco PS: from 23 to 27 february I won't have internet access but I'll look at all reported installations as soon as I'm back! |
|
From: Francesco <f18...@ya...> - 2010-02-17 21:17:28
|
Hi, 2010/2/16 Francesco <f18...@ya...>: > 2010/2/16 Frans Schreuder <fra...@gm...>: >>> I've tried the x86 version on Win XP, but no success (it causes an >>> exception with something like kernel32.dll and then libusb-1.0.dll) >> very strange. Is it a WinXP without Service Packs installed? >> Tomorrow (evening) I'll have a chance to test the installer on a >> relatively vanilla WinXP installation (so far I've tested only on the >> machine I use for programming and where I did miscellaneous driver >> tests). I'll let you know what I get. >> >> I have tried different XP machines (all SP3) and even wine. They all get the >> same error. > I don't know if it could be the source of problems but the machine > where I tested it is a WinXP SP2 pc. > Unfortunately today I didn't manage to test on a vanilla XP. I'll test > it tomorrow. I've tested it on a WinXP SP3. The installation apparently was ok but the installer asked me to reboot the machine. After rebooting however I started upp_wx (with the upp hw not connected) and I got an unhandled exception with a backtrace identical to yours. Ouch. Then I plugged in the upp hw. Windows didn't find the drivers (which the installer should have installed in the driver store!) and asked me for one. I pointed it to C:\Program Files\UsbPicProg\driver and the installation proceeded smoothly. I restarted upp_wx and it worked. This highlighted two problems: 1) libusb/libpthread seems buggy and if the driver is not installed it crashes; 2) dpinst seem not to have installed the driver correctly. For #1 I think that it is a matter of re-compiling everything in debug mode and run the app in MSVC and then make a proper bug report to libusb/libpthread guys with a proper backtrace (with function names). For #2 the problem is more on our shoulders. I checked and this is the C:\windows\dpinst.log portion relative to the installation of the upp driver: INFO: **************************************** INFO: 02/16/2010 17:17:25 INFO: Product Version 2.1.0.0. INFO: Version: 5.1.2600 Service Pack 3 INFO: Platform ID: 2 (NT) INFO: Service Pack: 3.0 INFO: Suite: 0x0100, Product Type: 1 INFO: Architecture: X86. INFO: Interactive Windows Station INFO: Command Line: '"C:\Programmi\UsbPicProg\driver\dpinst.exe"' INFO: DPInst is a multi-lingual binary. INFO: **************************************** INFO: Current working directory: 'C:\Programmi\UsbPicProg\driver' INFO: Running on path 'C:\Programmi\UsbPicProg\driver' INFO: DPInst.xml does not list the current UI language. INFO: User UI Language is 0x410. INFO: Install option set: Suppressing Wizard but no OS popups. INFO: Install option set: Running in quiet mode. Suppressing Wizard and OS popups. INFO: Install option set: legacy mode on. INFO: Install option set: Suppress Add or Remove Programs entries. INFO: Install option set: Install all driver packages or none. INFO: Found driver package: 'C:\Programmi\UsbPicProg\driver\bootloader.inf'. INFO: Found driver package: 'C:\Programmi\UsbPicProg\driver\upp.inf'. INFO: Preinstalling 'c:\programmi\usbpicprog\driver\bootloader.inf' ... INFO: ENTER: DriverPackagePreinstallW WARNING:Driver Package 'bootloader.inf' references Catalog file 'c:\programmi\usbpicprog\driver\libusb_device.cat' that cannot be found. INFO: Copied 'bootloader.inf' to driver store... INFO: Commiting queue... INFO: Copied file: 'c:\programmi\usbpicprog\driver\x86\WinUSBCoInstaller2.dll' -> 'C:\WINDOWS\system32\DRVSTORE\bootloader_F389A405038599F0F7494EC02C7E9AE68D9598EF\x86\WinUSBCoInstaller2.dll'. INFO: Copied file: 'c:\programmi\usbpicprog\driver\x86\WdfCoInstaller01009.dll' -> 'C:\WINDOWS\system32\DRVSTORE\bootloader_F389A405038599F0F7494EC02C7E9AE68D9598EF\x86\WdfCoInstaller01009.dll'. INFO: Removed driver package from store. INFO: RETURN: DriverPackagePreinstallW (0xE000022F) INFO: Returning with code 0x80020000 INFO: 02/16/2010 17:17:28 the warning about the cat shouldn't be a problem (it's a real problem only if <legacyMode> is not used in the dpinst.xml file). The problem is that the return code indicates (see http://msdn.microsoft.com/en-us/library/ms791066.aspx) that 1) a driver package could not be installed 2) the number of driver packages that could not be installed is 2 Now, I realized that there is indeed a bug in the parsing of the dpinst return code. I should have fixed it now. However I still don't understand why dpinst failed the installation and the log above doesn't help (looking at it, except for the return code, everything seems ok). I need to do some search about this. Francesco |
|
From: Francesco <f18...@ya...> - 2010-02-16 22:27:46
|
Hi, 2010/2/16 Frans Schreuder <fra...@gm...>: >> I've tried the x86 version on Win XP, but no success (it causes an >> exception with something like kernel32.dll and then libusb-1.0.dll) > very strange. Is it a WinXP without Service Packs installed? > Tomorrow (evening) I'll have a chance to test the installer on a > relatively vanilla WinXP installation (so far I've tested only on the > machine I use for programming and where I did miscellaneous driver > tests). I'll let you know what I get. > > I have tried different XP machines (all SP3) and even wine. They all get the > same error. I don't know if it could be the source of problems but the machine where I tested it is a WinXP SP2 pc. Unfortunately today I didn't manage to test on a vanilla XP. I'll test it tomorrow. > Did you use the libusb-1.0.dll compiled by me? that one was built using mingw, not MSVC++. no, I initially had some problems with the stuff which was in libusb1_win32 folder so I recompiled everything (except pthread whose precompiled versions were provided by Pete Batard on the win backend homepage) with MSVC++, made sure to enable release mode and to have the switch /MD used coherently everywhere.... > Backtrace: > =>0 0x7b866ffc InterlockedCompareExchange+0xc() in kernel32 (0x0032fc2c) > 1 0x00333358 in pthreadvc2 (+0x3358) (0x0032fc4c) > 2 0x10001e22 in libusb-1.0 (+0x1e22) (0x00845a78) > 3 0x00000000 (0x006020b4) > 4 0x004188d0 in usbpicprog (+0x188d0) (0x004ab910) > it looks to be a problem in pthreadvc2 then. Maybe I should build a debug version for now so that the EXE which gets installed can be easily debugged with MSVC++. Anyway probably in few days the pthread dependency willb e completely removed from libusb, for the windows backend. >> I've fixed this now and uploaded corrected installers at: >> http://usbpicprog.org/downloads/UsbPicProg-amd64-0.3.0.exe >> http://usbpicprog.org/downloads/UsbPicProg-x86-0.3.0.exe > > I guess you didn't build the 0.3.0 version from tags, but the latest trunk > version. Shouldn't we call it 819 in stead of 0.3.0? indeed. Will fix it. >> note however that you cannot run a 64bit OS in a virtual machine >> hosted on a 32bit OS (only the viceversa is possible)... > > Yes you can with virtualbox, as long as you have a 64 bit processor. interesting, I didn't know... > But > anyway, I do run ubuntu amd64 so I won't have a problem. if the problem persists I can setup a virtual machine, too (in the weekend).. Francesco |
6 messages has been excluded from this view by a project administrator.
