separating the data taken from the uart ? - Page 1
Forum section: electronics / general

author: koray692
author_rank: Contributor
timestamp: February 11, 2016, 11:34:09 pm
content: 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 VariablesUART1_Init(56000); // Initialize UART module at 56000 bpsDelay_ms(100); // Wait for UART module to stabilizevoid 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 wordreceived = 1;}} while(received == 0);// If it is GPGGA Data, then acquire it.if ((DataType == 'G') && (DataType == 'G') && (DataType == 'A')){received = 0;do{if (UART1_Data_Ready() == 1){UART1_Read_Text(NMEA, "*", 100); // Stop at *XX checksum datareceived = 1;}} while(received == 0);}receive = "x";}}}

author: uncle_bob
author_rank: Unknown
timestamp: February 12, 2016, 01:38:16 am
content: HiBacking 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