Menu
▾
▴
usbpicprog-technical
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(13) |
Nov
(27) |
Dec
(23) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(13) |
Mar
(24) |
Apr
(4) |
May
(11) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(5) |
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
(22) |
Mar
(52) |
Apr
(7) |
May
(19) |
Jun
(12) |
Jul
(9) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(8) |
Dec
(7) |
| 2011 |
Jan
(12) |
Feb
(7) |
Mar
(10) |
Apr
(14) |
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(12) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
|
Dec
|
| 2013 |
Jan
(7) |
Feb
(6) |
Mar
(6) |
Apr
(21) |
May
(7) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sa...@al...> - 2011-02-12 04:16:08
|
Dear Sir, I have wired up the circuit accordinigly in usbpicprog hardware 0.3.1 pdf. I have succesfully loaded .hex file for bootloader using JDM programmer. I have shorted jumpper as suggested that is VPP self and VDD. I have connected USBPICPROG it got detected and i was able to update the driver also. I'm using 18f4550. It shows bootloader v1.0 connected in usbpicprog software. I need assistance as how to connect the target (I know connection wise), But in software should i click on auto detect to detect my target device or what. Can you please help me using the software so that i can program my target device and also jumpper setting details in ie vpp_self, etc.ie p1. connector. Please reply and help me to proceed further I'm Stuck in this. With Regards Srinivas.V |
|
From: Frans S. <fra...@gm...> - 2011-02-11 22:08:24
|
<!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 text="#000000" bgcolor="#ffffff">
Dear Srinivas. V,<br>
<br>
In principle usbpicprog should be able to detect the device as it
connects to the programmer. When you say autodetect, it should try
to identify the connected target again. If you have used software /
firmware 0.4.1, there is a known bug that it doesn't autodetect some
16F devices. If this is the case please upgrade to 0.4.2-beta.<br>
You can also test the voltages on all the programming pins, using
the option IO_Test under Options. Just measure all the pins using a
multimeter.<br>
<br>
Kind regards,<br>
<br>
Frans Schreuder<br>
<br>
On 02/11/2011 01:31 AM, <a class="moz-txt-link-abbreviated" href="mailto:sa...@al...">sa...@al...</a> wrote:
<blockquote cite="mid:05BF78D9CB454F3BA5985655ADEA3C3C@als"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<meta name="GENERATOR" content="MSHTML 8.00.6001.18999">
<style></style>
<div><font face="Arial" size="2">Dear Sir,</font></div>
<div> </div>
<div><font face="Arial" size="2">I have wired up the circuit
accordinigly in usbpicprog hardware 0.3.1 pdf. I have
succesfully loaded .hex file for bootloader using JDM
programmer. I have shorted jumpper as suggested that is VPP
self and VDD. I have connected USBPICPROG it got detected and
i was able to update the driver also. I'm using 18f4550. It
shows bootloader v1.0 connected in usbpicprog software.</font></div>
<div> </div>
<div><font face="Arial" size="2">I need assistance as how to
connect the target (I know connection wise), But in software
should i click on auto detect to detect my target device or
what. Can you please help me using the software so that i can
program my target device and also jumpper setting details in
ie vpp_self, etc.ie p1. connector.</font></div>
<div> </div>
<div><font face="Arial" size="2">Please reply and help me to
proceed further I'm Stuck in this.</font></div>
<div> </div>
<div><font face="Arial" size="2">With Regards</font></div>
<div><font face="Arial" size="2">Srinivas.V</font></div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devfeb">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
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>
|
|
From: <sa...@al...> - 2011-02-11 17:14:19
|
Dear Sir, I have wired up the circuit accordinigly in usbpicprog hardware 0.3.1 pdf. I have succesfully loaded .hex file for bootloader using JDM programmer. I have shorted jumpper as suggested that is VPP self and VDD. I have connected USBPICPROG it got detected and i was able to update the driver also. I'm using 18f4550. It shows bootloader v1.0 connected in usbpicprog software. I need assistance as how to connect the target (I know connection wise), But in software should i click on auto detect to detect my target device or what. Can you please help me using the software so that i can program my target device and also jumpper setting details in ie vpp_self, etc.ie p1. connector. Please reply and help me to proceed further I'm Stuck in this. With Regards Srinivas.V |
|
From: Matt H. <mh...@me...> - 2011-01-31 15:48:31
|
Frans, Thanks for the pointers. I noticed you use mcc18 to compile the firmware. (Or at least your Makefile is setup that way). Do you use the commercial version? Or will it be ok to use the lite version? I also see #defines for sdcc - is this a valid option to compile the firmware? Thanks, Matt On 01/31/2011 03:54 AM, Frans Schreuder wrote: > Dear Matt, > > I think the sourcecode of the PC application doesn't have to be altered > for that, only the .xml files. > Only in the firmware some small modifications will have to be done. > Also the hardware can't just program these devices since it gives a VPP > of 12V where the 18f45K22 has a maximum VPP of 9V. > A very simple solution for this will be a 9V zener diode over the VPP > pin so that it won't exceed this limit. > > I don't see any other problems for implementing this device. > > Kind regards, > > Frans Schreuder > > > On 01/31/2011 09:06 AM, Matt Hirsch wrote: >> I was thinking of attempting to modify usbpicprog to program the >> 18f45k22. The programming spec is similar, with minor differences, to >> the PIC18F2XXX/4XXX family: >> >> http://ww1.microchip.com/downloads/en/DeviceDoc/39622L.pdf >> vs >> http://ww1.microchip.com/downloads/en/DeviceDoc/41398B.pdf >> >> And I see many parts from that first family are on the tested list. >> >> Should something like this process work?: >> http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical >> <http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical> >> >> I guess I will have to create a new family. >> >> I'd appreciate any comments. >> >> Best, >> Matt >> >> ------------------------------------------------------------------------------ >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsight-sfd2d >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > > > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: Frans S. <fra...@gm...> - 2011-01-31 08:54:59
|
Dear Matt, I think the sourcecode of the PC application doesn't have to be altered for that, only the .xml files. Only in the firmware some small modifications will have to be done. Also the hardware can't just program these devices since it gives a VPP of 12V where the 18f45K22 has a maximum VPP of 9V. A very simple solution for this will be a 9V zener diode over the VPP pin so that it won't exceed this limit. I don't see any other problems for implementing this device. Kind regards, Frans Schreuder On 01/31/2011 09:06 AM, Matt Hirsch wrote: > I was thinking of attempting to modify usbpicprog to program the > 18f45k22. The programming spec is similar, with minor differences, to > the PIC18F2XXX/4XXX family: > > http://ww1.microchip.com/downloads/en/DeviceDoc/39622L.pdf > vs > http://ww1.microchip.com/downloads/en/DeviceDoc/41398B.pdf > > And I see many parts from that first family are on the tested list. > > Should something like this process work?: > http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical > <http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical> > > I guess I will have to create a new family. > > I'd appreciate any comments. > > Best, > Matt > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: Matt H. <mh...@me...> - 2011-01-31 08:22:15
|
I was thinking of attempting to modify usbpicprog to program the 18f45k22. The programming spec is similar, with minor differences, to the PIC18F2XXX/4XXX family: http://ww1.microchip.com/downloads/en/DeviceDoc/39622L.pdf vs http://ww1.microchip.com/downloads/en/DeviceDoc/41398B.pdf And I see many parts from that first family are on the tested list. Should something like this process work?: http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical <http://sourceforge.net/mailarchive/forum.php?thread_name=4C035FBD.9030506%40gmail.com&forum_name=usbpicprog-technical> I guess I will have to create a new family. I'd appreciate any comments. Best, Matt |
|
From: Frans S. <fra...@gm...> - 2011-01-13 13:31:55
|
The footprint is 1206, but it fits minimelf or SMF packages as well. On 01/13/2011 02:28 PM, bisky wrote: > Hello again, > Tx for the fast response, I tested the programmer and every thing > else seems to be okay. Just one queston, what packege is this diode. > > Regards, Bojan >> Dear Bojan Biskup, >> >> The transistor Q3 can handle a much higher current than D9 and will thus >> not easily blow out. If the rest of the programmer is still working >> (e.g. the VPP should be ~12V) >> You can test this by means of the IO Test dialog in the usbpicprog >> application. >> In fact I think only D9 will have been distroyed, and this can be easily >> replaced. >> You can use any diode as long as it fits the footprint. You can even >> just short circuit D9, but in that case you can't connect an external >> powersupply while connecting usbpicprog at the same time. >> >> Kind regards, >> >> Frans Schreuder >> >> ps. I have also forwarded this e-mail to the mailing list because it >> could be useful for others. >> >> On 01/13/2011 01:47 PM, Bojan Biškup wrote: >>> Name: Bojan Biškup >>> >>> Email: bi...@gm... >>> >>> Subject: Burned d9 on smd programmer >>> >>> Message: Hello Frans >>> Today I managed to destroy D9 on the programmer, I guess the iscp was >>> connected wrong. I wonderd if U know of a such case and if any thing >>> else was burned. >>> >>> Regards, Bojan >>> >>> >>> >> > |
|
From: Frans S. <fra...@gm...> - 2011-01-13 13:02:13
|
Dear Bojan Biskup, The transistor Q3 can handle a much higher current than D9 and will thus not easily blow out. If the rest of the programmer is still working (e.g. the VPP should be ~12V) You can test this by means of the IO Test dialog in the usbpicprog application. In fact I think only D9 will have been distroyed, and this can be easily replaced. You can use any diode as long as it fits the footprint. You can even just short circuit D9, but in that case you can't connect an external powersupply while connecting usbpicprog at the same time. Kind regards, Frans Schreuder ps. I have also forwarded this e-mail to the mailing list because it could be useful for others. On 01/13/2011 01:47 PM, Bojan Biškup wrote: > Name: Bojan Biškup > > Email: bi...@gm... > > Subject: Burned d9 on smd programmer > > Message: Hello Frans > Today I managed to destroy D9 on the programmer, I guess the iscp was > connected wrong. I wonderd if U know of a such case and if any thing > else was burned. > > Regards, Bojan > > > |
|
From: Frans S. <fra...@gm...> - 2011-01-10 07:48:50
|
Dear David, Thank you for your suggestions. There is one thing that I wouldn't like to do in this schematic, and that is inverting the signal of the VPP_CTL pin. The reason for this is that it wouldn't be compatible anymore with older hardware. So either I would have to drop support for older hardware (a thing that I would never do) or I have to make two firmware versions. The second option is also not very convenient, especially for people who want to update their firmware and then need to search for which version they will need. Also in your suggestion, the G-S voltage will be 13.8V which is too high for the TSM2301. Of course another one can be used but I won't consider a P-channel mosfet in my design for the above reason. I would rather just use a bipolar transistor for Q4 in exactly the same circuit as it is in 0.3.1. The zener diode is in the circuit because some programming specifications say that 12.0V is the max VPP, but if you look in the datasheet of those devices, the absolute maximum ratings say 13.5V so the zener can also be removed from the schematic. I will soon come with a new hardware release, taking a higher VPP into account, but I will also try to be able to use the old PCB so that people will be able to alter their device to the new schematic without too many problems. Kind regards, Frans Schreuder On 01/10/2011 02:07 AM, David wrote: > Indeed, Q5 turned out to just be a diode -- thanks for the tip. The extra > pad to Vcc was throwing me off. This means what I really have is rev 702, > minus R13. > > I was able to get Vpp to 12.5V with no load by removing the Zener and > bypassing Q4 (so, Q1 shorts Vpp to turn it off). That solved my problem. > > Alternatively though, consider the attached schematic tweaks. I switched > out Q4 for an P-MOSFET. The resistance across Q4 should be in the milli > ohms in this setup, so the voltage drop should be negligible. It should > also easily give you 13V for Vpp (no load) as it also removes D4 which isn't > needed anymore. > > This could also allow for a slightly higher voltage Zener shunt and allow R2 > to be reduced, letting Vpp to remain above 12.5V at the 0.45mA load > prescribed in the PIC10F200 programming spec. > > > Either way, thanks for the quick reply. I hope this helps. > > David > > > > > On Sun, Jan 09, 2011 at 08:56:53PM +0100, Frans Schreuder wrote: >> Dear David, >> >> On the version you have, Q5 is actually a diode in an SOT23 casing, so >> it seems that it doesn't match the 0.3.1 design but it actually does. >> The problem you are facing is probably that the resistors R15/R16 were >> still 47k/100k. In the new schematic they are now 470k/1M because they >> were loading the circuit too much. They can be removed if you are not >> interested in measuring the voltage in the IO Test dialog. (you can also >> remove the 12V zener) >> When that is done, the circuit should go to at least 11.5V which is >> enough for 99% of the PIC devices. >> It is also possible to replace Q4 with a bipolar transistor (BC547 or >> something similar) which will bring the voltage drop to only 0.7V in >> stead of almost 2. I am still considering to do this action in a future >> hardware release. >> >> Kind regards, >> >> Frans Schreuder >> >> On 01/09/2011 08:02 PM, David wrote: >>> I think there's a design issue in how Vpp is being switched. >>> >>> I figured out my board is closer to rev 644 (minus R13). To that end, I >>> removed Q5 altogether as a test, and I still get the same 10.78V for Vpp. I >>> would have suspected body-diode conduction from Vpp to the 5V supply as the >>> culprit (as this appears to be the design oops Frans refers to), but alas no >>> change. >>> >>> On the other hand, I think the real issue is Q4: It's an N-MOSFET being used >>> to switch the 12V supply and the only thing to generate Vgs is the drop >>> across the MOSFET itself. The BS170 datasheet calls for a Vth anywhere from >>> 0.8V minimum to 3V max, with 2.1V typical. As such, depending on the device >>> tolerances, the ~1.25V drop between the pump and the Zener shunt isn't >>> enough to drive the MOSFET into good conduction. Moreover, the problem is >>> exacerbated with R1 being ahead of the pull-up for Q4, so as the Vpp current >>> increases (via the shunt or the load), Vgs drops even more. The result >>> significantly limits the current on Vpp. >>> >>> I may have *completely* misread the circuit and I'm a bit rusty on my analog >>> electronics (had to pull out the old text books), but this appears to be >>> what's happening. >>> >>> >>> The fix would be to use a P-MOSFET in place of Q4 (source towards the pump, >>> drain towards the Zener), with the rest of the circuit remaining unchanged >>> (though D4 could also be removed). VPP_CTL would change from being active >>> low to active high. The P-MOSFET won't conduct so long as the gate is held >>> towards the source, but will conduct quite well when Q1 pulls the gate down >>> to ground (Vgs=-13-14V, which will be too much for the TM2301. Fix with a >>> different MOSFET or an extra resistor to make a voltage divider on the >>> gate.) >>> >>> Thoughts? >>> >>> Of course, another, less elegant fix is to bypass Q4 altogether and use Q1 >>> to short out the 12V when not in use. This will cost about 6mA in draw, but >>> won't require any other circuit changes. >>> >>> If I have time later, I might try it. Nothing like doing some hotwired SMT >>> soldering! >>> >>> David >>> >>> On Sun, Jan 09, 2011 at 12:03:45PM -0500, David wrote: >>>> Hello everyone! >>>> >>>> I'm trying to troubleshoot a low Vpp on my usbpicprog v0.3 hardware. I'm >>>> only getting about ~10.78V with no load attached. USB supply voltage is >>>> 4.98V. >>>> >>>> I'm getting a solid 13.25V on the pump side of R1, with only a 0.17V drop >>>> across it, confirming little load. However, by the time I get to the Vpp >>>> header, I'm showing only 10.79V. The anode of D4 is also low at 11.27V. >>>> >>>> Unfortunately, the board I have (SMT version, pre-assembled) doesn't exactly >>>> match any of the schematics. I have what appears to be a Q5, and R13 is not >>>> assembled (which is what the v0.3.1 hardware calls for), yet I still have >>>> the 47k and 100k R16/R15 voltage divider on the Vpp sense (v0.3 design). I >>>> also have no D10. So, thus far, until I trace Q5, I'm a bit of a loss to >>>> troubleshoot further. >>>> >>>> FWIW, my Vpp may have always been low -- I recall having some issues reading >>>> a device a while back, but I moved the interface to a powered hub and all >>>> was well. I didn't investigate further. Now I'm on a powered hub and I'm >>>> unable to get a PIC10F206 to respond, which I'm assuming is because Vpp is >>>> well below spec for program mode entry. >>>> >>>> Any thoughts? >>>> >>>> Thanks! >>>> >>>> David >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Gaining the trust of online customers is vital for the success of any company >>>> that requires sensitive data to be transmitted over the Web. Learn how to >>>> best implement a security strategy that keeps consumers' information secure >>>> and instills the confidence they need to proceed with transactions. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Usbpicprog-technical mailing list >>>> Usb...@li... >>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >>> ------------------------------------------------------------------------------ >>> Gaining the trust of online customers is vital for the success of any company >>> that requires sensitive data to be transmitted over the Web. Learn how to >>> best implement a security strategy that keeps consumers' information secure >>> and instills the confidence they need to proceed with transactions. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Usbpicprog-technical mailing list >>> Usb...@li... >>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > >> ------------------------------------------------------------------------------ >> Gaining the trust of online customers is vital for the success of any company >> that requires sensitive data to be transmitted over the Web. Learn how to >> best implement a security strategy that keeps consumers' information secure >> and instills the confidence they need to proceed with transactions. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > > > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: David <dev...@fo...> - 2011-01-10 01:07:32
|
Indeed, Q5 turned out to just be a diode -- thanks for the tip. The extra pad to Vcc was throwing me off. This means what I really have is rev 702, minus R13. I was able to get Vpp to 12.5V with no load by removing the Zener and bypassing Q4 (so, Q1 shorts Vpp to turn it off). That solved my problem. Alternatively though, consider the attached schematic tweaks. I switched out Q4 for an P-MOSFET. The resistance across Q4 should be in the milli ohms in this setup, so the voltage drop should be negligible. It should also easily give you 13V for Vpp (no load) as it also removes D4 which isn't needed anymore. This could also allow for a slightly higher voltage Zener shunt and allow R2 to be reduced, letting Vpp to remain above 12.5V at the 0.45mA load prescribed in the PIC10F200 programming spec. Either way, thanks for the quick reply. I hope this helps. David On Sun, Jan 09, 2011 at 08:56:53PM +0100, Frans Schreuder wrote: > Dear David, > > On the version you have, Q5 is actually a diode in an SOT23 casing, so > it seems that it doesn't match the 0.3.1 design but it actually does. > The problem you are facing is probably that the resistors R15/R16 were > still 47k/100k. In the new schematic they are now 470k/1M because they > were loading the circuit too much. They can be removed if you are not > interested in measuring the voltage in the IO Test dialog. (you can also > remove the 12V zener) > When that is done, the circuit should go to at least 11.5V which is > enough for 99% of the PIC devices. > It is also possible to replace Q4 with a bipolar transistor (BC547 or > something similar) which will bring the voltage drop to only 0.7V in > stead of almost 2. I am still considering to do this action in a future > hardware release. > > Kind regards, > > Frans Schreuder > > On 01/09/2011 08:02 PM, David wrote: > > I think there's a design issue in how Vpp is being switched. > > > > I figured out my board is closer to rev 644 (minus R13). To that end, I > > removed Q5 altogether as a test, and I still get the same 10.78V for Vpp. I > > would have suspected body-diode conduction from Vpp to the 5V supply as the > > culprit (as this appears to be the design oops Frans refers to), but alas no > > change. > > > > On the other hand, I think the real issue is Q4: It's an N-MOSFET being used > > to switch the 12V supply and the only thing to generate Vgs is the drop > > across the MOSFET itself. The BS170 datasheet calls for a Vth anywhere from > > 0.8V minimum to 3V max, with 2.1V typical. As such, depending on the device > > tolerances, the ~1.25V drop between the pump and the Zener shunt isn't > > enough to drive the MOSFET into good conduction. Moreover, the problem is > > exacerbated with R1 being ahead of the pull-up for Q4, so as the Vpp current > > increases (via the shunt or the load), Vgs drops even more. The result > > significantly limits the current on Vpp. > > > > I may have *completely* misread the circuit and I'm a bit rusty on my analog > > electronics (had to pull out the old text books), but this appears to be > > what's happening. > > > > > > The fix would be to use a P-MOSFET in place of Q4 (source towards the pump, > > drain towards the Zener), with the rest of the circuit remaining unchanged > > (though D4 could also be removed). VPP_CTL would change from being active > > low to active high. The P-MOSFET won't conduct so long as the gate is held > > towards the source, but will conduct quite well when Q1 pulls the gate down > > to ground (Vgs=-13-14V, which will be too much for the TM2301. Fix with a > > different MOSFET or an extra resistor to make a voltage divider on the > > gate.) > > > > Thoughts? > > > > Of course, another, less elegant fix is to bypass Q4 altogether and use Q1 > > to short out the 12V when not in use. This will cost about 6mA in draw, but > > won't require any other circuit changes. > > > > If I have time later, I might try it. Nothing like doing some hotwired SMT > > soldering! > > > > David > > > > On Sun, Jan 09, 2011 at 12:03:45PM -0500, David wrote: > >> Hello everyone! > >> > >> I'm trying to troubleshoot a low Vpp on my usbpicprog v0.3 hardware. I'm > >> only getting about ~10.78V with no load attached. USB supply voltage is > >> 4.98V. > >> > >> I'm getting a solid 13.25V on the pump side of R1, with only a 0.17V drop > >> across it, confirming little load. However, by the time I get to the Vpp > >> header, I'm showing only 10.79V. The anode of D4 is also low at 11.27V. > >> > >> Unfortunately, the board I have (SMT version, pre-assembled) doesn't exactly > >> match any of the schematics. I have what appears to be a Q5, and R13 is not > >> assembled (which is what the v0.3.1 hardware calls for), yet I still have > >> the 47k and 100k R16/R15 voltage divider on the Vpp sense (v0.3 design). I > >> also have no D10. So, thus far, until I trace Q5, I'm a bit of a loss to > >> troubleshoot further. > >> > >> FWIW, my Vpp may have always been low -- I recall having some issues reading > >> a device a while back, but I moved the interface to a powered hub and all > >> was well. I didn't investigate further. Now I'm on a powered hub and I'm > >> unable to get a PIC10F206 to respond, which I'm assuming is because Vpp is > >> well below spec for program mode entry. > >> > >> Any thoughts? > >> > >> Thanks! > >> > >> David > >> > >> > >> ------------------------------------------------------------------------------ > >> Gaining the trust of online customers is vital for the success of any company > >> that requires sensitive data to be transmitted over the Web. Learn how to > >> best implement a security strategy that keeps consumers' information secure > >> and instills the confidence they need to proceed with transactions. > >> http://p.sf.net/sfu/oracle-sfdevnl > >> _______________________________________________ > >> Usbpicprog-technical mailing list > >> Usb...@li... > >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > ------------------------------------------------------------------------------ > > Gaining the trust of online customers is vital for the success of any company > > that requires sensitive data to be transmitted over the Web. Learn how to > > best implement a security strategy that keeps consumers' information secure > > and instills the confidence they need to proceed with transactions. > > http://p.sf.net/sfu/oracle-sfdevnl > > _______________________________________________ > > Usbpicprog-technical mailing list > > Usb...@li... > > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: Frans S. <fra...@gm...> - 2011-01-09 19:57:07
|
Dear David, On the version you have, Q5 is actually a diode in an SOT23 casing, so it seems that it doesn't match the 0.3.1 design but it actually does. The problem you are facing is probably that the resistors R15/R16 were still 47k/100k. In the new schematic they are now 470k/1M because they were loading the circuit too much. They can be removed if you are not interested in measuring the voltage in the IO Test dialog. (you can also remove the 12V zener) When that is done, the circuit should go to at least 11.5V which is enough for 99% of the PIC devices. It is also possible to replace Q4 with a bipolar transistor (BC547 or something similar) which will bring the voltage drop to only 0.7V in stead of almost 2. I am still considering to do this action in a future hardware release. Kind regards, Frans Schreuder On 01/09/2011 08:02 PM, David wrote: > I think there's a design issue in how Vpp is being switched. > > I figured out my board is closer to rev 644 (minus R13). To that end, I > removed Q5 altogether as a test, and I still get the same 10.78V for Vpp. I > would have suspected body-diode conduction from Vpp to the 5V supply as the > culprit (as this appears to be the design oops Frans refers to), but alas no > change. > > On the other hand, I think the real issue is Q4: It's an N-MOSFET being used > to switch the 12V supply and the only thing to generate Vgs is the drop > across the MOSFET itself. The BS170 datasheet calls for a Vth anywhere from > 0.8V minimum to 3V max, with 2.1V typical. As such, depending on the device > tolerances, the ~1.25V drop between the pump and the Zener shunt isn't > enough to drive the MOSFET into good conduction. Moreover, the problem is > exacerbated with R1 being ahead of the pull-up for Q4, so as the Vpp current > increases (via the shunt or the load), Vgs drops even more. The result > significantly limits the current on Vpp. > > I may have *completely* misread the circuit and I'm a bit rusty on my analog > electronics (had to pull out the old text books), but this appears to be > what's happening. > > > The fix would be to use a P-MOSFET in place of Q4 (source towards the pump, > drain towards the Zener), with the rest of the circuit remaining unchanged > (though D4 could also be removed). VPP_CTL would change from being active > low to active high. The P-MOSFET won't conduct so long as the gate is held > towards the source, but will conduct quite well when Q1 pulls the gate down > to ground (Vgs=-13-14V, which will be too much for the TM2301. Fix with a > different MOSFET or an extra resistor to make a voltage divider on the > gate.) > > Thoughts? > > Of course, another, less elegant fix is to bypass Q4 altogether and use Q1 > to short out the 12V when not in use. This will cost about 6mA in draw, but > won't require any other circuit changes. > > If I have time later, I might try it. Nothing like doing some hotwired SMT > soldering! > > David > > On Sun, Jan 09, 2011 at 12:03:45PM -0500, David wrote: >> Hello everyone! >> >> I'm trying to troubleshoot a low Vpp on my usbpicprog v0.3 hardware. I'm >> only getting about ~10.78V with no load attached. USB supply voltage is >> 4.98V. >> >> I'm getting a solid 13.25V on the pump side of R1, with only a 0.17V drop >> across it, confirming little load. However, by the time I get to the Vpp >> header, I'm showing only 10.79V. The anode of D4 is also low at 11.27V. >> >> Unfortunately, the board I have (SMT version, pre-assembled) doesn't exactly >> match any of the schematics. I have what appears to be a Q5, and R13 is not >> assembled (which is what the v0.3.1 hardware calls for), yet I still have >> the 47k and 100k R16/R15 voltage divider on the Vpp sense (v0.3 design). I >> also have no D10. So, thus far, until I trace Q5, I'm a bit of a loss to >> troubleshoot further. >> >> FWIW, my Vpp may have always been low -- I recall having some issues reading >> a device a while back, but I moved the interface to a powered hub and all >> was well. I didn't investigate further. Now I'm on a powered hub and I'm >> unable to get a PIC10F206 to respond, which I'm assuming is because Vpp is >> well below spec for program mode entry. >> >> Any thoughts? >> >> Thanks! >> >> David >> >> >> ------------------------------------------------------------------------------ >> Gaining the trust of online customers is vital for the success of any company >> that requires sensitive data to be transmitted over the Web. Learn how to >> best implement a security strategy that keeps consumers' information secure >> and instills the confidence they need to proceed with transactions. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: David <dev...@fo...> - 2011-01-09 19:02:48
|
I think there's a design issue in how Vpp is being switched. I figured out my board is closer to rev 644 (minus R13). To that end, I removed Q5 altogether as a test, and I still get the same 10.78V for Vpp. I would have suspected body-diode conduction from Vpp to the 5V supply as the culprit (as this appears to be the design oops Frans refers to), but alas no change. On the other hand, I think the real issue is Q4: It's an N-MOSFET being used to switch the 12V supply and the only thing to generate Vgs is the drop across the MOSFET itself. The BS170 datasheet calls for a Vth anywhere from 0.8V minimum to 3V max, with 2.1V typical. As such, depending on the device tolerances, the ~1.25V drop between the pump and the Zener shunt isn't enough to drive the MOSFET into good conduction. Moreover, the problem is exacerbated with R1 being ahead of the pull-up for Q4, so as the Vpp current increases (via the shunt or the load), Vgs drops even more. The result significantly limits the current on Vpp. I may have *completely* misread the circuit and I'm a bit rusty on my analog electronics (had to pull out the old text books), but this appears to be what's happening. The fix would be to use a P-MOSFET in place of Q4 (source towards the pump, drain towards the Zener), with the rest of the circuit remaining unchanged (though D4 could also be removed). VPP_CTL would change from being active low to active high. The P-MOSFET won't conduct so long as the gate is held towards the source, but will conduct quite well when Q1 pulls the gate down to ground (Vgs=-13-14V, which will be too much for the TM2301. Fix with a different MOSFET or an extra resistor to make a voltage divider on the gate.) Thoughts? Of course, another, less elegant fix is to bypass Q4 altogether and use Q1 to short out the 12V when not in use. This will cost about 6mA in draw, but won't require any other circuit changes. If I have time later, I might try it. Nothing like doing some hotwired SMT soldering! David On Sun, Jan 09, 2011 at 12:03:45PM -0500, David wrote: > > Hello everyone! > > I'm trying to troubleshoot a low Vpp on my usbpicprog v0.3 hardware. I'm > only getting about ~10.78V with no load attached. USB supply voltage is > 4.98V. > > I'm getting a solid 13.25V on the pump side of R1, with only a 0.17V drop > across it, confirming little load. However, by the time I get to the Vpp > header, I'm showing only 10.79V. The anode of D4 is also low at 11.27V. > > Unfortunately, the board I have (SMT version, pre-assembled) doesn't exactly > match any of the schematics. I have what appears to be a Q5, and R13 is not > assembled (which is what the v0.3.1 hardware calls for), yet I still have > the 47k and 100k R16/R15 voltage divider on the Vpp sense (v0.3 design). I > also have no D10. So, thus far, until I trace Q5, I'm a bit of a loss to > troubleshoot further. > > FWIW, my Vpp may have always been low -- I recall having some issues reading > a device a while back, but I moved the interface to a powered hub and all > was well. I didn't investigate further. Now I'm on a powered hub and I'm > unable to get a PIC10F206 to respond, which I'm assuming is because Vpp is > well below spec for program mode entry. > > Any thoughts? > > Thanks! > > David > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: David <dev...@fo...> - 2011-01-09 17:21:48
|
Hello everyone! I'm trying to troubleshoot a low Vpp on my usbpicprog v0.3 hardware. I'm only getting about ~10.78V with no load attached. USB supply voltage is 4.98V. I'm getting a solid 13.25V on the pump side of R1, with only a 0.17V drop across it, confirming little load. However, by the time I get to the Vpp header, I'm showing only 10.79V. The anode of D4 is also low at 11.27V. Unfortunately, the board I have (SMT version, pre-assembled) doesn't exactly match any of the schematics. I have what appears to be a Q5, and R13 is not assembled (which is what the v0.3.1 hardware calls for), yet I still have the 47k and 100k R16/R15 voltage divider on the Vpp sense (v0.3 design). I also have no D10. So, thus far, until I trace Q5, I'm a bit of a loss to troubleshoot further. FWIW, my Vpp may have always been low -- I recall having some issues reading a device a while back, but I moved the interface to a powered hub and all was well. I didn't investigate further. Now I'm on a powered hub and I'm unable to get a PIC10F206 to respond, which I'm assuming is because Vpp is well below spec for program mode entry. Any thoughts? Thanks! David |
|
From: Frans S. <fra...@gm...> - 2011-01-02 21:04:46
|
On 01/01/2011 03:31 AM, Jasper Wallace wrote: > On Mon, 20 Dec 2010, Frans Schreuder wrote: > >> Dear Jasper Wallace, >> >> I have been checking the firmware, and the only difference between 0.4.1 >> and 0.4.0 concerning autodetection of pic16F devices is that >> autodetection now occurs with VPP before VDD. I have uploaded a >> (possible) fix to launchpad, revision 978. r978 is now building on >> launchpad, you could check >> https://launchpad.net/~fransschreuder1/+archive/usbpicprog-devel for it >> to become ready. >> Could you try the usbpicprog-devel PPA and see if this fixes the problem >> for you (with firmware 0.4.1 of course)? > Hi, > > with the usbpicproc from the -devel ppa and firmware 0.4.1 autodetection > works with the pic 16f88. > > Thanks, and happy new year. Hi Jasper, That's great news! There is another bug that I have to fix, and when that has been fixed I will release 0.4.2-beta Happy new year! |
|
From: Jasper W. <ja...@po...> - 2011-01-01 02:31:20
|
On Mon, 20 Dec 2010, Frans Schreuder wrote: > Dear Jasper Wallace, > > I have been checking the firmware, and the only difference between 0.4.1 > and 0.4.0 concerning autodetection of pic16F devices is that > autodetection now occurs with VPP before VDD. I have uploaded a > (possible) fix to launchpad, revision 978. r978 is now building on > launchpad, you could check > https://launchpad.net/~fransschreuder1/+archive/usbpicprog-devel for it > to become ready. > Could you try the usbpicprog-devel PPA and see if this fixes the problem > for you (with firmware 0.4.1 of course)? Hi, with the usbpicproc from the -devel ppa and firmware 0.4.1 autodetection works with the pic 16f88. Thanks, and happy new year. -- [http://pointless.net/] [0x2ECA0975] |
|
From: Frans S. <fra...@gm...> - 2010-12-20 18:40:14
|
Dear Jasper Wallace, I have been checking the firmware, and the only difference between 0.4.1 and 0.4.0 concerning autodetection of pic16F devices is that autodetection now occurs with VPP before VDD. I have uploaded a (possible) fix to launchpad, revision 978. r978 is now building on launchpad, you could check https://launchpad.net/~fransschreuder1/+archive/usbpicprog-devel for it to become ready. Could you try the usbpicprog-devel PPA and see if this fixes the problem for you (with firmware 0.4.1 of course)? Thank you for your report. Kind regards, Frans Schreuder On 12/20/2010 07:16 PM, Jasper Wallace wrote: > On Mon, 20 Dec 2010, Frans Schreuder wrote: > >> Dear Jasper Wallace, >> >> Have you tried firmware 0.4.0 with software 0.4.1? If that is true, I >> can rule out the software for bug tracking. >> I was getting a similar message about the 16F87XA. It doesn't >> autodetect, but reading / writing is fine. The funny thing is that the >> autodetection method is just the same as reading the code memory. > I'm using 0.4.1 (I've got the fransschreuder1/usbpicprog-stable ppa setup > on ubuntu). > >> About the 16F1827, it will be possible, but a Zener diode of 8V or 9V >> will be necessary on the target board, >> For the LF versions, also a 3.3V regulator will be needed. > ok, thats good news. > |
|
From: Jasper W. <ja...@po...> - 2010-12-20 18:16:38
|
On Mon, 20 Dec 2010, Frans Schreuder wrote: > Dear Jasper Wallace, > > Have you tried firmware 0.4.0 with software 0.4.1? If that is true, I > can rule out the software for bug tracking. > I was getting a similar message about the 16F87XA. It doesn't > autodetect, but reading / writing is fine. The funny thing is that the > autodetection method is just the same as reading the code memory. I'm using 0.4.1 (I've got the fransschreuder1/usbpicprog-stable ppa setup on ubuntu). > About the 16F1827, it will be possible, but a Zener diode of 8V or 9V > will be necessary on the target board, > For the LF versions, also a 3.3V regulator will be needed. ok, thats good news. -- [http://pointless.net/] [0x2ECA0975] |
|
From: Frans S. <fra...@gm...> - 2010-12-20 17:56:31
|
Dear Jasper Wallace, Have you tried firmware 0.4.0 with software 0.4.1? If that is true, I can rule out the software for bug tracking. I was getting a similar message about the 16F87XA. It doesn't autodetect, but reading / writing is fine. The funny thing is that the autodetection method is just the same as reading the code memory. About the 16F1827, it will be possible, but a Zener diode of 8V or 9V will be necessary on the target board, For the LF versions, also a 3.3V regulator will be needed. Kind regards, Frans Schreuder On 12/20/2010 04:57 PM, Jasper Wallace wrote: > Hi, > > Firmware 0.4.0 autodetects pic16f88's fine, but 0.4.1 dosn't. > > P.S. would it be possible to program PIC16F1827 with a usbpicprog (with > firmware changes)? They seem to need a VPP of 9V max, see: > > http://ww1.microchip.com/downloads/en/DeviceDoc/41390C.pdf > > alternativly can the upp do Low voltage programming? > |
|
From: Jasper W. <ja...@po...> - 2010-12-20 16:35:27
|
Hi, Firmware 0.4.0 autodetects pic16f88's fine, but 0.4.1 dosn't. P.S. would it be possible to program PIC16F1827 with a usbpicprog (with firmware changes)? They seem to need a VPP of 9V max, see: http://ww1.microchip.com/downloads/en/DeviceDoc/41390C.pdf alternativly can the upp do Low voltage programming? -- [http://pointless.net/] [0x2ECA0975] |
|
From: Adly A. <ad...@ge...> - 2010-12-10 15:46:18
|
It's every 0x18 bytes. I jury rigged the programming setup on a breadboard that I'm now using for another project. So I'm not inclined to tear that down to do the file write/read test to see the difference between the hex files. I know I have a spare breadboard here somewhere. I'll see what I can do over the weekend. thank you -- Adly Oh, BTW, the link to the Ubuntu installer script on the usbpicprog main site is broken. I found the script by browsing sourceforge. Thought you should know. On 12/10/2010 04:37 PM, Frans Schreuder wrote: > Dear Adly Abdullah, > > I am sorry that you experience problems with usbpicprog. > I don't think the actual problem here is reading the firmware, there > must be a problem while writing since writing is a protocol that occurs > with 4 bytes at a time for this PIC. > I guess you are using the latest version (0.4.1) of the software / > firmware since you have recently purchased it. > Could you tell me if the problem occurs every 4 bytes, or only every > 0x18 bytes? That is very important for me to know, because it tells me > where to look. > It would also help if you send me the hex file you are trying to > program, and also the saved hex file which you have read back from the > 16F73. > > I have never heard of any problems with the 16F73, but I guess this is > not a very popular device that many people have been using. > I will for now put an X on writing program memory in the supported > devices section of usbpicprog. > > Kind regards, > > Frans Schreuder > > On 12/09/2010 04:46 PM, Adly Abdullah wrote: > >> This is an issue with PIC16F73 >> >> I'm not sure if the issue is simply with reading the memory or if it is >> with programming the PIC but whatever I program into the PIC gets an >> offset of 4 bytes when read back. For example, say I'm trying to program >> "8A 11 11 28 ..." it fails verification and when I try to read it back I >> get "FF 3F FF 3F 8A 11 11 28 ...". >> >> Actually, the entire left column is shifted by 4 bytes (which is why I >> suspect it may simply be a bug in reading the chip) as in it shifts >> everything at 0x000000 by 4 bytes and everything at 0x001800 by 4 bytes >> and everything at 0x003000 etc.. >> >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >> > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
|
From: Frans S. <fra...@gm...> - 2010-12-10 08:38:23
|
Dear Adly Abdullah, I am sorry that you experience problems with usbpicprog. I don't think the actual problem here is reading the firmware, there must be a problem while writing since writing is a protocol that occurs with 4 bytes at a time for this PIC. I guess you are using the latest version (0.4.1) of the software / firmware since you have recently purchased it. Could you tell me if the problem occurs every 4 bytes, or only every 0x18 bytes? That is very important for me to know, because it tells me where to look. It would also help if you send me the hex file you are trying to program, and also the saved hex file which you have read back from the 16F73. I have never heard of any problems with the 16F73, but I guess this is not a very popular device that many people have been using. I will for now put an X on writing program memory in the supported devices section of usbpicprog. Kind regards, Frans Schreuder On 12/09/2010 04:46 PM, Adly Abdullah wrote: > This is an issue with PIC16F73 > > I'm not sure if the issue is simply with reading the memory or if it is > with programming the PIC but whatever I program into the PIC gets an > offset of 4 bytes when read back. For example, say I'm trying to program > "8A 11 11 28 ..." it fails verification and when I try to read it back I > get "FF 3F FF 3F 8A 11 11 28 ...". > > Actually, the entire left column is shifted by 4 bytes (which is why I > suspect it may simply be a bug in reading the chip) as in it shifts > everything at 0x000000 by 4 bytes and everything at 0x001800 by 4 bytes > and everything at 0x003000 etc.. > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: Adly A. <ad...@ge...> - 2010-12-09 15:46:28
|
This is an issue with PIC16F73 I'm not sure if the issue is simply with reading the memory or if it is with programming the PIC but whatever I program into the PIC gets an offset of 4 bytes when read back. For example, say I'm trying to program "8A 11 11 28 ..." it fails verification and when I try to read it back I get "FF 3F FF 3F 8A 11 11 28 ...". Actually, the entire left column is shifted by 4 bytes (which is why I suspect it may simply be a bug in reading the chip) as in it shifts everything at 0x000000 by 4 bytes and everything at 0x001800 by 4 bytes and everything at 0x003000 etc.. |
|
From: Frans S. <fra...@gm...> - 2010-11-04 07:37:44
|
Hoi René, If you are really looking for osx / cocoa code, this is handled by wxWidgets. I am using this library to handle operating system specific things. Regards, Frans On 11/03/2010 07:57 PM, Frans Schreuder wrote: > Dear René, > > There is no different code for osx / cocoa. There are some os specific > #ifdef lines in the code, but that's all. > > Regards, > > Frans > > On 11/03/2010 07:50 PM, René v Amerongen wrote: >> Hoi Frans >> >> Of course I understand that UsbPicProg is open source and I have that code. But I cant find the cocoa code for the macosx app. >> >> Thank you >> >> René >> >> Op 3 nov 2010, om 15:42 heeft Frans Schreuder het volgende geschreven: >> >>> Dear René v Amerongen, >>> >>> The CLI for osx is somewhat difficult to access, since the binary is >>> inside an .app package. >> I know how to connect to the cli and I did found this already. >> >>> If you realize that the .app is just a directory, you can access it and >>> find the executable in usbpicprog.app/Contents/MacOS >>> if you type: >>> >>> export PATH=$PATH:/Applications/usbpicprog.app/Contents/MacOS/ >>> >>> You can access the cli by typing e.g.: >>> >>> usbpicprog -h >>> >>> Kind regards, >>> >>> Frans Schreuder >>> >>> On 11/03/2010 01:15 PM, René v Amerongen wrote: >>>> Hello, I could only find binaries, but is the tool also open source? >>>> Is the source available? >>>> >>>> Also if I understands well, the tool is connecting with the cli program to do its thing ( programming reading etc ). Plus it got a library to the device info? >>>> >>>> Greetz >>>> >>>> RvA >>>> ------------------------------------------------------------------------------ >>>> Achieve Improved Network Security with IP and DNS Reputation. >>>> Defend against bad network traffic, including botnets, malware, >>>> phishing sites, and compromised hosts - saving your company time, >>>> money, and embarrassment. Learn More! >>>> http://p.sf.net/sfu/hpdev2dev-nov >>>> _______________________________________________ >>>> Usbpicprog-technical mailing list >>>> Usb...@li... >>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >>> ------------------------------------------------------------------------------ >>> Achieve Improved Network Security with IP and DNS Reputation. >>> Defend against bad network traffic, including botnets, malware, >>> phishing sites, and compromised hosts - saving your company time, >>> money, and embarrassment. Learn More! >>> http://p.sf.net/sfu/hpdev2dev-nov_______________________________________________ >>> Usbpicprog-technical mailing list >>> Usb...@li... >>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >> ------------------------------------------------------------------------------ >> Achieve Improved Network Security with IP and DNS Reputation. >> Defend against bad network traffic, including botnets, malware, >> phishing sites, and compromised hosts - saving your company time, >> money, and embarrassment. Learn More! >> http://p.sf.net/sfu/hpdev2dev-nov >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: Frans S. <fra...@gm...> - 2010-11-03 18:58:07
|
Dear René, There is no different code for osx / cocoa. There are some os specific #ifdef lines in the code, but that's all. Regards, Frans On 11/03/2010 07:50 PM, René v Amerongen wrote: > Hoi Frans > > Of course I understand that UsbPicProg is open source and I have that code. But I cant find the cocoa code for the macosx app. > > Thank you > > René > > Op 3 nov 2010, om 15:42 heeft Frans Schreuder het volgende geschreven: > >> Dear René v Amerongen, >> >> The CLI for osx is somewhat difficult to access, since the binary is >> inside an .app package. > I know how to connect to the cli and I did found this already. > >> If you realize that the .app is just a directory, you can access it and >> find the executable in usbpicprog.app/Contents/MacOS >> if you type: >> >> export PATH=$PATH:/Applications/usbpicprog.app/Contents/MacOS/ >> >> You can access the cli by typing e.g.: >> >> usbpicprog -h >> >> Kind regards, >> >> Frans Schreuder >> >> On 11/03/2010 01:15 PM, René v Amerongen wrote: >>> Hello, I could only find binaries, but is the tool also open source? >>> Is the source available? >>> >>> Also if I understands well, the tool is connecting with the cli program to do its thing ( programming reading etc ). Plus it got a library to the device info? >>> >>> Greetz >>> >>> RvA >>> ------------------------------------------------------------------------------ >>> Achieve Improved Network Security with IP and DNS Reputation. >>> Defend against bad network traffic, including botnets, malware, >>> phishing sites, and compromised hosts - saving your company time, >>> money, and embarrassment. Learn More! >>> http://p.sf.net/sfu/hpdev2dev-nov >>> _______________________________________________ >>> Usbpicprog-technical mailing list >>> Usb...@li... >>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical >> >> ------------------------------------------------------------------------------ >> Achieve Improved Network Security with IP and DNS Reputation. >> Defend against bad network traffic, including botnets, malware, >> phishing sites, and compromised hosts - saving your company time, >> money, and embarrassment. Learn More! >> http://p.sf.net/sfu/hpdev2dev-nov_______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > ------------------------------------------------------------------------------ > Achieve Improved Network Security with IP and DNS Reputation. > Defend against bad network traffic, including botnets, malware, > phishing sites, and compromised hosts - saving your company time, > money, and embarrassment. Learn More! > http://p.sf.net/sfu/hpdev2dev-nov > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
|
From: René v A. <app...@xs...> - 2010-11-03 18:50:42
|
Hoi Frans Of course I understand that UsbPicProg is open source and I have that code. But I cant find the cocoa code for the macosx app. Thank you René Op 3 nov 2010, om 15:42 heeft Frans Schreuder het volgende geschreven: > Dear René v Amerongen, > > The CLI for osx is somewhat difficult to access, since the binary is > inside an .app package. I know how to connect to the cli and I did found this already. > If you realize that the .app is just a directory, you can access it and > find the executable in usbpicprog.app/Contents/MacOS > if you type: > > export PATH=$PATH:/Applications/usbpicprog.app/Contents/MacOS/ > > You can access the cli by typing e.g.: > > usbpicprog -h > > Kind regards, > > Frans Schreuder > > On 11/03/2010 01:15 PM, René v Amerongen wrote: >> Hello, I could only find binaries, but is the tool also open source? >> Is the source available? >> >> Also if I understands well, the tool is connecting with the cli program to do its thing ( programming reading etc ). Plus it got a library to the device info? >> >> Greetz >> >> RvA >> ------------------------------------------------------------------------------ >> Achieve Improved Network Security with IP and DNS Reputation. >> Defend against bad network traffic, including botnets, malware, >> phishing sites, and compromised hosts - saving your company time, >> money, and embarrassment. Learn More! >> http://p.sf.net/sfu/hpdev2dev-nov >> _______________________________________________ >> Usbpicprog-technical mailing list >> Usb...@li... >> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > > > ------------------------------------------------------------------------------ > Achieve Improved Network Security with IP and DNS Reputation. > Defend against bad network traffic, including botnets, malware, > phishing sites, and compromised hosts - saving your company time, > money, and embarrassment. Learn More! > http://p.sf.net/sfu/hpdev2dev-nov_______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical |
6 messages has been excluded from this view by a project administrator.
