Comparator weird behaviour

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

 Hi All,

   

I've two comparators (say, CompA & CompB) in my design, whose outputs I take as interrupts by enabling the ComparatorBus interrupt. CompA is at a lower level (threshold) than CompB. Both are continuous time blocks.

   

I see that CompA works fine when the i/p exceeds the threshold. But it does not give an interrupt for the vice-versa. But, CompB works great for both cases. (You may see that they have different thresholds but the same input). 

   

 

   

The red circle in the attached image indicates the absence of a transistion that has to occur when the input falls below the threshold or in other words that which executes an ISR.

   

 

   

Any clarification wud be greatly appreciated.

   

RAM.

0 Likes
7 Replies
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Might be helpful if you post project for forum to look at.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

@ Dana,

   

 

   

P0.5 - pulse input ; P0.4 - PGA o/p; P0.1 - input(s) to both comparators.

   

P0.4 & P0.1 are externally short.

   

 

   

The o/p (LED toggling) is seen on a DSO. The interrupt which should have been triggered by the trailing edge of the input (LTH) doesnt happen. Post your suggestions/changes to be incorporated.

   

 

   

Thanks,

   

RAM

0 Likes
Anonymous
Not applicable

 the file's attached

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable
0 Likes
Anonymous
Not applicable

Interrupt is generated only on rising edge of the comparator output. You are getting on CompB; this is due to the noise near the threshold. I would suggest to route the comparator outputs to a pin (through DigBuf) and then see the outputs. 

0 Likes
lock attach
Attachments are accessible only for community members.
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

There are two ways of doing this, via ISR as you were doing, and

   

just HW.

   

 

   

I ran the ISR approach, and had to use single shot scope capture because the

   

ISR asynch behaviour making a stable scope presentation difficult.

   

 

   

The attached archive is adding two buffers to bring out to pins the COMP outputs,

   

no ISRs invlved.

   

 

   

1) I commented out, but left in, your ISR code. boot.tpl as well as main.c

   

2) Added two bufs, routed to pins in PORT1, I have some stuff on my jig already tied to PORT 2

   

3) Added a DAC to generate a triangle to feed to the COMPs.

   

4) Ran on PSOCeval1, 29466

   

 

   

So in short I got both approachesd to work. HW approach slighty cleaner as interrupt latency

   

and asynch response not a factor.

   

 

   

Designer 5.3

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

One other thought, Hysteresis around a COMP is important, in almost

   

all environments. Especially where input signals have very low F compo-

   

nents. This can cause input to hover around Vth and put COMP into

   

oscillation, which in an ISR environment would be disastrous. As well

   

its affects on other HW and processes.

   

 

   

Regards, Dana.

0 Likes