Serin effecting Background HSerial

[obroni]

Hi,

I'm not sure if I have:-

a) Discovered a bug
b) Not done something right
c) Hit a known limitation

I'm using a 28x1 and trying to use both the normal serin with a timeout and the Hardware Serial with background receive.

I have found if I call a serin command with a timeout before I check the hserinflag or hserptr then the hardware serial will not receive anything until I issue some sort of serout or sertxd.

eg:-

start:
hserinflag=0
hserptr=0
serin [50,timeout_here],0,T2400_4,b0
timeout_here:
pause 2000 'I now send data in this part
sertxd (#hserinflag,#hserptr)
'at this point both hserinflag and hserptr both equal 0
goto start

If I remove the serin:-

start:
hserinflag=0
hserptr=0
'serin [50,timeout_here],0,T2400_4,b0
timeout_here:
pause 2000 'I now send data in this part
sertxd (#hserinflag,#hserptr)
goto start

hserinflag and hserptr both show data

If I stick a tx command after the serin:-

start:
hserinflag=0
hserptr=0
serin [50,timeout_here],0,T2400_4,b0
serout 0,T2400_4,(b0) 'or sertxd(b0)
timeout_here:
pause 2000 'I now send data in this part
sertxd (#hserinflag,#hserptr)
goto start


hserinflag and hserptr both show data


Its fairly easy for me to work around this, by adding in one of the tx commands but it seems a bit odd to me.

 

[hippy]

I believe SERIN is blocking in that it waits for data to arrive and needs to keep accurate timing so as to not corrupt data so cannot service the HSERIN. Why a SEROUT should solve things I'm not quite sure.

 

[obroni]

Hmmm...ah right I see, so a serin stops the background receive so it can guarantee stable timing, makes sense. I guess what could be happening is that when a serin is called the background receive is put on hold but is never resumed until another serial command is used???

I tried increasing the pause up to 10 seconds and still no luck, so it looks like once its put on hold its on hold til another serial command refreshes it.

I'm not sure if this is a bug or not, but it might be worth mentioning it in the manual somewhere to be wary of this behavior as it took me several hours to work out why this wasn't working with my IR tx rx bits.

 

[hippy]

Commands should only block while executing and background receive should continue once a command completes or timesout. We will check that is the case.

Because of the hardware buffering for background receive the last byte received should be captured and held during blocking and stored when coming out of blocking but earlier bytes would be lost if more than one received.

 

[obroni]

Actually yes you are right. I do remember seeing that 1 byte was finally stored in the scratchpad if I didn't reset the pointers every loop, but only after I issued a serial tx command, this would have been 2-5 seconds after sending it. So it was getting stored in the buffer you mention but not released into the scratchpad until a sertxd or serout was issued.

Thanks for checking it out.