Serving a more prioority interrupt while a I2C packet incoming (Arduino as slave

Hi mates, I've a question.

I'm planning to use a Mega 2560 to drive some triacs so I need to detect the zero crossing of the 220v line, I was thinking to use for it an interrupt but I discovered that in the level of priority (which we can't change) any of the hardware pins has more priority then I2C hardware pins. That means if a packet is incoming from Raspberry (I want to use Arduino ad slave I2C device, the Raspberry tells it the level it has to set to triac outputs) and during this a zero crossing is incoming, the packet will not be correctly received, discarted

Questions:

  1. will the raspberry (I'm using Node Red) resend automatically the packet? Can this overcome automatically any situation like that? Or should I answer from Arduino that I received correctly the packet or eventually ask for a retrasmission?
  2. In case of trasmission from Arduino to Raspberry, can this create a problem too?
  3. an uncomplete packet will infulence the performance of the I2C bus? I mean.. for example will Arduino keep waiting for the completition of packet( which it losts during the zero crossing) and because of this discard/mark uncorrectly the next packet?

Well there are other interrupts that may occour, internal timer for example. I really don't have idea if it's worth to use I2c or I sould invent/create other type of comunications.
Thank you!

  1. will the raspberry (I'm using Node Red) resend automatically the packet? Can this overcome automatically any situation like that? Or should I answer from Arduino that I received correctly the packet or eventually ask for a retrasmission?

No, the Raspberry Pi won't recognize that the byte (which is the I2C packet size) wasn't correctly received, if that actually was the case (see below).

  1. In case of trasmission from Arduino to Raspberry, can this create a problem too?

The Arduino cannot transfer anything to the Raspberry by I2C, it can only answer requests.

  1. an uncomplete packet will infulence the performance of the I2C bus? I mean.. for example will Arduino keep waiting for the completition of packet( which it losts during the zero crossing) and because of this discard/mark uncorrectly the next packet?

Yes. If the Arduino is busy handling the zero-crossing interrupt, it stretches the clock on the I2C while the I2C interrupt is not handled.
This shouldn't be a problem as interrupt handlers must be written to not use the processor for a longer time period. This holds true for both the zero-crossing interrupt and the I2C interrupt (as the zero-crossing interrupt is blocked while your handling the I2C interrupt).

So to keep it short: most of the problems are handled by the hardware. But if you do the programming wrong (lengthy interrupt handlers) any part of your system may fail (I2C might be blocked for a longer time, triac activation might be delayed).
The priority of the interrupts is only relevant until the interrupt handler was called. Once your sketch entered the interrupt handler all other interrupts are blocked until you return from the interrupt handler.

thank you really for your precious help!
From you I’ve learned:
Once in interrupt a higher one will not stop its process, so the I2C packets will be delivered or almost prepared (see after other question)

Well, as the core question is how the I2C interface works, then all the questions should consider it. As I read around the I2C interface is indipendent and contain a bugger of 32 bits, probably then it will receive autonomsly the packets and rise an interrupt when the stop bit is received, if so it’s sufficient to limit the bytes on 32 and don’t transmit more before the slave will acquire infos, and there will be no risk to lose or corrupt anything.
Yes the slave is not able to take initiative on the bus, so the master can’t know when slave complete the acquisition and is read to receive the next load of bytes, it probably have to ask it, but asking it too early (the slave haven’t yet processed the interrupt) it may destroy all or part of 32 bytes. Interesting here to hear if it’s like that, I’m just guessing.

So I then suppose the master should know how slave works and load it correctly, guessing how much time it could be busy with other interrupts.
Honestly this is not my case, it’s just for my interest to ask it, if you may confirm me the presence of an autonomus I2C interface that can hold bytes until I read them I’ll be ok, it will happen, I’ve just to send a couple of bytes or to request a value (byte, intensity of a particular light).

As I read too the wire library supports one slave address, it may be interesting to simplify the software to have one address for every triac, do you know if it’s possible?
Thank you!

As I read around the I2C interface is indipendent and contain a bugger of 32 bits, probably then it will receive autonomsly the packets and rise an interrupt when the stop bit is received,

I guess that should read "buffer", the buffers are 32 bytes in size but these buffers are not in the hardware but in the Wire library.

Yes the slave is not able to take initiative on the bus, so the master can't know when slave complete the acquisition and is read to receive the next load of bytes, it probably have to ask it, but asking it too early (the slave haven't yet processed the interrupt) it may destroy all or part of 32 bytes.

The master knows exactly when the slave got all bytes, the master is providing the clock signal for the transfer. Once the method Wire.endTransmission() returns all bytes in the buffer were transferred. The result code of that method tells you if the transmission was successful.

Honestly this is not my case, it's just for my interest to ask it, if you may confirm me the presence of an autonomus I2C interface that can hold bytes until I read them I'll be ok, it will happen

The I2C interface together with the Wire library: yes. But this holds only true if interrupts are activated. So if you have your own interrupt handlers and they weren't written with performance in mind (they shouldn't use more than a few microseconds) this system might fail.

As I read too the wire library supports one slave address, it may be interesting to simplify the software to have one address for every triac, do you know if it's possible?

Not with that hardware. It's usually a bad idea anyway to have multiple addresses in one device. Define a well-designed command set where you can address the corresponding hardware using registers as most sensors do and you won't get problems.