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.