usbpicprog-technical

Re: [Usbpicprog-technical] Compiling under Ubuntu 9.04

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Jasper Wallace,

I have built the .deb package (only i686 for now, I will do x86_64
later) on ubuntu 9.04 and it also appears to run well on 9.10.
I have updated the package in the download area!

Regards,

Frans Schreuder

Frans Schreuder wrote:
> Dear Jasper Wallace,
>
> Thank you for reporting this. I have already installed ubuntu 9.10,
>  which has the new glibc version. (Ubuntu 9.10 is going to be
> released next week). Ubuntu 9.10 is thus the system which I made
> the .deb package for. If you want to build it yourself, you will
> have to install wx2.9 indeed. (It should be able to compile with
> wx2.8.10, but it doesn't run very nicely) Thank you for reporting
> this issue, I will build a 9.04 version as well.
>
> Frans Schreuder
>
> Jasper Wallace wrote:
>> Hi,
>>
>> compiling fails with loads of wx includes/references errors, i
>> have 2.8 installed and that seems to be what configure.ac wants,
>> but the web pages says it need wx2.9 - is that really true?
>>
>> If i install the .deb and run it i get:
>>
>> usbpicprog: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not
>>  found (required by usbpicprog)
>>
>> Does anyone have 0.3.0 running under ubuntu?
>>
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrlbVgACgkQcY8HGIrVkF6T6wCglnV4TLATOFYA/FTcFpRnkMrL
pjMAnRzfvsVhFQTqiZUcfBMbcdPQPOiZ
=r9KY
-----END PGP SIGNATURE-----

Re: [Usbpicprog-technical] Compiling under Ubuntu 9.04

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

Hi Frans,

Jasper Wallace ha scritto:
> compiling fails with loads of wx includes/references errors, i have 2.8 
> installed and that seems to be what configure.ac wants, but the web pages 
> says it need wx2.9 - is that really true?
I think we should update configure.ac to require wx2.9 since now wx2.9.0 has 
been officially released since some time...

Francesco




Index: configure.ac
===================================================================
--- configure.ac        (revisione 750)
+++ configure.ac        (copia locale)
@@ -70,7 +70,7 @@
  #
  # check for wxWidgets
  #
-WX_CONFIG_CHECK([2.8.0], [has_wxWin=1])
+WX_CONFIG_CHECK([2.9.0], [has_wxWin=1])
  if test "$has_wxWin" != 1; then
      AC_MSG_ERROR([
         wxWidgets must be installed on your system
@@ -79,7 +79,7 @@
         Please check that wx-config is in path, the directory
         where wxWidgets libraries are installed (returned by
        'wx-config --libs' command) is in LD_LIBRARY_PATH or
-       equivalent variable and wxWidgets version is 2.8.0 or above.
+       equivalent variable and wxWidgets version is 2.9.0 or above.
      ])
  fi




-- 

Re: [Usbpicprog-technical] Compiling under Ubuntu 9.04

[Jasper W. <ja...@po...>]

On Sat, 24 Oct 2009, Frans Schreuder wrote:

> Dear Jasper Wallace,
> 
> Thank you for reporting this. I have already installed ubuntu 9.10, 
> which has the new glibc version. (Ubuntu 9.10 is going to be released 
> next week). Ubuntu 9.10 is thus the system which I made the .deb package 
> for.
> If you want to build it yourself, you will have to install wx2.9 indeed. 
> (It should be able to compile with wx2.8.10, but it doesn't run very nicely)
> Thank you for reporting this issue, I will build a 9.04 version as well.

No problem!

I installed wx-2.9.0 from source and compiled usbpicprog with it and it runs
fine. I was able to upgrade the firmware on the upp and reflash a 16f84a,
however it looks like it's not able to write the data area/eeprom on a
16f88. I'll look into it some more and get back to the list about it.

-- 
[http://pointless.net/]                                   [0x2ECA0975]

Re: [Usbpicprog-technical] Compiling under Ubuntu 9.04

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

Dear Jasper Wallace,

Thank you for reporting this. I have already installed ubuntu 9.10, 
which has the new glibc version. (Ubuntu 9.10 is going to be released 
next week). Ubuntu 9.10 is thus the system which I made the .deb package 
for.
If you want to build it yourself, you will have to install wx2.9 indeed. 
(It should be able to compile with wx2.8.10, but it doesn't run very nicely)
Thank you for reporting this issue, I will build a 9.04 version as well.

Frans Schreuder

Jasper Wallace wrote:
> Hi,
>
> compiling fails with loads of wx includes/references errors, i have 2.8 
> installed and that seems to be what configure.ac wants, but the web pages 
> says it need wx2.9 - is that really true?
>
> If i install the .deb and run it i get:
>
> usbpicprog: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found 
> (required by usbpicprog)
>
> Does anyone have 0.3.0 running under ubuntu?
>
>   

[Usbpicprog-technical] Compiling under Ubuntu 9.04

[Jasper W. <ja...@po...>]

Hi,

compiling fails with loads of wx includes/references errors, i have 2.8 
installed and that seems to be what configure.ac wants, but the web pages 
says it need wx2.9 - is that really true?

If i install the .deb and run it i get:

usbpicprog: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found 
(required by usbpicprog)

Does anyone have 0.3.0 running under ubuntu?

-- 
[http://pointless.net/]                                   [0x2ECA0975]

[Usbpicprog-technical] [usbpicprog-technical] beta release 0.3.0

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

Hello everyone!

I think we are almost ready for a new release of usbpicprog: 0.3.0.
I have already put a 0.3.0-beta release in the download section.
(just waiting for the translation updates and maybe some bugfixes)

Frans

Re: [Usbpicprog-technical] USB configuration problem after PC software copilation

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

Hi David,

I compiled the software with devc++ (latest beta version) and wxWidgets 
2.9.0 RC4 / libusb 0.12
Maybe you should try to compile using that configuration...

Regards,

Frans

David Combet wrote:
> Hi, thanks for reply.
>
> My error actually have no relation with the graphical part, cause I get the same error when I compile the project without any change. I also know that usbpicprog can run without any graphic, and that is why I decide to work with.
> The only remaining explanation is that the error is link to the way I compile. I have tried with DEVC++ and Visual Studio 2008... same problem. 
>
> if you have any ideas... other way I shall inform you of any progress.
>
> best regards,
> David
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

Re: [Usbpicprog-technical] USB configuration problem after PC software copilation

[David C. <co...@ec...>]

Hi, thanks for reply.

My error actually have no relation with the graphical part, cause I get the same error when I compile the project without any change. I also know that usbpicprog can run without any graphic, and that is why I decide to work with.
The only remaining explanation is that the error is link to the way I compile. I have tried with DEVC++ and Visual Studio 2008... same problem. 

if you have any ideas... other way I shall inform you of any progress.

best regards,
David

Re: [Usbpicprog-technical] USB configuration problem after PC software copilation

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

Hi David Combet,

Sorry for my late reply (I was on a holiday for 2 weeks).
The error you are getting doesn't seem to have any relation with the 
graphical part you are trying to remove. Did you know by the way that 
usbpicprog (as it is) can also run in a command line mode without any 
graphics? just try usbpicprog --help for the parameters!

Does the windows program with the graphical interface work or does it 
give you the same error?

Regards,

Frans Schreuder

David Combet wrote:
> Hi,
>
> I'm a french ECE student. ECE is a school of Engineering in Paris. I'm working with PIC and I find usbpicprog programmer solution. The already compiled software works very well, but i don't need a graphic interface, so I want to remove everything which is link to WxWidg. 
> I started first to compile usbpicprog software from this package: usbpicprog-0.2.0 and then i remove uninteresting parts of the program. It works with linux, but doesn't work with windows. 
>
> With or without WxWidg I get the same error: "LIBUSB_DLL: error: usb_set_configuration: could not set config 1: win error: Paramètre incorrect."
> I'm fighting with this problem for 2 weeks and I can't manage to fix the problem. Don't you have any idea? 
>
> I'm working with Visual Studio 2008, windows XP.
>
> Best regards,
> David
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

[Usbpicprog-technical] USB configuration problem after PC software copilation

[David C. <co...@ec...>]

Hi,

I'm a french ECE student. ECE is a school of Engineering in Paris. I'm working with PIC and I find usbpicprog programmer solution. The already compiled software works very well, but i don't need a graphic interface, so I want to remove everything which is link to WxWidg. 
I started first to compile usbpicprog software from this package: usbpicprog-0.2.0 and then i remove uninteresting parts of the program. It works with linux, but doesn't work with windows. 

With or without WxWidg I get the same error: "LIBUSB_DLL: error: usb_set_configuration: could not set config 1: win error: Paramètre incorrect."
I'm fighting with this problem for 2 weeks and I can't manage to fix the problem. Don't you have any idea? 

I'm working with Visual Studio 2008, windows XP.

Best regards,
David

[Usbpicprog-technical] Usbpicprog translation update

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

Dear usbpicprog translators,

In the last months we have made a lot of progress with usbpicprog, and it
will soon be time to release the new version of the firmware, the software
and the new PCB.
Although I know that the software still has some issues (especially the
dsPIC devices which are still not working) I think the software is at least
more stable than the current (0.2.0) release.

Could you have a look at your language file to see if there are still some
strings that need to be updated?
Instructions on how to do it can be found at the following page:

http://usbpicprog.org/?page_id=158

Thanks and regards,

Frans Schreuder
usbpicprog.org

Re: [Usbpicprog-technical] Programming the PIC16F88

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

Hi Anton,

I will try to put some things in a log file. The xml files are just 
"stolen" from Piklab, maybe there is some information on their website, 
but I think the information is pretty obvious if you open it with a text 
editor.
BTW, I have never focused so much on blank check since it is not very 
essential for programming the device. there is also another way to do 
it, by reading some other registers from the PIC (verification words) 
but it is not working yet.

I think verify is much more important to get right!

Cheers,

Frans

ps. why don't you subscribe to the mailing lists 
(usb...@li...), that way other people can 
also read about your questions.
I also cc'd this message to the mailing list...

Anton Post wrote:
> Hi Frans
>
> I just build and installed snapshot 668. The dialogue now stays up during
> programming thanks (and because of that you can't click a second time on the
> programming, so it doesn't crash).
>
> 09:52:25: Erasing before programming...
> 09:52:25: Erase OK
> 09:52:25: Programming the code area of the PIC...
> 09:52:42: Write Code memory OK
> 09:52:42: Programming the data area of the PIC...
> 09:52:42: Write Data memory OK
> 09:52:42: Programming configuration area of the PIC...
> 09:52:43: Write Config memory OK
> 09:52:43: Verifying all areas of the PIC...
> 09:53:00: Verify code failed at 0x0. Read: 0xFF, Expected: 0x8A
> 09:53:00: Operations completed with errors/warnings
>
> But really I am of course interested more in the actual programming side - can
> we include some more logging or diagnostics so we can find out what is not
> happening, or at what stage the wrong memory addresses (i.e. 0x2035) are being read?
>
> I just got:
> 09:59:25: Checking if the device is blank...
> 09:59:42: Blankcheck failed at 0x3C03. Read: 0xA5, Expected: 0xFF
> 09:59:42: Device is not blank.
> 09:59:42: All operations completed
>
> Is there documentation on the xml file format for the PIC definition? (Although
> I cannot see anything with that memory address range...)
>
> Thanks, 
> Anton
>
> ------------------------
>
> Hi Frans
>
> Thank you for that. How are things on the actual PIC programming side, though?
> Is it possible to put some more diagnostic code in or give me a release that
> writes critical steps to a log file, so I can help you localise why the code is
> not writing down?
>
> Thanks,
> Anton
>
> -----------------------------------------------------
>
>  Hi Anton,
>
> The bug with the window has been fixed in the svn repository. I will make a
> snapshot soon.
>
> I am working hard to fix all the bugs (that's why I didn't release it yet, don't
> expect a stable release yet from the snapshots).
>
> It's good to keep telling me if you experience any new problems with usbpicprog,
> it only helps to improve the software!
>
> Regards,
>
> Frans
>
> Anton Post wrote:
>   
>>> Hi Frans
>>>
>>> Thanks for all your help. I will try to clarify what happens for me:
>>>
>>> - I opened up usbpicprog
>>> 11:12:42: Detected PIC model 16F88 with device ID 0x765
>>> 11:12:42: usbpicprog 552 Connected
>>>
>>> - I open the hex file
>>> - I hit the "Program" button (in the preferences everything is selected - Erase,
>>> program code, data and config, verify)
>>> - The programming dialog comes up and straight away disappears. It doesn't seem
>>> to just lose focus, because it's not behind the window or anywhere to be seen if
>>> I minimise the other window or whatever.
>>> - At this stage I usually just clicked it again, at which point the program
>>>       
> crashes.
>   
>>> - But what I did just now (after reading your email) is leave it for a couple of
>>> minutes, and you are correct - a message comes up saying "All operations
>>>       
> completed".
>   
>>> 11:09:53: Erasing before programming...
>>> 11:09:53: Erase OK
>>> 11:09:53: Programming the code area of the PIC...
>>> 11:10:10: Write Code memory OK
>>> 11:10:10: Programming the data area of the PIC...
>>> 11:10:10: Write Data memory OK
>>> 11:10:10: Programming configuration area of the PIC...
>>> 11:10:11: Write Config memory OK
>>> 11:10:11: Verifying all areas of the PIC...
>>> 11:10:28: Verify successful
>>> 11:10:28: All operations completed
>>>
>>> The thing that I find strange about that bug is that if you don't have "Erase
>>> before programming" selected, the dialog does not disappear, but it updates as
>>> it goes through all the operations as expected. (Is it possible that the erase
>>> code brings up another popup with the same ID/name, and then straight away
>>> closes it in this situation?)
>>>
>>> The main difficulty overall for me, though, is that the PIC is not getting
>>> written to properly - when I do a read, or a verify after programming I get all
>>> the problems I mentioned in the last email (usually blank). It is my feeling
>>> (it's been hard to know for sure) that the "reading" code somehow interacts with
>>> the hex file that has just been written - the reason I say that is that usually
>>> if I do a read straight after a write, it may come up with some (usually
>>> corrupt) data. But if I re-start usbpicprog, and do a read, it always (?) comes
>>> up blank. Strangely, if I re-start usbpicprog, and open the hex file, and then
>>> do a read, it still comes up blank, so it must be something to do with writing
>>> the code, perhaps a bug in the firmware even?
>>>
>>> In any case, the program is not running in the PIC (it is a tested program that
>>> I trust) so I don't think it's all getting down.
>>>
>>> You ask about the blankcheck - the following is the output I get (sometimes a
>>> little different, but 0x2008, 0x30 is common):
>>> 11:22:34: Checking if the device is blank...
>>> 11:22:51: Blankcheck failed at 0x2008. Read: 0x30, Expected: 0xFF
>>> 11:22:51: Device is not blank.
>>> 11:22:51: All operations completed
>>>
>>> I am not sure how to tell if that is during the code, config or data section, as
>>> the dialog just says "Checking if device is blank".
>>>
>>> I mentioned it last time, but I repeat an odd finding - if I do an Erase on the
>>> device, then the answer does come back blank:
>>> 11:25:26: Checking if the device is blank...
>>> 11:25:44: Device is blank
>>> 11:25:44: All operations completed
>>>
>>> I hope these diagnostics are some help to you.
>>>
>>> Looking forward to a new version.  ;-) 
>>> Thanks again,
>>> Anton
>>>
>>> ----------------------------
>>>
>>> Dear Anton,
>>>
>>> I thought I already replied to your questions before, but I must have
>>>       
> forgotten it.
>   
>>> The problems you are having are not at all related to your hardware, the problem
>>> is that the current snapshot is not very stable...  :( 
>>> I am putting much effort in locating the problem, but it is software and the
>>> same behavior is true for most 16F devices.
>>>
>>> I will think about some firmware version checking.
>>>
>>> What you say about the complete program cycle (erase, write all, verify all),
>>> might it be that it is working but that the progress dialog loses focus?
>>> What if you wait for a while until it says "all operations completed" or
>>> something similar? I think that might be the problem...
>>>
>>> About the blankcheck, that is also another bug... it just shouldn't read beyond
>>> 0x2007. Could you tell me whether it occurs at checking the code or config
>>>       
> memory?
>   
>>> Regards,
>>>
>>> Frans
>>>
>>> Anton Post wrote:
>>>   
>>>       
>>>>> Hi Frans
>>>>>
>>>>> Sorry to keep disturbing you, as I'm sure you're very busy. I was just
>>>>>           
> wondering
>   
>>>>> whether you'd had a chance to look at my query below?
>>>>>
>>>>> I really did spend a bit of time trying quite a lot of diagnostics, but
>>>>>           
> was not
>   
>>>>> able to localise the problem beyond that - however, if you have some time I'm
>>>>> very keen on being able to progress further with my project.
>>>>>
>>>>> Thanks again,
>>>>> Anton
>>>>>
>>>>> --------------------------------------------------
>>>>>
>>>>> Hi Frans
>>>>>
>>>>> Thanks for the tip on using the snapshot copy of the firmware - I now have it
>>>>>     
>>>>>           
>>> saying "usbpicprog 552 connected", which I believe is the latest (and 0.2.1 for
>>> the software, although that may be generic (built today off 620 (I believe
>>> different from the upp_wx version I had before)). Might I request as a
>>> relatively simple future enhancement for the PC software to test the firmware
>>> version for compatibility - I think it will save a bit of headache for the
>>>       
> users.
>   
>>>   
>>>       
>>>>> Running a complete program cycle (erase, write all, verify all) fails straight
>>>>>     
>>>>>           
>>> away, and clicking it again crashed the program. (This is probably what you
>>> mentioned before?)
>>>   
>>>       
>>>>> However just doing a program (code+data+config) with no erase or verify seems
>>>>>     
>>>>>           
>>> to work fine, i.e. the bar goes across for about 20 seconds.
>>>   
>>>       
>>>>> Unfortunately then I get some odd behaviour:
>>>>> Usually I restart usbpicprog before doing a read, and usually the program
>>>>>     
>>>>>           
>>> appears to be blank. A blankcheck sometimes succeeds, sometimes fails:
>>>   
>>>       
>>>>> 12:44:50: Checking if the device is blank...
>>>>> 12:45:08: Blankcheck failed at 0x2008. Read: 0x30, Expected: 0xFF
>>>>> 12:45:08: Device is not blank.
>>>>>
>>>>> or 13:05:36: Blankcheck failed at 0x2035. Read: 0x1C, Expected: 0xFF
>>>>> or 13:06:55: Blankcheck failed at 0x21C7. Read: 0x00, Expected: 0xFF
>>>>>
>>>>> Note that even though those memory addresses seem to be invalid for a 16F84, a
>>>>>     
>>>>>           
>>> blank check does succeed following an erase, so something gets changed then -
>>> this seems to work reliably whether I restart the program in between or not:
>>>   
>>>       
>>>>> 12:47:58: Checking if the device is blank...
>>>>> 12:48:16: Device is blank
>>>>>
>>>>> Occasionally, (but usually/always?) when I haven't restarted usbpicprog,
>>>>>     
>>>>>           
>>> values are read from the area that was programmed, but they are usually corrupt
>>> (see examples below). The odd thing is that once I restart usbpicprog and do
>>> another read, it tends to come up "blank", as described above.
>>>   
>>>       
>>>>> As it is not very reliable is there something I should be checking on my
>>>>>     
>>>>>           
>>> circuit? Should I be adding some capacitors somewhere? My programming cable is
>>> perhaps 30cm long. I have visually inspected my circuit for shorts or bad
>>> connections, and have done the same with the programmer. MCLR is 11.95v. As some
>>> things work (for example autodetecting the PIC16F88) I assume that there can't
>>> be too much wrong with the physical communications.
>>>   
>>>       
>>>>> Desired program:
>>>>> 000000: 8A 15 0A 16 00 2F 04 28 83 12 03 13 85 01 83 16 85 01 83 12 86 01 83
>>>>>     
>>>>>           
>>> 16 000018: 86 01 98 16 83 12 FF 30 85 00 86 00 A0 01 05 30 20 02 03 18 25 28 A1
>>> 01 000030: 21 0A 03 19 23 28 A2 01 22 0A 03 19 21 28 A2 0A 1C 28 A1 0A 18 28 A0
>>> 0A 000048: 13 28 85 01 86 01 A0 01 05 30 20 02 03 18 3A 28 A1 01 21 0A 03 19 38
>>> 28 000060: A2 01 22 0A 03 19 36 28 A2 0A 31 28 A1 0A 2D 28 A0 0A 28 28 4F 30 8A
>>> 15 000078: F1 27 6B 30 F1 27 8A 11 0F 28 41 28 8A 15 00 27 8A 11 63 00 04 28 FF
>>> 3F 000090: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F
>>>       
> FF 3F
>   
>>>   
>>>       
>>>>> Read back:
>>>>> 000000: FF 3F FF 3F FF 3F 04 28 8A 15 0A 16 00 2F 83 16 83 12 03 13 85 01 83
>>>>>     
>>>>>           
>>> 16 000018: 85 01 83 12 86 01 FF 30 86 01 98 16 83 12 05 30 85 00 86 00 A0 01 A1
>>> 01 000030: 20 02 03 18 25 28 A2 01 21 0A 03 19 23 28 A2 0A 22 0A 03 19 21 28 A0
>>> 0A 000048: 1C 28 A1 0A 18 28 A0 01 13 28 85 01 86 01 3A 28 05 30 20 02 03 18 38
>>> 28 000060: A1 01 21 0A 03 19 36 28 A2 01 22 0A 03 19 2D 28 A2 0A 31 28 A1 0A 8A
>>> 15 000078: A0 0A 28 28 4F 30 8A 11 F1 27 6B 30 F1 27 00 27 0F 28 41 28 8A 15 FF
>>> 3F 000090: 8A 11 63 00 04 28 FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F
>>>       
> FF 3F
>   
>>>   
>>>       
>>>>> Another try:
>>>>> 000000: 8C 1E 26 08 99 00 08 00 00 00 F7 2F 1A 08 08 00 00 00 00 00 00 00 00
>>>>>     
>>>>>           
>>> 00 000018: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF
>>> 3F 000030: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F A1 01 20 02 03 18 25
>>> 28 000048: A2 01 21 0A 03 19 23 28 A2 0A 22 0A 03 19 21 28 A0 0A 1C 28 A1 0A 18
>>> 28 000060: A0 01 13 28 85 01 86 01 3A 28 05 30 20 02 03 18 38 28 A1 01 21 0A 03
>>> 19 000078: 36 28 A2 01 22 0A 03 19 2D 28 A2 0A 31 28 A1 0A 8A 15 A0 0A 28 28 4F
>>> 30 000090: 8A 11 F1 27 6B 30 F1 27 00 27 0F 28 41 28 8A 15 FF 3F 8A 11 63 00
>>>       
> 04 28
>   
>>>   
>>>       
>>>>> Another try:
>>>>> 000000: 88 14 02 00 00 00 00 00 00 00 03 03 00 00 00 00 00 00 00 00 00 00 00
>>>>>     
>>>>>           
>>> 00 000018: 86 01 98 16 83 12 FF 30 85 00 86 00 A0 01 05 30 20 02 03 18 25 28 A1
>>> 01 000030: 21 0A 03 19 23 28 A2 01 22 0A 03 19 21 28 A2 0A 00 00 20 02 00 08 20
>>> 08 000048: 02 00 01 00 02 01 20 00 00 00 20 02 03 18 20 28 A0 00 00 08 01 08 18
>>> 28 000060: A0 01 02 08 01 01 06 00 22 08 01 20 20 02 01 08 20 08 20 00 01 00 02
>>> 11 000078: 30 20 22 00 20 02 02 11 0D 28 00 08 00 00 00 02 8A 11 20 00 00 28 4F
>>> 30 000090: 8A 11 F1 27 6B 30 F1 27 00 27 0F 28 41 28 8A 15 FF 3F 8A 11 63 00
>>>       
> 04 28
>   
>>>   
>>>       
>>>>> Occasionally read back correctly:
>>>>> 000000: 8A 15 0A 16 00 2F 04 28 83 12 03 13 85 01 83 16 85 01 83 12 86 01 83
>>>>>     
>>>>>           
>>> 16 000018: 86 01 98 16 83 12 FF 30 85 00 86 00 A0 01 05 30 20 02 03 18 25 28 A1
>>> 01 000030: 21 0A 03 19 23 28 A2 01 22 0A 03 19 21 28 A2 0A 1C 28 A1 0A 18 28 A0
>>> 0A 000048: 13 28 85 01 86 01 A0 01 05 30 20 02 03 18 3A 28 A1 01 21 0A 03 19 38
>>> 28 000060: A2 01 22 0A 03 19 36 28 A2 0A 31 28 A1 0A 2D 28 A0 0A 28 28 4F 30 8A
>>> 15 000078: F1 27 6B 30 F1 27 8A 11 0F 28 41 28 8A 15 00 27 8A 11 63 00 04 28 FF
>>> 3F 000090: FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F FF 3F
>>>       
> FF 3F
>   
>>>   
>>>       
>>>>> One focus of all my diagnostics has been to try to figure out whether it's the
>>>>>     
>>>>>           
>>> reading or the writing that is unreliable - I haven't been able to figure that
>>> out, sorry. The other question I had (which is why I list three failed writes
>>> above) is whether there's a pattern, i.e. the programming is too fast for the
>>> flash to write completely - Looking bitwise at the above examples it does not
>>> appear to me to be the case. And the fact that restarting usbpicprog almost
>>> always changes the behaviour means I think that this is not where we should be
>>> looking.
>>>   
>>>       
>>>>> The main issue holding me up (apart from the unreliability) is that even when
>>>>>     
>>>>>           
>>> the program does get down correctly, I have never seen the configuration take
>>> hold - as I'm trying to run off an internal oscillator and it's set for an
>>> external one, the PIC just sits there.
>>>   
>>>       
>>>>> Thanks again,
>>>>> Anton
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>>
>>>>> Dear Anton Post,
>>>>>
>>>>> Did you load the latest (snapshot) firmware in the usbpicprog programmer?
>>>>>     
>>>>>           
>>> (Does it say usbpicprog 0.2.0 connected or does it tell you usbpicprog 6xx
>>> connected?)
>>>   
>>>       
>>>>> The stable (0.2.0) firmware does not yet support the 16F88
>>>>> The 0x200A readout should not occur though, I will check that one out!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Frans Schreuder
>>>>>
>>>>>
>>>>>   
>>>>>     
>>>>>           
>>>   
>>>       
>
>
>
>   

Re: [Usbpicprog-technical] My proposition for schematic , and Hello

[Piotr S. (S. <sq...@wp...>]

On Wednesday 13 of May 2009 10:38:51 Frans Schreuder wrote:
>  Dear Piotr,
>
>  Your version with switching regulators looks very nice, but the problem is
> that it is incompatible with the old hardware so I will need to write 2
> versions of the software.

If this is a problem we always can do branch , or fork.
I can do this for mostly backward compatybilyty but PWM must be free.

> I have also designed a new version of the
> hardware (0.3) please check out the svn. It doesn't have the switching
> regulators, but it does support lower voltages. 

I check this too and try do compatybile connections.

> What do you mean with
> "calibrating internal RC"?

We have osc-out with 1/4 interenal RC and we can calibrate internal oscilator 
of procesor.

>
>  Cheers,
>
>  Frans

Very THX for opinions . I become more work :D

PS Sorry for my ugly english.

Re: [Usbpicprog-technical] My proposition for schematic , and Hello

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

<!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">
Dear Piotr,<br>
<br>
Your version with switching regulators looks very nice, but the problem
is that it is incompatible with the old hardware so I will need to
write 2 versions of the software. I have also designed a new version of
the hardware (0.3) please check out the svn. It doesn't have the
switching regulators, but it does support lower voltages.<br>
What do you mean with "calibrating internal RC"?<br>
<br>
Cheers,<br>
<br>
Frans<br>
<br>
<br>
<br>
<br>
<br>
Piotr Sk&oacute;lski (SQLek) <a class="moz-txt-link-rfc2396E" href="mailto:sq...@wp...">&lt;sq...@wp...&gt;</a> wrote:
<blockquote cite="mid:200...@wp..." type="cite">
  <pre wrap="">Hello.
I want help you.
I do some changes that add some posible fatures:
- VPP regulated.
- VDD regulated.
- Power check (we can know what V is in programed board and chesk self 
valtages)
- Calibrating internal rc.
I don't route all connections because this can be made for pcb or elements 
optimise.
I want know your opinions.

Piotr Sk&oacute;slki (SQLek) <a class="moz-txt-link-rfc2396E" href="mailto:sq...@wp...">&lt;sq...@wp...&gt;</a>
  </pre>
  <br>
  <hr size="4" width="90%"><br>
  <center><img src="cid:par...@gm..."></center>
  <pre wrap="">
<hr size="4" width="90%">
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/kodak-com">http://p.sf.net/sfu/kodak-com</a></pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Usbpicprog-technical mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Usb...@li...">Usb...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical">https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical</a>
  </pre>
</blockquote>
</body>
</html>

Re: [Usbpicprog-technical] new PCB and current software status

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Francesco,<br>
<blockquote cite="mid:4A0...@ya..." type="cite">
  <blockquote type="cite">
    <pre wrap="">I will check the latest software tomorrow!
    </pre>
  </blockquote>
  <pre wrap=""><!---->Good!
Note that I've marked with FIXME a couple of points in the source code; in 
particular in hardware.cpp line 712 I suspect there could be a bug...

  </pre>
</blockquote>
The latest software doesn't seem to program anything anymore in the pic
(tested 18F2550 and 16F870), I didn't change the firmware.<br>
I will have a look at the changes in the hardware you made...<br>
<br>
Cheers,<br>
<br>
Frans<br>
</body>
</html>

Re: [Usbpicprog-technical] new PCB and current software status

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

Hi,

Frans Schreuder ha scritto:
> I have just married, so in the last couple of weeks I had some other 
> things to do :)
;) great, congratulations then!


> I have already changed the circuitry of the voltage pump, but I am 
> afraid that a voltage divider would unnecessarily take current from the 
> voltage pump.
that's true, indeed... maybe we could then have a "test pump mode" command in 
the firmware that makes the pump active so that one can test the UPP pump with 
its voltmeter without troubles of having to connect a PIC to it, issue a long 
programming command, etc etc.
The GUI would be a simple menu item under "Actions" named "Test charge pump" or 
something like that, whose effect would be to popup a modal dialog "Test the 
voltage on PIN 5 of the ICSP header; it should be 12V+/-xx%; click Cancel when 
done".

> By the way, I have not released the 0.3 yet, because it 
> needs some additional changes in the values of some resistors and some 
> last checkups.
ok! I'll wait then!

> I will check the latest software tomorrow!
Good!
Note that I've marked with FIXME a couple of points in the source code; in 
particular in hardware.cpp line 712 I suspect there could be a bug...

Bye,
Francesco


-- 

[Usbpicprog-technical] My proposition for schematic , and Hello

[Piotr S. (S. <sq...@wp...>]

Hello.
I want help you.
I do some changes that add some posible fatures:
- VPP regulated.
- VDD regulated.
- Power check (we can know what V is in programed board and chesk self 
valtages)
- Calibrating internal rc.
I don't route all connections because this can be made for pcb or elements 
optimise.
I want know your opinions.

Piotr Skóslki (SQLek) <sq...@wp...>

Re: [Usbpicprog-technical] new PCB and current software status

[Ravi <chi...@vs...>]

Hi Frans

> I have already changed the circuitry of the voltage pump, but I am 
> afraid that a voltage divider would unnecessarily take current from the 
> voltage pump. By the way, I have not released the 0.3 yet, because it 
> needs some additional changes in the values of some resistors and some 
> last checkups.

If we have a 1 mA bleeder current, then 12K and 1.5K will provide 1.5V 
to the ADC.

VCC	13.5
R1	12
R2	1.5
V1	(VCC*R2)/(R1+R2) = 1.5V

If we have a 0.1 mA bleeder current, then 120K and 15K will provide 1.5V 
to the ADC.

VCC	13.5
R1	120
R2	15
V1	(VCC*R2)/(R1+R2) = 1.5V

Cheers

Ravi

Re: [Usbpicprog-technical] new PCB and current software status

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

Hi Francesco,

I have just married, so in the last couple of weeks I had some other 
things to do :)
I have already changed the circuitry of the voltage pump, but I am 
afraid that a voltage divider would unnecessarily take current from the 
voltage pump. By the way, I have not released the 0.3 yet, because it 
needs some additional changes in the values of some resistors and some 
last checkups.

I will check the latest software tomorrow!

Cheers,

Frans

Francesco Montorsi wrote:
> Hi Frans,
>     I've noticed that you have committed a new version of the PCB (rev 0.3); it 
> seems the new schematic will allow to support also lower-voltage PICs; I'll try 
> to test it asap (if you say it's ready to be "beta-tested").
>
> May I suggest a new feature? When building UPP for the first time I found out 
> that most of the times the UPP failures were due to the pump not reaching 12V 
> for some reason. I see that pin #12 (AN11) of the PIC18F2550 used in the 
> programmer is not connected to anything.
> Connecting it to VPP (through a voltage divider) would allow the firmware to 
> self-test the charge-pump using its internal ADC.
>
> I understand that this would further complicate the routing but if it turns out 
> that this is not a big problem, then I think the two additional resistors are 
> worth it :)
>
> -----
>
> Other question: does current software/firmware works for you?
> I have revised almost all code of upp_wx, in particular the Hardware class, with 
> the aim of reducing redundancy and add more safety checks... this helped me to 
> better understand the internals of UPP but I still cannot currently 
> program&verify any of the following devices I have tested:
> - 16F84A
> - 18F2550
> - 18F4450
> I don't know if the problem lies
> a) in my UPP HW
> b) in the cable a little bit too long I'm using to connect UPP with PICs under 
> tests (unfortunately I cannot easily cut it)
> c) in the read or program operations of the firmware
>
> OTOH if I do a "program without verify" cycle UPP says everything was programmed 
> fine (except for the 16F84A which says "verify error during programming"); I'll 
> soon test if this is the case (putting the PIC in the real circuit where it 
> needs to go).
>
> I'm using firmware rev 547....
>
> I don't think the problem is the software since in my cases it fails just 
> because of the (error) codes returned by the firmware but just to be sure: does 
> current software works for you?
>
>
> Bye,
> Francesco
>
>
>   

[Usbpicprog-technical] new PCB and current software status

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

Hi Frans,
    I've noticed that you have committed a new version of the PCB (rev 0.3); it 
seems the new schematic will allow to support also lower-voltage PICs; I'll try 
to test it asap (if you say it's ready to be "beta-tested").

May I suggest a new feature? When building UPP for the first time I found out 
that most of the times the UPP failures were due to the pump not reaching 12V 
for some reason. I see that pin #12 (AN11) of the PIC18F2550 used in the 
programmer is not connected to anything.
Connecting it to VPP (through a voltage divider) would allow the firmware to 
self-test the charge-pump using its internal ADC.

I understand that this would further complicate the routing but if it turns out 
that this is not a big problem, then I think the two additional resistors are 
worth it :)

-----

Other question: does current software/firmware works for you?
I have revised almost all code of upp_wx, in particular the Hardware class, with 
the aim of reducing redundancy and add more safety checks... this helped me to 
better understand the internals of UPP but I still cannot currently 
program&verify any of the following devices I have tested:
- 16F84A
- 18F2550
- 18F4450
I don't know if the problem lies
a) in my UPP HW
b) in the cable a little bit too long I'm using to connect UPP with PICs under 
tests (unfortunately I cannot easily cut it)
c) in the read or program operations of the firmware

OTOH if I do a "program without verify" cycle UPP says everything was programmed 
fine (except for the 16F84A which says "verify error during programming"); I'll 
soon test if this is the case (putting the PIC in the real circuit where it 
needs to go).

I'm using firmware rev 547....

I don't think the problem is the software since in my cases it fails just 
because of the (error) codes returned by the firmware but just to be sure: does 
current software works for you?


Bye,
Francesco


-- 

[Usbpicprog-technical] VPP for PIC16F84

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

Dear Butch,

Can you tell me anything more about what sort of message you got from 
the software?
Does it sometimes work or did you never succeed with the 84A?

Cheers,

Frans

Butch Pastor wrote:
> Name: Butch Pastor
>
> Email: but...@ya...
>
> Subject: VPP for PIC16F84
>
> Message: Dear Frans,
>
> I am already in the stage where the PIC16F84A was detected when I
> launched the programming software. However, It failed to load the HEX
> files during programming. Likewise, the previously existing code in
> the PIC16F84A was erased.
>
> What could possibly be the cause?
>
> Hope to hear from u soon.
>
> Regards
>
> Butch
>
> IP: 125.212.8.7
> HOST: 125.212.8.7
>
>
>   

[Usbpicprog-technical] [wxGTK] tooltips for the new package-view buttons

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

Hi,
    I've just added in SVN repo some buttons to allow the user to zoom 
in/out/fit the package drawing.

Unfortunately because of this wxWidgets bug:
http://trac.wxwidgets.org/ticket/9859
(which I recently fixed in wx SVN trunk), no tooltips are available on these 
buttons even when explicitely set.

I'm using the attached patch to make the tooltip appear... I don't know however 
if it's ok to commit it, given that the changes I made to wx to fix bug #9859 
linked above won't be present in wx2.9.0 (which is to be released very soon).

Another nice thing of the patch is that it makes the wxStatusBar show tips for 
those panes whose contents were ellipsized/truncated. This is a new feature 
which won't be available in wx2.9.0, too...

Francesco


-- 

[Usbpicprog-technical] 16c745

[Mazzoli <ma...@bg...>]

Can i program pic 16c745 ??

or any pic xxcxxx  devices, as 12C508 ??




Michele

Re: [Usbpicprog-technical] pic16c745

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

Hi Michele,

Those devices are on my todo list, but not yet implemented.
You can try though by selecting the most lookalike 16f device instead

Cheers,

Frans

xzero2-email wrote:
> Can i program pic 16c745 ??
>
> or any pic xxcxxx  devices, as 12C508 ??
>
>
>
>
> Michele
>
>  
>  
>  --
>  Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
>  
>  Sponsor:
>  Ricevi e invia messaggi di posta, instant messaging e rimani in contatto ovunque ti trovi direttamente dal cellulare, con m.email. Provalo gratuitamente
>  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8920&d=14-4
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

[Usbpicprog-technical] pic16c745

[xzero2-email <xz...@em...>]

Can i program pic 16c745 ??

or any pic xxcxxx  devices, as 12C508 ??




Michele

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Ricevi e invia messaggi di posta, instant messaging e rimani in contatto ovunque ti trovi direttamente dal cellulare, con m.email. Provalo gratuitamente
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8920&d=14-4