Receiving buffer

[Labjac]

Hope somebody can help.

I using a 16f690 pic with a max232 chip.

Receiving and sending data works fine, but according to the data sheet the pic only got a 2 byte buffer.

Problem is I want to add a string of about 20-30 characters before sending it to the pic, not sending character for character. The pic now only accepts the first two bytes then ignores the rest. Does anybody know if there are chips available that got a bigger buffer or is my understanding wrong? Or should I change my program (using a plc to send data) to send only two characters at a time ? And then store it as an array ?

Regards,
Labjac

[Ttelmah]

You need to look at two of the examples that come with the compiler.
EX_SISR.c, shows how to implement an interrupt driven circular buffer for serial receive. The EX_STISR.c, shows how to implement an interrupt driven transmit buffer.
Such buffers are common in everything. If you look at your PC, the UART hardware buffer is typically only about 8 characters in size, yet you can send/ receive hundreds of bytes without problems. The reason, is that Windows implements exactly such interrupt driven buffers for you.
I'd suggest if you have enough RAM, make your buffers 32bytes in size (the sample code only works efficiently with 'binary' buffer sizes - 2,4,8,16,32 bytes etc..). If space is really tight, odd sizes can be used, and a search here will find the code tweaks needed to make these work well.

Best Wishes

[asmboy]

To add to Ttelmahs excellent comments - if you ditch the inefficient
modulo % operator and use an if-then statement for buffer wrap ..
then - there is NO Loss of efficiency for ANY sized buffer your pic can handle.
w/o segmentation

[Labjac]

Hallo

Thanks again for the always quick response, I used the example code and it works perfect, but there is a line in the code I still don't understand, can somebody please try an explain this to me.

[temtronic]

With your project open, press F11 to gain access to the onscreen help files ! Mine's always open as an instant reference to CCS Compiler information.
% refers to a type of math, please look it up....I'm older and forget things....
but KNOW where the info is located !!

As for the next_in=next_out you have to visualize that this is a circular buffer and the 'pointer' has to point to the next available array element.it loops from 1,2,3,... to 32 to 1,2,3....etc.

[Ttelmah]

You code has a fault with a full buffer - you have an extra ';' that should not be there.

On '%', the thing is you want a number that can go through a range, from '0' to the 'buffer size-1', so (for example), with a buffer size of 5, would go:

0 1 2 3 4 0 1 2 3 4....

Now the '%' operator returns the remainder from a division, so if you had a number going 0 1 2 3 4 5 6 7 8.... and then divided this by 5, the _remainder_ would be:

0 1 2 3 4 0 1 2 3 4

Exactly what is wanted. _but_ the problem is that it is an appallingly slow operator when used with a size like '5'. To get the remainder, the processor performs a division by 5, then takes the integer that results, multiplies this by 5, and subtracts this from the original number. On a PIC16, even with an 8bit value, this takes about 170 instructions!. On the PIC18, it is faster, but still takes about 117 instructions. Even worse, since this involves using the integer division code inside an interrupt, interrupts _will_ be disabled wherever the same code is used outside the interrupt....

The alternative to using '%', is to use the 'if' test. All you do is:

if (++counter == buffer_size) counter=0;

Here counter goes:

0 1 2 3 4, then on the next increment, it == 5, so jumps back to 0, exactly as needed. This takes only half a dozen instructions.

So you want either:

next_in=(++next_in) % BUFFER_SIZE;

or

if(++next_in==BUFFER_SIZE) next_in=0;

The latter is the better solution.

The former does work OK, if a binary buffer size is selected, since the compiler then replaces the '%' operator, with a binary and, which is almost as good. It is a case of a bit of 'careless' programming by CCS, which doesn't cause any problems as done, but does if you change the buffer size without being aware of the limitations.

So: