adafruit_support_mike wrote:Actually I need to confirm something.. I think you might have found a bug in the board support package:
Mike,
I am anxious to hear what you have concluded on the aledged "bug" with it.
Bill
Moderators: adafruit_support_bill, adafruit
adafruit_support_mike wrote:Actually I need to confirm something.. I think you might have found a bug in the board support package:
Curiously non-binary. The jury is still out then... Thanks for the update. Will stay tuned.adafruit_support_mike wrote:Still waiting for information from people testing it. So far, the answers have been ambiguous... half the time they say the interrupt works if they skip digitalPinToInterrupt() and call attachInterrupt() with the interrupt channel number, and half the time they say the macro works.
adafruit_support_mike wrote:Thank you. I'll have to dig into it further.
The digitalPinToInterrupt() macro's job is to save people from having to look up interrupts in the datasheet, and if it's broken we'll need to fix it. I'll poke around some more and see if I can make sense of things.
Code: Select all
// standard libraries #included
#define INT1_pin 3 // Itsy Bitsy D3
#define INT2_pin 4 // Itsy Bitsy D4
void setup() {
// When enabled, this next line ( 'attachInterrupt' code ) properly creates
// a functional INT-capable pin D3 and the pin responds perfectly
// when pulsed as it should.
/* attachInterrupt (INT1_pin, ISR_CLIENTS_DATA_READY, RISING); */
// But any attempt use the exact same code to implement D4 as
// an INT in the exact same circuit fails. D4 simply cannot be
// coded to work as an INT pin in the proper way (or in any way, for that matter).
// Pulsed when Metro-Mini's RFM69 array has data.
// RIGOL Scope: pulse width and level OK
// The following will NOT create an INT-capable D4.
attachInterrupt (INT2_pin, ISR_CLIENTS_DATA_READY, RISING);
} // end setup()
void loop(){
if (I2C_RF69_CLIENT_data_ready_FLAG == true){
// do stuff
}
} // end loop()
//=================================
Void ISR_CLIENTS_DATA_READY( ) {
I2C_RF69_CLIENT_data_ready_FLAG = true;
}
/*
//=========== Conclusion: When I wrote my original support request, neither D3 nor D4 would function but we focused on D3 and, kudos to you in modifying the package to get it working . But, as I discovered recently when implementing D4 is that we forgot to fix it as well. Clearly, D4 will not function as does D3. This is a spanking-new ItsyBitsy and I’ve exercised extreme care to ensure no errors on my part (hardware) nor software. It's a valid test and I was happy to contribute my time on it but now, as a hardware engineer, we're out of my pay grade to be modifying 'Adafruit Boards Packages', (assuming I'm correct on the root cause). Any attention to this would be appreciated.
I'm dead in the water without your support.
*/
Govner wrote:adafruit_support_mike wrote:Actually I need to confirm something.. I think you might have found a bug in the board support package:
Yes the digitalPinToInterrupt() macro just echoes back the pin number on the Itsybitsy M4adafruit_support_mike wrote:Still waiting for information from people testing it. So far, the answers have been ambiguous.
From what I can see in the BSP code, the digitalPinToInterrupt() macro just echoes back the pin number, which doesn't line up with the interrupt channels actually connected to the pins on that board. People seem to have a hard time reducing that to simple 'yes' or 'no' answers though.. half the time they say the interrupt works if they skip digitalPinToInterrupt() and call attachInterrupt() with the interrupt channel number, and half the time they say the macro works.