Problem using #INT_RDA and #INT_TBE for RS232 communication

ElectronPIC · Joined: 26 Dec 2016 Posts: 9

Hello everybody!

I'm relatively new on C programming on PICs and I'm having problems in getting RS232 communication working right. So any help I can get would be appreciated.

What I want to do is to send a chain of commands to the PIC from a PC through RS232 and getting a reply on the PC.
I'm using the #INT_RDA interrupt to receive characters and save them in a buffer called BufferIn. I'm using the #INT_TBE interrupt to send the characters of the reply.

When the reception buffer (BufferIn) is full, I disable the #INT_RDA interrupt until all commands in the buffer are decoded. So I accept that some commands can be lost.

In principle, seems to work well. But the problem is that SOMETIMES, after that BufferIn gets full and all commands are decoded, when reception restarts there are some garbage characters that appears at the beginning of the buffer. I don't know why is this happening.

For the test, I'm using chains of "commands" wich are ended with a line feed character <LF>: [A<LF>BB<LF>CCC<LF>...GGGGGGG<LF>].
When I send four chains (from A<LF> to GGGGGGG<LF>), sometimes appears the garbage characters I'v mentioned.

The code I'm using is this:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

The UART has a 2-deep receive fifo and the incoming shift-register.
It will still load up with characters, even if you shut off interrupts.
To clear the buffer, see the clear_uart() macro by Ttelmah in this post:
http://www.ccsinfo.com/forum/viewtopic.php?t=55147&start=7&highlight=clear_uart

ElectronPIC · Joined: 26 Dec 2016 Posts: 9

ElectronPIC · Joined: 26 Dec 2016 Posts: 9

Well, I've looked at the post and I think I'm doing the same thing to clear the buffer before enabling it. The problem persists. When I send a long string of commands, when I start receiving characters again the garbage characters appear at the beginning of the buffer.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I didn't actually look at your program before. I just read your symptoms
and thought of the usual solution.

I didn't look closely at your code, but here are some suggestions.

1. Post your #fuses statement, and anything else near the top of your
program which is not shown.

2. Disable the Watchdog.

3. Get rid of malloc code as a test. Substitute global arrays. Declare
the size of the arrays. My point is, you've got a ton of malloc's.
Do we know that malloc works 100% in vs. 5.015 ? I don't know it.

temtronic · Posted: Mon Dec 26, 2016 5:47 pm

I'd like to see what happens when you use the CCS supplied examples of ISR for both xmt and rcv. I know ex_sisr.c works well....

Just a thought......easy enough to merge/compile/test....

I have to 'second' the 'get rid of the WDT' !

Jay

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

stop disabling the RDA and TBE interrupts.
then
Try to just do a clever job of parsing your RX buffer instead.
see if that helps. consider making bufferin 32
and do you really need such a big buffer out ??
based on when /what you transmit -why so big ??
look at the ccs examples ...

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

RDA interrupt agree wholeheartedly.
However the TBE interrupt _has_ to be disabled when there is nothing to send.
Honestly leave INT_RDA enabled, set a flag when the command is seen, and do the parsing in the main code.
Consider 'swap buffers'. Have two RDA buffers. Have a flag to say which one is to be stored to. Then INT_RDA stores data into buffer[0]. When the command complete is seen, set the flag to say 'command seen', and start storing to the beginning of buffer[1]. In the main code parse the command from the buffer that is not being saved to.

kieranjefferies · Joined: 22 Dec 2016 Posts: 6 Location: Ireland

Hi, this is my first post here and hopefully I am replying to the topic...
Problem using #INT_RDA and #INT_TBE for RS232 communication.

I've been using CCS since way back when the compiler was distributed on floppy disk. I'm on 5.066 now Smile

.

Before I ask my question, I'd like to say a big THANK YOU to PCM_programmer, Ttelmah, temtronic, asmboy and all the other super contributers to this forum for all your posts, insight and help down through the years...

My question is on the use of #INT TBE. I've never used it yet religiously use #INT RDA to construct incoming packets and I guess I've been relying on the compiler to handle the transmission of packets of data. My question is... when would you guys use the #INT TBE ?
Thanks
Kieran

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

I use it all the time.

Have circular receive buffers on all incoming serials and similar buffers on all transmits.
Look at the example ex_stisr.c
Rewrite this not using '%' (a search here will find details on this), or always use 'binary' buffer sizes (4,8,16 etc.), and it is a good routine. It waits if the buffer goes 'full'.

newguy · Joined: 24 Jun 2004 Posts: 1909

I too use it all the time. That said, in my opinion it's the most "dangerous" interrupt because a mistake on your part will result in the PIC locking up.

As for why it's necessary? If you use a standard transmit routine (no TBE interrupt), you're effectively causing the PIC to completely stop what it's doing while it transmits. Even if you're using interrupts, the PIC can't attend to their "main loop" processing because it's effectively locked, focused on the transmit task.

...In my mind, just as big of a sin as using floats unnecessarily.

kieranjefferies · Joined: 22 Dec 2016 Posts: 6 Location: Ireland

Thanks Guys. Yes I can see in the assembly code of putc where the PIC is tied up waiting for TXIF to be set. My Tx and Rx routines have always been structured with start of transmission, command, n data bytes, checksum and end of transmission, all packets are validated on both ends of the link and yesterday when I saw the reference to #INT TBE, I was wondering how am I getting away without using it - and why would I use it... so both questions now answered.. putc looked after the timing and no TBE IRQ ties of the PIC during packet transmission,

Thanks again
Kieran

ElectronPIC · Joined: 26 Dec 2016 Posts: 9

Thank you all for your answers!

temtronic · Posted: Thu Dec 29, 2016 3:54 pm

re: WDT

WDT should be disabled until you're 100% confident your code is correct and 'market ready' THEN enable the WDT and see what happens....
WDT testing could easily take another week or 2....

It needs to be disabled(off) during development as any 'quirk' in your code or even a compiler 'bug' _might_ go 'funny' causing the WDT to trigger when really it's YOUR code , not the WDT that reset the PIC.

Nothing can cause more grief than trying to figure out what's gone 'wrong' when something else leads you to the wrong path or conclusion...

Jay

kieranjefferies · Joined: 22 Dec 2016 Posts: 6 Location: Ireland

Hi ElectronPIC, the reason you don't want to disable the RDA Interrupt is basically, you have no control over when bytes of data will arrive at the receiver input and if you don't read in and process / parse these byes before the arrival of subsequent bytes, they are over-written and lost. You could implement a solution without the RDA Interrupt if you had a very low baud rate, delays between subsequent bytes etc and dedicate most of your program resources to monitoring the serial port flags. But once you master the use of the RDA IRQ, you can create elegant and efficient routines which handle all communications reception with minimal impact on your main program.... the reception of data happens in the background. You can bring this to the ultimate level where the main program loop is notified of the reception of a complete & verified packet of data...