wzschoche / arduino-pinchangeint

Automatically exported from code.google.com/p/arduino-pinchangeint
0 stars 0 forks source link

Seems not to distinguish between RISING/FALLING #15

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I am trying to connect my Raspberry Pi via SPI to the Arduino UNO with the RPi 
as Master.

I have linked pin10 (SS) to pin2 (so there are no other pin changes on that 
port) and attached an interrupt to pin2.
I am trying to use the FALLING edge of the SS to detect that a new set of data 
is coming. The program works, but in testing I find that it
also detects a FALLING edge at the end of the data where I would expect a 
RISING edge.

I have tried to detect a FALLING and a RISING edge on pin2 but the program only 
sees the RISING edge and so does not work.

from the attached output which is just a proof of concept.

I expected to see
- a printout of the data sent which I do,

- a line containing the number of FALLING edges seen (followed by the number of 
RISING edges seen not currently used and so is =0) which I do

- a line starting with a "1" followed by zeros showing the position of the 
FALLING edge
here I see another 1 immediately after the data. has been sent

I am using spidev  within Python to send the data and I can see no reason for 
it to be sending another empty set of data which would possibly account for the 
problem. 

I am using Version 2.19 beta

The Arduino sketch and the Pyhton program are attached

Original issue reported on code.google.com by alantjoh...@gmail.com on 3 Apr 2013 at 6:44

Attachments:

GoogleCodeExporter commented 9 years ago
You cannot set 2 interrupt vectors to a single pin... it's one or the other. So 
you can interrupt on FALLING, *or* RISING, *or* CHANGE. I have created a 
modification of your program, attached a switch to pin 5 (which is still PORT 
D), and observed the printed output. All looks proper; it interrupts on rise or 
on fall and prints the counts properly.

To do what you want to do, you need to: 1) interrupt on CHANGE, and 2) observe 
the pinState in your interrupt routine by checking PCintPort::pinState.  If it 
is HIGH, your change was RISING. If it is LOW, your change was FALLING. So 
you'll have a single interrupt routine with an if statement in it.

Original comment by m...@schwager.com on 4 Apr 2013 at 3:00

Attachments:

GoogleCodeExporter commented 9 years ago
Thank you very much for that. It allows me to do what I want to do.

However I do not think it explains why I see 2 FALLING interrupts when ther was 
I believe only 1.

Alan

Original comment by alantjoh...@gmail.com on 4 Apr 2013 at 7:43

GoogleCodeExporter commented 9 years ago
I don't know, but the first step with troubleshooting is to make sure you're 
working within the proper parameters. Because you were trying to attach two 
interrupts to the same pin, I think the problem starts in the code you were 
creating.

My code demonstrates that the library is able to distinguish between rising and 
falling. If you continue to have a problem, then the shortest way to get to a 
solution is to strip out all nonessential code and illustrate the problem. One 
thing: are you doing a digitalWrite(pin, HIGH) to turn on the pullup resistor?

Original comment by m...@schwager.com on 4 Apr 2013 at 12:59

GoogleCodeExporter commented 9 years ago
I am not  writing to the pin. 
I am forced to conclude that the spidev module in Python is sending an extra
 SS low/SS high signal with no data after each data burst.

Original comment by alantjoh...@gmail.com on 5 Apr 2013 at 6:43

GoogleCodeExporter commented 9 years ago
You need to do a write to the pin to enable the pullup resistor... even if the 
pin's mode is set as input.

One thing you can do is interrupt on CHANGE, and in your loop() report on every 
interrupt. Use the millis() function to report on the actual time between state 
changes. Make sure the system's response is what you expect.

Original comment by m...@schwager.com on 8 Apr 2013 at 12:37

GoogleCodeExporter commented 9 years ago
I'll leave this up for another week or so unless there are further updates to 
the problem. Then I will close it.

Original comment by m...@schwager.com on 13 Apr 2013 at 4:16