Portenta UDP parsePacket delay

Using Arduino Networking, Protocols, and Devices
#1

I am trying to get a very simple proof-of-concept running for a project. The project uses UDP Multicast communications. In the "Loop" of the project I need to check if any UDP data has been received. I am using the following code:

WiFiUDP udp ;

if ( (ret = udp.parsePacket()) != 0)
{
    char rxBuffer[64] = {0} ;
    udp.read(&rxBuffer[0], sizeof(rxBuffer)) ;
    Serial1.print(&rxBuffer[0]);
}

What I find is that when there is no data received the "parsePacket" call takes 1-second. This of course delays the whole loop.

Is there a better way of checking for data than this?

I searched but could not find any asynchronous interface that would accpt a callback, this would be my ideal. Is this possible with Portenta and UDPMulticast?

#2

there was this comment a while back, I though it got fixed

have a look as well to the source code

"hoping" is not usually very scientific...

#3

Thanks for the suggestion, I tried disabling interrupts as shown in the link. That caused the sketch to crash and throw an exception:

++ MbedOS Error Info ++
Error Status: 0x80010133 Code: 307 Module: 1
Error Message: Mutex: 0x240019A4, Not allowed in ISR context
Location: 0x8045347
Error Value: 0x240019A4
Current Thread: main Id: 0x2400B6CC Entry: 0x8045271 StackSize: 0x8000 StackMem: 0x240036A8 SP: 0x2400B574
For more info, visit: mbedos-error
-- MbedOS Error Info --

More seriously, this exception caused the IDE to no longer be able to get the Portenta into DFU mode, I had to force DFU mode to recover.

#4

unfortunately no further ideas...

#5

It seems the problem is that in the "WiFiUDP" class the constructor hard-codes the socket timeout to be 1,000mS and provides no public method or member to adjust this. Really poor design.

The "UDPSocket" class exposes the "set_timeout" method (used in the "WiFiUDP" constructor, but neither the socket itself nor the method are accessible from a sketch.

#6

Subclass ?

#7

Possibly could go that way.

#8

Except of course the socket variable is "private". I don't think private members may be accessed in a subclass, only "protected" members may be accessed by a derived class.

#9

What about the method?

#10

Which method are you asking about?

#11

I'm on my phone. I was wondering if this was available to subclasses.

#12

Yes the set_timeout method is public in the UDPSocket class, but, the instance of that class in the WiFiUDP class is private.

I think the best approach here is to switch to using MBED, then, a separate thread can check for network input and use IPC to inform the main thread.

#13

OK

(or modify the library)

#14

Yes, that is how I proved my hypothesis was correct. Problem is that there are a number of PRs for libraries outstanding for several months, so, the chances of it being merged soon are not great.

Thanks for the posts, I really appreciate your efforts.

#15

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