Im fairly new to Arduino, but enjoying it thus far...
Currently im stuck with a slight problem with interrupts vs pcints vs polling.
Im using the Arduino Mega 2560 for my robot, which consists of 9 servos using PWM from the board but powered externally, i then have 4 IR sensors like those available from sharp etc. and 4 force sensors (FSRs) (will be adding additional contact switches +- 4 switches), i also use 3 Uart channels (2x rs232 1x rs485).
Reading over the Atmel atmega2560 datasheet i saw there were 8 ext ints but now see that the Arduino only has 6 (2 of which i need for pwm [must use timer3, frequency thing] and 2 for uart [I use uart 1]).
So being quiet an idiot i have already fabricated some PCBs with comparator circuits for the FSRs and IR sensors (circuit will switch to digital '1' when force exceeds "x" and '0' otherwise likewise the IR circuit '1' when "x" distance to object etc..) this is needed so that the thresholds can be adjusted via a pot easily and no need for extra ADC coding ("in the field").....
So can anyone please help with the problem regarding number of interrupts... PLEASE!
(reason for interrupt is I need the robot to stop IMMEDIATELY as soon as one of these conditions are true... If it does not stop eg. when im moving the arm forward to pick up a chemical it will bump it over, and boom[well not really, but u get the picture]...).
I have seen some mention the PCINTs but I dont really want to mess around with these as they are not 100% reliable (project requires a 99% accuracy) and I dont see how polling can be used if i tell servo to move to "x" and it bumps over something before stopping!
What makes you think that pin change interrupts are not 100% reliable?
If you want to avoid using pin change interrupts, you could use an OR-gate (or a diode/resistor network) to combine all the sensor comparator outputs into a single signal, and feed that to an additional Arduino pin. Configure that pin to generate an interrupt when it sees a rising edge. The interrupt service routine can read the pins corresponding to the individual comparator outputs to see which sensor has been triggered.
Issue with logic gates/ ladders etc is the arm has 7 D.O.F.(degrees of freedom) so it needs to stop in each direction of motion..
eg. if im moving forward only servos responsible for forward motion must stop, if moving left only the servo responsible for movement left must stop etc..
I think that the ISR reading could be affected(be inaccurate) if a change occurs during ISR.eg. Ur idea of a network, triggers the ISR (very good idea thx..), ISR then checks pin 1,2,3,... etc(let say N random pins) but during the check 1 input changes (environmental condition) ISR does not pick up in the service routine and continues to move arm. Now because interrupt occured in ISR nothing is done in future..**I do ralise that the check can be done in a split second but was just wanting a "STOP" function then return from ISR not having to check N pins...
But thank you very much for the idea its quite simple and brilliant..
It might also be possible to use ur idea of R-ladder(network) to read a value into the adc and take action but i think when adjusting pots(pots described for use in field, adjusting thresholds) it will become extremely complicated.
Thanks for the advise might look deeper into PCints..
@CrossRoads, Thanks for the insight, seems PCint is that simple... will definitely try that now!
Thanks also for your remote control (diode or) method, seems very attractive,
could i however ask if there were any delays in your ISR ( i might be forced to delay the code during the ISR for a few seconds (to move a servo back etc..., so might be a similar issue i raised in reply to dc42 regarding ISR inaccuracy..)
If you need a delay, set a flag in the ISR, if you see the flag set in loop then do your delay.
My ISR had no code in it; the uC went into power down sleep mode inside a Sleep function, the interrupt woke it up still inside that sleep function.
Starting & stopping in a known place was helpful to me, maybe not so useful for programs that need to process interrupts at random times.
If you need the delay IN the ISR, add a while loop and just count until the time you want is elapsed.
Maybe do a while loop within a while loop if you need it really long.
Ill leave this last thought for tonight(01h42 a.t.m.) and physically try the solutions suggested in the morning,
not to sound like a broken record, (might be a bit silly on my behalf) but if the following scenario plays out will a diode or method work 100%..
IR sensor 1 indicates object to near, diode or (makes '1' or '0' depending on config) ISR initializes and stops all current movement and then instructs servos x,y,z to move to desired position (which takes time "x") during this time (time "x") FSR sensor 1 detects vial is dropping...
My problem is this during the wait for the servo to move back and confirm it is in the correct position reason for delay(doesnt really confirm) will I be able to detect another event...
My answer to this is NO, in the ISR i will be able to see that FSR is now a '1' and do something about it ONLY AFTER the time delay (1ms might even be to long) has passed
Yes a flag could be set in ISR so no extreme delays are used but in this case wont it be something of a ISR in a ISR in a ISR? (at the end of ISR 20flags "highlighted".
Sorry if im not grasping the concept its early hours in the morning and probably just need sleep.. Anyhow..
How many directions are you moving at once?
What is usually done is when a critical interrupt occurs, you disable interrupts so you can work the code for that interrupt without being interrupted.
Or, set a flag when you are working the critical one, and if a lower level interrupt occurs, that one checks the critical flag and breaks out with no action so the main one proceeds.
