1. Home
  2. Embedded Programming
  3. Vdd control with a serial port PIC programmer

Vdd control with a serial port PIC programmer

I am building a serial port programmer for low end PICs (specifically for the 16F84 and 16F628).

I notice in the PIC programming spec that Vdd is supposed to be controlled - i.e.brought up to +5 AFTER /MCLR is brought up to

+13v in order to prevent the PIC from executing code while it is being brought into programmng mode. The critical time would be during the /MCLR transition from +5 to +13v. I realize this requirement is most critical when the PIC is not crystal controlled; however, the 16F628 may be run in RC mode so this could qualify as a problem PIC.

Since the RS232 port has only has 3 pins available for output (DTR, RTS and TX) and all three are required for Data, Clock, and VPP (/MCLR) control, it seems that most serial mode programmers simply ignore this requirement to control Vdd. Parallel port programmers often do it properly.

Is this OK? Are serial port programmers more problematic than parallel port programmers for a wide range of PIC types?

Thanks.

-Craig

Reply to
Craig Johnson
Loading thread data ...

How does that limit the functionality of a PIC programmer that uses the serial port? The programmers that I know of all use embedded controllers (usually PICs) to control the programming process, and the serial port just happens to be how they communicate with the host. Controlling the pins of a part to be programmed is the responsibility of the embedded controller, and it can certainly sequence things properly, regardless of the means used to communicate with the host.

-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Reply to
Robert Scott

Robert,

That's not the kind of programmer I am talking about. I am talking about the simple bit-toggling programmers, such as this one by J Aichinger:

formatting link

I would like to drive it with David Tait's FPP program. See

formatting link

As you can see, all the "smarts" are in the Windows software driving the COM port. There are no embedded controllers.

-Craig

Reply to
Craig Johnson

OK, I see now. But that still leaves open the possiblity of some logic on the programmer that can decode the state of the Vdd separately, and allow the kind of sequencing you were talking about. I don't think we have to assume that each RS-232 control line goes to just one pin on the device.

-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Reply to
Robert Scott

Robert,

Yes, it is possible to add additional logic to the programmer. Maybe the Vdd application could be delayed from the time when the MCLR signal is received on the TD pin. That would take minimal circuitry. Another possibility would be to send a special command (via the DTR line, clocked by the RTS line) which gets decoded by the programmer and triggers the application of Vdd. Possible, I guess, but would take more logic gates.

My point is that it is not possible to control the Vdd line directly. There just aren't enough output pins in RS232. I am trying to determine if this is a problem or not.

-Craig

Reply to
Craig Johnson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.