Encoder library pin definitions?

[grandaspanna]

I've started using this library: https://github.com/PaulStoffregen/Encoder and my first project was based around a 1614. Discovered that the library didn't know about it, so I added a small block in the interrupt_pins.h file to get me going.

I'm now using a 3216 and discovered I need to add that too :-)

For the 1614, I used:
#elif defined(__AVR_ATtiny1614__ )

It occurs to me there should be a smarter way of including x14, x16 etc parts, rather than each one.

What's the correct defines to use for each class of part?

[hmeijdam]

You may want to read this

[grandaspanna]

Awesome - that's great. I recalled a mention of this, but couldn't track it down.

[SpenceKonde]

https://github.com/SpenceKonde/megaTinyCore/blob/master/megaavr/extras/Ref_Defines.md#identifying-part-family-within-sketch

covers the defines I use.

Paul's libraries are not designed to work with modern AVRs and he simply ignores PR's to improve compatibility. I've had one on one of his other libraries open for years that would in one change support every modern AVR..... sigh....

think you want either this...

#elif defined(MEGATINYCORE)
  #define CORE_NUM_INTERRUPT EXTERNAL_NUM_INTERRUPTS
  #define CORE_INT0_PIN   PIN_PA0
  #define CORE_INT1_PIN   PIN_PA1
  #define CORE_INT2_PIN   PIN_PA2
  #define CORE_INT3_PIN   PIN_PA3
  #define CORE_INT4_PIN   PIN_PA4
  #define CORE_INT5_PIN   PIN_PA5
  #define CORE_INT6_PIN   PIN_PA6
  #define CORE_INT7_PIN   PIN_PA7
  #define CORE_INT8_PIN   PIN_PB0 
  #define CORE_INT9_PIN   PIN_PB1
  #define CORE_INT10_PIN   PIN_PB2
  #define CORE_INT11_PIN   PIN_PB3
  #define CORE_INT12_PIN   PIN_PB4
  #define CORE_INT13_PIN   PIN_PB5
  #define CORE_INT14_PIN   PIN_PB6
  #define CORE_INT15_PIN   PIN_PB7
  #define CORE_INT16_PIN   PIN_PC0
  #define CORE_INT17_PIN   PIN_PC1
  #define CORE_INT18_PIN   PIN_PC2
  #define CORE_INT19_PIN   PIN_PC3
  #define CORE_INT20_PIN   PIN_PC4
  #define CORE_INT21_PIN   PIN_PC5

Or with them defined as just the number (eg, #define CORE_INT0_PIN 0) , depending on what exact trickery it's up to.

I think I saw it successively testing if CORE_INTn_PIN was defined, so lines corresponding to pins that don't exist probably should be #if'ed out which can be done several ways with the defines we provide. (There are more beyond this that are all equivalent tests) PC4-5 and PB6-7 can be guarded with #if defined(PIN_PC4) or #if defined(__AVR_ATtinyxy7__), the PC0-3 and PB4-5 with #if defined(PIN_PC0) or #if defined(__AVR_ATtinyxy7__) | defined(__AVR_ATtinyxy6__), and finally PB0-3 and PA4-5 can be guarded by #if defined(PIN_PA4) or #if !defined(__AVR_ATtinyxy2__). (testing any of the pins added at a pincount increment is the same since they come and go as a group, and we only define them on pincounts where they exist. I am pretty sure that there aren't going to be any tinyAVR 3-series or beyond, and if there are, it's overwhelmingly likely that they will have the same pinout (in which case we're all set), or they will be reduced core, no good for arduino (in which case we don't care), or else they're a tiny in name only. At this point, the tinyAVR pinmappings and the upper bound of the flash are the only thing that really distinguishes tinyAVR from the Ex/Dx-series parts, with 8k 14-pin EB-series announced - and they cap out at 32k.

Anyway - I think I'm missing something - this library seems to be a really complex and unnecessary construction to do something that's pretty cookbook, and that method doesn't involve Encoder
(Off-topic)
Hum.... interesting, when did that come about... I wonder if I was fully aware that I did that. attachInterrupt() takes pin numbers, and digitalPinToInterrupt() is just replaced with whatever you pass it, and the logic of converting pin numbers to the internal implementation that relates to the hardware is done in the function (with just the digitalPinToPort()/BitPos() macros like usual). I mean, I think this implementation is better, because it avoids a trap for people who foolishly do attachInterrupt(pin,...) instead of attachInterrupt(digitalPinToInterrupt(pin),...). The only thing you can attach to is a pin, and every pin can get an interrupt (via a hideous contraption*), so what else would you expect the first argument to be but a pin?

(on classic AVRs, as you may recall, attach only worked on the INTn pins - they merged the functionality of INTn and PCINT into one thing - one vector per port, but all 4 interrupt modes selectable per pin)

* It is more hideous than the stock implementation to read, by far, though it is smaller and faster. The original was more readable, and looked small and efficient, but wasn't; it was mostly bad because of the nasty fixed cost on the smallest flash parts I still consider it a failure though - the secondary objective was achieved, but the whole reason I did all that crap was because I thought that I could get it to only include the vector if it knew that the value passed to it was a constant. Which in turn would mean that as long as I was keeping my hands where the compiler could see them and passed only compile time known constant values for the pin when using attachInterrupt(), it could coexist with manually defined interrupts on other ports. I don't think it's possible to coerce avr-gcc into doing this. So attachInterrupt is an all or nothing proposition. I don't use it in my code because the "all" is too gutwrenchingly slow and stupid and bad, and it makes me gag when I see the assembly listings. And that's after I renovated it!

[grandaspanna]

Thanks - much appreciated. To make it work originally, I did something pretty much along those lines.

My first projects with encoders used bare bones code without interrupts and were simple enough. I think I'm just a tad lazy and went looking for something that was easy enough to adopt. There's a few libraries for encoders out there and just seem to see the world quite differently from me. At some point, I'll do my own approach, but don't know how library-able it will be.

I've implemented my first onboard USB/UPDI programming port with a CH340N and that's cool. I'll add this to more :-)

[SpenceKonde]

Oh yeah, I was not saying that the cookbook encoder strategy was easy to understand, only that it was easy to copy.
IMHO the fun of doing the encoder on a case-by-case construction is that that way, you can exploit bit arrangements in a way that a general purpose library cannot (eg, using the same ISR to handle both pins changing state), and generally get the ISR much smaller and faster than a general library could

Yeah, the CH340N is really convenient. I've also got a few boards in progress based on the CH342 - dual serial port, and a separate I/O voltage.

Here's an interesting thing to ponder - DU-series release is coming in the not terribly distant future.
Suddenly you have a choice between a CH340N and an AVR32DU14 programmed to act as a serial adapter (or a dual serial adapter, or a dual serial adapter with one of the ports in single wire (UPDI) mode). That seems like a pretty cool trick.... And is pricing trends are as they have been, we might see one for just a buck? That's less than a CH342 or CH343. (though not a CH340N).