AT parser

Log in or register to post comments
Go To Last Post
3 posts / 0 new
Author
Message
pozzugno
pozzugno's picture
Level: Hangaround
Joined: Tue. Jun 4, 2013
Posts: 260 View posts
#1
Posted by pozzugno: Tue. May 20, 2014 - 03:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm developing a software that manages a GSM modem (actually it's a SIM900 from SimCom).

So I need to implement an AT parser. At first it appears a simple thing to do: the host microcontroller sends an AT command and waits for an answer usually ending with OK or something similar (ERROR, NO CARRIER, NO DIALTONE, ...).

The problem arises with unsolicited result codes (URC) that are asyncronous messages transmitted from the modem at any time (such as messages that signals the arrival of an incoming SMS or a RING).
I discovered those messages can be concatenated to the answer of a previous AT command: the first character of the URC could appear immediately after the last character of the answer of a previous AT command.

I know the application layer can break the incoming stream of characters from modem into messages, parsing the content, knowing all the possible expected answers and URC.

Anyway I think this is complicated so I'm thinking of a low-level (driver level) mechanism that is sufficiently generic.

I tried to search for something similar, but without success. Any suggestions?

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21558 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Tue. May 20, 2014 - 08:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finite State Machine works well for that sort of thing.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 20359 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. May 20, 2014 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

State Machine - absolutely :!:

aka FSM, Finite State Automaton.

Here's a good article on FSMs:

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

The specific example is an NMEA parser (for GPS) - but the principles are general.

You should study V.250 - the ITU standard which formalises the so-call "AT Command" structure.

http://www.itu.int/rec/T-REC-V.250/en

http://en.wikipedia.org/wiki/Hayes_command_set#V.250

http://en.wikibooks.org/wiki/Serial_Programming/Modems_and_AT_Commands

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top