Menu
▾
▴
usbpicprog-technical
|
From: Francesco M. <f18...@ya...> - 2008-12-08 22:35:13
|
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 -- |
|
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 > > > |
|
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: 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: 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 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: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: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: 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: 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-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...> - 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
--
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X