Help understanding USART component please

An area to discuss 8-bit PIC specific problems and examples

Moderator: Benj

Post Reply
crispin12
Posts: 51
Joined: Fri Apr 07, 2017 5:51 pm
Has thanked: 6 times
Been thanked: 11 times
Contact:

Help understanding USART component please

Post by crispin12 »

I wonder if someone could lend me a hand on getting to grips with RS232 USART.
This is the first time I’ve used the RS232 component and macros so I’ve looked back over some of the examples produced by Matrix in the past and there’s a few things I’m unsure about. I want to transmit and receive strings of data and the first thing I noticed in the examples is the use of a value of 50 for the timeout in the received string macro. Can someone please explain how this timeout value is derived and why it’s needed? Is the 50 relating to mS, uS or what? Is it related to the baud rate in some way?

If I am expecting to receive say one of 3 strings, one 12 byte long, the second 15 bytes long and the third 20 bytes long and I have no idea which string is going to come first, is it critical that I make the number of bytes exactly equal to the expected received string length or can I simply assume that as long as the byte setting is longer than the expected number of bytes in the string, then the data will be captured?

Finally, if I need to find out which of the 3 strings has been received first, then I need to be able to examine the data content which I believe is a parsing requirement to look for an identification character that effectively will identify which string I have received. (all 3 strings have different characters). Has anyone produced a sample flowchart that could help me learn how to do the character identification or parsing requirement from the received string?

Thanks in advance to anybody who might be able to give advice. I will probably use one of the popular PICs 16F, 18F with a hardware USART on board.

User avatar
LeighM
Matrix Staff
Posts: 2178
Joined: Tue Jan 17, 2012 10:07 am
Has thanked: 481 times
Been thanked: 699 times
Contact:

Re: Help understanding USART component please

Post by LeighM »

Hi,
The timeout value is in milliseconds, so if there is a gap in received data greater than this value the function will return.
You should not rely on the value being too accurate, so as long as you set the value to something between the minimum of the time between the characters (based on the baud rate, not the gap or stop bits) and the maximum of the delay between the strings, assuming there is one?
Are the strings machine generated, i.e. the characters in the string do not have a time gap?
Is there a reasonable gap between the strings such that this can be used to identify them (together with their individual lengths)?
Or do they conform to some sort of protocol, that indicates the start and end of the string?
Just things to think about.
Once you have the strings identified you can then start on the parsing, the best method will depend on the content of the string,
e.g. is it a comma separated list of values, or are the data fields fixed length?

Yes, the number of bytes is the maximum length of expected string,
the string receive function will return when either the maximum is reached or the timeout occurs.

If you hover your mouse over the macro parameters you will get hint text displayed to help you.

crispin12
Posts: 51
Joined: Fri Apr 07, 2017 5:51 pm
Has thanked: 6 times
Been thanked: 11 times
Contact:

Re: Help understanding USART component please

Post by crispin12 »

Thanks Leigh, that is very helpful and I think its a lot clearer now.
I think the biggest problem I may have to face is that I can not be certain when the incoming data on the Rx starts. However, when it starts it will always have the first 2 characters the same and then the following data after those characters contain the important message. Its a radio system where the PIC will send a text string to a radio modem and depending on what happens in the modem (was the text handled successfully, did it fail) the modem sends a string back to the PIC giving a status value. By capturing the status value and reading it, the PIC can then make the relevant decision about what to do next. The protocol is basically RS232 around 2400 / 9600 baud. Nothing sophisticated and pretty slow really by modern comms standards.
Probably the easiest way of tacking this is to make the Rx line on the PIC UART trigger an interrupt. Assuming the start bit of the RS232 incoming data triggers the interrupt I ought to be able to capture the string and the first 2 chars. Then all I need to do is read the values of the following chars to read the status code from the modem. At least that's my thinking so far about how to from a solution.
I think I will knock up a simple RS232 Flowchart and a PC terminal program and get the simulation working with the various modem strings transmitted from the PC terminal at a low baud rate and then move on from there. If you can think of any possible pitfalls or traps to be aware of I'm all ears!

Thanks again for the response.

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Help understanding USART component please

Post by medelec35 »

Hi,
Using the RX interrupt is definitely the way to go.
Otherwise, you will miss data even if using a tight loop.
One pitiful is RX interrupt works fine with hardware but does not simulate.
There are a few ways around this.
One way is to set up keymapping that will trigger a call to RX interrupt macro when you press a key, so that will only happen during simulation.
I can help you set that up.
Martin

crispin12
Posts: 51
Joined: Fri Apr 07, 2017 5:51 pm
Has thanked: 6 times
Been thanked: 11 times
Contact:

Re: Help understanding USART component please

Post by crispin12 »

Thanks Martin

So the Rx interrupt does not work under simulation. Well you've probably just saved me hours of frustration then. I wasn't aware of that at all. Do you happen to know if that is a Flowcode 7 anomaly (my current setup) but fixed on Flowcode 8 or is that also true of Flowcode 8?

