- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Labels:
-
PSoC 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Might be helpful if you post project for forum to look at.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the file's attached
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.