Variant of Serin2/Timeout Hang Problem

[Jimbo]

I've encountered an odd variant of the Serin2/Timeout hang problem.

The subroutine in question is entered via an interrupt and is
supposed to get some serial input and then do some fascinating
things depending on those commands. BUT -

If I ground my serial-IN pin through a 10k resistor to ensure it's low
and noise free, Serin2 won't timeout.

If I let the (true) serial line pull the pin up, Serin2 causes the PIC
to reset.

I've scoped everything looking for low and high-frequency noise and
the pulled-down input is absolutely silent. In theory, it SHOULD
timeout. I'm aware that if the pin is held high the timeout won't
work ... I suppose I'd have to double-invert to make it normally
low with the terminal attached.

Anyway, I don't *think* I'm doing anything unusual, and I've tried
a number of variants of the code, all with the same negative effects.

Program for PIC 16F88 using 4 Mhz internal RC clock.

The shortened code looks like :

.................................................. ..............
Define SER2_BITS 8

SDA var byte[8] ' serial-data-array (command-assembly buffer)

TRISA = %11111111 ' Set PORTA0-7 to input
TRISB = %11011111 ' Set PORTB0-4,6-7 to input (b2=serIN,b5=serOUT)
INTCON = %10000000 ' disable most interrupts

{program start}

ON INTERRUPT GOTO INTRPT
DISABLE ' disable interrupts here
INTCON = %10010000 ' enable rb0 as interrupt pin

WAITLOOP:
{interrupt waiting loop}

INTRPT:
{interrupt subroutine}

SEROUT2 PORTB.5,396,["I"] ' 2400,N81,True,Driven ... proves interrupt happened

serin2 PORTB.2,396,1500,T_OUT,[WAIT(42), SDA[1]]

SEROUT2 PORTB.5,396,["D"] ' 2400,N81,True,Driven ... shows serin2 dropped through

GOTO REZUM ' skip-over timeout stuff

T_OUT:

SEROUT2 PORTB.5,396,["T"] ' 2400,N81,True,Driven ... shows serin2 timed-out

REZUM:

SEROUT2 PORTB.5,396,["X"] ' 2400,N81,True,Driven ... shows normal exit from sub

RESUME WAITLOOP
{end interrupt sub}
.................................................. .

The interrupt worked first time (good for picbasic) as do SerOUT statements and
Pause() statements - but SERIN2 either hangs when it shouldn't or causes a reset
when it should. I suppose I could loop SERIN2, polling for input for a finite number
of loops, but that increases the chances of missing something.

Any clues ?

-Jimbo

p.s. - a new mode for serin/serin2 - "Wait for ANY input (until timeout if specified)" would
be a nice improvement for PBP since you don't always know what your first input byte
will be ........

[mister_e]

well... first observations,
i don't see any DISABLE and ENABLE 'round the ISR.

RESUME should not be followed by a label name,

and you don't reset the INT bit.

So yes it may cause some weirdnessssssssss.

And the following will explain when using pull-up/down for serin and timeout
http://www.picbasic.co.uk/forum/show...86&postcount=5

[Jimbo]

well... first observations,
i don't see any DISABLE and ENABLE 'round the ISR.

RESUME should not be followed by a label name,

and you don't reset the INT bit.

So yes it may cause some weirdnessssssssss.

And the following will explain when using pull-up/down for serin and timeout
http://www.picbasic.co.uk/forum/show...86&postcount=5

------

I'd been commenting things in and out for awhile, so my example
wasn't complete. My bad ...

Yes, DISABLE INTERRUPT was in there at the beginning of the ISR

"The INT bit" ... I suppose you're refering to INTCON.1 ... yes, it gets
cleared first thing in the ISR as well. This wasn't explicitly mentioned
in the manual, the assumption being that DISABLE INTERRUPT would
cope with multiple hits to the int pin. Nope.

I removed the label from "RESUME" ... but it didn't make any difference.
Actually, that IS a legal syntax. You can resume to any label, not just
to where you started from.

I also tried changing the literal milliseconds timeout value to a CON and
then a VAR just in case Serin2 didn't LIKE literals.

Alas, no joy. Still refuses to timeout when the input pin is held low, still
causes the chip to hard reset when the pin is high. Very frustrating.

I'd done quite a number of PBP programs before ... with plenty use of
the serial OUTPUT statements, but this is the first time I've tried to get
serial data IN ... and it's not looking hopeful. I even tried a new 'F88
chip just in case I'd somehow fried the first one. Could the 'F88 be
"special", some flag needing to be set that got missed by the PBP
compiler writers ?

Hmmm ... the 'F88 *does* have hardware USARTs. I wonder if going
to the HSERIN/HSERIN2 statements might have an effect ? Somehow
though I suspect the logic is exactly the same past a certain point.

Any more ideas/links/abuse/lottery_numbers/etc ?

-Jimbo

[Jimbo]

Useful new information :

Switching to HSERIN solved two problems at one stroke.

The timeout now works correctly AND it doesn't make any
difference whether the input pin is high or low (just so long
as it isn't noisy).

There are a couple of remaining issues with HSEROUT, primary
being that it's sometimes "tardy" about outputting a character,
waiting until another "pushes it out" - presumably out of a small
buffer. Alas it's one of those evil "sometimes" problems - sometimes
the character prints promptly, sometimes it doesn't - which makes
a generic 'dump your buffer' solution difficult. I may just have to
add extra, pointless, characters to the output.

The timeout seems to run fast also ... maybe 30% ... although
PAUSE() statements time perfectly. This isn't a biggie.

Of course none of this will help people using chips without an
internal USART. I wonder if the USART somehow interferred
with using my chosen I/O pins for the SERIN2 command ? I'm
pretty sure I'd disabled anything to do with it, the chip should
have responded as if it were an 'F84 ... should have. Lots of
subtle, poorly documented, interactions in these things however.

Anyway, I think I can proceed with my app now. I really didn't
want to change it over to CC5X just to get around one little
issue like this. Besides, I'd have to write more complex ISR
and serial routines in that language ...

- Jimbo