You have been quite thorough in you analysis of the problem. Chances are those that read your question didn't answer because they didn't have anything to add. It would appear that no one else has used the ccp module in the way you are using it, so asking if anyone else has experienced this will gether few replies. My own comment is that you should contact your microchip field applications engineer. If you don't have one, try contacting Microchip directly. As a future suggestion, shorter messages seem to gather more responses than longer detailed ones. You might have asked for your first question, "I'm using the CCP modules as an interrupt driven full-deuplex rs-232 transciever. It appears as though the two ccp channels are interacting, and I can only do half-duplex. Has anyone else had any trouble using one channel as a compare and the other as a capture simultaneously?" At that point those with some experience would comment, and ask for more detailed information. The key here is to get a few experts hooked on your thread, and the best way to do that is to ask an easy (short) question. I'm sorry I can't help with your problem directly. -Adam "Wollenberg, Frank" wrote: > > Hello again, > > Several days ago i've sent the (long) message below, but so far nobody > replied. Either no one has discovered this problem or it was my last > sentence of the message. NO NO NO, i'm NOT afraid, i wish to hear from you. > So help me, please. > TIA > Frank > > -----Original Message----- > > Hello folks, > > I'm using two serial links with a 16C66, one is the internal UART, the other > is implemented using 2 CCPs in a bit-banged fashion. Both are running > interrupt-driven. > My problem is the bit-banged UART. > > The receiving part is using one CCP in capture mode for detecting the start > bit. Data bits are then sampled using the SSP. > The transmitter is implemented using the second CCP in compare mode, > set/clear output on match. > Both parts are working as expected as long as i do only transmit or receive. > If i do both the same time (as i must have a full-duplex link), i will get > spurious failure on the transmitter side. > > I have examined the problem. If both events - CCP capture interrupt (start > bit detection) and CCP compare interrupt (setup next transmit data) - occur > the same time, the CCP compare module changes the port pin, but the pin goes > into the previous state immediately, so there is a short peak only!!! The > failure is reproducable and documented with an oscilloscope. The falling > edge of the receive line and the edge of the transmit data clock are > simultaniously. > > As a quick solution, i have changed the compare module to 'generate sw > interrupt on match' and setup the transmitting port pin in the interrupt > service function. Many jitter is the result. Because of some other complex > interrupt functions, the interrupt latency time can be about 60% of one bit > time. This won't working too. Therefore i have reduced the data rate, but i > can't accept this. > > Now my question: > Why will the compare module in the mode 'set/clear output on match' fail, if > the capture module has an event the same time ? > Has anyone had this failure, or similar ? > > Before one will reply with some simple solutions, i must say the following: > > - I have tested on PICs 16C63, 16C66, 16F876, also with ICE2000 with > PCM16XE1 module. Allways the same failure. > - I have reviewed all data sheets (newest) for the various PICs. > - I have reviewed all errata available (from very old until now). > - I have read various FAQ, news lists, Microchips BBS. No specific > information found. > - The data sheet says, the compare should be configured for special event > trigger. The reason is never discussed. Also i can't do it because of using > timer 1 as a free running timer for other timing issues. > - Microchip says the CCP modules are similar. > - I know, both CCP require timer 1 > - Timer 1 is working as a free running timer using the internal clock OSC/4 > (timer mode). > - The interaction of multiple CCP modules is discussed well in application > note AN594. > - AN594 appendix E (capt2.asm) uses both CCP in the same way as i have, but > i'm using several other interrupt sources. > > Anyway, problems with interacting CCP should be reported. Only some requests > I've found in the net. > Why not open a discussion thread "problem with interacting CCPs" ? > > I'm afraid about any replies, > Frank > > -------------------------- > GSP Sprachtechnologie GmbH > Frank Wollenberg > HW-Entwicklung > Tel.: +49 (0)30 769929-78 > Fax: +49 (0)30 769929-12 > eMail: f.wollenberg@gsp-berlin.de > > -- > GSP Sprachtechnologie GmbH > Teltowkanalstr.1, D-12247 Berlin > Tel.: +49 (0)30 769929-0 > Fax: +49 (0)30 769929-12 > eMail: Info@gsp-berlin.de > Web: http://www.gsp-berlin.de > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.