Setting up RS232 USART on STM32-P103

[cnocbarra]

Posted on January 15, 2011 at 23:47

Setting up RS232 USART on STM32-P103

[Andrew Neil]

Posted on September 05, 2011 at 23:28

At last - forum fixed!

Here is an example of decoding an NMEA stream using a State Machine:

http://www.visualgps.net/WhitePapers/NMEAParser/NMEAParser.html

[sara2]

Posted on September 08, 2011 at 13:59

Thank you very much Clive1, I hope one day I can control programming as you do...O.O

Now I am having a bit of trouble parsering the NMEA sentence. I have had a look at the samples that neil.andrew suggested. I does look like it works...however I find myself unable to set it to my parameters. I dont know how to to put my input sentence to start decoding. My aim of this is being able to read the data and if some of the string corresponds to a set string that we are looking for, set on a signal. For example, if lots of sentences are coming in, only the ones that come with the GGA id will set up the LED. Thank you in advance for your help...I do feel a bit stuck...:( and I try not to post anything until I am desperate...to bother you the least possible...sorry and thanks again.

[Tesla DeLorean]

Posted on September 08, 2011 at 17:22

The first step is to validate the checksum, and sanity check the sentence, to eliminate potentially garbled data.

I approach parsing by breaking the comma delimited sentences into separate fields. Traverse the string, and fill a table of pointers to the start of each field, and replace the commas with NULs. Then have sentence specific decoding to crack out the salient data, check the fix status, and reconstruct the latitude/longitude data into decimal degrees instead of the problematic degree/minute format which was designed in the 1980's for ease of direct display. if (strcmp(field[0],''$GPGSA'') == 0) { }

[sara2]

Posted on September 14, 2011 at 16:35

I am having trouble programming in this...Maybe I am doing something wrong...

I am writing the code step by step checking that I don't mess up completely so every few steps I flash my code into the mpu. Lets say I've taken step 1,2,3 and 4 and everything works as I wanted to...but then, when I take step 5 I accidentally made an infinite loop so I go to my code back to step 4 and now nothing works and I may need to go back to step 2 to get everything settle again... and take steps 3 and 4 slowly... I am writing my code in eclipse and flashing it through an ARM-USB-OCD by telnet localhost... Maybe its the size.... MEMORY {   ram (rwx) : ORIGIN = 0x20000000, LENGTH = 30K   rom (rx) : ORIGIN = 0x00000000, LENGTH = 128K }  If I change the ram to 20K it gives me an error:region `ram' overflowed by 6884 bytes... Do you know what can I do? Or where is the best place to post this?? Thanks again!

[Tesla DeLorean]

Posted on September 14, 2011 at 16:53

You could post it at the top of the STM32 forum, I don't think anyone has a problem about asking general platform/toolset questions here.

If your part actually has 20KB of RAM, you can't use an application that's consuming 26KB. You'll need to look seriously at how you are allocating static/global data structures. Consider if some are constant, and thus could exist in FLASH, or if the use is temporal, or limited to a specific function, in which case you could use local variables, or pass down pointers. Consider if you can process data in smaller pieces. Dynamic memory allocation can work if carefully considered, but tends to be problematic in embedded designs. If the footprint really is that large, you'll need to consider a part with more RAM.

[sara2]

Posted on September 14, 2011 at 17:45

Well, to be honest there is a lot that is constant, I just don't have any idea how to locate it in flash and not ram...or how to make the .bss file smaller...

Is it possible to decide what goes in the flash memory and what doesnt?? I would like to try things instead of just ordering another part since the problem is probably that I dont have the knowledge... I apologize if this is common knowledge for everyone else....

[Tesla DeLorean]

Posted on September 14, 2011 at 18:01

You can use something like ''const'' or ''static const'', to indicate to the tool chain that something is not changed, or limit it's scope so placement decisions are simplified.

ie static const char Hex[] = ''0123456789ABCDEF''; The use of ''static const'' within subroutines can be particularly useful, depending on the compiler, because it won't allocate local stack space and copy the data there, but instead utilize the data in-place. Compilers will also typically offer directives or pragmas to direct code/data into specific segments described in the linker script/scatter file. The use of ''const'' will also permit the folding of multiple instances of the same data into a single memory representation. ie const char msg1[] = ''Press any key''; const char msg2[] = ''Press any key''; const char msg3[] = ''any key''; // depending on how clever your tool chain is.

[sara2]

Posted on September 15, 2011 at 18:15

Hello again... :(

Thanks for your tips clive1. I had inherited the code from some1 else and I did some ''clean up'' and deleted all I wasn't using and I manage to not overflow my system... However I still get sometimes some weird behaviour from the mpu...I make step 1, 2, 3, and 4 and it compiles works fine...and if I get something wrong in step 5 I need to go right back to maybe step 2 and start compiling again step by step because if now it gets into strange loops... I thought it was a memory problem, but now that I sorted out I cant think of anything else...what can it be?? To be slightly more specific... I try getting the nmea string with your code and sending it again. Works. Then I try a loop to look for the * char and stop it when it finds it. Works. Then I try to XOR each of the components of the string and fails... And when I try to go back to look for the * char it doesn't work any more, and I have to go and compile again just getting the string, and once this is compiled and working again, THEN I can try to look for the * char again... :( ...

[Tesla DeLorean]

Posted on September 15, 2011 at 18:30

Don't know, I'd need to see code.  sourcer32@gmail.com

The string data is stored on the stack, so is temporal in nature, and will unwind as subroutines exit. You'd have to be careful if you passed it off to other routines that expect it to be persistent.

[denal05]

Posted on August 14, 2012 at 15:00

Hello Clive,

Thanks for the answer, it helped a lot! It turned out that there is a problem, possibly hardware bug, because although the UART word length (data bits) is set to 8 bits, the serial terminal will display correct data only if its Data Bits parameter is set to 7 bits.The problem was that I was getting garbage on my serial terminal (I prefer Realterm). For a long time I thought the reason was my cable and/or bad configuration of the UART. It turned out it's a little bit of both. I thought I should use a null-modem UART cable, but that was a wrong assumption. And, yes, the UART word length is set to 8 bits, but Realterm was able to give us clues that the upper byte was always a fixed value, while the lower byte was just fine. So, my colleague Srdjan simply set the word length (Data Bits) on Realterm to 7 bits, and it worked! For the first time I saw ''Welcome to wherever you are''.Do you have any ideas why I see garbage if I set the Data Bits parameter on Realterm to 8 bits, but I see the correct string if I set it to 7 bits?Best regards,Denis