As soon as I get my demo test flowcode done (might be a while as summer school holidays are here again) I will post back here for the keyboard mapping setup.

regards etc.

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Help understanding USART component please

Post by medelec35 »

It has never been implemented on any version.
I would love to see it implemented, but there may be a technical reason why it has not.
All other interrupts work during simulation.
E.g Timer, IOC, INT etc.
Martin

User avatar
petesmart
Valued Contributor
Valued Contributor
Posts: 395
Joined: Thu May 06, 2010 11:42 am
Location: Sydney, Australia
Has thanked: 187 times
Been thanked: 140 times
Contact:

Re: Help understanding USART component please

Post by petesmart »

I agree Martin.....simulation Of rx Int would be very helpful...

One way I have done it in past projects is to create a macro to read the rx buffer and calling it with a simulation icon from the main loop...this way it does not impact compiled code...

Best

Pete
sorry about that Chief!

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Help understanding USART component please

Post by medelec35 »

Hi Pete,
Yes I agree.
My method you press a key of your choice to call RX interrupt which does not impact compiled code.
Your method, the flowchart can be set up with a decision branch that is only accessed during simulation
That could use Simulation Start/Stop events for example, which as you said not impact compiled code.
Depends if manual or automatic is preferred.
Just like cars :lol:
Martin

crispin12
Posts: 51
Joined: Fri Apr 07, 2017 5:51 pm
Has thanked: 6 times
Been thanked: 11 times
Contact:

Re: Help understanding USART component please

Post by crispin12 »

Martin

Further to the requirement to parse the incoming Rx string can you tell me what the calculation command would be to read for example the 'nth' character in for example a 10 byte string situated in a variable and place that character / byte into a new byte variable?
So for example, lets say the variable "string" holds 10 bytes / characters and let's say I want to read the 4th character from the start of the string and insert it into a new var called "new_var". I believe that can only be achieved by a 'c' calculation icon/icons. Can you please suggest the command structure to accomplish this (as unfortunately my 'c' language skills are pretty dire).

Thanks in advance if you can point me in the right direction.

crispin12
Posts: 51
Joined: Fri Apr 07, 2017 5:51 pm
Has thanked: 6 times
Been thanked: 11 times
Contact:

Re: Help understanding USART component please

Post by crispin12 »

Just realised a flaw in what I am attempting above. I can't take the 4th char from the string and insert it into a byte var without first converting the character to an integer. However, I think i could copy the character into a string var of just 1 byte in length, So I wonder could I do something like

strncpy(new_var, string+4)

to copy the 4th character from 'string' into the 1 byte string var called 'new_var'

This raises in my mind what exactly does the convert string to an integer function do?
If we have a string containing "flowcode is great"
If you convert that to an integer what is actually happening? Are the ascii values ones and zeros of each char converted into one long binary number which is then converted into a decimal integer?

kersing
Valued Contributor
Valued Contributor
Posts: 2045
Joined: Wed Aug 27, 2008 10:31 pm
Location: Netherlands
Has thanked: 553 times
Been thanked: 1081 times
Contact:

Re: Help understanding USART component please

Post by kersing »

Take a look at the help page for string manipulation functions...

There is an example to set the value of a string with

Code: Select all

Str1[0] = 'H'
Str1[1] = 'e' 
...
To reverse this (get the value from a string) you could use:

Code: Select all

a = str[4]
Just make sure to check the length of the string first. It does not make sense to read the 4th character if the string is just two characters long. (You will get a value but that is garbage, may-be something left over from a previous string may-be a random value)
“Integrity is doing the right thing, even when no one is watching.”

― C.S. Lewis

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Help understanding USART component please

Post by medelec35 »

I like Kersing's, method but to copy from one string to a single byte string (if you want to keep as a string), you can use the Mid$ function:

Code: Select all

New_Var = Mid$ (StringVar,3,1)
This is found Within the string functions of a calculation box:
Mid$ Function.png
(69.04 KiB) Downloaded 3429 times
Martin

crispin12
Posts: 51
Joined: Fri Apr 07, 2017 5:51 pm
Has thanked: 6 times
Been thanked: 11 times
Contact:

Re: Help understanding USART component please

Post by crispin12 »

Ok but do these string manipulation functions work when the string is alpha as opposed to numeric? Martin you give an example using numbers but is it also true if the string is letters or words? Just checking. THanks

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: Help understanding USART component please

Post by medelec35 »

crispin12 wrote: but do these string manipulation functions work when the string is alpha as opposed to numeric?
Mid$ Function 2.png
(34.6 KiB) Downloaded 3421 times
If you want to view variable values then take a look here
Although was intended for V6, same applies to V7 & 8
Martin

crispin12
Posts: 51
Joined: Fri Apr 07, 2017 5:51 pm
Has thanked: 6 times
Been thanked: 11 times
Contact:

Re: Help understanding USART component please

Post by crispin12 »

Many thanks Martin.

Post Reply