Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

pic programming help

Status
Not open for further replies.

williB

New Member
Hi all,
I am using the microchip pic 16F84A, well trying to..
I have connected it to the PC I/O channel bus, for programming purposes.
While it only took a few days to design and construct the circuit, it has been three weeks, yesterday,writing the software(pascal) to talk to the 16F84A.
My question is when giving certain programming commands to the pic , is it necessary to allways follow the six bit command with sixteen pulses on RB6?
The Increment Address command for example, has no associated " data " to add after it, but does it still need sixteen clock tics on RB6?
 

Nigel Goodwin

Super Moderator
Most Helpful Member
williB said:
Hi all,
I am using the microchip pic 16F84A, well trying to..
I have connected it to the PC I/O channel bus, for programming purposes.
While it only took a few days to design and construct the circuit, it has been three weeks, yesterday,writing the software(pascal) to talk to the 16F84A.
My question is when giving certain programming commands to the pic , is it necessary to allways follow the six bit command with sixteen pulses on RB6?
The Increment Address command for example, has no associated " data " to add after it, but does it still need sixteen clock tics on RB6?

The programming information is included in the programmign datasheet, you need to follow the (very unclear) instructions in that. But you do have to supply the full number of clock pulses, in order to clock the data in to the correct place.

I'm somewhat puzzled by your reference to "PC I/O channel bus", does this mean you are building a PIC programme ron an internal card?.

Also, it seems rather silly using the obselete 16F84 series, it was replaced by the cheaper, higher spec, 16F628 ages ago.
 

williB

New Member
Nigel Goodwin said:
williB said:
Hi all,
I am using the microchip pic 16F84A, well trying to..
I have connected it to the PC I/O channel bus, for programming purposes.
While it only took a few days to design and construct the circuit, it has been three weeks, yesterday,writing the software(pascal) to talk to the 16F84A.
My question is when giving certain programming commands to the pic , is it necessary to allways follow the six bit command with sixteen pulses on RB6?
The Increment Address command for example, has no associated " data " to add after it, but does it still need sixteen clock tics on RB6?

The programming information is included in the programmign datasheet, you need to follow the (very unclear) instructions in that. But you do have to supply the full number of clock pulses, in order to clock the data in to the correct place.

I'm somewhat puzzled by your reference to "PC I/O channel bus", does this mean you are building a PIC programmer on an internal card?.

Also, it seems rather silly using the obselete 16F84 series, it was replaced by the cheaper, higher spec, 16F628 ages ago.
Thanks for the quick responses :D
first off... i wish somone had told me of the 16F628 :x
to answer your question Yes i have built a circuit on a wire wrap card, or internal card...which plugs into the PC bus.
 

williB

New Member
this ISA wire wrap board is essential and a lot cheaper than the PCI bus version. $24.95 vs $75 although the one i use has a ground & +5V going around the perimeter this one will do fine. It is Jameco Part # 28206ca.

https://www.jameco.com/webapp/wcs/s...1&catalogId=10001&pa=28206CA&productId=116674

The programming information is included in the programmign datasheet, you need to follow the (very unclear) instructions in that. But you do have to supply the full number of clock pulses, in order to clock the data in to the correct place.
tell me about it ( very unclear) is an understatement..
have you seen their Memory Maps ? Absolutly laughable.. or cryable..
So i do need the clocks on the commands without the associated "data" ?
i apologize for the format of the command list (below) but it was hard to post the chart from the pdf.


Load Configuration [ X X 0 0 0 0] ( 0, data (14), 0)
Load Data for Program Memory [ X X 0 0 1 0] ( 0, data (14), 0)
Read Data from Program Memory [X X 0 1 0 0 ] ( 0, data (14), 0)
Increment Address [ X X 0 1 1 0]
Begin Erase Programming Cycle [ 0 0 1 0 0 0]
Begin Programming Only Cycle [0 1 1 0 0 0]
Load Data for Data Memory [X X 0 0 1 1 ] ( 0, data (14), 0)
Read Data from Data Memory [X X 0 1 0 1 ] ( 0, data (14), 0)
Bulk Erase Program Memory [X X 1 0 0 1]
Bulk Erase Data Memory [X X 1 0 1 1]


