Variant of Serin2/Timeout Hang Problem

[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