udp.read() - woher kommen die Daten?

[Frank E.]

Ich möchte mit einem Arduino und einem kleinen Display eine Art Monitor
parallel zu einer draußen stehenden LED (https://www.mikrocontroller.net/articles/LED)-Matrixanzeige bauen. Die
LED-Matrix (https://www.mikrocontroller.net/articles/LED-Matrix) erhält ihre Daten als RAW-RGB-Block per UDP-Multicast, da
könnte ich am Arduino bequem die Daten parallel mitempfangen.

Die Auflösung der LED-Matrix (https://www.mikrocontroller.net/articles/LED-Matrix) beträgt 192x96, was bei RGB über 55kByte
pro Bild sind. Wenn ich von der Sender-Applikation alternativ für den
Monitor ein Bild mit halber Auflösung erstellen lasse, bin ich bei
96x46. In RGB sind das ca. 13KByte - für Arduino immer noch ziemlich
"sportlich". Wndle ich die 3 Byte RGB für die Übertragung auf insgesamt
1 Byte (z.B. 3-3-2 Bit), bleiben noch 4,4k ...

Das Problem ist der vermutlich viel zu kleine Speicher des Arduino mit
ca. 2kByte. Dabei stellt sich mir die Frage, wo kommen die Daten denn
bei udp.read() eigentlich her? Werden die zwangsweise im RAM des Arduino
gepuffert oder werden die aus dem Empfangspuffer des Netzwerkchip
gelesen?

Wenn letzteres, dann könnte es gehen, denn der WIZ5000x hat 16 oder 32
KByte Buffer ... ein ENC28J60 (https://www.mikrocontroller.net/part/ENC28J60) immerhin 8kByte ...

[Mxt]

Hallo,



Dabei stellt sich mir die Frage, wo kommen die Daten denn
bei udp.read() eigentlich her? Werden die zwangsweise im RAM des Arduino
gepuffert oder werden die aus dem Empfangspuffer des Netzwerkchip
gelesen?

Ich habe keine Arduino mit Ethernet-Shield, aber wenn ich mir die Doku zur Library und das UDP-Beispiel anschaue, würde ich sagen, die Pakete stehen zuerst im Empfangspuffer des Ethernet-Interfaces und werden Byte- oder Blockweise in den Arduino geholt.

Es könnte so sein, dass weitere eingehende UDP-Pakete verlorengehen, wenn der Arduino die nicht schnell genug abholen kann.

Ethernet ist was, wo ich nicht mit Arduino arbeite. Ein mittelgroßes ARM-Board sollte keine Probleme mit den obigen Originaldaten haben, zumindest, wenn etwas Zeit ist, sie zu verarbeiten, z.B.
https://developer.mbed.org/platforms/FRDM-K64F/