On 7/1/05, WH Tan <spam_OUTwhsiungTakeThisOuTtm.net.my> wrote:
> Hello,
>
> I recall vaguely that someone has written about replacing the PICKit1
> controller with a PIC18F USB controller. Anyway I can't remember any
> result mentioned here.
>
> Has anyone done it?
>
> I'm on my way doing this and I believe I'm just a step away from
> completing it. I would like to discuss with anyone who did/do the
> same.
>
WH,
Isn't the pinout different?
I notice the ship date for the Pickit 2 on buy.microchip.com is August
12. Part #DV164120
The Pickit 2 will already come with a full-speed USB device. I think
this means a flash part... I'm still waiting to see if MC releases
firmware source for the programmer chip like they did for Pickit 1.
PicKit 2 supports 8,14, and 20 pin parts.
I guess I should order one this weekend and get started on Linux
support for it. However, estimated arrival date for my first child is
August 3, so I may not have much free time when it comes!
Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie
Hello Mark,
I didn't notice about PICkit2. I was talking about transforming
PICkit1 into using PIC18F part. Anyway I took a look at Microchip
site. Didn't find any documents describing it. The only information I
got is some description on buy.microchip.
> Isn't the pinout different?
If you mean the basic pin functions, I think it's same. But of course
PIC18 parts have more functions built into it. For example ICD2
debugging support, which PIC16C745 don't have.
If you mean the design comparison of PICkit1 and PICkit2, yes, I'm not
surprised as PIC18F are far superior than PIC16C! Actually I didn't
own a real PICKit1. I built mine on a matrix board. Through the
building process, I have decided to change some pinouts. Namely I used
RB7, RB6 for ICD2 but PICkit1 uses it for some other purposes.
> I notice the ship date for the Pickit 2 on buy.microchip.com is
> August
> 12. Part #DV164120
Yup, If I never done this, perhaps I would consider it :)
> The Pickit 2 will already come with a full-speed USB device. I
> think
> this means a flash part... I'm still waiting to see if MC releases
> firmware source for the programmer chip like they did for Pickit 1.
Yes I think it's a flash part. And time will tell if they're going to
release the source! :)
> I guess I should order one this weekend and get started on Linux
> support for it. However, estimated arrival date for my first child
> is
> August 3, so I may not have much free time when it comes!
Congratulations Mark. And happy birthday to him/her!
Great to heat that. Now it is finally out. I heard this
one a year ago on the Microchip Forum (not formally named
as PICKit 2 then). I will try to get one as soon as possible.
----------------------------------------------
Xiaofan Chen
R&D Engineer, Photoelectric Sensor Development
Pepperl+Fuchs Singapore http://www.pepperl-fuchs.com
Signals for the world of automation
--------------------------------------------
I think no one has done it even though I raised this proposition
quite some time ago. I think it is a worthy effort even though
PICKit 2 is on the horizon. I will be very much interested in your
design.
1) ASM would be better. C18 is not cheap and the student version
has some limitations. However since you have done it in C18,
it may be not necessary to port it to ASM if there is too much
effort involved.
2) PID control: again ASM and you have done it already, right?
3) ICSP: again ASM. It is the common language for the PIClisters. :)
Actually I do not see many discussion for C (including C18) here.
I have some more suggestions.
1) Is it possible to implement Olin's protocol? The tricky part
is that Olin's host program will not work since this one is based
on USB.
2) Have you written the host program? It would be wonderful
if it is written in a cross platform language like c or python.
3) PICkit 1 is using a 6MHz ceramic oscillator and you need to
use 4Mhz oscillators (or 8Mhz, etc) for the 18F USB parts. Anyway
since you do not really own a PICKit 1, it does not matter.
Regards,
Xiaofan
----------------------------------------------
Xiaofan Chen
R&D Engineer, Photoelectric Sensor Development
Pepperl+Fuchs Singapore http://www.pepperl-fuchs.com
Signals for the world of automation
--------------------------------------------
> I think no one has done it even though I raised this proposition
> quite some time ago. I think it is a worthy effort even though
> PICKit 2 is on the horizon. I will be very much interested in your
> design.
>
> 1) ASM would be better. C18 is not cheap and the student version
> has some limitations. However since you have done it in C18,
> it may be not necessary to port it to ASM if there is too much
> effort involved.
> 2) PID control: again ASM and you have done it already, right?
> 3) ICSP: again ASM. It is the common language for the PIClisters. :)
> Actually I do not see many discussion for C (including C18) here.
>
> I have some more suggestions.
> 1) Is it possible to implement Olin's protocol? The tricky part
> is that Olin's host program will not work since this one is based
> on USB.
> 2) Have you written the host program? It would be wonderful
> if it is written in a cross platform language like c or python.
> 3) PICkit 1 is using a 6MHz ceramic oscillator and you need to
> use 4Mhz oscillators (or 8Mhz, etc) for the 18F USB parts. Anyway
> since you do not really own a PICKit 1, it does not matter.
>
>
> Regards,
> Xiaofan
I think the attraction of the Pickit is that it is "plug-and-play".
If you already have another programmer to program the 18F2550 etc.,
then maybe you aren't as interested in the PicKit 1.
I am hoping the PIckit 2 will be self-programmable or at least capable
of programming the full speed USB parts. Then the beginner can get
enhanced functionality with a software upgrade.
Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie
It is plug-n-play and it is "cheap". It is also quite
easy to build as well but one will need an ICD2 or similar
to bootstrap the 18F2550. Actually for the chips it supports,
I would prefer PICkit as a programmer than a ICD2.
I strongly believe that PICKit 2 will be upgradeable through
the USB bootloader. I would hope that they will release the
firmware and host software source as soon as the product becomes
available. I am quite sure that they will do this but I am
not so sure how fast they will do it.
The release of PICkit 2 will also confirm that new 16F (which
will be the low end chip after they reduce the price of 18F and
release 24Fxxx 16-bit chips) will be mostly 8/14/20 pins.
The release of PICkit 2 will also confirm that new 16F (which
will be the low end chip after they reduce the price of 18F and
release 24Fxxx 16-bit chips) will be mostly 8/14/20 pins.
On Mon, 2005-07-04 at 22:50 -0400, Charles Craft wrote:
> Here's hoping that someone attending the MASTERs brings back the roadmap to the futures.
>
> 8 pin 16F? Fact, rumor or wishful thinking?
Already here. The 12F629 and 12F675 are actually 16F parts in 8 pin
packages. TTYL
At the Atmel seminar I almost asked if they used a dart board for part numbering.
Microchip can be almost as confusing but I tend to forget (forgive?) it.
There are 16F parts with 12 bit cores and 12F parts with 14 bit cores. %-)
The only absolute is 16 bit 18F parts and 18F parts only have 16 bit cores?
Hi,
After overnight of programming, at last the C18 USB framework, ASM PID
control, ASM ICSP protocol (decided when I was starting to look into
it last night) all seems to be integrated perfectly. I'm doing test
with PIC12F675 and the devide ID & configuration fuses seem to be read
correctly. For the time being, I'm using the VB program posted on
Microchip website and Jan Axelson HID testing program (VC++, with some
modification of course).
For the time being, I'm doing this for fun. Anyway I own a full
version C18. Yes the PID control is in ASM because not much porting
job involved. Porting PIC16 instructions to PIC18 directly is far more
simple than re-written it in C18! The parts that required much effort
is to make use of the hardware multiplier to replace the software
multiplier routines and rewritten some part to make use 'extra' PIC18
instructions.
Regarding your suggestion:
1) Yes surely I will have a look into this matter soon. I'm just a
beginner when come to ICSP! At the time I will stick with the protocol
used by PICKit 1. Surely if Microchip decided to release thier new
PICKit 2 source, which I think will be most likely to happen, then
that will provide extra option for me :)
2) Not yet. And I plan it in VC++.
3) Regarding the crystal. Yes not a problem for me. I use 20MHz.
> I think the attraction of the Pickit is that it is "plug-and-play".
> If you already have another programmer to program the 18F2550 etc.,
> then maybe you aren't as interested in the PicKit 1.
I have ICD2! Still I'm interested in PICKit 1. To me PICKit 1 is not
just a programmer. At least it's an USB tesing board. But the real
down side is that PICKit 1 use PIC16C part. With the PIC18F falsh
part, thing have change and that why I decided to build one.
> I am hoping the PIckit 2 will be self-programmable or at least
> capable
> of programming the full speed USB parts. Then the beginner can get
> enhanced functionality with a software upgrade.
I bet Microchip will put the USB bootloader into it. If they don't
still you can do it yourself! Not too difficult to implement if the
source are available . Anyway you have to figure out how you are going
to program the chip with a bootloader for the first time :)
Great to hear that you have done most of the job. Congratulations!
You own a full version of C18 for fun! That is not small
investment. :)
VC++ may be great for the Windows platform, but it will be not
cross-platform as Python and plain C.
By the way, will you release your code one it is ready?
----------------------------------------------
Xiaofan Chen
R&D Engineer, Photoelectric Sensor Development
Pepperl+Fuchs Singapore http://www.pepperl-fuchs.com
Signals for the world of automation
--------------------------------------------
Me too. I have ICD2 and yet I like the PICkit 1. But then I see
that very few people would like to work with OTP parts or
windowed EEPROM parts even though a lot of people here have the
technical expertise to extend the PICkit 1.
Now that PICKit 2 is on the horizon, more people will be willing to
hack it to do more. And you are definitely doing the pioneer work.
> By the way, will you release your code one it is ready?
Sure. But it will be slow... until its functions are all tested. But
if you want to see the code now, mail me offlist. I still have some
hardware issues to settle... the waveform looks correct on scope but
the PIC reads 0x3FCF instead of 0x3FFF... Still I confirm that's no
bug in the read routine. I think it has something to do with the level
of the waveform or overshot/undershot etc.
> Now that PICKit 2 is on the horizon, more people will be willing to
> hack it to do more.
We will see how the PICKit 2 design... As far as PICKit 1 hardware is
concerned, I see there is a problem if you want to extend its
capability. Namely the Vpp output from the charge pump circuit. I have
seen on my scope last night, it will raise to 12V then drop back in
curve to somewhere slightly lower than 10V before up again after the
PID makes the necessary correction. I think this happen because the
firmware prepare the Vpp to 12V in advance before turning on the Vpp
transistor. Anyway when it's loaded by the target PIC, a new
adjustment needed and it takes time for the PID to perform. This will
not be a problem for PIC12F675 as the Vpp range is Vdd+3.5V until
13.5V!
I like the bus-powered USB product! The design of PICKit 1 is great to
get 13.5V (and its level is controllable through the PID) out of the
5V from USB bus. Anyway if the PID controlled Vpp can't be improved, I
see there is a very limited device, which can be supported. Anyway I'm
not a hardware guru and am seeking for a solution...
> And you are definitely doing the pioneer work.
Well I don't think I am. I bet there must be someone out there doing
the same... :)
I think the boost converter (it is not a charge pump) can be
improved by the following ways.
1) Change R10 or R11 to a poti so that one can adjust the Vpp range.
Different PICs have different Vpp ranges.
2) C4 may not be good enough due to higher ESR and the PID control
is not fast enough so that you see the voltage drop. We can put big
ceramic capacitors in parallel to replace C4 (47u, 25V) but we need to
see if the supply stability is still there.
3) Over Voltage protection (like a zener) can be put after C4. Anyway
Vpp consumes very little current.
4) The PID loop may be able to be tuned. I have not looked into it yet.
1) I think this is unneccessary. The output voltage can be controlled by an
internal register (Target - implemented in VppCntrl.asm). The real problem
is the additional load that causes the momentary voltage drop. And I think
this is talking point. See my answers next.
2) Yes, I think this worth a shot. I will try some experiments.
3) Good point. When testing a new hardware + firmware, I think the target
PIC should get some protection against possible fault by the programmer :)
4) I think this is a valid point. I had been looking into this matter and
found that there should be some rooms for improvement. The PID output 7-bit
signed value. The set point for target Vpp is also a 7-bit value. Perhaps
increase the bit number will improve the settlement time for the Vpp to
reach its set point value (PID and hardware expert, please correct this if
i'm wrong). This should not cause too much overhead to the controller with
the hardware multiplier + it has double the speed of PIC16C745 + it has more
instructions to support more efficient coding. However I will try not to
increase the constant rate of the PID checking the feedback voltage. The
reason is that I think it is not so good if the PID taking too much of the
processor time. And the time that the PID's service is really needed is when
the load change is too much (example when turning on Vpp transistor, and
this is happening only several times during a programming cycle) and causing
a great error from the set point voltage. When the set point voltage has
been established and load change is almost none and the error is very small.
1 idea in my mind now is to implement variable frequency of the feedback
sampling. For example increase the frequency of sampling before turning on
Vpp transistor, then reduce it back to its original rate once the Vpp has
settled down. Anyway I haven't really look into it yet.
Another option for improvement of the PICkit 1 Vpp power generation
is to use a separate small SMPS like the one inside ICD2. I have
since measured the Vpp waveform of the ICD2 Vpp line and it is quite
nice (not like PICkit 1).
Based on a well circulated ICD2 clone circuit, the ICD2 Vpp generation
is a boost (step-up) converter based on an OnSemi MC34063 (quite cheap),
a 100uH inductor, a BAT85 (?) Schottky diode, a 47uF capacitor.
To smooth the output voltage, it has employed another 10uH inductor
and a 47uF capacitor. The feedback is a voltage divider consisting two
resistor and a digital poti. The digital poti can be simply replaced
by a analog poti if no automatic adjustment of Vpp is required.
I have opened the original ICD2 and find it to be similarly built
(or I should say the clone is following the original ICD2 design).
Another option is to use a 10F20x, just like the one used in Olin's
prototype board discussed sometime ago.
Quite interesting alternatives. My testing board was built on a matrix
board. Should not be a problem to add those suggestions to my
experiments later. Not my top priority at the moment. I am excited by
the progress so far. With a PIC12F675, it seems like performing well.
I have written data to program memory + EEROM data
and all read back correctly. My priority now is to keep playing with
the board and see if I could add some enhancement to the command sets.
For instance the command to change the Vpp...and perhaps looking into
the chance to improve the PID. Not really must get a result from the
latter. Just want to study a bit more about the PID.
By the way, in the MPLAB project that I sent to you, I used 'retfie
fast'. I was doing this to 'experience' how bad the silicon bug is
with C18. You should not use return fast and put back the context
saving code that I have commented out.
On 7/8/05, WH Tan <.....whsiungKILLspam.....tm.net.my> wrote:
> Finally the informations are posted there...
> www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805
>
Nice!
Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie
On 7/8/05, Mark Rages <EraseMEmarkragesspam_OUTTakeThisOuTgmail.com> wrote:
> On 7/8/05, WH Tan <whsiungspam_OUTtm.net.my> wrote:
> > Finally the informations are posted there...
> > www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805
> >
So, in summary:
- PIC18F2550 inside
- Bootloader upgradeable
- Schematics are given
- Firmware source is not given. Yuck!
- Programming is ICSP with optional daughterboard.
- Target can use USB power or other power. PICKit 2 includes FETs to
switch external power.
Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie
Hi Mark,
Had you read about the push button! The user's guide says it's for
triggering a function, which is not implemented currently.
My guess is 2 x 512kbit = 64kword of instructions! Perhaps for the
programmer to perform the programming without a host. Maybe just my on
side thinking because I plan to include one in my testing board for
the same purpose. Anyway I will connected an Atmel 4Mbit DataFalsh
(5V, a pretty old - now obsolete device).
> > Finally the informations are posted there...
>
> Interesting!
>
> Note the pushbutton (documented as 'currently no funtion') and the two
> 24LC512's. I can guess what they are for!
>
> Also note that the doc states 'able to program most flash chips', so it
> is aimed 'higher' than the Baseline Flash Programmer or the PicKit 1.
>
> But I see no price indication :(
>
It seems like the 'boost converter' design is almost the same as
PICKit 1. Then I wonder the firmware must be done some tweaking to
achive the 'acceptable' level of 'fluctuation' when a load is
connected, as if it is to 'support' most of the flash parts. I believe
my firmware output is the same as what the real PICKit 1 does. And
here is what happen when the Vpp transistor was turning on.
I was not really measuring the current. But the circuit is exactly the
same as PICKit 1 design. So it's driving
1) Before Vpp transistor driving the voltage divider resistors for the
feedback voltage. From calculation about 13/7.4k + a bit more into the
A/DC. So I think about 2mA.
2) A load resistor R22, after the Vpp transistor, about 13/10k = 1.3mA
3) The target PIC, which is PIC12F675. From the programming spec. , it
doesn't mention the value but the require high voltage is generated
internally. Vpp apply to MCLR is used as a level source and didn't
take much currect. I think neglect able.
I have an original PICkit 1 and I measure the waveform of the boost
converter output and the MCLR pin waveform. I think the design of
the original firmware is flawed or maybe it is the limitation
of the USB requirement.
If you measure the output of the boost converter. You will find that
It also has the dip you noticed on the Vpp/MCLR pin.
The dip is not because of the turn-on of Vpp (i.e. turn of Q3 and
Q4) or because of lousy regulation but because of the +13V itself.
The reason is that it is normally at 4.8V (Vusb minus some drop) since
Q2 is always off. Then when the host software issues a Read/Write command,
the boost converter starts to generate the 13V needed. Then you have
the settling time of the boost converter (overshoot and undershoot) and
thus the dip.
The correct way is to generate 13V constantly. The potential problem
is the slightly higher current consumption when there is no read/write
command. Another possible solution is to have longer delay time after
starting the PWM.
part 1 475 bytes content-type:text/plain;Attached please find the waveform captured after issuing a
read command for a 12F629. The scope is a Lecroy LT264.
Trace D is the zoom of channel 4 (Output of the boost converter
measured at positive terminal of C4 (47uF/25V).
Trace C is the zoom of channel 3 (Vpp/MCLR pin of 12F629).
It is quite clear that +13V is not constantly generated. I
have not measured ICD2. I guess that the +13V in ICD2 is
constantly generated (after USB enumeration).
Regards,
Xiaofan
part 2 14138 bytes content-type:image/gif; (decode) part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)
I think I can say that my waveform is very much the same as the real PICKit
1. I wonder you must be using the the latest firmware. Since you have looked
into the source. You should notice in v2.0.2, the VppOn, VppHigh etc have
been commented out. In my version I put it back. That was why it has a sharp
rise time to +13V. Also the second pulse should be longer as yours, anyway I
used a breakpoint and it has been came into effect. Also I have raised the
target voltage a bit.
At 10.12 2005.07.11 +0800, you wrote:
>Attached please find the waveform captured after issuing a
>read command for a 12F629. The scope is a Lecroy LT264.
>
>Trace D is the zoom of channel 4 (Output of the boost converter
>measured at positive terminal of C4 (47uF/25V).
>
>Trace C is the zoom of channel 3 (Vpp/MCLR pin of 12F629).
>
>It is quite clear that +13V is not constantly generated. I
>have not measured ICD2. I guess that the +13V in ICD2 is
>constantly generated (after USB enumeration).
>
>Regards,
>Xiaofan
>
>[ pickit1.gif ]
Hi,
if I may ask, what is your oscilloscope brand/model?
The brand is Lecroy. The model is Waverunner LT264.
It is 350MHz, 1GS/s, 4-ch and I think it quite expensive.
I liked my previous HP54600B but this one is much
better (but much more expensive). However I think
Lecroy has got some newer models already.
Regards,
Xiaofan
-----Original Message-----
From: Electron [TakeThisOuTelectron2k4EraseMEspam_OUTinfinito.it]
Sent: Monday, July 11, 2005 5:50 PM
To: Microcontroller discussion list - Public.
Subject: RE: [PIC] PICKIT 2 (was PICKit1 & PIC18F2550)
At 10.12 2005.07.11 +0800, you wrote:
>Attached please find the waveform captured after issuing a
>read command for a 12F629. The scope is a Lecroy LT264.
Hi,
if I may ask, what is your oscilloscope brand/model?
At 17.26 2005.07.11 +0800, you wrote:
>
>The brand is Lecroy. The model is Waverunner LT264.
>It is 350MHz, 1GS/s, 4-ch and I think it quite expensive.
>I liked my previous HP54600B but this one is much
>better (but much more expensive). However I think
>Lecroy has got some newer models already.
>Regards,
>Xiaofan
Thanks.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
I downloaded the user guide and schematics yesterday.
It is a pity that the firmware source code is not available.
Actually the programming protocol is not available either.
I am not so sure whether they will release the firmware
code any more after I see the potential capability of the
PICkit 2. Therefore WH Tan's work is still quite interesting
(to port PICkit 1 16C745 to 18F2550).
>From the schematics, the implementation of the Vpp power
is the same as PICkit 1. Not so sure if the firmware is
better. There are quite some circuitry added for the
target Vdd adjustment. The target Vdd seems to be able to
be adjusted from 5V downwards.
>From the host application, it is aiming quite high.
It now supports baseline and mid-range 12F and 16F. It
also has menu options for 18F, 18J (0.25um parts)
and dsPIC! However these options are not enabled now.
The 2 EEPROMs and the push-button are there. I think they
are for off-line programming.
Yes indeed. I was having the same feeling. It's a tool rather than testing
board as in PICKit 1. No firmware source for public this time around. I was
looking for the protocol used in PICKit 2 as well. Again it suggests that
Microchip has a difference policy for PICKit 2. And look at the PICKit 2
appearence, it really look like a tool rather than a testing board.
Hehe, the famous "From" problem from WH Tan's email system.
Look at the two ">" from the quoted email. Some people
got really frustrated by this bug in the GNUPIC list
while promoting open source. Looks like a Unix/Linux problem
or SendMail problem.
Yes it looks rather like a tool. But you can always open it and
throw away the case. :) Since the schematic is open, one can easily
build the PICkit 2 as well. Even without the schematic, it is
rather easy to reproduce the hardware since it is not so
complicated as ICD2 (lots of clone on the Web).
The "case" of the firmware is much more difficult to throw
away. :) I do not think one would like to reverse engineering
the firmware. But maybe the protocol can be reverse engineered.
LPLAB is doing that (to reverse engineering the ICD2 protocol).
Regards,
Xiaofan
-----Original Message-----
From: WH Tan
Sent: Thursday, July 14, 2005 11:56 AM
Hi,
Yes indeed. I was having the same feeling. It's a tool rather than testing
board as in PICKit 1. No firmware source for public this time around. I was
looking for the protocol used in PICKit 2 as well. Again it suggests that
Microchip has a difference policy for PICKit 2. And look at the PICKit 2
appearence, it really look like a tool rather than a testing board.
I am using version 2.02 firmware for the PICkit 1 but I do not
see that VppON and VppOff being commented out. Attached is the
firmware source code that I have.
Regards,
Xiaofan
Version 2.02 download from Microchip:
;***************************************************************************
***
; EnterProgramMode
; Issues Enter Program Mode command to PIC12F629/675. Clears ProgramCntr.
; Inputs: none
; Outputs: none
;***************************************************************************
***
EnterProgramMode
call VppInit ; Initiate Vpp PWM
call VppOff ; Turn Vpp off
call VppHigh ; Set Vpp to 13v (when it's turned on)
bcf PORTC,ICSPDATA ; make both clock and data outputs
bcf PORTC,ICSPCLOCK
bsf STATUS,RP0
bcf TRISC,ICSPDATA ; make both clock and data outputs
bcf TRISC,ICSPCLOCK
bcf STATUS,RP0
movlw 0x3F ; force clock and data pin low
andwf PORTC,f
call Delay2_5ms ; delay
call Delay2_5ms
Actually, My main priority with the PICKit 1 is to study some experiments.
First the USB HID class communication. It appears to me that the descriptors
used in PICKit 1 is very much differ from Microchip and Jan Axelson's
example. Now it's emulation proceeded suscessfully. MPLAB then can connect
to it and I had suscessfully 'write' something to PIC12F675.
The next thing is the PID and voltage control. Well again an interesting
subject to study. Until now I see that there are a lot of experiments
awating me. I can't do it now but until the end of next week, perhaps I will
have a chance to do something then. As the moment, it seems to me that some
tuning can be done to the PID multiplier factor (forget the symbol used here
without any reference in hand, I think something like Kp, Ki, Kd etc).
I think then 'reverse engineering' the PICKit 2 is not a priority for me. At
least the efforts required could be much more than to study/implement one
yourself. This is especially true as many resources are available for PICKit
1.
>> The target Vdd seems to be able to
>> be adjusted from 5V downwards.
>
> That seems a bit silly to me, the lowest guaranteed vltage from USB
> is
> iirc some 4.5V, who would want to adjust down from that?
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>
>
I see. I agree with you that it is better to enable the
boost converter PWM after the USB enumeration, i.e., to
un-comment the following three lines of codes.
; call VppInit ; Initiate Vpp PWM
; call VppOff ; Turn Vpp off
; call VppHigh ; Set Vpp to 13v (when it's turned on)
Regards,
Xiaofan
;***************************************************************
;Version 2.02
Main
movlw .30 ; delay 16 uS to wait for USB to reset
movwf W_save ; SIE before initializing registers
decfsz W_save,f ; W_save is merely a convienient register
goto $-1 ; to use for the delay counter.
...
pagesel InitUSB
call InitUSB ; Initialize USB communication.
tm.net.my> wrote:
