> 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.
>
> Glenn

> 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.
>
> Glenn
>
>

>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

>
>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.
>
>Glenn

>On woensdag 22 september 1999 13:25, Glenn Pure
>[SMTP:EraseMEGlenn.Purespam_OUTTakeThisOuTPCUG.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
>got
>> 15 minutes to spare.
>>
>><SNIP>
>
>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,
>John
>
>