|
|
View previous topic :: View next topic |
Author |
Message |
hello188
Joined: 02 Jun 2010 Posts: 74
|
putc, printf, fputc, fprintf, etc Question |
Posted: Thu Jul 26, 2012 12:39 am |
|
|
Hi, fellow programmers.
When using CCS-provided EUSART function to send data, does it allow multi tasking?
For example, let say i use
If myString has length of 5, and baud rate is 4800, it takes 11/4800*5 = about 11ms to completely send the string. Does the program wait 11ms seconds? or does it run in back ground using #INT_TBE?
Because in real time application with program cycle of only about a few ms, we can't afford to wait that long.
Anyone idea? Thank you. |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Thu Jul 26, 2012 1:15 am |
|
|
Don't know whether the built-in routines do that for you. I strongly suspect they are blocking.
That's an application where I'd implement my own circular buffering and interrupt driven transmit routine. I tend to do that anyway for any serious serial-using application.
That way you have full control, and you use sprintf and its cousins to format the data prior to buffering it.
RF Developer |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19496
|
|
Posted: Thu Jul 26, 2012 1:16 am |
|
|
The standard io functions in CCS, are blocking, except for the fractionally under two characters of hardware buffering in the chip itself (for PIC16/18). So if you are using the hardware UART, and send "Fred", the call will return after the 'F', and the 'r' are sent.
So in your '5 character' example, after 6.24mSec.
Remember there is no 'OS' behind the code, so nothing to handle buffering.
To buffer the output, use EX_STISR.c, which contains an INT_TBE handler and buffer example. In CCS, printf etc., are 'expanded' over the standard functions, in allowing _you_ to specify the routine they send to, so if you include the data definitions, #int_tbe code and bputc from EX_STISR, then you can call printf, with:
printf(bputc,"The string to print");
or
printf(bputc,"%s",myString);
and the characters will be buffered (you have to enable global interrupts in your code as well).
Best Wishes |
|
|
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Thu Jul 26, 2012 7:20 am |
|
|
Asynchronous serial I/O by the PIC MCU is often conflated with the I/O experience encountered with a PC. A PC OS will have massive hidden buffers and will time slice (share CPU cycles) as well as use hidden hardware interrupts.
The method with a PIC that is most likely to get the results that a PC experience gives is to use circular buffers driven by the corresponding I/O interrupts and matching ISR's. A modern PIC will usually have enough RAM for these buffers. Anyone interested in success with their PIC serial I/O should first study EX_STISR.c.
CCS is good at giving built in functionality it might be a good idea to have an extension to printf say bprintf that behind the scenes creates a buffer and the isr. Or maybe it is added to the #USE something like BUFFERED=64 for a 64 byte buffer. So many PIC coders don't look at EX_STISR.c
and then have an unsuccessful experience with serial I/O. |
|
|
|
|
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
|