Adventures in Science: Arduino Programming Syntax

This week, we look at what constitutes syntax in a programming language and how to employ it when writing code in Arduino.

Favorited Favorite 0

Last week, we examined how a program flows in Arduino. This week, we continue with the computer science theme and look at syntax rules: What do we mean by syntax in programming, and how do we use it when writing for Arduino?

Syntax, as it relates to computer science, is the set of rules for combining words, phrases, numbers and symbols to create correctly structured code in a programming language. In the video, we look at how high-level languages like C and C++ came to be, what makes up identifiers, and some keywords to avoid using as identifiers. We also examine single line (//) and multiple line (/* */) comments and how they can be used to document code.

Many of the reserved keywords and built-in Arduino functions can be found on Arduino's reference page, which has proven to be an invaluable resource when teaching people the building blocks of Arduino.

If you're new to Arduino but have some experience programming, this tutorial might be able to shed some light on what this Arduino thing is:

What other computer science concepts would you like to see covered? Please let us know in the comments below.

I'm hoping to cover the basics for students and beginners. Time permitting, I would love to get around to more advanced topics like PWM, interrupts and writing your own Arduino libraries using object-oriented programming.

Comments 8 comments

  • I could write a ton of stuff at this point (hey, as I like to say, I first got "into" computers shortly after Neil Armstrong took his "one small step" [on the Moon], and I spent nearly 25 years writing [highly specialized] compilers), but I'll try to keep it fairly short.

    First, a couple of nits: It almost sounds like you said "cobalt". To be clear, it's COBOL, an acronym for "COmmon Busniess Oriented Language". ("FORTRAN" = "FORmula TRANslator", and "LISP" = "LISt Processor"). FORTRAN was first, but was not really good for "business" applications, where strings (e.g., customer names) were important, and not things like expressing very large numbers or very small numbers, which are important in scientific and engineering, were needed. This latter, by the way, required extra hardware, at a time when it was VERY expensive, so COBOL came about. LISP was a bit later, and people joked that LISP was done to show that what was left out of FORTRAN was, in and of itself, sufficient for a language. (LISP primarily uses "linked lists" and "recursion", which were "known concepts", but had been left out of FORTRAN as being too difficult to implement.) LISP is (usually) an interpretive language, meaning that each statement is "compiled" as it is executed. FORTRAN and COBOL are "compiled" languages, in the sense that the entire program is translated to machine language before any of it is executed. (I suspect I'm the only one reading this stuff who has written a cross-assembler in COBOL.)

    Two last nits: C++ is a "superset" of C, meaning that a C program is a C++ program, but doesn't use the extended features. FWIW, the "//" form of comment is C++. C was limited to the "slash asterisk - asterisk slash" comment form.

    Enough of the nits (and history lessons): You'd asked for opinions on what should be covered next: My vote would be to have a lesson on variables and some "flow control" like the "if" and "for" statements. A thought on an example might be to have the LED make a "single flash", then a "double flash", then a "triple flash", then start over. (If you know Morse code, think "E" followed by "I", followed by "S".)

    Then in the next lesson after that, include some of the capabilities of the pre-processor, such as #define, #if, #ifdef, and #include. Given the Arduino's lack of a debugger (putting us back in the 1970s), these can be very handy.

  • I want to add a comment related to learning other languages. Learning coding languages is like learning a foreign language, you have to learn the RULES of the language to understand how to format your phrases. Same thing with the syntax of a coding language. If you start off with C/C++ based syntax, learn all of the languages that are similar in syntax!

    For example, you are learning C/C++, and now you are wanting to go to FPGAs, your logical step should be to Verilog/SystemVerilog. This is because it syntactically similar to C/C++.

    Just my 2 cents.

    • I'd suggest (as I was taught in CS school) looking for the underlying structures -- which are common across many/all languages. Once you've done this a couple of times, it makes learning another computer language often just a matter of figuring out which "constructs" the language provides, and the specific syntax/lexical rules for the "new" language.

      My 2 cents.

      • I agree with this. Looking up specific built-in functionality is easily done with Google once you are comfortable with the fundamentals of programming. No need to believe you're locked into a specific family of languages because that's where you started.

        Only time I can see this being trickier is if you're starting with procedural/OOP and go to a functional programming language.

      • I should have also mentioned that "good programming style" rules can help avoid a LOT of frustration. One of the first is to include a LOT of comments. Another is to use "meaningful" variable name. (Single letter names are only appropriate when writing on a chalk/white board! Rather than "for ( i" use "for ( idx".) And only use a "goto" when the program needs to abort.

    • Good tip, thanks! This seems to hold true when learning any new paradigm, like object oriented programming.

      • Shawn,

        I've suggested this to several people who have set out to learn object oriented programming. First, go read the book Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig. Don't worry, it doesn't have much to do with either Zen or motorcycle maintenance. And it has nothing, directly, to do with ANY computer programming, OOP or otherwise. However, it can help you to be open-minded to new paradigms, which is what you need to succeed with learning OOP.

        • I really tried with Zen and the Art of Motorcycle Maintenance, but I couldn't get past the first few chapters. I still own it; perhaps I should give it another shot or get it on audio book.

Related Posts

Recent Posts


All Tags