"TASK_priority"

[kmp84]

Hi All!
Many of my projects are "focused" into digital packet (rs232,rs485 serial async.) communication with Master (PC) devices. About this reason for me replay from PIC(Slave) to PC(maste) MUST ALWAYS present.

In my last project (digital thermo controller) i have rs485 half duplex communication and 4 DALLAS "1-wire" temp sensors. Some time when PIC communicate with 1-wire devices replay to MAster (PC) not present, because CPU in use with i.e one_wire reset(); write_byte()...and other function. Any idea ...???

P.S : I've used #INT_RDA interrupts,Linear packet buffer method for receive serial data, CCS 4.104 compiller ver., PIC16F648A,periodically #INT_TIMER2 to get data from temp. sensors.
Thanks!

[Ttelmah]

First, switch to a small circular buffer, and assemble your linear data outside the interrupt. Problem with linear buffers, is they always involve some form of 'extra work', at the end of the buffer when a complete packet has been seen, and you only have one character time (potentially), before the first character of the next buffer load arrives. It is generally better to have a small circular buffer (say just 8 characters), and then have your main code perform the operations on this as if they were arriving from the UART.
Then add a similar buffer for your RS232/485 transmission. Make this large enough to hold the biggest string you are going to send. You can then use a buffered printf, when you want to send a message, and not have to wait for transmission - keeps the code flow in the main routines quick.
Don't use 'INT_TIMER2' to get data from the temperature sensors. Instead, in your new (quick) main loop, _poll_ a flag. Set this flag with INT_TIMER2, and when it is seen, then read the sensors. You have already found the problem with reading anything like a sensor inside an interrupt. Don't....

Best Wishes

[kmp84]

Thanks for your fast and good answer Ttelmah!
Can you post a some example for circular buffer,buffered printf for transsmision.? If you want I'll put my current code ver. project.

[Ttelmah]

You already have quite good examples with the compiler. EX_SISR.c for the receive (make sure if you use this example, that you keep the buffer size a binary multiple - 4,8,16,32 bytes etc., or search here for how to do other sizes - has been covered hundreds of times - basically test, rather than using '%'), and ex_STISR.c for the transmit (same comment on buffer sizes....).

Best Wishes

[kmp84]

I saw the ex_sisr.c and ex_stisr.c, and one question ?
What will happen if I use rs485 half duplex (sn75176) and #int_rda and #int_tbe occur in same time.?

[Ttelmah]

Half duplex, they can't!.....
However full duplex, no problem. Because the interrupts are _short_ (only about 30 machine instructions, plus the 60 instructions for the global interrupt overhead), at 4MHz, the worst case is under 100uSec to handle either interrupt, while at higher clocks, it is proportionately faster. If INT_TBE is set as the higher priority, it'll be handled first, and you have an entire character time on the receive, before the UART will overflow (remember the INT_RDA, triggers when one character is in the input latch, and there is a separate input shift register, which takes a further character time to fill, even if the data is arriving continuously). Alternatively if INT_TBE is given the lower priority, all that will happen is that you will have a gap of the time taken to handle the RDA interrupt, in the output data 'stream'.
The key though is always keeping the interrupt handlers as short as possible. If _any_ interrupt handler takes longer than a character time to complete, you will get lost data (your problem with timer2).

Best Wishes