I'm using a derivative of Interrupt-based Rotary Encoder Sketch by Simon Merrett, based on insight from Oleg Mazurov, Nick Gammon, rt, Steve Spence with pin change interrupts. I also make extensive use pf SoftwareSerial for RS485 communications.
Now SoftwareSerial is known for not playing well with others by consuming all the interrupt vectors for its own diversity. I've long since hack that into SSerialB, C and D so that each consumes only the vectors associated with its named port. Now when you include PinChangeInt.h preceded by the NO_PORTC_PINCHANGES directive, it and SSerialC work together nicely.
PinChangeInt however, was deprecated in favour of EnableInterrupt as being 'faster and easier to use'. That my be but given that it won't work with other libraries competing for the same vectors kind of makes the issue moot.
Is there something I'm missing? Without hacking EnableInterrupt is there a quick-and-dirty to having it work with other libraries (or code for that matter) that need pin change interrupts?
In frustration I started digging through the EnableInterrupt code again and noticed down around line 1700
reference to EI_NOTPORTC. I've since tried this as a compiler directive and it passes the verification test - no vector conflicts, which is promising. I will test in the next day or two to see if it will in fact work.
SoftwareSerial is very inefficient, because it disables interrupts for long periods of time. This can interfere with other libraries or prevent receiving data on Serial. It cannot transmit and receive at the same time.
Serial would be best, as you can usually continue to print debug statements to the Serial Monitor window. This does not interfere with receiving data from a device connected to pin 0. The only disadvantage is that you must disconnect pin 0 to upload sketches via USB. If your RS-485 protocol has message framing (i.e., a special start character), these debug prints will not interfere with sending a message on pin 1. One advantage is that you can see the debug prints and the sent messages on the Serial Monitor window.
AltSoftSerial is the best software serial library, if you can use the two pins it requires (8 & 9 on an UNO). It uses a TIMER, so it may interfere with other libraries.
NeoSWSerial is almost as efficient. It does not use any extra resources, but it only runs at 9600, 19200 and 38400. It has an option to allow it to co-exist with other libraries that use Pin Change Interrupts (e.g., EnableInterrupt). It can run on any two pins.
AltSoftSerial and NeoSWSerial can receive simultaneously, allowing you to add 2 receiving ports. However, transmitting on NeoSWSerial prevents receiving on AltSoftSerial. Transmitting on AltSoftSerial does not interfere with anything else.
AltSoftSerial and NeoSWSerial are available from the Arduino IDE Library Manager, under the menu Sketch -> Include Library -> Manage Libraries.
I've just completed some testing with EnableInterrupt handling my rotary encoder on PORTB (pins 8 and 9) and my hacked/chopped versions of SoftwareSerial on PORTC (pins 14 and 15) and PORTD (pins 3 and 4) working singularly and with both loaded and running two additional ports. All is well.
So the undocumented compiler directives EI_NOTPORTB, EI_NOTPORTC and EI_NOTPORTD all have the effect of releasing the respective interrupt vectors for use by others. In my case, I used EI_NOTPORTC and EI_NOTPORTD together with SSerialC and SSerialD and everything worked fine, until now.
I'll attach/upload a copy of my hacked/chopped libraries (SSerialB, SSerialC and SSerialD) just as soon as I figure out how. They are instantiated and operate the same way as SoftwareSerial -> SSerial mySerial(Rx,Tx), for any who are interested.