Need # define for MAx # of interruptable pins

[GoogleCodeExporter]

Would you please add a # define that defines
the max # of interruptable pins?

//IS
uint8_t interrupt_count[20]={0}; // 20 possible arduino pins

//SHOULD BE SOMETHING SIMILAR
uint8_t interrupt_count[MAX_INT_PINS]={0}; // 20 possible arduino pins

This # define should be set based on the chip.
168/328's vs 2560, etc

All codes (especially loops) should reference the # define
to avoid overrwriting the end of the array

Original issue reported on code.google.com by cappy2...@gmail.com on 14 Jun 2012 at 12:45

[GoogleCodeExporter]

This is actually a little more complicated than it sounds, and I don't think it 
will be useful.  First, the fact that there are 20 possible Arduino pins will 
rarely be used, IMHO.  You want to allocate space for the number of pins that 
you are going to utilize for your project, not waste memory allocations for 
pins you're not using. Of course, that is a choice that's up to the developer.  
But I'd venture to say that 99+% of the time MAX_INT_PINS would not be used.  
Rather, most projects using this library are going to choose a subset of the 
Arduino's pins for interrupts, so the pin count (and thus the interrupt_count 
array size) would be unique to each project.

Do you really have a project that uses *all* of the Arduino's pins for 
interrupts?  ...No LEDs, no I2C, no output of any kind?

I guess I don't understand the use case.  Perhaps you can explain in more 
detail?

Original comment by mschw...@gmail.com on 23 Jun 2012 at 10:33

[GoogleCodeExporter]

I'll leave this open for another week, to allow for more discussion.  If at the 
end of that period there is nothing further I will change to "Won't fix".

Original comment by m...@schwager.com on 28 Jun 2012 at 5:31

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

You can close it now.
Not critical, just a convenience

Original comment by cappy2...@gmail.com on 28 Jun 2012 at 7:34

[GoogleCodeExporter]

Issue closed as per agreement.

Original comment by m...@schwager.com on 29 Jun 2012 at 12:22

• Changed state: WontFix