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: Francesco M. <f18...@ya...> - 2008-11-20 20:53:47
|
Hi, using the upp_wx program I've thought to the following changes/improvements... let me know what you think of them. 1) the toolbar currently uses two radio boxes to inform the user about what hardware has been detected. This is a misuse of the checkbox widget; in fact in upp_wx they aren't used for user input just as "read-only" displays, isn't it? I think it would be better to create a wxControl-derived custom control, which simply draws: DETECTED HARDWARE: UPP v. 1.1 or DETECTED HARDWARE: UPP BOOTLOADER v. 1.1 it would be much more user-friendly, I believe. 2) the toolbar uses a wxComboBox. However there's no reason for the user to type inside it; why not use a wxChoice instead? 3) the main window currently displays 3 big grids. I'd suggest using instead a wxNotebook with 3 tabs: code, config, data. In this way it would be easier for the user to locate what he wants to view. Also, in future the "config" tab could contain a more complex UI layout to show the various config flag names, etc etc. Other possible notebook tabs to add are those displayed by piklab when selecting a specific device: - Device information: basic features of the selected PIC + link to microchip.com - Memory Map - Voltage-frequency Graphs - Pin diagrams, possibly with the PGD, PGC, Vdd, MCLR, GND pins highlighted. 4) currently when issuing a command which provokes a read/write operation on the USB, the program "hangs"; the UI doesn't redraw and the program does not respond to user. This is because those operations should be done in a secondary thread... this shouldn't be difficult to do; a simple wxThread should be enough. I'm ready to help with any of these tasks... Bye, Francesco -- |
From: Francesco M. <f18...@ya...> - 2008-11-20 17:35:54
|
Hi, Frans Schreuder ha scritto: > Hi >> I've seen that Piklab has in "piklab/src/devices/pic/xml_data" all >> datas available for lots of PICs; the XML files there should contain >> all required info for implementing those masks... since they release >> Piklab under GPL I think it would be ok to reuse those files. > I have looked at these files before, but I think it's more work to > actually make the scripts and everything to convert them to usbpicprog > source than to do it myself. > I have already implemented the masks in the latest SVN revision now! Great! However the Piklab .xml files contains lot of useful informations and setting up routines which read those .xml files is a matter of few minutes using the built-in wxWidgets XML classes (which by chance were partly written by me :))... Also, I like more the Piklab approach because separing data from sources allows you to quickly add new devices info. Possibly a database could have been an even better choice, but XML is good, too. Re-using Piklab XML would allow UPP to display lots of more info about the selected devices and give readable names for e.g. config registers, etc, so I think it would be a Good Thing to reuse them. >> Btw, I read on the website about the old piklab plugin; is the new one >> being developed? > The old plugin was the first attempt for usbpicprog, but I moved to a > stand alone program for some reasons: > > * it's cross platform > * the plugin was too slow (it was some kind of bitbanging algorithm > on the PC side) > * I was unable to track the fast changes of piklab in order to stay > compatible with the latest version > > the usbpicprog software does now also have a command line interface > which makes it possible to use it from within any IDE. > I think it would be a good idea (and the easiest) to write a general > piklab plugin that can run a command line programmer, maybe with default > options for usbpicprog. that's probably the best thing, sure. >> I'm ready to give an hand with patches/implementation work :) >> > Thanks! maybe you can can give a hand with the piklab command-line plugin? Sure; however before working on such plugin I'd prefer to give some help with the main app (see my other mail). >>> You can disable the verify function for config memory in the >>> preferences panel! >> I'll do so in the meanwhile, then. > If you checkout the latest SVN revision, you can enable it again :P I've tested the new version and indeed it says "verify successful"! Thanks. Bye, Francesco -- |
From: Frans S. <fra...@gm...> - 2008-11-18 08:52:29
|
Hi > I've seen that Piklab has in "piklab/src/devices/pic/xml_data" all > datas available for lots of PICs; the XML files there should contain > all required info for implementing those masks... since they release > Piklab under GPL I think it would be ok to reuse those files. I have looked at these files before, but I think it's more work to actually make the scripts and everything to convert them to usbpicprog source than to do it myself. I have already implemented the masks in the latest SVN revision now! > > Btw, I read on the website about the old piklab plugin; is the new one > being developed? The old plugin was the first attempt for usbpicprog, but I moved to a stand alone program for some reasons: * it's cross platform * the plugin was too slow (it was some kind of bitbanging algorithm on the PC side) * I was unable to track the fast changes of piklab in order to stay compatible with the latest version the usbpicprog software does now also have a command line interface which makes it possible to use it from within any IDE. I think it would be a good idea (and the easiest) to write a general piklab plugin that can run a command line programmer, maybe with default options for usbpicprog. > > I'm ready to give an hand with patches/implementation work :) > Thanks! maybe you can can give a hand with the piklab command-line plugin? >> You can disable the verify function for config memory in the >> preferences panel! > I'll do so in the meanwhile, then. If you checkout the latest SVN revision, you can enable it again :P Cheers, Frans |
From: Frans S. <fra...@gm...> - 2008-11-17 15:27:51
|
Hi, > > > I've made some shots of my circuit and tarred them at: > http://frm.users.sourceforge.net/upp_th_photos.tar.bz2 I've put it on the site under hardware! Thanks > > Disclaimer: > - the PCB is not professional, no silk, etc > - unfortunately I couldn't manage to make some of the close-up photos > sharp... my digital camera seems unable to focus near objects :/ > - the only PMOS I could find was SMD so that I soldered it with the > help of small wire on the top side :/ > > I hope there is at least an usable photo... > > Bye, > Francesco > > > PS: I suggest setting the default "reply-to" of this mailing list to > the mailing list itself, instead of the sender > So I did... |
From: Francesco M. <f18...@ya...> - 2008-11-17 13:11:32
|
Hi, Frans Schreuder ha scritto: > Hi, >> I have programmed my other two PIC18F2550 with the UPP bootloader. UPP (v.1.1) autodetected them correctly and when I clicked Actions->Program the programming seems successful. >> However if I click Actions->Verify for both those PICs I get "Verify config failed at 0x300004. Read 0x00. Expected 0xFF". >> If I understand it correctly, the bits are relative to the watchdog timer (WDTPS2-WDTPS0 e WDTEN). >> > There's nothing wrong with your usbpicprog, it's just normal that it can't verify this locations since it is not implemented in the pic and always reads as 0x00. ah, good! > I should still add some kind of mask in the software for which configuration bits to verify and which not. But since it differs for every PIC it is a lot of work to do that, so it will probably take a while. I've seen that Piklab has in "piklab/src/devices/pic/xml_data" all datas available for lots of PICs; the XML files there should contain all required info for implementing those masks... since they release Piklab under GPL I think it would be ok to reuse those files. Btw, I read on the website about the old piklab plugin; is the new one being developed? I'm ready to give an hand with patches/implementation work :) > You can disable the verify function for config memory in the preferences panel! I'll do so in the meanwhile, then. Bye, Francesco -- |
From: Francesco M. <f18...@ya...> - 2008-11-17 13:08:51
|
Hi, Frans Schreuder ha scritto: > Could you also take some pictures of your through hole version of usbpicprog? > (maybe in action programming something) > It would be nice to put it on the site! sure! I've made some shots of my circuit and tarred them at: http://frm.users.sourceforge.net/upp_th_photos.tar.bz2 Disclaimer: - the PCB is not professional, no silk, etc - unfortunately I couldn't manage to make some of the close-up photos sharp... my digital camera seems unable to focus near objects :/ - the only PMOS I could find was SMD so that I soldered it with the help of small wire on the top side :/ I hope there is at least an usable photo... Bye, Francesco PS: I suggest setting the default "reply-to" of this mailing list to the mailing list itself, instead of the sender -- -- |
From: Frans S. <fra...@gm...> - 2008-11-15 16:16:11
|
Hi Francesco, Could you also take some pictures of your through hole version of usbpicprog? (maybe in action programming something) It would be nice to put it on the site! Cheers, Frans |
From: Frans S. <fra...@gm...> - 2008-11-15 16:10:07
|
Hi, > > I have programmed my other two PIC18F2550 with the UPP bootloader. UPP > (v.1.1) autodetected them correctly and when I clicked > Actions->Program the programming seems successful. > However if I click Actions->Verify for both those PICs I get "Verify > config failed at 0x300004. Read 0x00. Expected 0xFF". > If I understand it correctly, the bits are relative to the watchdog > timer (WDTPS2-WDTPS0 e WDTEN). > There's nothing wrong with your usbpicprog, it's just normal that it can't verify this locations since it is not implemented in the pic and always reads as 0x00. I should still add some kind of mask in the software for which configuration bits to verify and which not. But since it differs for every PIC it is a lot of work to do that, so it will probably take a while. You can disable the verify function for config memory in the preferences panel! > I wonder if this is because the PICs were damaged by my previous > experiments :) or rather because of something related to > code-protection flags... Nothing is broken really! > Thanks!! > Francesco > > Thank you for reporting! Frans |
From: Frans S. <fra...@gm...> - 2008-11-13 08:48:28
|
Hi, > After flashing (successfully ;)) the uc_code-1.1 (and installing the > second jumper) I still see the UPP listed as "ID 04d8:000e Microchip > Technology, Inc."... but usbpicprog recognizes it (says "usbpicprog > 0.1.1 connected") so it looks like everything works ;) > > As soon as I can I'll post the results about how my UPP through-hole > works ;) There's also something else you can check before actually trying to program a pic: first measure the voltage on the last of the diodes. There should be something like 12 or 13 volts on it when both of the jumpers are attached. Cheers, Frans |
From: Frans S. <fra...@gm...> - 2008-11-13 07:30:09
|
Hi, >> On the firmware page: http://usbpicprog.org/?page_id=6 you can see >> that you have to attach jumpers on the programming header. >> One jumper is on the MCLR pin of the 18F2550. If you attach only this >> one, you will see the bootloader in lsusb (it's called Microchip >> Picdem something) > To me it showed up as: > "ID 04d8:000e Microchip Technology, Inc." The bootloader should have said: "ID 04d8:000b Microchip Technology, Inc." and it probably did, or else you couldn't have flashed the firmware successfully! The "Microchip Technology, Inc." string is just related to the 04d8, it has nothing to do with any string in the firmware but generated by the operating system. > >> When you attach the other jumper after programming the usbpicprog >> firmware, you will see usbpicprog in lsusb. > After flashing (successfully ;)) the uc_code-1.1 (and installing the > second jumper) I still see the UPP listed as "ID 04d8:000e Microchip > Technology, Inc."... but usbpicprog recognizes it (says "usbpicprog > 0.1.1 connected") so it looks like everything works ;) > > As soon as I can I'll post the results about how my UPP through-hole > works ;) Great! Don't forget to tell me which devices you have programmed successfully! cheers, Frans |
From: Francesco M. <f18...@ya...> - 2008-11-12 22:57:55
|
Hi, Frans Schreuder ha scritto: > On the firmware page: http://usbpicprog.org/?page_id=6 you can see that > you have to attach jumpers on the programming header. > One jumper is on the MCLR pin of the 18F2550. If you attach only this > one, you will see the bootloader in lsusb (it's called Microchip Picdem > something) To me it showed up as: "ID 04d8:000e Microchip Technology, Inc." > When you attach the other jumper after programming the usbpicprog > firmware, you will see usbpicprog in lsusb. After flashing (successfully ;)) the uc_code-1.1 (and installing the second jumper) I still see the UPP listed as "ID 04d8:000e Microchip Technology, Inc."... but usbpicprog recognizes it (says "usbpicprog 0.1.1 connected") so it looks like everything works ;) As soon as I can I'll post the results about how my UPP through-hole works ;) Thanks, Francesco -- |
From: Frans S. <fra...@gm...> - 2008-11-12 07:23:38
|
Hi Francesco, On the firmware page: http://usbpicprog.org/?page_id=6 you can see that you have to attach jumpers on the programming header. One jumper is on the MCLR pin of the 18F2550. If you attach only this one, you will see the bootloader in lsusb (it's called Microchip Picdem something) When you attach the other jumper after programming the usbpicprog firmware, you will see usbpicprog in lsusb. Cheers, Frans Francesco Montorsi wrote: > Hi Frans, > today I've received your pre-programmed PIC; thanks indeed! > > One question: if I type in linux 'lsusb' with the UPP attached (with the PIC > with only the bootloader flashed), should I see a line indicating the UPP? > Or I need to flash the microcontroller code on the PIC to see something listed? > > Thanks, > Francesco > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
From: Francesco M. <f18...@ya...> - 2008-11-11 19:33:19
|
Hi Frans, today I've received your pre-programmed PIC; thanks indeed! One question: if I type in linux 'lsusb' with the UPP attached (with the PIC with only the bootloader flashed), should I see a line indicating the UPP? Or I need to flash the microcontroller code on the PIC to see something listed? Thanks, Francesco |
From: Francesco M. <f18...@ya...> - 2008-10-29 17:34:45
|
Hi, Frans Schreuder ha scritto: > Well, I tried it with piklab 0.15.2 and 0.15.1 before, never with > 0.15.3. Maybe you should try the older versions of piklab I tried but the older versions do not work either :/ > Have you mentioned that you have to invert the MCLR line? I did it > Have you measured the voltages on the PGD, PGC and MCLR with the PIC > connected? it shoud be 0v/5v, 0v/5v and 0v/12v on MCLR the voltage is correctly 0/12; but on PGD and PGC lines the voltage levels are not exactly 0/5 but rather -0.6/5.5; I think this (or maybe one of the several other attempts I did :)) may have damaged the PIC I'm using... (abs max ratings say that voltages lower than -0.3V or higher than 5.3V on any pin except MCLR and few others may damage the PIC) :/ > Did you connect a proper 12v power supply? I did; in fact when MCLR is driven to 12V I read before the limiting resistor D6 exactly 12V (thanks to the zener); after the resistor about 11.65V... > > If you still fail, I can send you a programmed PIC18F2550. I'd appreciate this very much, if it's not a problem! I built the through-hole version so that if you have a DIP 18F2550 that would be perfect. I'll obviously pay (using paypal is ok?) for the PIC and shipping charge fees... If it's ok, I'll send you my mail address privately... Thanks, Francesco |
From: Frans S. <fra...@gm...> - 2008-10-28 07:14:51
|
Well, I tried it with piklab 0.15.2 and 0.15.1 before, never with 0.15.3. Maybe you should try the older versions of piklab Have you mentioned that you have to invert the MCLR line? Have you measured the voltages on the PGD, PGC and MCLR with the PIC connected? it shoud be 0v/5v, 0v/5v and 0v/12v Did you connect a proper 12v power supply? If you still fail, I can send you a programmed PIC18F2550. Cheers, Frans > Hi, > I'm having troubles programming the PIC18F2550 with the bootloader: I've > built (actually, on a breadboard) the JDM programmer as suggested in the > website of UPP. > > However, using Piklab 0.15.3, when I try to clear the configuration bits of the > PIC (after a warning saying me that the programmer does not support selective > erasing and that all PIC memory will be cleared), piklab hangs forever. > > If instead I try to program the code memory it says: > > ------------- > Programming device memory... > protected: code=false data=false > Writing memory: Code memory > start before align: 0 > start after align: 0 (align=16) > end before align: 949 > end after align: 959 (align=16) > start=0x000000 nbWords=0x0003C0 total=0x004000 force=false varOffset=true > varSize=true > Verifying memory: Code memory > start=0x000000 nbWords=0x004000 total=0x004000 force=true varOffset=true > varSize=true > Device memory does not match hex file (in Code memory at address 0x000000: > reading 0xFFFF and expecting 0xEFA0). > ------------- > > My setup is: > - breadboard with JDM programmer connected to the serial port, to an external > 12V stabilized power supply and to the P2 connector of my UPP > - UPP connected to the JDM programmer and to the USB port of the PC (for power > supply) > > If I sense (without running piklab or any other app using the serial port) with > a voltage meter the base of the BC547 transistor on the JDM programmer (that is > approximatively the voltage level on the pin 3 of the RS232) I read -10.8V. > > On the UPP's PIC I read 5.17V on Vdd (pin 20) and 11.8V on MCLR (pin 1); on PGD > and PGC lines (pin 28 and 27) I read respectively -0.5V and -0.8V... I think all > these readings are ok... > > I think however the programmer isn't working correctly because if I compile > latest SVN version of UPP_WX and run it (as root) and then do 'Actions->Connect > bootloader' I get: > > ------ > USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it > usb_set_debug: Setting debugging level to 2 (on) > usb_os_init: Found USB VFS at /dev/bus/usb > usb_os_find_busses: Found 005 > usb_os_find_busses: Found 004 > usb_os_find_busses: Found 003 > usb_os_find_busses: Found 002 > usb_os_find_busses: Found 001 > usb_os_find_devices: Found 001 on 005 > usb_os_find_devices: Found 001 on 004 > usb_os_find_devices: Found 001 on 003 > usb_os_find_devices: Found 001 on 002 > usb_os_find_devices: Found 005 on 001 > skipped 1 class/vendor specific interface descriptors > usb_os_find_devices: Found 004 on 001 > skipped 1 class/vendor specific interface descriptors > skipped 1 class/vendor specific interface descriptors > usb_os_find_devices: Found 001 on 001 > error obtaining child information: Inappropriate ioctl for device > error obtaining child information: Inappropriate ioctl for device > USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it > usb_set_debug: Setting debugging level to 2 (on) > ------ > > I think this is normal because 'lsusb' says: > > ----- > Bus 005 Device 001: ID 0000:0000 > Bus 004 Device 001: ID 0000:0000 > Bus 003 Device 001: ID 0000:0000 > Bus 002 Device 001: ID 0000:0000 > Bus 001 Device 005: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical > Bus 001 Device 004: ID 046d:c309 Logitech, Inc. Internet Keyboard > Bus 001 Device 001: ID 0000:0000 > ----- > > that is, the PIC seems unprogrammed :/ > > > thanks for any hints, > Francesco > > |
From: Francesco M. <f18...@ya...> - 2008-10-27 16:37:46
|
Hi, I'm having troubles programming the PIC18F2550 with the bootloader: I've built (actually, on a breadboard) the JDM programmer as suggested in the website of UPP. However, using Piklab 0.15.3, when I try to clear the configuration bits of the PIC (after a warning saying me that the programmer does not support selective erasing and that all PIC memory will be cleared), piklab hangs forever. If instead I try to program the code memory it says: ------------- Programming device memory... protected: code=false data=false Writing memory: Code memory start before align: 0 start after align: 0 (align=16) end before align: 949 end after align: 959 (align=16) start=0x000000 nbWords=0x0003C0 total=0x004000 force=false varOffset=true varSize=true Verifying memory: Code memory start=0x000000 nbWords=0x004000 total=0x004000 force=true varOffset=true varSize=true Device memory does not match hex file (in Code memory at address 0x000000: reading 0xFFFF and expecting 0xEFA0). ------------- My setup is: - breadboard with JDM programmer connected to the serial port, to an external 12V stabilized power supply and to the P2 connector of my UPP - UPP connected to the JDM programmer and to the USB port of the PC (for power supply) If I sense (without running piklab or any other app using the serial port) with a voltage meter the base of the BC547 transistor on the JDM programmer (that is approximatively the voltage level on the pin 3 of the RS232) I read -10.8V. On the UPP's PIC I read 5.17V on Vdd (pin 20) and 11.8V on MCLR (pin 1); on PGD and PGC lines (pin 28 and 27) I read respectively -0.5V and -0.8V... I think all these readings are ok... I think however the programmer isn't working correctly because if I compile latest SVN version of UPP_WX and run it (as root) and then do 'Actions->Connect bootloader' I get: ------ USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it usb_set_debug: Setting debugging level to 2 (on) usb_os_init: Found USB VFS at /dev/bus/usb usb_os_find_busses: Found 005 usb_os_find_busses: Found 004 usb_os_find_busses: Found 003 usb_os_find_busses: Found 002 usb_os_find_busses: Found 001 usb_os_find_devices: Found 001 on 005 usb_os_find_devices: Found 001 on 004 usb_os_find_devices: Found 001 on 003 usb_os_find_devices: Found 001 on 002 usb_os_find_devices: Found 005 on 001 skipped 1 class/vendor specific interface descriptors usb_os_find_devices: Found 004 on 001 skipped 1 class/vendor specific interface descriptors skipped 1 class/vendor specific interface descriptors usb_os_find_devices: Found 001 on 001 error obtaining child information: Inappropriate ioctl for device error obtaining child information: Inappropriate ioctl for device USB debug enabled, remove #define USB_DEBUG 10 in hardware.cpp to disable it usb_set_debug: Setting debugging level to 2 (on) ------ I think this is normal because 'lsusb' says: ----- Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 005: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical Bus 001 Device 004: ID 046d:c309 Logitech, Inc. Internet Keyboard Bus 001 Device 001: ID 0000:0000 ----- that is, the PIC seems unprogrammed :/ thanks for any hints, Francesco -- |
From: Frans S. <fra...@gm...> - 2008-10-20 11:20:07
|
Hi, If you look at the top layer of the circuit, you can see that there is a jumper! Frans 2008/10/20 Francesco Montorsi <f18...@ya...> > Hi, > I've almost completed a through-hole version of the UPP; I used the PCB > in > the pcb folder of the SVN repo; however I've just noticed that the portion > of > ground plane below the PIC18F2550 (the portion which e.g. connects pins 8 > and > 19) has no direct contact with the outer portion of ground plane (the one > which > connects e.g. C7). > > Is this wanted? Or is a jumper required to connect the two portions of the > ground plane? > > Thanks, > Francesco > > -- > > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
From: Francesco M. <f18...@ya...> - 2008-10-20 10:48:46
|
Hi, I've almost completed a through-hole version of the UPP; I used the PCB in the pcb folder of the SVN repo; however I've just noticed that the portion of ground plane below the PIC18F2550 (the portion which e.g. connects pins 8 and 19) has no direct contact with the outer portion of ground plane (the one which connects e.g. C7). Is this wanted? Or is a jumper required to connect the two portions of the ground plane? Thanks, Francesco -- |
From: Frans S. <fra...@gm...> - 2008-10-09 11:07:03
|
> So let me ask you 1 last thing; then I won't bug you anymore :) > when do you expect to be able to test/release the new schematic with the > resistive divider? The software needs to support it as well, but I think I will start with it within the next 1 or 2 months if I have time. But I can't guarantee anything about when it will be finished, for now if you want to use PIC24, you better use a commercial programmer. Cheers, Frans |
From: Francesco M. <f18...@ya...> - 2008-10-09 10:28:42
|
Hi, > A solution with the resistive divider may be the attached one: if > the jumper is present, then the two resistors attached to the UPP's > PIC divide by two the voltage; the buffer is used to avoid problems > if the PIC-to-program draws too current. > Since a buffer is used, using an IC which packages four opamps, > another opamp may be used as a non-inverting amplifier with gain = > 2; this way when you're programming a 2.5V PIC, the UPP-PIC gets > back TTL levels, instead of 0/2.5V levels. > The nice thing is that since the op-amps are always powered with > 0/+5V, the UPP-PIC always get back 0/5V TTL levels from the > PIC-to-program, without the need of a further jumper. > I hope I was clear :) > > Something similar (not shown in the attached schematic) may be done > for PGC clock line (using a single opamp since that's not a > bidirectional line, AFAIK). > > How does it look? > > 1: I am not going to change the hardware that much right now, let's > first investigate the resistive divider thing > 2: the pins don't draw current, so we CAN use resistive dividers > 3: stop doing so difficult, I don't want to use more components and > certainly no opamps / voltage regulators and all that stuff ok ok; it's just that I have all hardware components at hand for building the UPP but since I have to use (in near future) a PIC24, I'd like to directly build an hardware version which can handle them. So let me ask you 1 last thing; then I won't bug you anymore :) when do you expect to be able to test/release the new schematic with the resistive divider? Thanks, Francesco -- |
From: Frans S. <fra...@gm...> - 2008-10-09 09:55:20
|
2008/10/9 Francesco Montorsi <f18...@ya...> > Hi, > > Frans Schreuder ha scritto: > >> Pull-down resistors on the drain pins of the two new PMOS may be >> necessary to ensure a good zero voltage level. >> >> This should allow to use UPP to program also 2.5V devices, isn't it? >> Do I miss something? >> >> >> Thanks for thinking with me about the hardware, but I can't agree with >> your version of the circuit for a couple of reasons: >> >> * With these mosfets you have made an open-drain circuit which can >> pull the data / clock line towards 5V / 2.5V. What about if you >> want to send a "0"? >> > right; I thought that pull-down resistors could be used for that. > > * I don't like the size of the circuit you have added. usbpicprog >> must be kept as simple as possible in terms of hardware. The L317 >> and all the jumpers and stuff make the circuit too complex to control >> * You are losing the pin-direction of the data line, with a mosfet >> you can "write" to the data line, but how will you read the level? >> > indeed. This is the killer reason for the proposed schematic. > Actually I "forgot" about the fact that the PGD dataline must be > bidirectional :/ Sorry!! > > * I have already been thinking about a revision with just a >> resistive voltage divider, this way you achieve the same with just >> 2 additional resistors connected to 2 other pins of the PIC. (You >> don't need all this additional stuff :P ) >> > The problem of a resistive divider is that if the current drawn from the > "middle node" (the node connecting the two resistors) is comparable with the > current that the UPP is sourcing, then it ceases to be a simple resistive > divider and the voltage at the middle node drops. > A solution with the resistive divider may be the attached one: if the > jumper is present, then the two resistors attached to the UPP's PIC divide > by two the voltage; the buffer is used to avoid problems if the > PIC-to-program draws too current. > Since a buffer is used, using an IC which packages four opamps, another > opamp may be used as a non-inverting amplifier with gain = 2; this way when > you're programming a 2.5V PIC, the UPP-PIC gets back TTL levels, instead of > 0/2.5V levels. > The nice thing is that since the op-amps are always powered with 0/+5V, the > UPP-PIC always get back 0/5V TTL levels from the PIC-to-program, without the > need of a further jumper. > I hope I was clear :) > > Something similar (not shown in the attached schematic) may be done for PGC > clock line (using a single opamp since that's not a bidirectional line, > AFAIK). > > How does it look? > 1: I am not going to change the hardware that much right now, let's first investigate the resistive divider thing 2: the pins don't draw current, so we CAN use resistive dividers 3: stop doing so difficult, I don't want to use more components and certainly no opamps / voltage regulators and all that stuff > > > What about dynamic characteristics? I don't know which data rate >> should the clock and data line be able to handle... >> >> If you use long wires ( > 40cm or something), the wires become the >> limiting factor. Else, it's the clock frequency of usbpicprog but since it's >> an synchrounous system, the software determines wether it wants to use >> higher or lower data rates. I am also testing this while writing the >> software. >> > ok; btw using op-amps as suggested above the data rates shouldn't be a > problem (op-amps up to 20Mhz are very cheap). > > THanks, > Francesco > > > -- > > > > > > |
From: Francesco M. <f18...@ya...> - 2008-10-09 09:46:15
|
Hi, Frans Schreuder ha scritto: > Pull-down resistors on the drain pins of the two new PMOS may be > necessary to ensure a good zero voltage level. > > This should allow to use UPP to program also 2.5V devices, isn't it? > Do I miss something? > > > Thanks for thinking with me about the hardware, but I can't agree with > your version of the circuit for a couple of reasons: > > * With these mosfets you have made an open-drain circuit which can > pull the data / clock line towards 5V / 2.5V. What about if you > want to send a "0"? right; I thought that pull-down resistors could be used for that. > * I don't like the size of the circuit you have added. usbpicprog > must be kept as simple as possible in terms of hardware. The L317 > and all the jumpers and stuff make the circuit too complex to control > * You are losing the pin-direction of the data line, with a mosfet > you can "write" to the data line, but how will you read the level? indeed. This is the killer reason for the proposed schematic. Actually I "forgot" about the fact that the PGD dataline must be bidirectional :/ Sorry!! > * I have already been thinking about a revision with just a > resistive voltage divider, this way you achieve the same with just > 2 additional resistors connected to 2 other pins of the PIC. (You > don't need all this additional stuff :P ) The problem of a resistive divider is that if the current drawn from the "middle node" (the node connecting the two resistors) is comparable with the current that the UPP is sourcing, then it ceases to be a simple resistive divider and the voltage at the middle node drops. A solution with the resistive divider may be the attached one: if the jumper is present, then the two resistors attached to the UPP's PIC divide by two the voltage; the buffer is used to avoid problems if the PIC-to-program draws too current. Since a buffer is used, using an IC which packages four opamps, another opamp may be used as a non-inverting amplifier with gain = 2; this way when you're programming a 2.5V PIC, the UPP-PIC gets back TTL levels, instead of 0/2.5V levels. The nice thing is that since the op-amps are always powered with 0/+5V, the UPP-PIC always get back 0/5V TTL levels from the PIC-to-program, without the need of a further jumper. I hope I was clear :) Something similar (not shown in the attached schematic) may be done for PGC clock line (using a single opamp since that's not a bidirectional line, AFAIK). How does it look? > What about dynamic characteristics? I don't know which data rate > should the clock and data line be able to handle... > > If you use long wires ( > 40cm or something), the wires become the > limiting factor. Else, it's the clock frequency of usbpicprog but since > it's an synchrounous system, the software determines wether it wants to > use higher or lower data rates. I am also testing this while writing the > software. ok; btw using op-amps as suggested above the data rates shouldn't be a problem (op-amps up to 20Mhz are very cheap). THanks, Francesco -- |
From: Francesco M. <f18...@ya...> - 2008-10-09 09:17:54
|
Frans Schreuder ha scritto: > ok; but what about Vpp? > The charge pump can deliver only a very small current; I've > simulated it (using a square wave on Vpump1 and Vpump2 at about > 20kHz) and absorbing 1.5mA makes Vpp drop to 9V.... > > OTOH I couldn't find any specs about the minimal current which this > pin should be able to provide... I've found references to a LVP > (low-voltage programming) mode, where Vpp is used only as a voltage > reference (if I got it right); while in non-LVP mode, Vpp is used as > source for the EEPROM programming. > I may be wrong however... > > > According to Microchip's programming specification: > > /To activate the Programming mode, high voltage needs to be applied to > the MCLR input. Since MCLR is used for a > level source, this means that MCLR does not draw any significant current./ > > So also don't worry about that one! Ok, thanks for the reassurance! Francesco PS: probably the reply-to header field of the mailing list should be set to the "list" instead of to the "poster". You can find this setting in the [general options] GNU mailman admin page of the mailing list, at the row containing "Where are replies to list messages directed?"... -- |
From: Francesco M. <f18...@ya...> - 2008-10-08 23:15:42
|
Hi, as written in upp website (http://usbpicprog.org/?page_id=5) currently the UPP cannot be used with PIC24 and PIC33 series because of the TTL output levels. I attach a sligthly modified version of the UPP schematic: here the PGD and PGC lines are attached instead to two PMOS instead of directly to the ICSP connector. Through a simple jumper, the user of UPP can select whether to send 0-5V or 0-2.5V to the PIC being programmed. The 2.5V reference could be generated using a common LM317 or any other linear regulator. Pull-down resistors on the drain pins of the two new PMOS may be necessary to ensure a good zero voltage level. This should allow to use UPP to program also 2.5V devices, isn't it? Do I miss something? What about dynamic characteristics? I don't know which data rate should the clock and data line be able to handle... THanks, Francesco PS: it would be nice to have an SVG version of the schematic in the website HW page, instead of the current medium-resolution PNG. -- |
From: Francesco M. <f18...@ya...> - 2008-10-08 22:34:11
|
Hi, Frans Schreuder ha scritto: > Sorry for not responding, I just opened these mailing lists and > discovered that I forgot to subscribe myself! no problem ;) > Don't worry too much about the current consumption of usbpicprog, it > will draw 50mA max. It can also work from 4.2V. very good. > What you do have to worry about is connecting a target board which is > powered by usbpicprog. If that one draws more than about 300mA, give it > his own powersupply of 5V. ok; but what about Vpp? The charge pump can deliver only a very small current; I've simulated it (using a square wave on Vpump1 and Vpump2 at about 20kHz) and absorbing 1.5mA makes Vpp drop to 9V.... OTOH I couldn't find any specs about the minimal current which this pin should be able to provide... I've found references to a LVP (low-voltage programming) mode, where Vpp is used only as a voltage reference (if I got it right); while in non-LVP mode, Vpp is used as source for the EEPROM programming. I may be wrong however... > Because of the diode in the VDD connection, it is allowed to use a 5V > power supply (but don't use a lower voltage than 4.5V when usbpicprog is > trying to power up the target board) sure; I guess that powering the external circuit with < 4.5V would turn on that diode, and provoke a large current flow through the PMOS, leading to its possible destruction... Thanks, Francesco -- |