Author Topic: separating the data taken from the uart ?  (Read 1890 times)

0 Members and 1 Guest are viewing this topic.

Offline koray692Topic starter

  • Contributor
  • Posts: 13
separating the data taken from the uart ?
« on: February 11, 2016, 11:34:09 pm »
hello I am working to separate data taking from the uart (gps neo 6m).I use mikroc for arm with stm32f407 I want to ask that ? want to use code is good(useful) or not ? dont want to be a problem at this stage ? will use interrupt at this code...let me share code ;


int a=0, received = 0;
char DataType[] = "GPXXX";
char NMEA[] = "$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
char receive;
// End Variables

 
  UART1_Init(56000);              // Initialize UART module at 56000 bps
  Delay_ms(100);                  // Wait for UART module to stabilize
 

void main ()
{

if (UART1_Data_Ready() == 1) {
receive = UART1_Read();
if (receive == '$')  // Check if sentence begins.
{
      received = 0;
      do{
        if (UART1_Data_Ready() == 1)
        {
         UART1_Read_Text(DataType, ",", 10);  // Capture GPXXX word
         received = 1;
        }
      } while(received == 0);

      // If it is GPGGA Data, then acquire it.

      if ((DataType[2] == 'G') && (DataType[3] == 'G') && (DataType[4] == 'A'))
      {
        received = 0;
        do{
          if (UART1_Data_Ready() == 1)
          {
           UART1_Read_Text(NMEA, "*", 100);   // Stop at *XX checksum data
           received = 1;
          }
        } while(received == 0);



 }

      receive = "x";
   }
  }
}
 

 

Offline uncle_bob

  • Supporter
  • ****
  • Posts: 2441
  • Country: us
Re: separating the data taken from the uart ?
« Reply #1 on: February 12, 2016, 01:38:16 am »
Hi

Backing off a bit to uBlox decoding:

The streams all start and end with certain characters. The easy thing to catch is the cr/lf at the end.

There is absolutely no guarantee that one string will stop, time will pass, and another one will start. It is far more likely that they all will come out in a giant blob of characters. Depending on what you have turned on, that maybe several thousand characters.

By far the best way to do this is to use a buffer. One routine shoves characters into the buffer as fast at they come in (>=115.2K baud is a really good idea ...). That's all that routine does. It is small and fast. It likely runs off of an interrupt.

Next up is a simple routine that pulls characters out of the buffer. That does not sound to complex, but it has to keep all the counts correct. It is not as easy as it sounds (don't ask how I know this ...).

Normally, you have some sort of timer that runs the higher level code. It could be as simple as a loop. It could be part of an RTOS. The net effect is the same. Code pops up, looks to see if there is anything in the buffer. If not, it goes back to sleep. If there are enough characters in the buffer that it might be interesting, it gets the buffer contents. Next check is for a full line. No full line? back to sleep.

At this point, you get into a structural decision. You can parse the line in the same code as you check it, you can pass it on down the line to something else. There are a lot of reasons for going each way. Either way, you need to parse the line.

The uBlox data is coma separated ASCII text. Each coma you find in the line equals another data field. It becomes a "next coma" / "get data" / "case statement" ... on and on sort of process.

If you are sending data to the device while you are receiving strings from it, there is the added complexity of the ACK and NACK on the string you send. How you work that into your parser is another whole set of decisions.

So, have I gone to crazy to fast?

Bob
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf