Interrupts and Arduino EthernetShield lib

Hi everyone, I'm in need of a little guidance in a project Im working on for college.

Basically, I'll be using two arduinos:

The first one will have: 1 RF Link Receiver (linke here: https://www.sparkfun.com/products/10532) 1 Ethernet Shield

The Second one will have 1 RF Link Transmitter (linke here: https://www.sparkfun.com/products/10534) 1 RHT03 Humidity and Temperature Sensor (https://www.sparkfun.com/products/10167)

As you can probably figure, what I want to do is read some data from the sensor in the second arduino, transmit it over RF, receive it and send it to a server in the web.

I'm having some trouble deciding what approach to take in sending via Web and receiving the data over RF. I'll need to constatly listen to the receiver, and If I receive a message then send it. I thought about coding a Linked List, and "storing" the values of the sensed data, and then send a http request for each object in the list until it is empty. But what if I receive another read from the sensor while I'm sending the message? What way would be best to send the data over the arduino Ethernet Shield and still be able to get the messages from the RF receiver?

I thought about interrupts, but I have no idea how it would behave while reading the response of the HTML request, as most examples use millis() and delay functions.

This is getting to be my “hobby horse”, but interrupts are a nasty distraction to “newbie” programmers. Interrupts can be - and should almost always be - completely ignored and left to the ambit of certain library routines such as those for keeping time.

They are basically never needed for a “HID” interface and in particular should never be used for pushbuttons where there is a need to de-bounce. Interrupts are for things that need a fast response, meaning computer-fast, that is, microseconds.

In this case (as so often happens), you have been confused by the idea that an interrupt will “interrupt” the task that you are presently doing. In fact and to the contrary, it is a critical point of design that your main program as such should never know that an interrupt has occurred at all because the interrupt has left the operating state of the main routine absolutely unchanged. Interrupts are intended only for events that occur in “computer time”; that need to be attended to within microseconds. By the same token, they have to be dealt with and completed within fractions of a millisecond - if only because other such important events may require attention.

I have not used the Ethernet modules, so cannot offer particularly specific advice regarding that, but in general, you load data into the module, and it sends it. You need to do this consistently to ensure the integrity of the data, but this can be interspersed with performing other tasks and the data has to be consistent; no point stopping halfway through - if you need to send an alternate version, well, you do that after sending the first. It may be worthwhile to investigate discussions here regarding “state machines” in this regard.

Now, note in regard to your receiver description:

Note: These modules are indiscriminate and will receive a fair amount of noise. Both the transmitter and receiver work at common frequencies and don’t have IDs. Therefore, a method of filtering this noise and pairing transmitter and receiver will be necessary. The example code below shows such an example for basic operation. Please refer to the example code and links below for ways to accomplish a robust wireless data link.

It is indeed necessary to have the receiver software continuously running in order to pick up transmissions (and even then, you expect that it will miss a proportion of transmissions, so they must be repeated). The code supplied does this, and (using libraries) handles the necessary interrupts (which are regular timer interrupts) for you.

This code needs to be interleaved in a “non-blocking” manner with the Ethernet sending code so that each performs a necessary step at a time but never waiting for any event, instead passing on to the rest of the “loop” code. When sufficient data is received to form a message, that is then transferred as a block (string) from the part of the “loop” code that assembles it piecemeal, to the code that forwards it on piecemeal.