Video and interrupts

[basicchip]

>from the help line
>My project uses 2 superpros with BASIC, I'm calling them units A and B. Unit "A" scans in video information into a 63 element array every .1 seconds or so. Unit B sends an interrupt (on pin 74) to unit A approx. every .2 seconds. The interrupt subroutine on unit A then sends the 63 bytes of video data to unit B. I have the dongle connected to unit B and I have (for development purposes) unit B use "print" to display the 63 received data bytes on my PC screen. The problem is that the data displayed is always just the first set of 63 bytes, over and over. I know the video data coming into unit A from the sensors is constantly changing, and I know the interrupts are being sent every .2 seconds (I have a scope connected to the interrupt line (74)), but only the first set of data is ever printed. It's as if when the interrupt subroutine is over, the unit A program starts over at the beginning of its program, instead of picking up and continuing from the point where it was interrupted.

>Does the fact that I am using the "print" command on unit B somehow effect this?, does it mess with the interrupts? The dongle is connected to unit B which is NOT the unit where the interrupt subroutine is. Why would the unit A program start back at the beginning after it's interrupt subroutine is executed?

I don't see how a PRINT on B would affect anything on A. Interrupts would not cause a program to start over, a simple test of that would be to add a statement at the beginning of the program on A like

Code: Select all

main:
print "Hey I'm starting"

Or if a dongle and USB connection is not handy, have it wiggle an IO or flash the LED.

How are you sending the video data from A to B.
You will have to narrow down the possible errors--
1-- does A really see different data
2-- does A send the right data
3-- does B receive the right data

[ctkilian]

Thanks Bruce for the suggestions. In my troubleshooting a new issue has made itself apparent, which is that after unit B sends an interrupt (or two) , unit A simply stops working, like it's hit an "end" command, (or stuck in a loop, and I think I've eliminated that possibly). The only "end" command is at the end of main: and there is a "goto" instruction in front of it, so it should never see the "end" . It will start up again if I push the resent button. Also , the interrupt subroutine in A has no conditional loops, so I don't what's making the program stop. or how it's stopping. Any ideas?
Chris

[basicchip]

Another possibility is that you only get 1 interrupt on A. Again wiggling a line in the interrupt could show whether this is the problem or not.

The interrupt source has to be cleared as part of the interrupt routine or it won't interrupt next time.

[ctkilian]

I believe I have solved the problem of the program stopping. It turned out there was a loop in the interrupt sub that I just didn't see-in all the times I stared at it! But now I have some questions about interrupts, am I right that the interrupt line should be normally high and active low? Also, does the actual interrupt occur on the falling edge or rising edge ( I'm using the example interrupt routine from the manual without change). What is the significance, if any, of the length of the interrupt pulse? Is there a desired length? How would the length effect the main program?
Thanks

[basicchip]

GPIO interrupts can be on edge or level, and as for minimum pulse from the hardware perspective it is probably in the nsec. That would be found in NXPs data sheets. The real limit is on software interrupt response which has some fixed overhead in microsec, and then the length of code in your ISR. details on GPIO interrupts are in the NXP user manuals.