I am working on a program that transfers information between a esp8266 and an arduino due both ways (from the esp to the due and from the due to the esp).
Basically, i have a touchscreen hooked up to a due that collects information based on presses of the touchscreen, fills out an array, then sends it to the esp for broadcast. In return, the esp reports the weather and time for display on the screen when i'm not pressing buttons.
The esp is the master and the due is the slave, so every time through the loop the esp requests data and the due dutifly sends it. I am just wondering if this is ok (Its working) or if there would be any benefit in requesting I2C data say, only every three seconds or so? (i'm not doing anything where clock cycles is critical).
I was mainly asking about best practices regarding i2c, since i'm not that familiar with it. I didn't think i should need to worry about it but.. why not be sure.
Here is the code. Its probably like 10k lines. 
programs.zip (52.1 KB)
Transferring data only when it is needed, is generally a best practice. But sometimes it is more efficient to send redundant data and only use what you need (because selection can add a small overhead). You have to look at the side effects.
One way to look at things, is that if you keep everything sensible at the start, there won't be a mess to clean up later, if you have to expand or alter functionality.
By sensible, I mean that the things you do make sense. Here is an example of a side effect. You can write zeros to a port pin all day long and it will just stay low. If your code is more efficient that way, then it doesn't matter. But it seems logically like hitting your head against the wall (it wastes CPU cycles). However, it takes code and memory to avoid doing it. Suppose you decide it doesn't matter, and get in the habit of doing such things (or never learn to do it any other way). Now you apply that habit to writing something to a TFT LCD display. Your program slows to a crawl and the screen flashes repeatedly. Now you have to apply some sense to it, and only write when something actually has to change.
In the case of I2C, it doesn't sound like a great idea to burden it with 1000 times more data than it needs to transfer, because there is substantial overhead in doing it.
Thanks.
So if I understanding correctly, for i2c:
I have a master and a slave, the master has to request the data from the slave in order fore the slave to send data to the master.
I only want to send data to the master if information has changed on the slave. How will the master know that data has changed on the slave, therefore making a request to the slave?
Qdeathstar:
Thanks.
So if I understanding correctly, for i2c:
I have a master and a slave, the master has to request the data from the slave in order fore the slave to send data to the master.
I only want to send data to the master if information has changed on the slave. How will the master know that data has changed on the slave, therefore making a request to the slave?
A slave cannot initiate a transaction. So you have to either poll the slave, or have the slave send a signal by some other means, like an I/O port connection.
Expanding on aargs reply. Hook one extra wire between the esp and the due. If there is a change, the esp pulls the pin low (or makes it high).
In the loop() of the due, you check if there is a change. If so, do your I2C. When the esp has completed the I2C it will make the pin high again (or low).
Depending on how responsive it has to be (the above will be responsive), you can also just let the due request data every 250ms instead of polling every iteration of the loop().
But I don't think there is anything wrong with the current approach for the given scenario.