if you look at this pitiful "chart" the
increment address,
begin erase programming cycle,
begin programming only cycle,
bulk erase program memory &
bulk erase data memory , have no associated (start bit,.. 14 data bits,..stop bit)
 

Nigel Goodwin

Super Moderator
Most Helpful Member
WinPicprog uses two different procedures, one for commands and one for data, this is in Delphi which is essentially Pascal for Windows.

This is the command procedure:

Code:
Procedure Command(Cmd : Byte); {Send a progamming command to PIC}
Var
  x,
  BitPos : Byte;
Begin
   BitPos := 1;
   For x := 0 To 5 Do
   Begin
     IF (Cmd AND BitPos) = BitPos THEN
       ClockPulse(DHigh)
     ELSE
       ClockPulse(DLow);
     BitPos := BitPos Shl 1;
   End;
End;

And this is the data procedure:

Code:
Procedure OutWord(Data : Word);
Var
  x,
  BitPos : Word;
Begin
  ClockPulse(DLow);
  BitPos := 1;
  For x := 0 To 13 Do
  Begin
    IF (Data AND BitPos) = BitPos THEN
      ClockPulse(DHigh)
    ELSE
      ClockPulse(DLow);
    BitPos := BitPos Shl 1;
  End;
  ClockPulse(DLow);
End;

These are for chips like the 16F84 or 16F628, other chips require different routines.

However, I'm somewhat bemused by you making an internal programmer card - particularly using the obselete ISA bus (I don't even have a PC with an ISA slot anymore!). Programmers normally use the parallel or serial ports (parallel port prefered), or use a programmer with a built-in processor and transfer data to it via serial or USB.

There seems very little reason to build a more complicated internal programmer.
 

williB

New Member
Nigel Goodwin said:
However, I'm somewhat bemused by you making an internal programmer card - particularly using the obselete ISA bus (I don't even have a PC with an ISA slot anymore!). Programmers normally use the parallel or serial ports (parallel port prefered), or use a programmer with a built-in processor and transfer data to it via serial or USB.

There seems very little reason to build a more complicated internal programmer.
Well the isa wire wrap card is all i had to work with.and i also had an older M/board .It really wasnt hard at all..
i just wish it worked.. :?
 

Nigel Goodwin

Super Moderator
Most Helpful Member
TiagoSilva said:
Wy you still program in Pascal ??? It's a full mess :D !!!

Pascal is an extremely capable language, it gives the power of C with the ease of BASIC, and was the preferred teaching language for many years.

As a well structured language it's also easy to understand, something which C has never claimed to be 8)

It also has the huge advantage of being very fast to compile, a Turbo Pascal compiler is probably upwards of 10 times faster than similar C compilers (including Turbo C).
 

Exo

Active Member
TiagoSilva said:
Wy you still program in Pascal ??? It's a full mess :D !!!

I don't see what's a mess about it!...

I don't know Delphi supports OOP. If not then that's a huge disadvantage, escpecially in windows.
 

williB

New Member
can anyone see a problem with my circuit.
specifically the connection to RB7..
cuz when i try to read back just one line of code, i get back whatever RB7 was left at.
i've fixed the problem of leaving RB7 low, cuz with open collector outputs on the 7407 an active output ( transistor On) would sink RB7 low when it is trying to output data....
so after the command to read the data from RB7 i set RB7 high so it can sink or not the output..

but it isnt working ???
 

Nigel Goodwin

Super Moderator
Most Helpful Member
williB said:
can anyone see a problem with my circuit.
specifically the connection to RB7..
cuz when i try to read back just one line of code, i get back whatever RB7 was left at.
i've fixed the problem of leaving RB7 low, cuz with open collector outputs on the 7407 an active output ( transistor On) would sink RB7 low when it is trying to output data....
so after the command to read the data from RB7 i set RB7 high so it can sink or not the output..

but it isnt working ???

It doesn't look like a workable PIC programmer, you only have a single data connection (which is read from RB7), where are the writes to data and clock?, not to mention Vdd and Vpp.
 

williB

