multi-task advice

[LomasS]

Hi all,
I'm having trouble seeing the way to implement my 'muti-task' requirements.
I've written code to do Manchester encoding for a low power RF link, but now I need to do the receive side. The data is regular bursts of 32 bits of recovered data sent multiple repeats approx once an hour.
I don't have a problem with the code to decode, It's how to do this at the same time as all these tasks:
1. Decode data from receiver.
2. Sample receiver signal strength (using A/D).
3. Monitor a single line bi-directional serial link as per the CCS example, to another PIC for a single character 'Poll'
4. Reply to the other PIC, although this could be delayed

All this in a 12F675 if I can.
I want to use the 12F675 PIC to do the RF decode to ease the burden on the main pic (18F252) as there will be a lot of false data on the RF link due to noise.
I can see that I need to implement some involved interrupt code to produce the pseudo multi tasking, but I just can't seem to get my head round where to start.
Anyone got any pointers (pun intended, but not very funny)?

For what it's worth I am a new user of CCS & PICs but found the compiler good value and this forum full of useful advice and helpful folk.
Regards,
Steve.

[Neutone]

Look this over. Maybe it will inspire you.

http://home.houston.rr.com/neutone/serial.c

[LomasS]

If only I could use a hardware UART.
The 12F675 has no UART so I need to do bit sampling on both the received radio data and the software serial port, this is the bit I'm struggling to visualise, no use of delay_xx() functions as I clearly can't sit in tight loops as I'll risk missing one or other inputs changing.
The only thing I can think of is multiple timers reset on each input bit state change incremented from timer interrupt at a suitable rate (10*bit width ?) then checking the bit period for validity on both the received radio data and the serial link.
Does this sound practical, anyone done similar?
I guess the ability to visualise these multi-tasks is what makes a good embedded programmer, I will get there one day but maybee I'll have torn all my hair out by then!

Thanks.

[kamyip]

lomass,

i have similar experience in doing RF rx and tx at the same time. like what you've just pointed out, the biggest problem is the responsiveness. However, using timer might not be the best solution .

1) as the distance between tx and rx increase, noise creep in ie your rx data will not be "clean". thus it is very difficult to determine the start of the frame.
2) the data you have tx might not be exactly the same when decoded out from rx. My painful experince in this is the rx signal actually skew a little from the tx data thus adding error to the decoding timing.

The following helps:
1) generating a header a several pulse -this is to give rx some time to stabilse
2) generate some form of syn pulse to let the rx know that this is the start of the frame
3) start tx data
4) finish of with a checksum error data just to make sure the correct data has been rx

5) have the rx transmit a "OK" response once correct data has been rx. if no "OK" is received then keep on tx-ing. Generate a timeout error if this is not succesful after a predefined time.


This might not be the best solution, but so far this scheme works well for me. I'm using 433.92Mhz and 418Mhz. The distance is about 100m.

[LomasS]

I too am going to use 433.92 and I will include the header, sync & checksum as you suggest.
My link is unidirectional so I can't send an 'OK' message back, but I intend to send the data repeated several times to help ensure it's decoded.
Thanks for your suggestions.