Pin change interrupts & external interrupts at the same time ?

Hi is it possible, to use external interrupts and pin change interrupts together ? I have a "special" case where i would like to have 6 pin changes interrupts and 1 external interrupt - of course i could use just the pin change interrupts, but that would mean to rewrite some code. SO it would be easier, if i could have/use an external interrupt

cider101: Hi is it possible, to use external interrupts and pin change interrupts together ? I have a "special" case where i would like to have 6 pin changes interrupts and 1 external interrupt - of course i could use just the pin change interrupts, but that would mean to rewrite some code. SO it would be easier, if i could have/use an external interrupt

Yes, it is.

anyting i need to take special care of ? I'm asking, because it works in a stand alone sketch (only using ext but no pin change ints). As soon is i integrate the exat same code into my project - there is a lock-up... (meaning the program doesn't continue)

uint8_t _pin = 2;
pinMode(_pin, INPUT_PULLUP);
attachInterrupt(_pin-2, on_interrupt0 , CHANGE);

If that's all your code, it's surprising that you can tell that it works, or doesn't.

I had some code that had 2 hardware interrupts and 2 PCINTs reading the outputs of rotary encoder chips. So you can definitely the types.

CrossRoads: I had some code that had 2 hardware interrupts and 2 PCINTs reading the outputs of rotary encoder chips. So you can definitely the types.

does it matter, if the pc-ints are enabled on the ext-int "port" as well ? I have a quadratur encoder connected to each pc-int port and wan't to use the ext-int for a hall sensor...

It all just works - the interrupt system is carefully designed so none are lost(*), they get queued up and handled in
turn, the fact that the same pin might be generating both kinds of interrupts isn’t an issue, The order they are
handled in I don’t know, that depends on the number of clocks delay on triggering the interrupts - the circuitry
is probably different for the two sorts.

(*) unless they are triggered at a faster rate than can be handled.

analyzed to problem a bit further…

seems, like the call to attachInterrupt does not return (or corrupts the memory). Funny thing is, if i copy paste the code from attachInterrupt into my own “setup”

EICRA = (EICRA & ~((1 << ISC00) | (1 << ISC01))) | (RISING << ISC00);
		    			EIMSK |= (1 << INT0);

and use my own SIGNAL handler

SIGNAL(INT0_vect) {
	ExternalIntterruptRpmMeter::on_interrupt0();
}

everything works as it is supposed… as i mentioned above, the problem is not, not getting any interrupts. The problem is not being able to register the interrupt handler (attachInterrupt doesn’t return ). So, i guess i must be doing something wrong
Below is my full code… the static methods on_interrupt is used as interrupt handler…I ommited the super class here since it’s fairly trivial (just doing some increments of a counter)

template<typename T>
class ExtIntHallsensor : public Hallsensor<T, uint8_t> {
private:
	static ExtIntHallsensor *_instance[2];
	typedef Hallsensor<T, uint8_t> super;

	public:
		ExtIntHallsensor(uint8_t pin) : super(pin) {
			pinMode(pin, INPUT_PULLUP);
			info << "setup ExtIntHallsensor " << pin << "..." << std::endl;
			//attachInterrupt(pin-2, pin == 2 ? on_interrupt0 : on_interrupt1 , RISING);
		        switch(pin) {
		    	      case 2: EICRA = (EICRA & ~((1 << ISC00) | (1 << ISC01))) | (RISING << ISC00);
		    		       	EIMSK |= (1 << INT0);
		    			break;

		    	       case 3:
		    			EICRA = (EICRA & ~((1 << ISC10) | (1 << ISC11))) | (RISING<< ISC10);
		    			EIMSK |= (1 << INT1);
		    			break;
		    }


			_instance[pin-2] = this;
			info << "...ExtIntHallsensor " << pin << " ready" << std::endl;
		}
		~ExtIntHallsensor() {
			detachInterrupt(super::_pin-2);
		}


	public:
		static void on_interrupt0() { _instance[0]->incrementTicks(); }
		static void on_interrupt1() {_instance[1]->incrementTicks(); }
};

Interrupt handlers cannot be C++ methods, they must be plain C functions.

MarkT: Interrupt handlers cannot be C++ methods, they must be plain C functions.

thats not entirerly correct....they can't be member methods, but they can be static class methods