Page 2 of 2

Re: USART without "USART.h"

PostPosted: Mon Aug 04, 2014 1:59 pm
by Dimebag
16 bit core threads includes 18f etc.
This is the 16 bit core forum. For show and tell, go back to 5th grade.

Re: USART without "USART.h"

PostPosted: Mon Aug 04, 2014 2:44 pm
by Dimebag
Hi Olin,
My point was more that he neglected to ask a question. I assumed this to be a oversight.

People need to learn to ask what they want to know, not employ silly word games. For example, stupidly asked questions like "Does anyone know ..." deserve short answers like "Yes, surely someone does". Unfortunately on busy forums there is always some wannabe that can't resist the temptation to look smart and blurts out the answer anyway.
I am direct sir. I ask questions due to the fact I don't know the right answers to give to the next question. I am still developing some knowledge to provide useful questions to submit.

Re: USART without "USART.h"

PostPosted: Tue Aug 05, 2014 1:20 pm
by tunelabguy
Dimebag wrote:I have been reading the datasheet for 18F452. I am just trying to make a start on using the datasheets to program in C without using the (read.c) and (write.c).
....

If you are looking for confirmation that accessing the UART without using a compiler vendor's packaged interface functions is an OK thing to do, I can confirm that it is. I do it myself all the time. I use the CCS compiler, but I have never used any of their peripheral interface functions. I like to program by directly accessing registers as they are documented in the PIC datasheet. Often a compiler vendor's peripheral interface function is more difficult to adapt to than the basic PIC registers themselves, and it adds another level of uncertainty regarding function usage and execution time. With my own implementations, especially the time-critical ones, I can look at the disassembly of my C code and fine-tune performance characteristics to match my application requirements. Also I find that Microchip has done a pretty good job in documenting their peripheral registers - perhaps a better job than the compiler vendors have done in documenting their function calls. So I find I am losing very little by avoiding the compiler's peripheral interface functions.