does putc block?

Simon · Guest

Hi,

I am wondering if the putc function blocks until the byte has been sent or if it writes to a buffer and returns?

If I write:

putc('A');
putc('A');
putc('A');

Is this relatively slow?

Cheers,
Simon

Ttelmah · Guest

With a software UART, it waits for each character. With a hardware UART, it transfers the character to the internal hardware buffer if possible, or waits for this to become empty if not.
For the three characters shown, assuming the UART buffers are empty, the first two characters will transfer immediately, and then the third character will block, and wait till the first character is sent.
If you want a fully 'non blocking' version, then use the TBE interrupt, and a software buffer.

Best Wishes

Simon · Guest

Yeah, that explains a few things - sort of.

I have noticed that the code execution slows down dramatically by moving from a two byte response to a three byte response, which you have explained.

What concerns me is that it appears that my interrupt routines are not being serviced until after the third byte is sent. I will try implementing it in software as you suggest - it is my preferred approach, but if putc is not blocking my interrupts then I am still unsure what is going on...

Thanks,
Simon

Ttelmah · Guest

This is a buffered transmit routine, that I use without problems:

future · Joined: 14 May 2004 Posts: 330

So there is no way around blocking if I want to send a full 80x25 screen?

I am experimenting a tx thread that accepts pointer and length of data. It fills the buffer when possible and decrements the length or returns if buffer is full.

Ttelmah · Guest

Depends on the size of your PIC.
The posted buffered transmit code, cn be modified quite easily (int16), to handle buffers of a couple of thousand characters, if your PIC has this much RAM.

Best Wishes

future · Joined: 14 May 2004 Posts: 330

Yes I understand that the buffer must be able to hold the full string. I was just wondering how computer OS's does with its buffers...

Ttelmah · Guest

If you look at the standard 'PC', the UART itself, on the oldest units, has typically 16 characters of buffering, and on some of the new high speed versions, have up to 1KB (many of the USB 'UARTs' have this as well). Then the software in the PC, typically has in excess of 1KB of it's own buffer. Yet even then, the PC will often 'block' if asked to send large amounts of serial data. Remember that the PC is running a 'timeslicing' OS (the nature of the switching depends on the OS), so when a particular program 'blocks', provided it is reasonably written, the other programs remain running. So jobs carry on being 'done', despite the system waiting for the transmission. The same can be done on the PIC, with careful programming.

Best Wishes

Zer0flag · Guest

Hi all!

First I tried the buffered putc routine from the book "Embedded C Programming and the Microchip PIC" written by Barnett, Cox and O'Cull. As far as I can see their routine is also used in the code library in this forum under topic "Communcation between PIC's using wireless RS232". Unfortunately I had some problems with that routine. When I output a lot of chars (more than the buffer can hold) this routine makes my program freeze for some reason.

So I tried the nice buffered putc routine posted in this thread by Ttelmah and it works great. Thank you once again Ttelmah! BTW I had to add a missing bracket in the following code line to make the code compile:

Ttelmah · Guest

There are two basic ways of performing single operation buffer size arithmetic.
1) Use the modulus operator (%).
2) Use the binary '&' operator.
My code uses the latter (and if it is the full version, should comment that it does).
The former will allow non binary multiple buffer sizes.
The difference, is code size, and speed. The compiler in latter versions, is smart enough, that if you use the modulus operator, with a fixed binary buffer size, it'll switch internally to using the '&' form. The difference is massive. For example, using a binary buffer size, the '&' form, takes typically just one instruction (plus about four instructions to access the value). The modulus version, takes about 120 instructions in total.
So, for simplicity, I use binary buffer sizes, to give the best performance.

The best way of handling non binary buffer sizes, is to instead use the increment and test approach. So (for the 'out' counter):

Zer0flag · Guest

Thank you for the good explanation Ttelmah!

Best regards,
Zer0flag

Zer0flag · Guest

I have some more comments and questions regarding Ttelmah's buffered putc routine:

The problem with the routine is, that it outputs 0x00 for the number of bytes in the buffer when it starts. I think this is because the variable RSTcount needs to be initialized to STBUFF (i.e. the size of the buffer) first instead of leaving it unitialized. This is because RSTcount represents the number of free bytes in the buffer and it is not 0 at start up but should be the size of the buffer:

Ttelmah · Guest

The code has been mistyped. The original version, tests _TXIE_, not _TXIF_. TXIE, says that the interrupts are disabled, which only occurs if the chip has finished sending all data, and the interrupt routine has turned the interrupts off. In this state, all that is needed is to transfer the byte directly to the hardware.
The original code was posted in the thread 'Multi-Interrupt' (ID 22953), and includes initialisation, and doesn't have these errors. There is a slightly different version in the thread 'RS232 losing first character transmitted', which is slightly less efficient (it calls the interrupt even for the first character), but is slightly smaller.
I don't know where the mistyped version came from, I just cut and pasted from a search in the forum, and didn't check that it _was_ my original code....

Best Wishes