Question re: use of PCINT and current limiting resistors

Using Arduino Project Guidance
1

Hi everyone,

I'm trying and failing to make use of PCINT pins on a 1284P, most likely due to also having LED's on the input pins. That will be fixed tonight (i.e. LED will be yanked) but I have some additional questions I hope that someone can help me with. I am using a 1284p with the EnableInterrupt library, the Mighty 1284p Optibootloader, and version 1.6.6 of the Arduino IDE.

My current proposed connection implementation is as follows:
Wire Terminal - 470 Resistor - GPIO pin on 1284P.

The GPIO pin would be configured via the pinMode (x, PULLUP_INTERNAL) command.

Then I'd use a ISR from the library and have the 1284p report a reed switch, pushbutton, or even NPN transistor grounding the Wire Terminal input.

The 470 Ohm resistor is simply there to limit current in case something goes wrong on the outside. I doubt it would have a significant impact on the PCINT signal if the pullups are indeed on the order of 50k as I have read elsewhere on the forum.

That said,

  1. Can I rely on the built-in pull-ups alone or would a stronger external pull-up be a better choice?
  2. Does the EnableInterrupt library enable built-in pull-ups? Or should I enable that function separately?
  3. Is such a use of current limiting resistors permissible? Or would I be better off without it?

Lastly, I wonder if anyone has used PCINTs with external zener diode protection and whether the use of a zener could influence things somehow?

2

470 is overkill, but will work.
As long as the external device can drivea pin low (i.e. has 5V/30000 ohm amp of current sink capability, so 16.7uA?) then it can create a LOW interrupt.
Zener would just keep the pin from going too high.
Stronger pullup might be suggested (1K to 10K) it there would be long wires connecting the switch to the pin.

3

Crossroads, you are amazing as always!

Have you made use of the high-speed mode in EnableInterrupt? The wiki for the highspeed portion does not mention the 1284p even though the regular-speed library does seem to support it. The high-speed library may be just what the doctor ordered for me...

4

What high speed mode? I have never heard of that.
I just did my own PCINT ISR with some help from Nick Gammon.

5

The enable interrupt library comes in two flavors, normal mode (where a appropriate interrupt triggers a function call) and high speed mode, where a uint8_t is incremented each time a change is detected.

The benefit of the high speed mode is that you are much less likely to have the problem of the uC detecting a interrupt but by the time it reads the port byte the triggering pin appears unchanged (because it has already flipped back). For my application, the ISR equivalent would have been just incrementing a uint8_t anyway, so using high speed mode is a good fit.

I also wonder to what extent only using one PCINT per port is helpful, i.e. Ensuring that whatever interrupts are triggered can only point back at one pin and simultaneous interrupts on one bank cannot happen.

6

Is... there a reason you use that library instead of writing the ISR yourself?

7

I use libraries for the usual reasons:

  1. Easier to read code in the INO file (given the limitations of the Arduino IDE)
  2. Faster implementation of features than I could achieve on my own

I create libraries for my own projects for the same reason - being able to re-use code is a big plus, and 'known-good' implementations help with trouble-shooting. The Arduino IDE is a great achievement, but once you look at creating programs that can chew gum and walk at the same time, it can get very difficult to maintain it all. Libraries serve me well in that regard.

For example, this particular 1284P serves as the master to ten 1-Wire channels, 3 counters, and communicates via RS485 to a host MCU. If I were to put all the necessary code into one INO file, it would be thousands upon thousands of lines of code. It's quite unlikely that I would be able to maintain it all well.

Portions of the code (like RS485 communications protocols) are a natural for a library to enable consistency across multiple host/client units. FWIW, writing the RS485 communications library was my first taste of how difficult it can be to write a library that can compile across multiple platforms. The code base in EnableInterrupt is even more convoluted for that very reason (no shortage of compiler instructions!).

So... this chip uses EasyTransfer, OneWire, EnableInterupt, Metro, DallasTemperature, DHT, and other libraries to reduce the code in the INO file to less than 500 lines as of this writing. Once the RS485 comms is fully implemented, I expect that to grow to maybe 750 lines.

Anyhow, the HIGHSPEED mode of the EnableInterrupt library is EXACTLY what I was looking for, i.e. a simple uint8_t incrementing variable in the background that I can query /reset whenever the MCU is done doing other stuff (like resetting the 1-Wire bus, or talking to the host MCU). Unfortunately, HIGHSPEED mode does not compile as of this writing due to numerous issues with the library and/or my IDE. So I will rely on the usual function call that is not as MCU efficient (per GreyGnome's testing) but that likely works well enough.

Though I was able to resolve the issues with the default HIGHSPEED example on a 1284P, the errors that sprang up once I tried compiling with pins 29,20, and 30 were beyond my current abilities to address. So I posted my issues here and perhaps GreyGnome will take a look at the code to see if these issues can be addressed. Bottom line: I am incredibly grateful to the folk who take the time to write and publish these sorts of libraries, they make so much possible in so much less time.

Standing on the shoulders of giants indeed.