 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Zer0flag
Guest
|
| putc timeout? |
 Posted: Thu Feb 21, 2008 5:19 am |
 |
|
Hi all!
Reading the forum it looks like putc() is described as a blocking function. Though when my PIC is not connected to a PC my program just continues to work and does not block. So there must be some timeout?
Best regards,
Zer0flag |
|
 |
Ttelmah
Guest
|
|
| Posted: Thu Feb 21, 2008 6:28 am |
|
|
More complex than this.....
A _single_ putc, to the hardware port, will return immediately.
Three putc's to the same port, will wait till the first sends, before returning.
On a 'software' UART, putc will wait till the character is sent, before returning.
Normally, unless you add tests for RTS/CTS, putc itself, will send data, whether the connection is present or not (this is almost certainly why your code does not function differently without the PC).
Getc, _will_ wait till data arrives (and hence block).
Best Wishes |
|
|
Zer0flag
Guest
|
|
| Posted: Thu Feb 21, 2008 7:00 am |
|
|
Thank you for the fast reply Ttelmah,
I am using the HW UART on a PIC18 and when my program starts it sends an identification string to the RS232:
| Code: |
#use rs232(baud=19200, parity=N, bits=8, stop=1, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
//-------------------- Outputs a char to the rs232, can also send strings
void rs232_putc(char c)
{
putc(c);
}
//------------- Sends the identification string of the device
void rs232_send_ident()
{
rs232_putc("MANUFACTURER ");
rs232_putc(DEV_MODEL);
rs232_putc(", HW: ");
rs232_putc(HARDWARE_TYPE);
rs232_putc(HARDWARE_VERSION);
rs232_putc(", SW: v");
rs232_putc(SOFTWARE_VERSION);
rs232_putc(", Ser#: ");
printf("%lu", SERNUM);
}
|
So there should be more than 3 putc() but the function does not block my program... |
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Thu Feb 21, 2008 8:05 am |
|
|
More importantly How the hell is your program working ?
Passing a string (pointer) to a function which accepts only a char should not compile let alone run. |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
| Re: putc timeout? |
| Posted: Thu Feb 21, 2008 8:08 am |
|
|
| Zer0flag wrote: | Though when my PIC is not connected to a PC my program just continues to work and does not block.
|
Using just the usual RS232 RX & TX lines the PIC has no way of knowing if anything is connected to the other end of the wire. It won't behave differently if the PC is or is not present.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Feb 21, 2008 8:58 am |
|
|
| Wayne_ wrote: | More importantly How the hell is your program working ?
Passing a string (pointer) to a function which accepts only a char should not compile let alone run. |
It'll run, because this is a standard 'shortcut' in CCS C, to get round the lack of support for constant pointers. If a function that expects a single character, is called with a constant string, the compiler automatically calls the function multiple times, once for each single character.
To ZeroFlag, read the penultimate line of my reply. Putc, actually _never_ blocks. It'll _delay_ by one or more character times, but unless _you_ add tsting for line status (RTS/CTS), the function wil always just send the data, and not care at all about what is at the other end...
Best Wishes |
|
|
Zer0flag
Guest
|
|
| Posted: Thu Feb 21, 2008 10:03 am |
|
|
| Ttelmah wrote: | | To ZeroFlag, read the penultimate line of my reply. Putc, actually _never_ blocks. It'll _delay_ by one or more character times, but unless _you_ add tsting for line status (RTS/CTS), the function wil always just send the data, and not care at all about what is at the other end... |
Thank you for the clarification. So I will assume that my character sending does not block and will not slow down my program significantly. This means that there is no need to implement an interrupt triggered send buffer, right?
Best regards,
Zer0flag |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Fri Feb 22, 2008 5:33 pm |
|
|
| Remember the transmission and reception are asynchronous. Consider the PIC when its transmitting then it cannot guarantee that the sender is ready nor can it always assume that its transmit hardware is finished with the last character. Now most PIC code is written to send chars with out regard to the receivers situation. Most often it is a PC with speed and buffer advantages that make it unlikely it can be overrun. In the PC case the TBE isr may not be necessary or even wanted. Now back to the PIC. Suppose your PIC code at some moment has oodles of chars to send. Then the chars could be written to a buffer and a TBE isr would chew on the buffer sending the data at the baud rate chosen ( as if in background). While the isr chews on the data your PIC is fee to move on and do something else. As long as the average transmission out through put is less than the max baud rate you have effectively burst a chunk of data into a buffer at MIPS speed rather than chugging along at baud speed. I would guess most writing code for a TBE isr have a transmit buffer in mind. |
|
|
Zer0flag
Guest
|
|
| Posted: Mon Feb 25, 2008 10:08 am |
|
|
| This is a really good explanation Douglas. Thank you very much. BTW, can you think of any *disadvantages* a buffered interrupt driven transmit routine may have? |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
