Interrupt prioir to Serin

[alband]

This project is a target and display system. The target is a 7x7 grid of phototransistors (PTR's) connected to a PICAXE-40X. Schematics are in the next two posts (limit of two attachments). The display has a 7x7 grid of LED's and an LCD display. I need to be able to have the target always waiting for a serial communication but it also needs to check the PTR's (currently it is only checking 25 of them (5x5 grid for simplicity). Therefore I need to be able to interrupt the targets code and then communicate with it. So, I'm using the setint command. The problem is that the Target only responds some of the time. Is there anywhere in the target's code where it wouldn't respond to and interrupt.
The code for both is attached in this post (one of which being the one that was described as gibberish in another post, now de-gibbered). The schematic will come in the following posts.

 

[alband]

These are the PTR's and LED's.
I've only drawn some as it is a reoccurring pattern.

 

[alband]

These are the main Schematics.
The Display:
The connector at the diode goes to the same named connector in the target and is the serial line.
The three connectors below that, that stand out, are the switches.
The pin above VDD on the right goes to the display.
The other connectors go to the LED's.

The Target:
The connector at the diode goes to the same named connector in the display and is the serial line.
All the rest come from the PTR's.

All necessary-to-run pins are connected correctly, this is a code problem.
The PTR sensor board is not currently working and so I'm just using wires as switches (since they use digital input pins it works fine).

Think I've included all relevant info, but I'm sure I'll soon know if I haven't.

 

[hippy]

It won't respond to interrupts while executing SEROUT and interrupts are only tested for at the end of each command.

Your timeout in the interrupt routine also restarts the program which is not the proper way to exit an interrupt. Do that and interrupts will not be responded to afterwards, not even after a further SETINT command. You must RETURN from the interrupt routine, not jump out of it.

If it receives "1" it will go into an endless loop and spend most of its time in SEROUT which gives only a narrow opportunity for any interrupt to be seen.

From the sender's side there's only a short interrupt pulse sent which it may miss, you then update your LCD which takes a considerable time, so when you come to read the first response you may have missed it, it having been already sent.

Interrupts can be incredibly hard to get right and debug, especially with two asynchronous systems doing multiple things. You may be better with a handshaking approach where each side checks if the other has anything to send while that other indicates it has something and waits until it is told to proceed.

I'd also suggest stripping your code right down to the bare minimum, get that working solidly then start adding things to it. Once a system like this goes wrong and gets out of kilter it's extremely hard to discover what went wrong and where. It's hard to do debugging because that in itself affects the operation and it's hard to follow what two things are each doing at the same time.

 

[alband]

Thanks loads - must have taken a while to look through.
I'll try all that stuff but I reckon it's the "getting stuck in the "1" loop".

 

[alband]

Also, how do I use the timeout feature in the serin within an interrupt. Do I need to make a label in the interrupt - is that possible or will it cause the same problem.

 

[hippy]

yes, timeout to a label within the subroutine. In this case immediately after the SERIN, before the SETINT and the RETURN.

 

[alband]

Thought so.
These are the latest codes.
The stopping of the loops has made it more reliable but still misses it sometimes so I might give the serin's on the display timeouts, where if it's the first timeout, try again, but if it fails twice, show the error message.

One big problem I'm having though is after the select target routine. The routine is mostly a way of using the button command to scroll through the column's and rows to display a selected target and and create the variable that represents that target, allowing the shot information to be compared with this.

It works fine until this:

label_73:	pulsout 1,100
		pause 10
		serout 1,N2400,("2")
		goto label_75 'appears to "crash" here
								
label_75:	serin 7,N2400,("?"),b2,b3
		if b2 != "0" then label_75_1
		if b3 != "0" then label_75_1
		goto TS_miss

The middle button is pressed to select the final target and the code is directed to "label_73". It then performs exactly the same routine as the start of "Just shoot" earlier in the code which works. It sends "2" to the target, which should tell the target to start sending data about the PTR status. For some reason though, it either goes back to the beginning, or the LCD just blanks out (in my case showing sort of half filled boxes but this is what this brand of screen does when it is cleared).
It never gets to label_75.