Compilation fails on WSN430-v1.4. Can you see into it?

forgot to include header and define for DEBUG() statement. Should be fixed now.

Travis is happy again.

@thomaseichinger Please exceuse me for the delay in my reaction, I've been busy with exam preparations last week. I should be more active again as of now.
Concerning this PR, ACK from me. I think you can squash it right away.
Maybe should we get another ACK to be sure... @OlegHahm what is your opinion?

Changed the milestone since it fixes a "FIX ME FIRST" issue.
@rousselk never mind, I'm the last one to complain about comment latencies :-)
@OlegHahm could you check?

TL;DR:
After discussing this topic with @OlegHahm today we agreed that the existing implementation for TelosB and Z1 are already the most robust ones. As a result I changed the ISR for wsn430-v1_4 to harmonise interrupt handling.

In the timing chart below two cases are described

1. In this (upper) case multiple packets arrive in very short time so the MCU cannot read a whole packet before reception of a 2nd packet has finished. Taken this case FIFOP pin signals the reception of a second packet but is cleared by reading data from the RXFIFO for the first packet. Continuing, a third packet arrives triggering the overflow interrupt. Now there is data of a complete packet (p2) and a fraction of another (p3) in the RXFIFO. One could argue that reading the data for p2 by reading the first byte (packet length) could be possible but this wouldn't be the case for p3. Due to the fact that the FIFO pin is inactive we can't verify that all data specified in the packet length is actually in the RXFIFO so reading could include undefined data. This is especially the case if RXFIFO is overflown already by p2. As a result we concluded that dismissing maybe valid data from the RXFIFO is safer than reading undefined data.
2. This (lower) case should describe the most common case, where data of a received packet can be processed by the MCU in time so no overflow appears and all is fine. \o/

@rousselk Do you agree with our argumentation?

@thomaseichinger To sum up: yes.
In detail:
1). Yes, this is a limitation of the chip: there is only room for one packet in both transmission and reception. If good network drivers can gracefully manage the former to avoid any clash, the latter depends on two consecutive packets never to arrive too closely timewise... On CC2420, we have the ability to play on the threshold of unread bytes in receive buffer (FIFOP_THR bits in the IOCFG0 register), to have the FIFOP signal go up earlier if we found this problem to occur to frequently. By default, FIFOP goes high when at least 64 bytes of unread data are in the RX FIFO (cf. CC2420 manual pages 33, 34, and 72).

However, I don't think this will be much of a problem: we will receive corrupted data ONLY if we read the RXFIFO bytes slower than the transceiver receives and writes them into its buffer; however, 802.15.4 is a (relatively) slow protocol (250 kbit/s, which mean each byte is received from the medium in 32 microseconds); since the MSP430 UART drives the SPI communication with the transceiver at half the MCU speed, that is: at least 1 MHz on TelosB and circa 4 MHz on Z1, we can quite safely assume that reading bytes from CC2420 will be done faster that the transceiver receives them.
This means we should only suffer from this problem if we begin to read a packet after the transceiver has begun to overwrite it with new one, but before the new packet has finished arriving. Since we use interrupts to react to packet arrival (FIFOP), this situation is quite unlikely...

2). This is the trouble-free case where we can read all the incoming packet before the next one begins to arrive. For the reasons cited hereabove, I think we will almost always be in this situation.

So: if @OlegHahm acks, I can merge this PR, maybe after a squash.

ACK - merge or squash, I'll leave it to you, @thomaseichinger.

squashed and go

Nice! :)