CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

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

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
RogerM



Joined: 07 Jun 2004
Posts: 10

View user's profile Send private message

uart1.c and uart1.h vs "standard" CCS serial I/O
PostPosted: Sat Nov 30, 2019 6:13 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sun Dec 01, 2019 1:33 am     Reply with quote

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



Joined: 07 Jun 2004
Posts: 10

View user's profile Send private message

PostPosted: Sun Dec 01, 2019 2:48 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sun Dec 01, 2019 2:55 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group