How to use uart Receive interruption (rda)

[qwwe]

Hello
If possible,
An example is to interrupt the rda serial and change the buffer size of the received information.
How to use uart interruption ?
For example, if you receive 100 characters in a buffer at a moment, how do we change the buffer size so information is not lost?

[temtronic]

An example for ISR buffer driven RS232 is included in the examples that CCS supplies. It's call 'ex_sisr.c', located in the examples folder.
As well, if you 'search' this forum, you'll find a few posts that 'tweak' the program for better performance.
As for buffer size, 'old school' design would be to make the buffer twice (x2) the size of the maximum anticipated data stream length. However you need to know the PICs RAM size and what variables you need to store. I tend to make buffers 'binary' in size, like 128, 256, etc. Just something I've done for 40 years...

Jay

[qwwe]

I have seen the example I said, but I did not understand if you could get a simple example.

[PCM programmer]

Read Mr. Kennedy's replies on how Ex_sisr.c works:
http://www.ccsinfo.com/forum/viewtopic.php?t=42434

Also read his comments on Ex_sisr.c near the end of this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=28881

Ttelmah's explanation of Ex_sisr.c in this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=19083

This thread explains how and why the "buffer wrap" math is done:
http://www.ccsinfo.com/forum/viewtopic.php?t=17873

[qwwe]

Thank you.
I read the posts and read the example.
I now understand the general routine, but I do not understand this part of the example:

[Ttelmah]

The #define, does a test to see if there is any data in the buffer.
If the input pointer matches the output, then there is no data.
So if they don't match, there is data waiting.

Then the bgetc is the routine to read a character from the buffer.
Normally you would have tested for a character being available before you call it. However if you haven't, it tests for data, and waits it there isn't any.

Then it reads the character in the buffer at 'next_out', increments 'next_out', with the same test for wrapping as the interrupt routine, and returns the character it has read.

[qwwe]

Thanks for the description given.
Namely I have to read a string.
We need to store the data function in an array in the program code by a loop and call the function bgetc() of the information.


Can I use the buffer information without using the function bgetc ?
By function gets() received a string ?

[Ttelmah]

Forget about strings.....

C does not actually technically 'have' a string data type. In C a 'string' is just a sequence of characters _terminated with a null_.

Now what you are sending is a sequence of character data.

'gets', gets a 'line' of data (has to be a sequence of characters terminated with a 'line feed' character), and writes this sequence into a character array that you have defined, and adds the terminating 'null' when the line feed is seen.

If your incoming data is 'lines', then you can use this. However it has the huge caveat/cost, that everything else has to stop and wait for this. :(

The point about interrupt driven ring buffers, is they allow data to be stored ready for you to process later, while you are doing other jobs. So (for instance), every few tens of mSec, you can simply test 'bkbhit', and if nothing has arrived, return to what you were doing. It's like a little temporary notepad where you can jot down things so they are not forgotten.

A huge amount depends on what the actual format of your received data 'is'. If it has a particular character that always marks the end of a sequence, then it is trivial to add code to test for this.
Equally if it is always linear with a variable number of characters, with a end sequence that can be detected, then you can just use an array of 'lines', rather than a ring buffer, and when the terminator is seen, put the null terminator to make the stored data into a 'string', and advance to the next line.
These are all different types of solution to different forms of data, and different needs for handling.
You need to tell us a lot more about what you are actually dealing with.

[qwwe]

I want to work with a GSM modem
According to the datasheet, the modem responses are as follows

[Ttelmah]

Use a small ring buffer as people have already said.

Then have a 'state machine'. In the first state, if a character arrives, and is an 'O' move to state 2 and exit. If it sees an 'E', move to state 3 and exit. If it sees a '+' move to state 4 and exit. All other characters ignore.

Then in state 2 just test for 'K'. Anything else, return to state 1. If you see the 'K', set a system flag to say 'OK seen', and return to state 1.

In state 3, walk through looking for 'RROR', and if this is seen set a flag for 'ERROR' and return to state 1.

In state 4, start walking through possible other words. Depending on your modem settings, if you are running with 'unsolicited replies' disabled, you only have to look for the message for the command you have just sent. If unsolicited replies are enabled, you may have a lot of other messages to check.

Look at this thread, and the link at the end, and the link there to newer code.

This is for text messages controlling something, but the basic design shows how to do this type of thing. I have a version I'm currently using (commercial so can't post), that handles sending and receiving SMS's, HTTP, etc. etc.. The basic idea is just like this.

[qwwe]

Thank you for all the tips.

[qwwe]

Mr Ttelmah

You edited the text of the received sms in the project you were doing
Did you use string functions?
If possible, leave the SMS text editing code

[Ttelmah]

Somehow the link I posted got lost:

<http://www.ccsinfo.com/forum/viewtopic.php?t=50390&highlight=sms+code>

Once you are parsing, then you can elect to copy data from the incoming stream after the recognised characters up to (say) the CR into a temporary buffer. Null terminate this when you get to the CR, and you can then use 'string' functions.

[qwwe]

I know I must save the received string in an array.
Then parse it.
My problem here is that the received message is as follows

+CMGR: "REC UNREAD","+98XXXXXXX","Fader/1","17/09/09,12:41:32+14"
on
OK

According to the datasheet, the modem responses are as follows

<CR><LF>RESPONSE<CR><LF>

In fact, the answer is as follows

<CR><LF>+CMGR: "REC UNREAD","+98XXXXXXX","Fader/1","17/09/09,12:41:32+14" <CR><LF>
<CR><LF>on CR><LF>
<CR><LF>OK <CR><LF>

Which we do not see <CR><LF>

How should this SMS be broken down and specify the text or phone number

[Ttelmah]

No. Do some initial parsing _first_.
Use a state machine to decide whether the line is one you want to process, and the nature of what to store, before starting to move the rest of the reply to the buffer. That way you don't have to wate time and storage handling lines that you don't want.