Menu
▾
▴
usbpicprog-technical
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(13) |
Nov
(27) |
Dec
(23) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(13) |
Mar
(24) |
Apr
(4) |
May
(11) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(5) |
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
(22) |
Mar
(52) |
Apr
(7) |
May
(19) |
Jun
(12) |
Jul
(9) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(8) |
Dec
(7) |
| 2011 |
Jan
(12) |
Feb
(7) |
Mar
(10) |
Apr
(14) |
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(12) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
|
Dec
|
| 2013 |
Jan
(7) |
Feb
(6) |
Mar
(6) |
Apr
(21) |
May
(7) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Frans S. <fra...@gm...> - 2009-02-28 20:05:14
|
Hi Francesco, I think Doxygen is a good idea, the thing is that I have never done it, how do I start? Cheers, Frans Francesco Montorsi wrote: > Hi Frans, > I think that even if upp_wx internals are quite simple (at least for now) and linear, it would be better to use doxygen-styled comments in the headers to document the internal interfaces of the various classes instead of plain comments. > > This would greatly help other developers interested in the project to contribute modifications and new features... > > Sounds good? > > Francesco > > __________________________________________________ > Do You Yahoo!? > Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi > http://mail.yahoo.it > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
|
From: Francesco M. <f18...@ya...> - 2009-02-28 19:06:54
|
Hi Frans, I think that even if upp_wx internals are quite simple (at least for now) and linear, it would be better to use doxygen-styled comments in the headers to document the internal interfaces of the various classes instead of plain comments. This would greatly help other developers interested in the project to contribute modifications and new features... Sounds good? Francesco __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it |
|
From: Francesco M. <f18...@ya...> - 2009-02-28 14:30:43
|
Hi Frans,
I'm looking at implementing loading PIC data from Piklab XML as we talked
about some time ago.
This would allow to have an "Info" page next to the "Code", "Cfg flags" and
"Data" current pages with lots of info about the selected PIC and to have the
"Configuration flags" page reorganized to contain e.g. an array of checkboxes
which indicate "Oscillator type", etc etc. This last feature in particular would
help very much IMO (looking at the flags in hexadecimal form is quite ugly).
Looking at the UPP source file, for example for PIC16F84A, I see:
{
"P16F84A", //Name
0x1FF*2, //CodeSize
0x2007, //ConfigAddress
0x2100, //DataAddress in hex file
0x40, //Datasize
0x2, //ConfigSize
P16F84A, //PicFamily
0x0560, //DevId
0x3FE0, //DevIdMask
{0xFF,0x3F}
},
the relative XML data is:
<device name="16F84A" ... id="0x0560" ...>
....
<!--* Memory ***************************************************************-->
<memory name="code" start="0x0000" end="0x03FF" />
<memory name="user_ids" start="0x2000" end="0x2003" rmask="0x007F" />
<memory name="device_id" start="0x2006" end="0x2006" />
<memory name="config" start="0x2007" end="0x2007" />
<memory name="eeprom" start="0x0000" end="0x003F" hexfile_offset="0x2100" />
<!--* Configuration bits ***************************************************-->
<config offset="0x0" name="" wmask="0x3FFF" bvalue="0x3FFF" >
<mask name="FOSC" value="0x0003" >
<value value="0x0000" name="LP" cname="_LP_OSC" />
<value value="0x0001" name="XT" cname="_XT_OSC" />
<value value="0x0002" name="HS" cname="_HS_OSC" />
<value value="0x0003" name="EXTRC_CLKOUT" cname="_RC_OSC" />
</mask>
<mask name="WDT" value="0x0004" >
<value value="0x0000" name="Off" cname="_WDT_OFF" />
<value value="0x0004" name="On" cname="_WDT_ON" />
</mask>
<mask name="PWRTE" value="0x0008" >
<value value="0x0000" name="On" cname="_PWRTE_ON" />
<value value="0x0008" name="Off" cname="_PWRTE_OFF" />
</mask>
<mask name="CP" value="0x3FF0" >
<value value="0x0000" name="All" cname="_CP_ON" />
<value value="0x3FF0" name="Off" cname="_CP_OFF" />
<value value="default" name="invalid" />
</mask>
</config>
....
</device>
So that the info we currently keep in pictype.cpp could be loaded from (using a
pseudo syntax to refer to the XML tags and XML attributes):
typedef struct {
string Name; <== "P"+ <device@name>
int CodeSize; <== <memory@name="code"@end> - <memory@name="code"@start>
int ConfigAddress; <== <memory@name="config"@start>
int DataAddress; //in hex file <== <memory@name="eeprom"@hexfile_offset>
int DataSize; <== <memory@name="eeprom"@end> - <memory@name="eeprom"@start>
int ConfigSize; <== <memory@name="config"@end> - <memory@name="config"@start>
PicFamily picFamily;
int DevId; <== <device@id>
int DevIdMask;
int ConfigMask[16];
} Pic;
stuff that seems cannot be loaded from XML is thus:
1) PicFamily picFamily;
This is a number corresponding to the UPP internal classification of
the PIC families and thus is obviously not present in Piklab XML files.
I think we can't do nothing about this.
2)
int DevIdMask;
int ConfigMask[16];
maybe I'm just missing something but this data cannot be derived from the data
contained in Piklab XML files in some way?
It would be nice to be able to load all data from the Piklab XML files without
being forced to modify them so that we could simply overwrite our XML files with
Piklab's updated ones from time to time.
Thanks,
Francesco
--
|
|
From: Francesco M. <f18...@ya...> - 2009-02-28 11:36:12
|
Hi,
sorry for the long delay, but better late than never :)
Frans Schreuder ha scritto:
>>> I don't think it should be very different, do you have the latest firmware?
>>>
>> I should have the firmware 0.1.1; I'll see what happens with the firmware in trunk.
>>
> Yes, try that one... It's also compiled, so you can just load the hex
> file...
I'm successfully using UPP with PIC16F84 and the very latest trunk firmware
since some week. I thought to report it here to close this thread :)
>> good idea; I'm currently using a cable 27cm long. I'll try with a shorter one
>> even if the electrical length of the cable at 8Mhz is about
>>
>> L = 0.27/37 = 0.0073
>>
>> which I think could be considered negligible.
>>
> In terms of wavelength you are absolutely right, but what about inductance?
> If we consider the wire to be 1.5nH per millimeter, you get something
> like 400nH which will result in 20 Ohms reactance at 8MHz. Luckily the
> programmer doesn't run at 8 MHz, but something closer to 1MHz, so this
> wouldn't be a big problem, it's just a couple of ohms.
Indeed, you're right. I'm used to think in terms of electrical lengths but I
shouldn't have overlooked the wire inductance :)
> But you shouldn't make them much longer than that!
Ok!
Francesco
--
|
|
From: Francesco M. <f18...@ya...> - 2009-02-08 13:42:50
|
Hi Frans, Frans Schreuder ha scritto: > You have implemented some code in usbpicprog which forces me to update > to the latest wx svn... > Unfortunately wxwidgets doesn't compile for me at the moment: > > /usr/include/libpng12 ../src/common/fdiodispatcher.cpp > In file included from ../src/common/fdiodispatcher.cpp:34: > ../include/wx/unix/private/epolldispatcher.h:38: error: conflicting > return type specified for ‘virtual int wxEpollDispatcher::Dispatch(int)’ > ../include/wx/private/fdiodispatcher.h:73: error: overriding ‘virtual > bool wxFDIODispatcher::Dispatch(int)’ > make: *** [baselib_fdiodispatcher.o] Error 1 > make: *** Waiting for unfinished jobs.... > > Could you tell me which revision I have to use that still compiles (at > least on linux)? I'm sorry - I think you had bad luck and updated in the middle of a series of commits... for me r58760 (the very latest one ATM) builds fine... Let me know if you still get errors... Francesco -- |
|
From: Frans S. <fra...@gm...> - 2009-02-08 09:49:54
|
Hi Francesco, You have implemented some code in usbpicprog which forces me to update to the latest wx svn... Unfortunately wxwidgets doesn't compile for me at the moment: /usr/include/libpng12 ../src/common/fdiodispatcher.cpp In file included from ../src/common/fdiodispatcher.cpp:34: ../include/wx/unix/private/epolldispatcher.h:38: error: conflicting return type specified for ‘virtual int wxEpollDispatcher::Dispatch(int)’ ../include/wx/private/fdiodispatcher.h:73: error: overriding ‘virtual bool wxFDIODispatcher::Dispatch(int)’ make: *** [baselib_fdiodispatcher.o] Error 1 make: *** Waiting for unfinished jobs.... Could you tell me which revision I have to use that still compiles (at least on linux)? Thanks, Frans |
|
From: Frans S. <fra...@gm...> - 2009-02-05 07:46:33
|
Hi Francesco, Nice to see that you have fixed the progress dialog! I wanted to release 0.2.0 just before Fosdem http://fosdem.org/2009/ since I am going to do a presentation there! Of course I can release a version 0.2.1 soon... there's always a next release... I can also just recompile and release it as the same version since nothing in the usbpicprog code changed! Next time, I'll let the mailing list know... Frans Francesco Montorsi wrote: > Francesco Montorsi ha scritto: > >> PS: I think that after this fix a new release could be done.... >> > Ops! I've just noticed that I missed the 0.2.0 release few days ago :) > I think it would be nice when making releases to also send an announcement to > this mailing list and also to the mailing list of other possibly-interested > parties (e.g. sci.electronics.equipment, alt.engineering.electrical; for Italy I > could post to it.hobby.elettronica, etc etc)... > > Anyway it's nice to see the project advancing ;) > Francesco > > > |
|
From: Francesco M. <f18...@ya...> - 2009-02-04 21:14:49
|
Francesco Montorsi ha scritto: > PS: I think that after this fix a new release could be done.... Ops! I've just noticed that I missed the 0.2.0 release few days ago :) I think it would be nice when making releases to also send an announcement to this mailing list and also to the mailing list of other possibly-interested parties (e.g. sci.electronics.equipment, alt.engineering.electrical; for Italy I could post to it.hobby.elettronica, etc etc)... Anyway it's nice to see the project advancing ;) Francesco -- |
|
From: Francesco M. <f18...@ya...> - 2009-02-04 19:54:26
|
Hi all!
as promised I finally managed to fix the race condition in wxProgressDialog
(that race condition which forced us to call Sleep() inside UppMainWindow::Entry).
This however requires you to update to the very latest wxWidgets trunk to be
able to compile UPP (NB: it should still compile against wx28 but when wx29 is
found at compile time, then the new wxThreadEvent class is required).
Please let me know if you find any problem with this change!
Keep up the good work!
Francesco
PS: I think that after this fix a new release could be done....
--
|
|
From: Frans S. <fra...@gm...> - 2009-02-01 13:19:03
|
Hi Kacper, If you want to implement this, go ahead! For myself, I want to concentrate more on implementing the other devices into usbpicprog, rather than implementing things like this. Maybe in the future! Cheers, Frans 2009/2/1 Junk <ju...@ka...> > Hi, > > Sorry that my question didn't make any sense. Well first of all perhaps I > should introduce my self... > I'm a young student currently learning about PIC programming. > > I meant I would like to communicate with the 629 through usb, I was > thinking about using usbpicprog so that I can both communicate and program > the 629. The FT232 look promising but then I would have to switch between > the programmer and the FT232. > > Thanks, > Kacper > > > On Sun, Feb 1, 2009 at 1:21 PM, Frans Schreuder <fra...@gm...>wrote: > >> Hi, >> >> I don't really understand what you are talking about. >> If you mean that you want to program the 12F629 with usbpicprog, yes you >> can... >> If you want to make another version of usbpicprog, using the 12F629 as the >> core, forget it >> If you want to communicate with the 629 through usb, you are probably >> better off using an FT232 chip. >> Please explain better the next time what you mean (and who you are...)! >> >> Cheers, >> >> Frans >> >> 2009/2/1 Junk <ju...@ka...> >> >>> Would it be possible to modify usbpicprog to support USB communication >>> with another pic that lacks USB support - in this case a pic12f629. Right >>> now the 12f629 is controlled by the VPP line (connected to the TxD on the >>> serial port). >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by: >>> SourcForge Community >>> SourceForge wants to tell your story. >>> http://p.sf.net/sfu/sf-spreadtheword >>> _______________________________________________ >>> Usbpicprog-technical mailing list >>> Usb...@li... >>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >>> >>> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >> >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > |
|
From: Junk <ju...@ka...> - 2009-02-01 12:51:51
|
Hi, Sorry that my question didn't make any sense. Well first of all perhaps I should introduce my self... I'm a young student currently learning about PIC programming. I meant I would like to communicate with the 629 through usb, I was thinking about using usbpicprog so that I can both communicate and program the 629. The FT232 look promising but then I would have to switch between the programmer and the FT232. Thanks, Kacper On Sun, Feb 1, 2009 at 1:21 PM, Frans Schreuder <fra...@gm...>wrote: > Hi, > > I don't really understand what you are talking about. > If you mean that you want to program the 12F629 with usbpicprog, yes you > can... > If you want to make another version of usbpicprog, using the 12F629 as the > core, forget it > If you want to communicate with the 629 through usb, you are probably > better off using an FT232 chip. > Please explain better the next time what you mean (and who you are...)! > > Cheers, > > Frans > > 2009/2/1 Junk <ju...@ka...> > >> Would it be possible to modify usbpicprog to support USB communication >> with another pic that lacks USB support - in this case a pic12f629. Right >> now the 12f629 is controlled by the VPP line (connected to the TxD on the >> serial port). >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >> >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > |
|
From: Frans S. <fra...@gm...> - 2009-02-01 12:21:10
|
Hi, I don't really understand what you are talking about. If you mean that you want to program the 12F629 with usbpicprog, yes you can... If you want to make another version of usbpicprog, using the 12F629 as the core, forget it If you want to communicate with the 629 through usb, you are probably better off using an FT232 chip. Please explain better the next time what you mean (and who you are...)! Cheers, Frans 2009/2/1 Junk <ju...@ka...> > Would it be possible to modify usbpicprog to support USB communication with > another pic that lacks USB support - in this case a pic12f629. Right now the > 12f629 is controlled by the VPP line (connected to the TxD on the serial > port). > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > |
|
From: Junk <ju...@ka...> - 2009-02-01 03:54:44
|
Would it be possible to modify usbpicprog to support USB communication with another pic that lacks USB support - in this case a pic12f629. Right now the 12f629 is controlled by the VPP line (connected to the TxD on the serial port). |
|
From: Francesco M. <f18...@ya...> - 2008-12-29 11:12:08
|
Hi Frans Frans Schreuder ha scritto: > Hi Francesco, > > I have been struggling using the bootloader with the new threaded > usbpicprog, but I get a segmentation fault every time I use it... > > The funny thing is that I don't see any difference in the thread > handling with the bootloader and the usbpicprog hardware, but it happens > on reading and on programming the bootloader. > > Could you have a look at it? I already hit this bug some days ago (a week or so) and I wanted to drop a message here but I hadn't find time. The bug is deriving from the wxYieldIfNeeded() call in wxProgressDialog::Update() which causes the progress dialog to be destroyed while it's still in use. I'm working on a fix directly in wxWidgets code (I've been discussing this hot topic in the last days on wx-dev) and I'm very very near to the final fix... I'll let you know when I fix it (I think this is the last thing which blocks a release...) Sorry for the problem, Francesco -- |
|
From: Frans S. <fra...@gm...> - 2008-12-29 11:07:47
|
Hi Francesco,
I have been struggling using the bootloader with the new threaded
usbpicprog, but I get a segmentation fault every time I use it...
The funny thing is that I don't see any difference in the thread
handling with the bootloader and the usbpicprog hardware, but it happens
on reading and on programming the bootloader.
Could you have a look at it?
Cheers,
Frans
gdb output:
[New Thread 0xb649ab90 (LWP 7873)]
[Thread 0xb649ab90 (LWP 7873) exited]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7375790 (LWP 7862)]
0x00000000 in ?? ()
(gdb) backtrace
#0 0x00000000 in ?? ()
#1 0x081c93f2 in wxProgressDialog::DoAfterUpdate ()
#2 0x081ca237 in wxProgressDialog::Update ()
#3 0x08066f88 in UppMainWindow::OnThreadUpdate (this=0x871a458,
evt=@0xb5b01938) at uppmainwindow.cpp:468
#4 0x0831d6c5 in wxEvtHandler::ProcessEventIfMatches ()
#5 0x0831d836 in wxEvtHandler::SearchDynamicEventTable ()
#6 0x0831e663 in wxEvtHandler::ProcessEventHere ()
#7 0x0831e6ec in wxEvtHandler::ProcessEvent ()
#8 0x0831ddc1 in wxEvtHandler::ProcessPendingEvents ()
#9 0x082414b0 in wxAppConsoleBase::ProcessPendingEvents ()
#10 0x08127f99 in wxAppBase::ProcessIdle ()
#11 0x080dada3 in wxApp::DoIdle ()
#12 0x080daea3 in wxapp_idle_callback ()
#13 0xb79bc7c1 in ?? () from /usr/lib/libglib-2.0.so.0
#14 0xb79be6f8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0xb79c1da3 in ?? () from /usr/lib/libglib-2.0.so.0
#16 0xb79c22c2 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#17 0xb7df03a9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x081e2684 in wxGUIEventLoop::Run ()
#19 0x082411d0 in wxAppConsoleBase::MainLoop ()
#20 0x0829f8fd in wxEntry ()
#21 0x08073570 in main (argc=592, argv=0x18) at main.cpp:25
|
|
From: Frans S. <fra...@gm...> - 2008-12-12 16:40:33
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Francesco Montorsi wrote:
<blockquote cite="mid:494...@ya..." type="cite">
<pre wrap="">Frans Schreuder ha scritto:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">AFAIK the wx translations should get loaded automatically... I'll look why they
aren't.
</pre>
</blockquote>
<pre wrap="">At the moment we use strings like _("new") for the toolbar buttons, and
wxID_NEW with a wxEmtyString for the caption. I think I will just put
the strings in the formbuilder project, and we are done...
</pre>
</blockquote>
<pre wrap=""><!---->if this not an urgent issue I think I can fix it in the proper way (i.e. using
stock items and stock wx translations). Fixing this also means less work for
translators (no need to translate stock items) and that all wxWidgets internal
error messages which it could throw from "inside" the library would appear
correctly translated, too.
</pre>
</blockquote>
well, the "new" strings were there already, so it was no extra work at
all, I already fixed it...<br>
will commit shortly...<br>
<blockquote cite="mid:494...@ya..." type="cite">
<pre wrap="">Francesco
</pre>
</blockquote>
</body>
</html>
|
|
From: Francesco M. <f18...@ya...> - 2008-12-12 16:38:16
|
Frans Schreuder ha scritto:
>> AFAIK the wx translations should get loaded automatically... I'll look why they
>> aren't.
>>
> At the moment we use strings like _("new") for the toolbar buttons, and
> wxID_NEW with a wxEmtyString for the caption. I think I will just put
> the strings in the formbuilder project, and we are done...
if this not an urgent issue I think I can fix it in the proper way (i.e. using
stock items and stock wx translations). Fixing this also means less work for
translators (no need to translate stock items) and that all wxWidgets internal
error messages which it could throw from "inside" the library would appear
correctly translated, too.
Francesco
--
|
|
From: Frans S. <fra...@gm...> - 2008-12-12 16:33:02
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:494...@ya..." type="cite">
<pre wrap="">Hi Frans,
Frans Schreuder ha scritto:
</pre>
<blockquote type="cite">
<pre wrap="">You have changed all the menu items lixe "&New" and "&Open" into
wxID_NEW etcetera.
</pre>
</blockquote>
<pre wrap=""><!---->Yes, since those IDs correspond to 'stock items' wxWidgets will automatically
choose the correct native accelerator, label, etc.
</pre>
</blockquote>
Well, they are not... :( And also the one who has made the Arabic
version didn't see the translated string, neither did he in Windows.<br>
<blockquote cite="mid:494...@ya..." type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">I guess they should be translated by the system, but
they are not... Do you have any idea how to make them translate
themselves? Do I need to install special locales for wxWidgets or
something?
</pre>
</blockquote>
<pre wrap=""><!---->Yes, exactly. wxWidgets has its own locales in wxWidgets/locale and there are
all stock item labels translated in lots of languages...
AFAIK the wx translations should get loaded automatically... I'll look why they
aren't.
</pre>
</blockquote>
At the moment we use strings like _("new") for the toolbar buttons, and
wxID_NEW with a wxEmtyString for the caption. I think I will just put
the strings in the formbuilder project, and we are done...<br>
<blockquote cite="mid:494...@ya..." type="cite">
<pre wrap="">
Btw how do you test locales != english? I rememeber I managed to do it in one of
my past projects but now if I try:
frm@ubuntu:~/work/usbpicprog/upp_wx$ export LANG=nl_NL
frm@ubuntu:~/work/usbpicprog/upp_wx$ src/usbpicprog
</pre>
</blockquote>
It's either <br>
$export LANG=nl_NL.UTF-8 <br>
or<br>
$LC_ALL=nl_NL.UTF-8 usbpicprog<br>
<br>
<br>
<blockquote cite="mid:494...@ya..." type="cite">
<pre wrap="">I get:
(process:10965): Gdk-WARNING **: locale not supported by C library
(usbpicprog:10965): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
[Debug] 17:26:38: ../src/common/intl.cpp(2576): assert "IsOk()" failed in
AddCatalog(): must initialize catalog first
Trace/breakpoint trap
Francesco
</pre>
</blockquote>
</body>
</html>
|
|
From: Francesco M. <f18...@ya...> - 2008-12-12 16:27:26
|
Hi Frans,
Frans Schreuder ha scritto:
> You have changed all the menu items lixe "&New" and "&Open" into
> wxID_NEW etcetera.
Yes, since those IDs correspond to 'stock items' wxWidgets will automatically
choose the correct native accelerator, label, etc.
>I guess they should be translated by the system, but
> they are not... Do you have any idea how to make them translate
> themselves? Do I need to install special locales for wxWidgets or
> something?
Yes, exactly. wxWidgets has its own locales in wxWidgets/locale and there are
all stock item labels translated in lots of languages...
AFAIK the wx translations should get loaded automatically... I'll look why they
aren't.
Btw how do you test locales != english? I rememeber I managed to do it in one of
my past projects but now if I try:
frm@ubuntu:~/work/usbpicprog/upp_wx$ export LANG=nl_NL
frm@ubuntu:~/work/usbpicprog/upp_wx$ src/usbpicprog
I get:
(process:10965): Gdk-WARNING **: locale not supported by C library
(usbpicprog:10965): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
[Debug] 17:26:38: ../src/common/intl.cpp(2576): assert "IsOk()" failed in
AddCatalog(): must initialize catalog first
Trace/breakpoint trap
Francesco
--
|
|
From: Frans S. <fra...@gm...> - 2008-12-12 15:11:06
|
Hi Francesco, You have changed all the menu items lixe "&New" and "&Open" into wxID_NEW etcetera. I guess they should be translated by the system, but they are not... Do you have any idea how to make them translate themselves? Do I need to install special locales for wxWidgets or something? If you don't know, I will just put the strings back and translate them in the po files. Cheers, Frans |
|
From: Frans S. <fra...@gm...> - 2008-12-10 10:12:50
|
Hi Francesco, Francesco Montorsi wrote: > Hi, > > Frans Schreuder ha scritto: > >> I don't think it should be very different, do you have the latest firmware? >> > I should have the firmware 0.1.1; I'll see what happens with the firmware in trunk. > Yes, try that one... It's also compiled, so you can just load the hex file... > > > good idea; I'm currently using a cable 27cm long. I'll try with a shorter one > even if the electrical length of the cable at 8Mhz is about > > L = 0.27/37 = 0.0073 > > which I think could be considered negligible. > In terms of wavelength you are absolutely right, but what about inductance? If we consider the wire to be 1.5nH per millimeter, you get something like 400nH which will result in 20 Ohms reactance at 8MHz. Luckily the programmer doesn't run at 8 MHz, but something closer to 1MHz, so this wouldn't be a big problem, it's just a couple of ohms. But you shouldn't make them much longer than that! Cheers, Frans |
|
From: Francesco M. <f18...@ya...> - 2008-12-10 09:18:34
|
Hi, Frans Schreuder ha scritto: > I don't think it should be very different, do you have the latest firmware? I should have the firmware 0.1.1; I'll see what happens with the firmware in trunk. > I will try the 16F84A tomorrow if it still works for me. The only way to > debug such things is to modify the firmware to let it send back something. > For the PIC16F84A (and LF) usbpicprog verifies the memory also during > programming time, so if it doesn't complain during programming, it > should be ok. interesting >Autodetecting is the same algorithm as reading the device, > so I think the problem is the reading. Maybe you should try to run your > program. indeed, I'll test it asap. > btw, how long is your cable from upp to 16LF84A? maybe you can try a > shorter one. good idea; I'm currently using a cable 27cm long. I'll try with a shorter one even if the electrical length of the cable at 8Mhz is about L = 0.27/37 = 0.0073 which I think could be considered negligible. Thanks, Francesco -- |
|
From: Francesco M. <f18...@ya...> - 2008-12-10 09:17:16
|
Hi, Frans Schreuder ha scritto: > I think we can remove the branched version again since it is now > merged... what do you think? I think it would be better to leave it in "branches" tree... in the other open source projects where I collaborate, we never delete branches; they give no problems and instead they could give problems if removed. E.g. if you look at the history of a trunk upp_wx file: http://usbpicprog.svn.sourceforge.net/viewvc/usbpicprog/trunk/upp_wx/src/uppmainwindow.cpp?view=log you'll see that many revisions have "Original Path: branches/upp_wx_thread/upp_wx/src/uppmainwindow.cpp". I'm not sure what happens if the branch gets removed. Maybe we just loose all the history of those revisions... In conclusion, I'd rather not remove it unless there are specific advantages in doing it. Bye, Francesco -- |
|
From: Frans S. <fra...@gm...> - 2008-12-09 20:02:54
|
Hi Francesco, I think we can remove the branched version again since it is now merged... what do you think? Cheers, Frans |
|
From: Frans S. <fra...@gm...> - 2008-12-09 07:31:15
|
Hi Francesco, I don't think it should be very different, do you have the latest firmware? I will try the 16F84A tomorrow if it still works for me. The only way to debug such things is to modify the firmware to let it send back something. For the PIC16F84A (and LF) usbpicprog verifies the memory also during programming time, so if it doesn't complain during programming, it should be ok. Autodetecting is the same algorithm as reading the device, so I think the problem is the reading. Maybe you should try to run your program. btw, how long is your cable from upp to 16LF84A? maybe you can try a shorter one. Cheers, Frans Francesco Montorsi wrote: > Hi Frans, > today I wanted to test UPP with a PIC16LF84A. > > It seems to be unable to autodetect it and after programming (which doesn't give > errors) if I choose "verify" I get: > > 23:29:40: => Verifying all areas of the PIC... > 23:29:43: => Verify code failed at 0x1. Read: 0xFF, Expected: 0x30 > 23:29:43: Operations completed with errors/warnings > > Do you know if the 16LF84A is significantly different from 16F84A ? > > How do you debug such problems? > > Thanks, > Francesco > > > |
6 messages has been excluded from this view by a project administrator.
