Circumvent problems with UDP fragmentation

The ESP’s IP stack seems not to support UDP packet fragmentation and
drops such packets silently which is problematic for setups with many
LEDs and huge updates.

With this patch, the UDP server processes up to 3 full UDP packets per
frame, allowing much larger updates. Additionally, the new END_OF_UPDATE
flag allows to signal when a update sequence is finished. If this flag
is encountered, no further UDP packets are processed in the current
frame.

include/UDPProto.h

@@ -12,6 +12,7 @@ public:
         FADE_COLOUR = 1,
         ADD_COLOUR = 2,
         SET_FADESTEP = 3,
+        END_OF_UPDATE = 254,
         ACK_REQUEST = 255
     };
 
@@ -24,6 +25,8 @@ public:
     bool loop(void);
 
 private:
+    const static uint32_t MAX_PACKETS_PER_UPDATE = 3;
+
     WiFiUDP m_udpServer;
     Fader *m_fader;
 };

src/UDPProto.cpp

@@ -39,9 +39,12 @@ bool UDPProto::loop(void)
 	byte cmd[WS2801_CMD_LEN];
 	byte action, strip, module, r, g, b, w;
 	int len;
+	int packets_processed = 0;
+	bool done_something = false;
 
 	int32_t seq = -1;
 
+	while(packets_processed < MAX_PACKETS_PER_UPDATE) {
 		int packetSize = m_udpServer.parsePacket();
 		if(packetSize)
 		{
@@ -84,6 +87,10 @@ bool UDPProto::loop(void)
 						m_fader->set_fadestep(r); // red channel contains the fadestep in this case
 						break;
 
+					case END_OF_UPDATE:
+						packets_processed = MAX_PACKETS_PER_UPDATE;
+						break;
+
 					case ACK_REQUEST:
 						seq = ((int32_t)r) << 8 | (int32_t)g;
 
@@ -103,8 +110,11 @@ bool UDPProto::loop(void)
 
 			m_udpServer.flush();
 
-		return true; // processed a packet
+			done_something = true;
 		} else {
-		return false;
+			break;
 		}
+	}
+
+	return done_something;
 }