Passing serial messages between UARTs (PIC24F)

KTrenholm · Joined: 19 Dec 2012 Posts: 43 Location: Connecticut, USA

Hi all.

I've got an interesting conundrum I've been working on and I need some help on getting the UARTs working properly.

I am using a PIC24FV32KA304 on PCWHD 4.132. The clock is a 18.432MHz crystal.

I need to take any serial communication coming in from UART1 and pass it through to UART2 and do the same thing from UART2 to UART1.
In short, I need to connect the device on UART1 to UART2 with my board as a "middleman" of sorts.

The issue is that the baud rate is pretty quick at 115200 baud. It's a serial programming stream about 1MB in size, so it's sending a constant stream of characters for a relatively extended amount of time (about 90 seconds is typical). My normal way of accomplishing this would be to take the received character in the RDA_ISR and put it out via fputc(). My code for this is below:

jeremiah · Joined: 20 Jul 2010 Posts: 1329

Check the assembly, but I would guess your original issue was with the fputc() calls in the interrupts. Those would probably cause unwanted delays in the receive interrupts which would propagate over time. Since the PIC24's have a 4 character buffer, when they fill, fputc typically waits for the buffer to have space before finishing, which would delay your ISR from receiving more data. Also, check the errata on that chip. I seem to remember there being some TX related issues.

Have you tried a set of buffered serial receive ISRs with the main generating the output streams after reading the buffers (or possibly interrupt driven TX as well)?

The ex_sisr.c file that comes with your compiler in the example's folder shows a pretty decent example of how to do buffered serial receive ISR. The only thing to watch for is they use a % operator to handle the indexing. This is only fast for buffer sizes that are powers of two. For other buffer sizes, you would need to use a different approach.

The idea is you make a buffer just large enough to give you time to transmit out everything before the buffer fills up.

KTrenholm · Joined: 19 Dec 2012 Posts: 43 Location: Connecticut, USA

temtronic · Posted: Tue Feb 11, 2014 2:11 pm

I've used the ex_sisr.c example at 115k200 and have never lost a byte of data doing what you want to do. in-uart1---->out-uart2 using the 18F46k22.I use a 128 byte buffer.Depending on what else the PIC has to do,you might need a bigger buffer.

Always test with known data though, just because it 'looks' like it works doesn't mean it really does!

hth
jay

jeremiah · Joined: 20 Jul 2010 Posts: 1329

As an additional note, you shouldn't need to buffer the entire 1MB data, just enough of it to keep up.

In your previous example, you were losing time because you were delaying the interrupt. If you take the fputc calls out of the ISR and use buffered serial input, then those will run faster than the incoming serial data. From that point, your main just needs to get data out faster than it can service the buffered data. That is more dependent on your other non serial tasks in main.

I have no clue what the rest of your program does, so as an example, say that your program does 20ms worth of processing not related to the serial in/out. That means your buffer needs to be large enough to cover 20ms + a little bit to handle the time it takes to move data from the software buffer to the hardware UART (not very long). In that case, you would want a buffer that is higher than 231 bytes (20ms of down time at 115200 BPS...10bits per byte). If your processing in main takes only 10ms, it would take a buffer only half the size.

On the flip side if your program main does nothing else but output the buffered serial data, then the buffer doesn't need to be very large at all (maybe 16 bytes? just guessing there).

EDIT: alternately, if your main is too slow to have a big enough buffer, you can try interrupt driven transmits as well. That would reduce your overall buffer needs in a really slow main() scenario.

You are right in that you do not have a lot of RAM. Those chips are not really designed for high RAM apps. They are designed for low low power and very very small board space applications. I use the F versions of these a lot. You aren't going to be making use of the super low power since you are using UART and you cannot perform UART in sleep mode. Other chips have similar sizes (aside from needing an external EEPROM).

If you are truly worried about RAM, you might consider a different chip. The PIC24FJ256GA106 has around 16k RAM if I remember right (maybe it is 8k, but you can verify either way). Having sub 2k RAM on that chip is very limiting.

KTrenholm · Joined: 19 Dec 2012 Posts: 43 Location: Connecticut, USA

jeremiah · Joined: 20 Jul 2010 Posts: 1329

That can run automatically if you use the OCx pins. Check the output compare section for the PWM.

Gabriel · Joined: 03 Aug 2009 Posts: 1067 Location: Panama

Is flow control not an option?
_________________
CCS PCM 5.078 & CCS PCH 5.093

KTrenholm · Joined: 19 Dec 2012 Posts: 43 Location: Connecticut, USA

Nah can't do flow control. This application needs to drop right into an existing environment which doesn't use it.

I did get it working though!
At the reception of a serial command the program drops into a limited process loop that keeps some of the attached buttons responsive and passes all transmissions from UART2 to UART1 (and vice-versa) via 2 buffers. The whole stream went through no problem. Pretty much followed the EX_SISR.C example as recommended earlier.

jeremiah · Joined: 20 Jul 2010 Posts: 1329

Just remember to keep BUFFER_SIZE a power of 2 (and make sure that is highlighted in your comments next to the #define). The % operator takes a long time to execute otherwise and could slow you down too much.

KTrenholm · Joined: 19 Dec 2012 Posts: 43 Location: Connecticut, USA