Abstract task scheduling

[t0mpr1c3]

It may be good to have a generic pattern for tasks like this (beeper, LEDs, watchdog, ...) including knitter, e.g.:

// Abstract class for Task
class Task {
  public:
    virtual void run() = 0;
}
...
// Classes that needs to be scheduled implements run() method
class Beeper: public Task {
  public:
    void run() {
    // non-blocking code called from the scheduler
    }
    ...
    void beep(uint8_t repeats){
    }
    ...
}
...

class Scheduler {
  public:
    bool register(const Task &task) {
    // Add task to scheduler list
    }
    void schedule() {
    // Call run() method for each registered task
    }
}

setup() {
  // Objects to schedule
  Beeper beeper;
  Knitter knitter;
  Led ledA, ledB;
  SerialCom serialCom;
  Watchdog watchdog;
  // Main Scheduler
  Scheduler scheduler;
  ...
  scheduler.register(beeper);
  scheduler.register(knitter);
  scheduler.register(ledA); // blinking (vs solid) led as "firmware alive" indication
  scheduler.register(ledB); 
  scheduler.register(serialCom);  // call PacketSerial.update()
  scheduler.register(watchdog);
  ...
}

loop () {
  scheduler.schedule()
} 

[jpcornil-git]

You can already start without a scheduler but a RR strategy in the main loop to simplify matters (scheduler may be considered when implementing the webserver interface):

// Abstract class for Task
class Task {
  public:
    virtual void update() = 0;
}
...
// Classes that needs to be scheduled implements update() method
class Beeper: public Task {
  public:
    void update() {
    // non-blocking code called from the scheduler
    }
    ...
    void beep(uint8_t repeats){
    }
    ...
}
...

setup() {
  // Task objects
  Beeper beeper;
  Knitter knitter;
  Led ledA, ledB;
  SerialCom serialCom;
  Watchdog watchdog;
  ...
}

loop () {
  beeper.update();
  knitter.update();
  ledA.update(); // blinking (vs solid) led as "firmware alive" indication
  ledB.update(); 
  serialCom.update();  // call PacketSerial.update()
  watchdog.update();
  ...
}