Searching \ for 'Writing data to PIC16F84 from PC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'Writing data to PIC16F84 from PC'.

Truncated match.
PICList Thread
'Writing data to PIC16F84 from PC'
1999\09\22@084148 by Glenn Pure

picon face
I'm seeking some help to solve a problem with a gadget I'm making.

This is a long and detailed question so don't bother now if you haven't got
15 minutes to spare.

First, here's what I'm doing...

1. I've built a 'controller' using a PIC16F84 to keep a real time clock and
switch relays on and off according to program information stored in the
PIC, in the 64 bytes of EEPROM data memory. This part is working fine

2. I need to update the program data in the EEPROM data memory from time to
time. This will be done through an interface with the parallel port on a
standard IBM PC running Windows 3.x or later.

I'm writing the PC Windows application with Borland C. I can read the
contents of my PIC EEPROM data memory without problem. I can also write
fresh data to this memory with my software, but the latter process is
unreliable. Sometimes it will write 64 bytes without a glitch, other times
it will stop writing after an unpredictable number of bytes (from 1 to
63!). I can't fathom why. About 50% of the write operations occur without
problem and the other 50% fail at some point.

I'll describe the logic behind the software in my PIC and the Windows
software with which it interacts in the hope someone might be able to give
me clues about why my writes are unreliable. I'm sure lots of other people
have done this sort of thing lots of other times before.

The PIC is triggered to enter read or write mode with the RB0/INT pin
(which is connected to D4 of the parallel port). As soon as the interupt is
detected, the remaining software routines for reading and writing operate
entirely on a 'polled' rather than interupt basis.

If a write to the PIC is to occur, I send RB6 on the PIC low (connected to
D0 of the parallel port). Next step is a 'handshake' so the PC can be
convinced it is connected to the controller. This handshake is simply 50
cycles of the following:

* the PC sends RB1 high (configured as an input on the PIC, of course). The
PIC loops for a few milliseconds waiting for this to happen
* once the PIC sees RB1 go high, it sends RB2 low (configured as an
output). The PC watches the relevant port pin to which RB2 is connected
until it sees this then it sends RB1 low.
* when the PIC sees RB1 go low, it sends RB2 high and the whole cycle
repeats again.

For added robustness, I make the PIC send out the two bytes "O" then "K"
serially on RB2 (using the read process I have written).

The above handshake appears to occur very reliably and errors are very rare.

I won't bother explaining the read process as this is occurring reliably
(it uses a variation on the handshake to clock data into the PC serially
from RB2 on the PIC).

The PC to PIC write process is also similar to the read except the data is
clocked serially from PC to PIC as follows:

* After the handshake process succeeds, the PIC is signalled to go into the
write routine as RB6 is sent low by the PC. After this, RB6 is ignored.

* Each byte is read in one at a time and written to the EEPROM memory in
the PIC straight after it is received. That is, a byte is received, then
written, then the next received then written (and so until until 64 bytes
received). The PIC will exit from this process if the routine for receiving
data from the PC times out while waiting for the correct signals from the
PC for receipt of bits (see below for details).

* As noted above, a byte is sent to the PIC serially and the following
loops eight times, once for each bit. First, the PIC sends RB2 high to
signal it is ready for a bit. The PC sends RB3 high when the output bit is
ready (the bit is output to RB1). Once the PIC sees RB3 go high, it
immediately sends RB2 low and then reads the bit. It then waits for RB3 to
go low before starting the loop again for the next bit. The PIC and the PIC
both loop for a set maximum amount of time (a few milliseconds) while
waiting for the next signal from one another. If either of these loops
times out, and error occurs and the routines are exited.

* Once the PIC has received a byte, it is written and the PIC signals the
write is completed by sends RA0 high (normally held low by the PC). The PC
loops for up to 20 milliseconds until it sees this. If the PC times out at
this point, the routine aborts.

Through diagnostics I have built into the software, I can determine that
the write failures are always occuring as a failure by the PIC to receive
the first bit after a write operation is completed. Specifically, the PC
fails to see RB2 go low.

I strongly suspect a timing problem but have not seen *any* improvement by
changing the length of time allowed for polling of signals. I can increase
this by 5 or ten fold and see no improvement in reliability.

I have tried lots of other things to try and solve this by adding software
debouncing of signals, changing the pins used for signalling (and months
worth of other things) without any improvement. I have just about given up
trying to solve this. In fact, I have copped out by simply changing the
software so I write until a byte fails, then pick up at this byte next
time. By repeating this up to five times, I can get the data written to the
PIC. But I hate fixes like this and would really like to know what I might
be doing wrong.


1999\09\23@035026 by Dubois Michel

First, sorry for my English......

I have se same kind of problem, using Visual Basic 3.
I found a partial explanation: my printer driver (a Canon LBP660) sends
something on the parallel port every minute.....
I disabled it from the WIN.INI

Glenn Pure a Žcrit :

{Quote hidden}

1999\09\23@035442 by Dr. Imre Bartfai


did you time the write operation to the PIC EEPROM? One must wait until
the writing is completed.


On Wed, 22 Sep 1999, Glenn Pure wrote:

{Quote hidden}

1999\09\23@045650 by John Bes

On woensdag 22 september 1999 13:25, Glenn Pure
[SMTP:spam_OUTGlenn.PureTakeThisOuTspamPCUG.ORG.AU] wrote:
> I'm seeking some help to solve a problem with a gadget I'm making.
> This is a long and detailed question so don't bother now if you haven't
> 15 minutes to spare.

I had a similar problem with the eeprom. It took me some time, but finally
found out that I was switching memory banks, but when a certain event
occured I didn't switch back. This resulted in me updating EEADR and EEDATA,
but in the wrong bank. It didn't hang, though it looked like it. What it was
doing was: repeatedly writing the previous EEDATA value to the previous
EEADR (it wasn't updated). It seemed the pic wasn't going anywhere, but it
just was repeating itself all the time.

Hope this helps,

1999\09\24@064326 by felix centeno

try with a second stop bit (or 2 stops bits), I had have some problems with
the serial port and this solve it

-----Mensaje original-----
De: Glenn Pure <.....Glenn.PureKILLspamspam@spam@PCUG.ORG.AU>
Para: fcentenospamKILLspamIAMNET.COM <.....fcentenoKILLspamspam.....IAMNET.COM>
Fecha: Miircoles, 22 de Septiembre de 1999 08:55 a.m.
Asunto: Writing data to PIC16F84 from PC

{Quote hidden}

{Quote hidden}

1999\09\24@081205 by Glenn Pure
picon face
Thanks. I don't think this is my problem as the error is random - but I'll
take a look. I still suspect a timing problem of some sort, possibly due to
Windows 95b (under which I am doing the testing) interupting the exchange
with the PIC. However, I haven't yet cracked where in my code to fix this
(if in fact it is the problem).


At 10:49 23/09/99 +0200, you wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...