USART without "USART.h"

(instructions, reset, WDT, specifications...) PIC17Cxx, PIC18Fxxx

Re: USART without "USART.h"

Postby Dimebag » Mon Aug 04, 2014 1:59 pm

16 bit core threads includes 18f etc.
This is the 16 bit core forum. For show and tell, go back to 5th grade.
Dimebag
 
Posts: 109
Joined: Sun Jun 29, 2014 7:51 am
Location: Sydney, Australia

Re: USART without "USART.h"

Postby Dimebag » Mon Aug 04, 2014 2:44 pm

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.
Dimebag
 
Posts: 109
Joined: Sun Jun 29, 2014 7:51 am
Location: Sydney, Australia

Re: USART without "USART.h"

Postby tunelabguy » Tue Aug 05, 2014 1:20 pm

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.
User avatar
tunelabguy
Verified identity
 
Posts: 29
Joined: Sun Jul 20, 2014 9:41 pm
PIC experience: Professional 5+ years with MCHP products

Previous

Return to 16-Bit Core

Who is online

Users browsing this forum: No registered users and 9 guests

cron