Interrupt & communication

Hello All,

I'm working on a home automation project. Several Arduino's will function as gateway to a "SCADA" like system called Domoticz.

In short, I have the Arduino collecting data from several sensors like DHT22, Serial P1 data, Push-buttons, Hall sensor flow-meter etc. Also relay outputs will be used. Data is send/received from the Arduino to/from Domoticz with the W5100 shield.

I'm using the interrupts on some digital input pins (PORTD) for buttons and if possible the hall flow meter.

My question is, what happens when a message is send/received by the Ethernet shield or serial rs232 bus, and there is an interrupt caused by a push-button or flow-meter?

Is the communication disrupted?

For example when the flow-meter generates several pulses/s would this break the Ethernet comms? I don't mind missing some of the flow-meter pulses.

I'm using the interrupts on some digital input pins (PORTD) for buttons

Why? Why does pushing a button demand IMMEDIATE attention? Surely, noticing that a switch was pressed a few milliseconds later would be soon enough.

and if possible the hall flow meter.

That makes sense, since the hall effect sensor wont keep the pin HIGH (or LOW, depending on wiring) until you get around to reading it.

My question is, what happens when a message is send/received by the Ethernet shield or serial rs232 bus, and there is an interrupt caused by a push-button or flow-meter?

Serial data is already interrupt driven, and, as you've yet to observe a problem, that means that the interrupts do not interfere with other code, because they are very fast.

Any interrupt service routine you write must be very fast, too.

For example when the flow-meter generates several pulses/s would this break the Ethernet comms?

Interrupt, yes. Break, no.

I don't mind missing some of the flow-meter pulses.

Then, why are you bothering to read any of them? You should mind.

Thanks for the response. It somehow seems better to just react on a button push, than to make sure the other code finishes on time to reacts in a timely matter. Unless you use delays of course this happens lightning fast but if nothing changes on the input, why bother scanning it.

The reason I was asking this, I experienced some weird issues on the Ethernetshield. I had a server listening on a port, waiting for commands. Also a client was configured on another port. For some reason pushing the buttons sometimes crashed the listening server. The client continued working.

Once I disabled the interrupt while handling incoming client commands and enabling afterwards the problem disappeared.

So when connecting the flowmeter, which can generate a lot of pulses, it seems a good idea to disable the interrupts while the shield communicates and/or handling the incoming data routine.

RFMuser: . So when connecting the flowmeter, which can generate a lot of pulses, it seems a good idea to disable the interrupts while the shield communicates and/or handling the incoming data routine.

The idea is to make the interrupts fast, just count the pulses and return. Don't do any floating point or calls to libraries if you can possibly avoid it. Then just do any other processing that you need with those counted pulses in the main loop. Small interrupt routines like that can do their thing and return in as little as several microseconds.

As long as your main loop executes around 8 or more times per second (which it will if it's under 2 million cpu cycles) then you shouldn't miss any user input from polled switches.

A typical packet-based comms chip, whether ethernet or radio, will typically have on-chip buffers that are filled/emptied via SPI to/from the microcontroller, and at whatever rate the microcontroller wants. Typically all the timing sensitive stuff is fully autonomous on the comms chip, maybe it interrupts the MCU on receiving a packet or on completion of sending a packet.

Interrupts don't interfere with the hardware SPI. If you were to use software SPI it probably wouldn't matter either as SPI is explicitly-clocked - there is only a maximum rate, not a minimum.