Test Loom_Interrupt_Manager - Carter

[rcpeene]

On both of my hardware systems, I am receiving a serial monitor error during setup:

[Device] Cannot add null module

[rcpeene]

The problem was that the config.h file listed Interrupt_Manager as the key for the module, rather than the real key for the Interrupt Manager which was InterruptManager. Easily fixed.

[rcpeene]

A new problem has arisen. When testing DS3231, I discovered an issue that resembles the problem with the Neopixel. The first call to getInterruptManager.func_name_here will run successfully, but any subsequent calls will cause the code to pause. I have rearranged and reorganized which function calls are made, and it appears to be the case that the second function call causes a halt.

[rcpeene]

These are the config and .ino files used. The sketch is just a modified version of the Interrupt manager example. The first several calls to InterruptManager have been rearranged a number of times.

"{\
    'general':\
    {\
        'name':'Device',\
        'instance':1\
    },\
    'components':[\
        {\
            'name':'DS3231',\
            'params':'default'\
        },\
        {\
            'name':'InterruptManager',\
            'params':'default'\
        },\
        {\
            'name':'Analog',\
            'params':'default'\
        }\
    ]\
}"

///////////////////////////////////////////////////////////////////////////////

// This is a basic example of settings a repeating alarm with the DS3231 RTC.

// This program can be used as a base to an RTC interrupt driven program

///////////////////////////////////////////////////////////////////////////////

#include <Loom.h>

// Include configuration
const char* json_config =
#include "config.h"
;

// In Tools menu, set:
// Internet  > Disabled
// Sensors   > Enabled
// Radios    > Disabled
// Actuators > Disabled
// Max       > Disabled

using namespace Loom;

Loom::Manager Feather{};

#define ALARM_PIN 6

volatile bool alarmFlag = false;
void alarmISR() {
    detachInterrupt(digitalPinToInterrupt(ALARM_PIN));

    getInterruptManager(Feather).get_RTC_module()->clear_alarms();

    alarmFlag = true;
}

void setup()
{
  pinMode(5,OUTPUT);
  pinMode(6,OUTPUT);
  digitalWrite(5,LOW);
  digitalWrite(6,HIGH);

    Feather.begin_LED();
    Feather.begin_serial(true,true);
    Feather.parse_config(json_config);
    Feather.print_config();

  LPrintln("\n ** Checkpoint ** ");

  getInterruptManager(Feather).print_config();
  getInterruptManager(Feather).print_state();

    getInterruptManager(Feather).register_ISR(ALARM_PIN, alarmISR, LOW, ISR_Type::IMMEDIATE);
  LPrintln("\n ** Checkpoint 2** ");
  LPrintln("pt 2.5???");

  //Feather.print_config();
    getInterruptManager(Feather).RTC_alarm_duration(TimeSpan(10));
  LPrintln("\n ** Checkpoint 3** ");

    digitalWrite(LED_BUILTIN, LOW);

    LPrintln("\n ** Setup Complete ** ");
}

void loop()
{
    if (alarmFlag) {
        digitalWrite(LED_BUILTIN, HIGH);
        LPrintln("Alarm triggered, resetting alarm");
        Feather.pause(1000);

        // Don't call RTC_alarm_duration before reconnect_interrupt
        // unless sleeping or calling:
        // Feather.get<Loom::InterruptManager>()->get_RTC_module()->clear_alarms();
        // post sleep calls this, and in this example it is in the ISR

        getInterruptManager(Feather).reconnect_interrupt(ALARM_PIN);
        getInterruptManager(Feather).RTC_alarm_duration(TimeSpan(10));

        digitalWrite(LED_BUILTIN, LOW);
        alarmFlag = false;
    }
}

[lukegoertzen]

Same advice as noted on the Neopixel issue, i.e try using Feather.get<X>() methods instead of getInterruptManager, curious if that makes a difference.

Doing a test with the OLED example, switching in Feather.get() for getOLED() fixed hard faults. I expect it is the same issue.