| View previous topic :: View next topic |
| Author |
Message |
Franck
Guest
|
| printf without #use... |
 Posted: Mon Aug 20, 2007 9:24 am |
 |
|
Hi everybody,
Is it possible to use printf without #use rs232... initialisation ? In other words, can I initialize the uart myself and then use printf ?
I would like to do that to be as close as possible of ansi C. I don't like to use buil-in functions.
Regards.
Franck |
|
 |
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Mon Aug 20, 2007 10:26 am |
|
|
| I'll bet the answer is no unless you want to set the bits in the control registers directly and probably incurring not only non standard C but even incompatibilities between various PIC's. Printf is built into all c compilers that support it. At some point in the process the rubber has to hit the road and an ascii char has to be serialized and sent out of a specific pin bit by bit at a specific baud rate with added features like stop bits and parity. #use RS232 supplies the pins for TX and Rx, baud parity etc. its necessary information. Remember PICs are silicon devices with specific features. When your universal view of C hits the silicon only the features that are in silicon will work. PICs aren't designed to support every feature of C but CCS C is designed to support every feature of PIC's. The CCS C extensions via built in functions for me represent the PIC features in silicon. For example if the PIC has I2c and you wish to use I2c then # UseI2C makes that feature available. |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Aug 20, 2007 10:32 am |
|
|
It is perfectly possible.
All you do, is generate your own 'print a byte' function (instead of putc), and call printf, with:
printf(your_function_name,definitions",stuff to send);
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Mon Aug 20, 2007 11:59 am |
|
|
Douglas Kennedy wrote:
| Quote: |
1) When your universal view of C hits the silicon only the features that are in silicon will work.
2) PICs aren't designed to support every feature of C but CCS C is designed to support every feature of PIC's.
|
These that seems obvious, are the best definitions that I have read regarding the continuous
dispute of embedded C & ANSI C.
Humberto |
|
|
Guest
|
|
| Posted: Tue Aug 21, 2007 1:07 am |
|
|
Thanks for your answer. I missed the thread talking about this.
Douglas, I don't to write pure ansi C code for fun. But the less the program is compiler dependant, the more portable it is. If I design a device for a customer and give him the source code, what happend if the guy want the program to be compatible with his compiler ? |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Tue Aug 21, 2007 8:44 am |
|
|
Guest says
| Quote: | | I don't to write pure ansi C code for fun. |
Having source code that in its ideal form will run on every compiler and run on every piece of silicon....well why wouldn't everyone want that? The issue is with the silicon ....the PIC devices we have are targeted to specific applications...the silicon to do everything is missing. Some might argue PIC's should be like Intel CPU's and able to play DVD's and run multi-megabyte operating systems and come with 500W power supplies. Perhaps that will be the future. For now PIC's are utilitarian and come in many varieties each with its own niche market. The application picks the PIC and the PIC the compiler its very spartan in its bottom up concept. The minimal amount of silicon up to the task is chosen and everything follows from that. Some say the world we live in ( electro-magnetism) is just electrons moving from place to place. The pragmatic energy efficient approach is to only move the electrons that are needed for each application no more no less. |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Tue Aug 21, 2007 10:57 am |
|
|
| Quote: | | I don't to write pure ansi C code for fun. |
I am not willing to sacrifice product size, weight, battery life, or anything else that matters to the end user for the sake of ANSI compatibility. I do use CCS C instead of assembler because that cuts end product cost. If using 8 bit integers means I can use a slower crystal, I will get longer battery life which can increase product sales. ANSI compatibility doesn't do that for me.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
