How can I -simply- "print" to an UDP port?


I wrote a quite long program that has a lot of serial communication.

Currently I can define several serial ports to issue messages and reports and change their ports just upon using a macro.

I would like to be able to "print" and "printf" on UDP the same way.
The only thing is that one must open the UDP channel before "printing" and close it after.

How would you do it in the most elegant way?

What's your board?

The UDP class inherits from Stream.

  • On an ESP architecture that means you can use printf() directly on your WiFiUDP instance
  • on small AVRs printf is not implemented for Streams due to the limited available memory.

Yes I use ESPs.

The point it to open and close to port at each line when printing to UDP.
In a function?
I could open the port in a macro to replace Serial, but not close it after the print statements.
Or rewrite everything to prints() and swap the function calls with a macro?

The aim is to have a common code irrespective if the output goes to a physical serial port or to an UDP port.

that's not always desirable, is it? that's why you usually have a Udp.beginPacket(), then the payload (where you can use printf), then the Udp.endPacket();

if that's OK to encapsulate every single print into a transaction then you could probably write some macros. May be something like this would do? (totally untested)

#define udpprintf(udpStream, ip, port, ...)   {udpStream.beginPacket(ip, port); udpStream.printf(__VA_ARGS__);  udpStream.endPacket();}
#define udpprint(udpStream, ip, port, ...)    {udpStream.beginPacket(ip, port); udpStream.print(__VA_ARGS__);   udpStream.endPacket();}
#define udpprintln(udpStream, ip, port,...)   {udpStream.beginPacket(ip, port); udpStream.println(__VA_ARGS__); udpStream.endPacket();}
#define udpwrite(udpStream, ip, port,...)     {udpStream.beginPacket(ip, port); udpStream.write(__VA_ARGS__);   udpStream.endPacket();}

why UDP instead of TCP?

Why TCP instead of UDP?

I already have UDP streams and the leaner the library the better.

Did the #define work?

i worked on a project where i was told the chances of an communication over the backplane was virtually zero. this ended not being true when application speeds increased and there were buffer overflows.

tcp inherently takes care of flow control.

not know thing the application, it's unclear to me if this is a potential issue

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.