Need some hints about analog input and interrupt generation

Gaal Alexandru said:

(desired) ... generate an interrupt only when the input value is higher than a certain value? Or should I use the analog comparator? Or digital comparator?   How should the ADC be triggered in this case?

May we note your (very) complete analysis of the (multiple) options provided by this vendor - that's quite good!

Now - our experience reveals that each/every method you've listed can be made to work.   Yet my firm has a very strong "favorite" and I bet that we can (successfully) sell that.

You've identified 3 options - have you not?   Let's list them for clarity:

• employ the MCU's ADC - this must be programmed to run at a rate sufficient to "catch" your (offending) high-level, analog input signal
• employ the MCU's analog comparator
• employ the MCU's digital comparator

Again all can be made to work - so (which) to choose?   (and why?  i.e. "justify" that choice)

My firm was (long past) faced w/just this requirement.   (we sought to "kill PWM output" when our BLDC motor controller's "current sensor" detected an "over-current" condition)   This "over-current" condition was noted by our sensor's voltage (exceeding) a known value.   This substantially duplicates your listed conditions - does it not?

 Now you list "no selection criteria" for arriving at your decision.   (consider that)  Ok - time's up - let's (again) list some:

• reliability/robustness of the chosen effort
• programming effort required
• time delay between the arrival of the "offending" signal and the MCU's correcting/preventive response
• ability of your "method" to be quickly/easily (and dynamically) broadened.   (i.e. you seek to - "on the fly" - alter that 1V5 "trip point.")

Above list does not insure completeness - yet serves as a reasonable beginning.   Now we must compare/contrast each of these selection criteria against your (earlier) "three identified methods."   And the winner is... ... (hands down - I believe) method #2 "MCU's (on board {chip actually}) Analog Comparator." 

Now a "blow by blow" justification of the superiority of Analog Comparator:

• robustness - once the MCU's Analog Comparator is, "Set-Up/Configured" it is substantially "Software error-free" can "protect" even if the MCU lands, "in the weeds."   Your ADC - and especially the ADC's "linked" digital comparator - are "held hostage" to "correctly and continually executing" software - which reduces reliability.
• program effort - easy victory for MCU's Analog Comparator.   Only "Set-Up" is required - far beyond this is demanded by (other) (i.e. far lesser) methods.
• time delay (i.e. speed of response to offending input)  Again NO Contest (this is getting boring) Analog Comparator operates at the (always desirable) hardware level - thus proves the "hare" to (outclassed) other method's "tortoise."   (apologies to turtles)  Can your desire (afford) the time delay in responding?   Really?
• dynamically change your set-point - all other methods demand that you make quite considerable ADC & digital comparator register changes - often in a prescribed manner/order.   Our M4s employ an on-chip DAC - which we feed to the "negative input" of the MCU's Analog Comparator (that's our trip-point input) while the "live input signal is routed to "positive input."   For MCUs (missing) the always helpful DAC - a timer's PWM output can be R-C filtered - serve the same purpose.

Unstated herein is our treatment of the "MCU's Analog Comparator" output pin.   In our "kill the PWM" application we (simply) route this to the MCU's, "PWM Fault Input" pin - and this level shift proves sufficient to (extinguish) all six PWM outputs.   Yet another benefit - for those offending signals which prove "transient" (i.e. "most of them") - method detailed here (uniquely) provides an "Automatic - Restore to normal operation" capability.   (when the offender "returns to normal" desired operation immediately restores - automatically - which "regulatory agencies" (all) applaud...)

Has the case in (extremely) strong favor of, "MCU's Analog Comparator" been made to your liking?   We note that it (also) meets your desire for an "example."

Which point - have you read the entire post? There are (many) points in great support of my recommendation.

I'm at an airport - net is "in/out" - I compose and "send" in spurts - as connection allows.

By my (re-read) post is above/beyond (most) here - have you really read slowly/thought/tried to absorb?   How (possibly) can I make (any) clearer?

So... I tried the analog comparator, indeed it's very simple to implement.
However, I can't figure out how to set the PC6 pin as comparator input.

The TivaWare file pin_map.h does not contain any macro for the comparator input.

#define GPIO_PC6_U3RX           0x00021801
#define GPIO_PC6_PHB1           0x00021806
#define GPIO_PC6_WT1CCP0        0x00021807
#define GPIO_PC6_USB0EPEN       0x00021808

I was expecting something line GPIO_PC6_C0I or C1I... but only comparator outputs are defined for PF0 and PF1 

#define GPIO_PF0_C0O            0x00050009
#define GPIO_PF1_C1O            0x00050409

I assume this might be one of the reasons why I'm not getting any feedback from the comparator ISR.

My initialization function is the following:

void COMP_mic_input_init(void)
{
	SysCtlPeripheralEnable(SYSCTL_PERIPH_COMP0);		//Comp 0 enable 
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);	 	//Port C enable
	
	//GPIOPinConfigure(GPIO_PC6_...);								// ?!?! What to do here :)
	GPIOPinTypeComparator(GPIO_PORTC_BASE, GPIO_PIN_6);	// Not enaugh???
	
	ComparatorConfigure(COMP_BASE,0,COMP_TRIG_NONE|COMP_INT_HIGH|COMP_ASRCP_REF|COMP_OUTPUT_NORMAL);
	ComparatorRefSet(COMP_BASE,COMP_REF_0_825V);
	
	ComparatorIntEnable(COMP_BASE,0);
}

And the ISR for the comparator is:

void Comp0_Handler(void)			//Analog comparator 0 ISR
{
	if(ComparatorIntStatus(COMP_BASE,0,false))
	{
		ComparatorIntClear(COMP_BASE,0);
		Motion_Max_Speed();
	}
}

May this reporter note that the (suggested) xx339 (quad comparator) - kicked to the curb - would have been "On the Air" w/in 1 day - Max!

Ten days have now passed - MCU as "kitchen sink" reveals - again - substantial pain/suffering!    (which was predictable)

Rejecting the "easy" - for the hard/uncertain - makes sense somewhere & some when. (Yet NOT here - and NOT now!)

Hi Amit,

There's at least one, order of magnitude's EASE, in mastering xx339 vs. MCU's (especially) digital comparators.

You speak of  "ripples of doubt" - yet the "kitchen sink" - lasting here for TEN Days - far exceeds ripple!   Tsunami, anyone?

xx339 would have been "On the Air" w/in 1 day - MAX!   (and the pond's surface shines like Glass - ripple free...)

Droidbot_SW_v6_comparator_test.rar

I made an archive of it. 
The project is made in Keil IDE.
The main and startup files are in the root folder, the rest of the code in modules folder.

comparator_handler and interrupt_handler are the ones handling the comparator

The simplified version of the SW:

Droidbot_SW_v6_comparator_test_simplified.rar