Quote Originally Posted by mister_e View Post
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