Anyone need to control their code from the serial monitor?

Here's what (I Hope) is a simple to set up command line parser.

  1. Setup an enum list of commands you'd like to look for.
  2. Match these commands with "text strings" to type in.
  3. Run your text through the parser in your loop() function.

Like this. (Serving suggestion)

void loop(void) {

   char  inChar;
   int   command;
   
   if (Serial.available()) {                                // If serial has some data..
      inChar = Serial.read();                               // Read out a charactor.
      Serial.print(inChar);                                 // *Optional* echo the charactor.
      command = ourParser.addChar(inChar);                  // Try parsing what we have.
      switch (command) {                                    // Check the results.
         case noCommand : break;                            // Nothing to report, move along.
         case command1   : handleCommand1();       break;   // Call the handler function for comman1
         case command2   : handleCommand2();       break;   // Call the handler function for comman1
         default        : Serial.println("What?"); break;   // No idea. Try again?
      }
   }
}

A simple, ready to run, example.

/************************************************************************************
*************************************************************************************
                          10/15/2020 Damn pandemic still going on.
                                    
This is a really simple test/demo program for the Left Coast lilParser.
In the serial monitor..
      
      Type : on    to turn on the LED.
      Type : off   to turn it off again.
      
In order to run this you will need, along with this library : LC_baseTools
LC_baseTools can be found in in the Arduino library manager.

Or here : https://github.com/leftCoast/LC_baseTools


*************************************************************************************
*************************************************************************************/

#include "lilParser.h"

#define LED_PIN 13 // Pin for built in LED.

 
enum commands {   noCommand,  // ALWAYS start with noCommand. Or something simlar.
                  LEDOn,      // The rest is up to you. help would be a good one. Have it list
                  LEDOff,     // What the other commands are, how they work and what they do.
                  };          // Our list of commands.

lilParser   ourParser;        // The parser object.

void setup() {
   
   Serial.begin(9600);
   pinMode(LED_PIN, OUTPUT);        // Set up the LED pin.
   ourParser.addCmd(LEDOn,"on");    // Type on to turn on the LED.
   ourParser.addCmd(LEDOff,"off");  // Type off to turn it off again.
}


// Your loop where it parses out all your typings.
void loop(void) {

   char  inChar;
   int   command;
   
   if (Serial.available()) {                                   // If serial has some data..
      inChar = Serial.read();                                  // Read out a charactor.
      Serial.print(inChar);                                    // If using development machine, echo the charactor.
      command = ourParser.addChar(inChar);                     // Try parsing what we have.
      switch (command) {                                       // Check the results.
         case noCommand : break;                               // Nothing to report, move along.
         case LEDOn     : digitalWrite(LED_PIN, HIGH); break;  // Turn the LED on (HIGH is the voltage level)
         case LEDOff    : digitalWrite(LED_PIN, LOW);  break;  // Turn the LED off by making the voltage LOW
         default        : Serial.println("What?"); break;      // No idea. Try again?
      }
   }
}

More info? Heres' the readme : README.md

Its in the Arduino IDE library manager. Search for : LC_lilParser.

-jim lee

You published first!
I’m still fiddling with https://github.com/WestfW/parser. (simpleParser is in pretty good shape, but has essentially no docs. The other parser is sorta broken...)
(As I use it in some other sketches.)

Yeah, but..

Seeing the only reply is from the competition. I fear parsers are not a hot commodity in the Arduino community.

And I find that really odd, because I use mine ALL the time when developing stuff.

-jim lee

Yeah, the fact that beginners can get into all sorts of trouble with Strings, and losing/missing terminators etc, it seems paradoxical, they would be looking away when two relatively skilled users have posted a guide to parsing ‘better’.

I’m going to have a good look at what you’ve done, because I’m keen to rewrite my own current (buried-in) parser.

The tricks I currently handle are splitting the (serial) command line into individual (whitespace) words, then parse a multi (variable-number) word commands and parameters from that.
One special trick, is to use all words from a chosen position as a single parameter..l
e.g. [Set nAMe John Smith]. would pull out [SET] [NAME] [John Smith]
The keyword parser is not case sensitive, while the composite (3rd) parameter retains the original input case.

The major feature I want to add is an unambiguator(tm) that will accept simple typos, and score for the ‘best fit’ of keywords in each word position... accepting simple typos, truncated keywords, or swapped letters etc, when nothing other than a known keyword will fit.

This will also allow me to add predictive autocomplete if the comms are over a live bidirectional port (e.g. hardware console port)

This is because users are clumsy, and comms are often sent over slow or costly paths (SMS etc), and if the parser can ‘guess’ the required command line - great. If not, it can respond, telling you what was ‘close’, but not accepted.
(This is the bit that I need to work on as a new feature)

If I’m comfortable I’ll post it as open-source when it’s done.
The existing code is part of a pretty big program buried spaghetti-style in a 1284, next generation of hardware will likely be a pi-Zero, but the code will start on a MEGA 8-bitter.

Mine parses the first token of a inputted stream of chars, looking for EOL to break off parsing. Then it breaks the rest of the string (Remaining chars to the EOL) up into tokens and lets you get them one by one. If any.

I think the newbies don't look at this because, when you are mentally maxxed out, the last thing you want is to add more stuff to you "codes". Its just seen as adding to the confusion.

@westfw : Silicon Valley, CA, USA? Where? I grew up there.

-jim lee