usbpicprog-technical

[Usbpicprog-technical] [usbpicprog-technical] Initialization of libusb

[Frans S. <fra...@gm...>]

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

Re: [Usbpicprog-technical] [usbpicprog-technical] Initialization of libusb

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

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

Re: [Usbpicprog-technical] [usbpicprog-technical] Initialization of libusb

[Frans S. <fra...@gm...>]

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

Re: [Usbpicprog-technical] [usbpicprog-technical] Initialization of libusb

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

Hi Frans,

2010/3/4 Frans Schreuder <fra...@gm...>:
> Because the way it was, only the gui part was connecting to the programmer,
> when the command line interface was invoked, usbpicprog gave a seg fault. Of
> course it is also possible to initialize libusb twice, but I think from
> hardware is more charming...
I've re-tested upp_wx on WinXP and indeed I was able to reproduce the
problem recently reported by Mark Jones on a vanilla installation.
IMO the best solution in case libusb fails to initialize is to
immediately stop the application. That's why I moved libusb
initialization back to main.cpp again but this time I made sure that
libusb is initialized also when running in console mode.

I hope the change is ok for you...

Francesco

Re: [Usbpicprog-technical] [usbpicprog-technical] Initialization of libusb

[Frans S. <fra...@gm...>]

> 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

Re: [Usbpicprog-technical] [usbpicprog-technical] Initialization of libusb

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

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