Post by thread:[PIC] Solved? (sorta) Pin sharing between clock an

I tracked it down to the clock that is the issue, as the I/O works fine on the shared port/bit (PortD-5). If anything, you would think that's the one that would have problems being that it's a switching I/O port. So, that just leaves the clock that works on PortB-0, but not on shared port D-6. Well, I tried changing the timing (adding NOPs) before and after reading the bit, and that made no difference. I am right at the 200 nS minimum bit available time spec, but that same code worked fine with the dedicated bit (PortB-0). I also made sure I cleared port D at the beginning of the clock subroutine just so I start with a known state. Then, I tried port D-0 (also shared), and it worked! That's odd because D-0 is also shared with the LCD display data. So, I tried D-5, and that worked. So, I moved the clock to D-7 and moved the I/O to D-6 since I wanted them to use consecutive port bits. And that works. FYI, the RST line is dedicated since it controls when the clock is accepting data input. So, the question is: Why does the clock signal not work on D-6, but it works on (seemingly) any other bit on the same port, and why does the I/O work on D-6? Yes, I made sure there was nothing other than the LCD and this clock chip using ports D5, 6, and 7. While this will work, I would like to understand what was wrong. Any ideas? Thanks, Joe M. Spehro Pefhany wrote: {Quote hidden}> At 12:11 AM 2/15/2010, you wrote: >> All I can tell you is that it works on separate pins. >> >> Are you thinking there is some capacitance in the LCD data input that is >> "holding" one of the data lines higher for an extra uS or so? > > No, that's quite unlikely. > >> But, it might be a good idea to "clear" that port every time the LCD is >> done reading rather than leave the pin in it's "previous state". > > Yes, clear it every time, and delay at least 1usec after clearing it > before bringing the CE high (assuming 5V supply). > >> Best regards, > > Spehro Pefhany --"it's the network..." "The Journey is the reward" > spam_OUTspeffTakeThisOuTinterlog.com Info for manufacturers: http://www.trexon.com > Embedded software/hardware/analog Info for designers: http://www.speff.com > > > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2688 - Release Date: 02/14/10 14:35:00 >

I should note that when I say "clock", I'm talking about the CLK signal, not the clock chip itself. Joe M. MCH wrote: {Quote hidden}> I tracked it down to the clock that is the issue, as the I/O works fine > on the shared port/bit (PortD-5). If anything, you would think that's > the one that would have problems being that it's a switching I/O port. > > So, that just leaves the clock that works on PortB-0, but not on shared > port D-6. > > Well, I tried changing the timing (adding NOPs) before and after reading > the bit, and that made no difference. I am right at the 200 nS minimum > bit available time spec, but that same code worked fine with the > dedicated bit (PortB-0). I also made sure I cleared port D at the > beginning of the clock subroutine just so I start with a known state. > > Then, I tried port D-0 (also shared), and it worked! That's odd because > D-0 is also shared with the LCD display data. So, I tried D-5, and that > worked. > > So, I moved the clock to D-7 and moved the I/O to D-6 since I wanted > them to use consecutive port bits. And that works. FYI, the RST line is > dedicated since it controls when the clock is accepting data input. > > So, the question is: Why does the clock signal not work on D-6, but it > works on (seemingly) any other bit on the same port, and why does the > I/O work on D-6? > > Yes, I made sure there was nothing other than the LCD and this clock > chip using ports D5, 6, and 7. > > While this will work, I would like to understand what was wrong. > Any ideas? > > Thanks, > Joe M. > > Spehro Pefhany wrote: >> At 12:11 AM 2/15/2010, you wrote: >>> All I can tell you is that it works on separate pins. >>> >>> Are you thinking there is some capacitance in the LCD data input that is >>> "holding" one of the data lines higher for an extra uS or so? >> No, that's quite unlikely. >> >>> But, it might be a good idea to "clear" that port every time the LCD is >>> done reading rather than leave the pin in it's "previous state". >> Yes, clear it every time, and delay at least 1usec after clearing it >> before bringing the CE high (assuming 5V supply). >> >>> Best regards, >> Spehro Pefhany --"it's the network..." "The Journey is the reward" >> .....speffKILLspam@spam@interlog.com Info for manufacturers: http://www.trexon.com >> Embedded software/hardware/analog Info for designers: http://www.speff.com >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 9.0.733 / Virus Database: 271.1.1/2688 - Release Date: 02/14/10 14:35:00 >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 9.0.733 / Virus Database: 271.1.1/2690 - Release Date: 02/15/10 14:35:00 >>