uart1.c and uart1.h vs "standard" CCS serial I/O

[RogerM]

I noticed that in the EZZ_APP and the CCS bluetooth functions they use some special uart functions uart1.c uart1.h, etc . These appear to interface behind the scenes with the standard CCS functions but am not sure why they needed.

My reason for asking is that I have used serial for many applications, always with the standard CCS functions. Now I am working on connecting to a bluetooth module, not the RN4020 but that is a different story. This is via a serial connection from the PIC. I have used the uart1 based code and have had a few issues that I'm working on. Using the uart1.c makes the code more complicated. So was wondering if there was a special reason reason for it?

any suggestions?

[Ttelmah]

The give interrupt driven serial buffering, and wrapper functions to control
the UART settings. Read the top of uart1.h which describes what is done.
They are not exactly complex.

[RogerM]

I was under the impression, which sounds like I'm mistaken? that if in the #use RS232 I specified

RECEIVE_BUFFER=x - Size in bytes of UART circular receive buffer, default if not specified is zero. Uses an interrupt to receive data, supports RDA interrupt or external interrupts.

with x = 60 in my case

And I as was using a hardware UART the I would get an interrupt driven receive code without having to do what uart1.c does.

In my case where I'm adding a Bluetooth "board" to provide a serial cable replacement I would never want to change the UART characteristics so I don't need that .

What happened to cause me to ask the question is that I am using bluetooth to connect an Android device to 2 different PIC based devices, one has a PIC18 and the other a PIC24. I uses CCS compilers, latest version. Both of them use UART 1 to connect to the Bluetooth. I had some difficulty in getting the "conversation" between the PIC and the BT right. This caused by incorrect setting in the BT board causing it to switch between COMMAND and STREAM mode. using the CCS debugger on the PIC 18 I found from the symbol table RCV_BUFFER_1 which showed the buffer used bu the serial I/o on uart1 and it held a record of what the BT Device had sent so I was able to figure what the BT Device was up to. Then I moved the code to a PIC 24 and has a similar but not identical problem but when I tried to use the same approach the symbol table did not have RCV_BUFFER_1 but it did have a RCV_BUFFER_2. I believe that the number 1 or 2 related to the UART and I was using UART1 in both cases.

RCV_BUFFER_2 held some information that looked a little odd

So tracing through the uart1.c code and the CCS bluetooth modules that I modified to use with a Silicon Labs Gecko BT had lots of #defines and verifying that there were right is hard as there are many places where it could be wrong - and hard to produce a 'simple' example to attempt troubleshoot the root problem.


Roger

[Ttelmah]

Yes. However the problem is that this has no handling for overflow.
The added code inserts handling for this.
It also gives easy to use testing for the amount of data held in the
buffer etc.