New Member
Nigel Goodwin said:
williB said:
can anyone see a problem with my circuit.
specifically the connection to RB7..
cuz when i try to read back just one line of code, i get back whatever RB7 was left at.
i've fixed the problem of leaving RB7 low, cuz with open collector outputs on the 7407 an active output ( transistor On) would sink RB7 low when it is trying to output data....
so after the command to read the data from RB7 i set RB7 high so it can sink or not the output..

but it isnt working ???

It doesn't look like a workable PIC programmer, you only have a single data connection (which is read from RB7), where are the writes to data and clock?, not to mention Vdd and Vpp.
A simple write to port[$378] accomplishes bringing MCLR To 14 V.
And a write to port[$379] brings MCLR Low.
similarly a write to port[$37C] brings RB6 high.
and a write to port[$37D] brings RB6 low.
Vdd & Vss were omitted for clarity
RB7 IN was the only one i needed the data bus for.
 

motion

New Member
williB said:
can anyone see a problem with my circuit.
specifically the connection to RB7..
cuz when i try to read back just one line of code, i get back whatever RB7 was left at.
i've fixed the problem of leaving RB7 low, cuz with open collector outputs on the 7407 an active output ( transistor On) would sink RB7 low when it is trying to output data....
so after the command to read the data from RB7 i set RB7 high so it can sink or not the output..

but it isnt working ???

Try replacing the 10K pull-ups to something faster like 1K-2K. You may be reading RB7 almost immediately after bringing the output of the 7407 buffer high.

In software, you may have to delay the reading of RB7 a few intructions after writing to port[37Bh].
 

williB

New Member
motion said:
williB said:
can anyone see a problem with my circuit.
specifically the connection to RB7..
cuz when i try to read back just one line of code, i get back whatever RB7 was left at.
i've fixed the problem of leaving RB7 low, cuz with open collector outputs on the 7407 an active output ( transistor On) would sink RB7 low when it is trying to output data....
so after the command to read the data from RB7 i set RB7 high so it can sink or not the output..

but it isnt working ???

Try replacing the 10K pull-ups to something faster like 1K-2K. You may be reading RB7 almost immediately after bringing the output of the 7407 buffer high.

In software, you may have to delay the reading of RB7 a few intructions after writing to port[37Bh].
Got the delay covered with this
for i := 0 to 6000000 do
begin
end;
i was surprised how fast it could count to six million.
i will try your suggestion., thanks.
 

Nigel Goodwin

Super Moderator
Most Helpful Member
williB said:
Got the delay covered with this
for i := 0 to 6000000 do
begin
end;
i was surprised how fast it could count to six million.
i will try your suggestion., thanks.

Obviously doing the delay in a simple software loop is completely processor speed dependent - so it's not very good practice.

As you mentioned Pascal (and the code above is Pascal), I'm presuming you're writing for DOS? - in which case the Delay() procedure gives a processor independent delay time with millisecond resolution.

As WilliB mentioned, you are likely to have problems with the speed of the pull-ups, which is another major reason not to build a PIC programmer on an I/O card. I'm presuming (again!) that you don't take your PC to pieces to plug the PIC in?, instead you're attempting to do ICSP (In Circuit Serial Programming) with a long wire from the PC to your target board?. This will cause huge problems, the wires from the 7407 to the PIC need to be REALLY! short - under an inch is good, with a couple of inches likely to prevent it working properly. The basic reason for this is the inability of the pull-up resistors to pull the line high fast enough, due to the capacitance of the wires. For ICSP you really need a more active drive than a pull-up resistor, something which can provide some current to overcome the capacitance.
 

williB

New Member
You have brought up some good points Nigel
i just checked the rise time of MCLR.
it rises to almost 12v in 10 uS or so..
Not good.
the Maximum rise time is 8 uS.So say the specs.
also the almost 12v kinda bothers me , it might be that the scope needs calibrating.
* back to the drawing board* :oops:
 

williB

New Member
oh, yes i am using DOS.
turbo pascal
open M/board (no case) on table :D
Tektronix 465 scope
i've calibrated it as best i could but still reading thirteen Or so volts when it should be 14 ??
I am going to shorten the connections between The FET and the MCLR input .
I'll let ya know what happens.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top