Skip to content
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Development
  3. Some simple asynchronous Arduino classes
  • Getting Started
  • Controller
  • Build
  • Hardware
  • Download/API
  • Forum
  • Store

Some simple asynchronous Arduino classes

Scheduled Pinned Locked Moved Development
3 Posts 3 Posters 2.4k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • TD22057T Offline
    TD22057T Offline
    TD22057
    Hardware Contributor
    wrote on last edited by
    #1

    I wanted to share some of the classes I've been using for my MySensor modules. I've been making some fairly complicated sensors (boards with a lot of things going on - see my mother/daugter board system) and I have found that these classes to be very useful. They're all fully commented and include test sketches. They're designed around two main principals:

    • Asynchronous operations. There are no delay calls anywhere. Each class maintains it's own state and behaves accordingly. This allows me to combine many different items and use them all without worrying about how they interact with anything else.

    • Hardware abstraction. Each class has a very similar API in which the hardware specific information is set in the init() function called in the the setup. After that, all the interaction is via state change ("turn on", "blink 5 times", "sensor triggered", etc). In my board system, I connection these things via direct Arduino pins (some digital, some analog, some analog only A6/A7) and shift registers. This abstraction allows be to use the same logic code regardless of how the hardware is actually connected.

    The basic idea is that:

    • setup(): initializes the hardware (pins, etc) and state
    • loop(): poll each object with a callback function to look for changes
    • callback(): handle the state change

    I've found that I really like this type of API. All of the hardware configuration is in setup() and all of the state changes (what happens) is in the callback. I've found that this makes the code easier for me to debug and much easier for me to understand (when I come back and look at it 6 months later) since the role of each function is clearly defined. On the output side, the DigitalOutput class allows me to turn things on for different amounts of time (turn a relay on for 5 seconds) while various LED's are blinking at different rates with very simple code. It's not the most size efficient code - but I've never found that to be a problem for my builds and the ease of use and clarity of intent is more important to me.

    • DigitalInput: On/Off inputs (switches) with either HIGH or LOW
      active, optional debouncing, and support for digital pins, analog only
      pins (A6/A7) and shift registers.
    • DigitalOutput: On/Off ouputs (LED's, relays) including blinking.
    • MedianFilter: N sample running median filter.
    • Sonar: Ultrasonic snsor.
    • Timer: Repeating (num or infinite) periodic triggers.
    • Valve: 5 wire articulated valve control

    The repository is here: https://github.com/TD22057/TD-Arduino-Core
    A good, long'ish example using several different classes is: https://github.com/TD22057/TD-Arduino-Core/blob/master/Valve/tests/leak_sensor/leak_sensor.ino

    Feel free to use these if you find them helpful and any comments or suggestions are welcome.

    1 Reply Last reply
    3
    • barduinoB Offline
      barduinoB Offline
      barduino
      wrote on last edited by
      #2

      Very interesting, I'll definitely take a look.

      Had similar situation when creating classes independent of my sensors, where the main sketch pools or sends information to/from them.

      Cheers

      1 Reply Last reply
      0
      • scalzS Offline
        scalzS Offline
        scalz
        Hardware Contributor
        wrote on last edited by scalz
        #3

        @TD22057 : I will look at it too. I like asynchronous, often the best way ;)
        There is something I wanted to try but never had time yet! http://oosmos.com/intro
        Maybe you already know it ??? Interesting stuff too...

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        17

        Online

        11.7k

        Users

        11.2k

        Topics

        113.0k

        Posts


        Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • OpenHardware.io
        • Categories
        • Recent
        • Tags
        • Popular