Hserout/In funny results

[manie]

I'm sending a few bytes of data between 28x1's via Hserout/Hserin(background receive with flag5 set as interrupt trigger). I have Hserial setup as follows:

setfreq m8
pause 2000			'pause for LCD startup etc.
put 2,0:put 3,0:put 4,0:put 5,0	'O/P pins clear limit flags
setintflags %00100000,%00100000
pause 5
hsersetup B9600_8,%01
pause 5
hserptr=100
pause 5				'operations data stored below RAM 100
hserflag=0
pause 5

The transmitter code is:

'Transmitter sending routine.

			put 80,10:put 81,0
			put 82,3:put 83,0:put 84,5
			gosub SendIt

'-------------------------
SendIt:

	for cntb1= 80 to 84		'5 data bytes
		get cntb1,cntb2		'get the byte
		hserout 0,(cntb2)		'send the data byte
		pause 2			'give receiver time to write
	next cntb1


return
'-------------------------

On the receiver side I have:

	get 100,cntb1		'read the code
	
	select case cntb1		'immediately decode for action
		
		case 10			'LIMIT switch TRIPPED !
			low Sdn		'immediately stop all shutters !
			low Sup
			low Ndn
			low Nup
			pause 5
			get 101,cntb1		'get 1st O/P pin, 2/3/4/5(Sup/Sdn etc)
			get 102,cntb2		'get 2nd O/P pin
			get 103,cntb3		'get 3rd O/P pin
			get 104,nowtb		'get 4th O/P pin
sertxd("hserptr= ",#hserptr,cr,lf)
pause 2000						'just to see it
			put 2,cntb1:put 3,cntb2
			put 4,cntb3:put 5,nowtb
sertxd("received - /",#cntb1,"/",#cntb2,"/",#cntb3,"/",nowtb,"/")

On the receiver the Sertxd shows the Hserptr ends up as "104" which means only 4 bytes received, not 5 that was sent. Also the the second Sertxd shows:

received - /2/0/0/

missing the byte that should be in "nowtb"...

Sending from the "receiver" (20 bytes) using the same routine "SendIt" has no problems being received on the "transmitter" without missing last byte.

Any ideas ?

 

[hippy]

sertxd("received - /",#cntb1,"/",#cntb2,"/",#cntb3,"/",nowtb,"/")

Shouldn't there be a # in front of nowtb ?

 

[hippy]

There's not enough information in the abridged code to tell what's really going on and I suspect the full code will be overwhelming to understand. It's not clear if this is single direction comms or bi-directional, where, when and how often each piece of code is getting called. Presumably the receive code is a part of the interrupt routine but what else is going on in that ? Do you send one packet of data or multiple packets ?

For complicated problem code like this it's best to strip that down to a bare minimum, no clutter, which demonstrates the problem occurring. It will be much easier to understand and see or theorise on what's happening and there will be no concern it's something in, but not seen, in the rest of the code.

One thing you might consider is that the HSERFLAG interrupt occurs when the first byte is received. You seem to be handling the interrupt and expecting there to be five bytes received when you come to use them; there may not be.

You send five bytes, with 2ms pauses, so that's about 10ms. In your receive code you appear to have a 5ms delay before reading those five bytes.

 

[manie]

Hippy: True what you say, however, in the receiver interrupt, first line there is also a "pause 50". After playing around with the pause and removing the transmitter pauses, things went ok. It was a matter of timing it seems. Yes the "#" sign was missing, but the data on the 5th byte was missing. It is fixed now and bi-directional Tx/Rx with the associated Interrupt routines on both sides now well synchronised.

Thanks for looking, sometimes it takes JUST A LITTLE more juggling and you solve your own problem. Sorry I bothered you but at 22h00 after coding more than 12hours one feels a little dumb..... which I'm sure I was ! Thanks.

 

[hippy]

Glad it's working now. Timing and interactions in bi-directional systems can be a nightmare to figure out.

 

[manie]

Agree with THAT ! More often than not, one must persist, OBSERVE in detail, analyse, adjust, OBSERVE, analyse.... PERSIST ! If you are doing something fundamentally wrong it probably will not work at all. If it is working but not "correctly" then you probably need to just at it. In this case I got it right, sometimes you need more knowledge...