Serin after instant interupt?

I have a 12F683 device waiting for an incomming single byte via standard 8,N,1 9600 baud comms.

The device is executing a loop and doing other work so is not sat waiting in a serin for the byte.

Can i use an instant interrupt on the receiving pin and then jump straight to a serin or serin2 to get
the data or will the first bit be corrupted/missing ?

Can i use the known fact the first bit is corrupted/missing to correct the data after it has been
receieved? Or will the serin hang waiting for a missing bit?

Any other ideas?

In the past I have used a seperate pulse to tell the chip data is about to arrive and it then goes
and waits in the serin.

A further question about serin2 with a timeout of say 1000ms

If the data only appears at the pin at say 999ms is the timeout count aborted or does it exit because the timeout expires even though it may be half way through receiving a byte?

If you have the control over TX side, you can pull the TX pin low for say 100ms, then your RX routine jumps to Interrupt routine and wait for the serial data to come in. So you do not lose any bit.

Or, assuming you can control the TX side, you can send two bytes instead of one byte. First byte, %10000001, will interrupt the RX side, and you will receive the second byte. This may cause issues though.

I have been doing the toggle the pin routine for a few ms to get the chips attention and then going to the serin but i wanted to speed things up and remove the pre-amble and simplify the code. Any other ideas?

I thought about just have a serin2 with a long timeout, my other code takes only a few ms so out of 5 seconds as an example it would only not be listening for data for a few ms.

Hi,
Can you you use the handshake feature of SERIN2?

Is there a specific range of values of the byte you are sending? I'm trying to see how the actual bitpattern looks and if it might be possible to fool it by, for example, setting up the sender to send 2 stopbits but the receiver is set to 1 stopbit or something.

That way the startbit trips the interrupts then the first databit acts as the actual startbit, seven more databits, first stopbit acts as the 8th databit and the second stopbit acts as actual stopbit.

Not saying it'll work just thinking out loud.

/Henrik.

Just bumping this old thread as i want to revisit the idea.

I don't have access to the transmitting device so can't add bits or change format etc.
I can't use handshaking etc.
My PIC18F2680 Hardware Usarts/hserin etc are already committed.

I want to trigger an interrupt when a pin goes low (it idles high) then receive that incoming serial data with Serin2
If it jumps to the Serin2 quickly enough will it work? Or will I lose that first bit.

The actual first byte of incoming data isn't critical (it's a header) but the next 4-5 bytes are.

Say that you use the low-going edge as an interrupt trigger.

Then you start the Serin command that waits for the negative going edge. My guess is that it will loose the first byte and then will receive next one.

So, I would make two same characters as a start, one will be lost, the second will be the wait character, and then start getting the payload.

Ioannis

I don't have any control over the transmitting device.. So I can't add bytes.

You could also manually read the RCREG directly.

I'm using software serin2 on a non usart pin.. My hardware UART are taken.

Any chance to use a PIC with two USARTs?

Ioannis

the likely hood of getting serin/debugin/ser2in to sync up within 4 or 5 bytes
when isr triggered by start bit is very low


my strategy would be to
create a buffered single byte serial input routine edge triggered by interrupt.
the routine could then react with the assumption that start bit is underway.






to flesh it out further one would need to know :-
baud rate
inter byte delay if any
size of and timing of data "parcels"
start and/or end markers if any
any crc or other indication of successful reception

Thanks for the input.

Incoming data is standard 9600,8,N,1
Interbyte delay 80us
Packets are 5 bytes long.

1) Header (I know what this will be so could skip/lose this byte)
2) Length (5)
3) Data 1
4) Data 2
5) Checksum (I know the header byte even if it is corrupted/lost so can still calculate the checksum)

if your data looks like this
Attachment 8804

and your chip is fast enough

a isr routine like this [clear the flag, set inx to zero, set edge index active and off you go]
when flag set you have a pkt

Attachment 8805

might work in pbp



i would do in asm though