UDP issues and workarounds

Troubleshooting
22

It’s good to know about the Photon. Thank you! Any chance the endPacket issue will be fixed in the firmware?

To get around the lack of buffer, I wrote a MemoryStream class (http://pastebin.com/rSqrRKax) inspired by C#'s MemoryStream. I can write:

MemoryStream* stream = new MemoryStream();
stream->write((byte)'h');
stream->write((byte)Spark.deviceID().length());
stream->write(Spark.deviceID());
udpClient.beginPacket(serverAddress, port);
udpClient.write(stream->getBuffer(), stream->getSize());
udpClient.endPacket();
delete stream;

MemoryStream is helpful because it expands dynamically and efficiently. The firmware API could use a solution like this behind the scenes rather than fixed size buffers.

23

@jnm2 makes a good point. The endPacket problem/feature/bug and buffering for sending could and should be fixed. I would attempt to fix it if I was proficient enough in c++.

Good Luck! Personally I have abandoned the spark core for receiving UDP packets. I can't design something that doesn't follow network standards. Even if I could tell 3rd parties that I needed them to encapsulate their UDP packets in an envelope they would laugh. Nor do they want to spend the development time implementing. I also refuse to write a UDP proxy either, one of the many points of UDP is the speed and this takes away from the speed. I also don't want to have to additionally support a proxy increasing my total cost ownership.

I hope from all the threads about UDP that the photon addresses all these problems. I really like the "spark" feature set: cloud, web ide, community, price, ability to use wifi without much difficulty, and all the other features. Nice job spark team. Please have this fixed in the photon.

Thanks

24

Hi @jnm2

Your MemoryStream class looks very nice and is interesting but heap fragmentation is a real problem on processors like Spark and calling new many times for small numbers of bytes is usually not a good way to maintain stability. Static allocation is generally more stable and leads to fewer problems on smaller processors like this. The Spark team are moving to less static buffer allocation at compile time, but to allocate only the buffers you really need for your code–right now there can be unused buffers allocated in RAM by the base firmware.

One other point is that there is no point in growing the UDP buffer size to be larger than the MTU size of the TI CC3000 which is fixed at 1468 bytes maximum if you intend to call UDP.write on that buffer. You are dealing with the packet level interface and there is no other buffer in the system to absorb your write requests, other than the packets buffers inside the TI part.

I had thought about sending in a pull request to fix the UDP write/endPacket problem too but then Photon happened and things are going to be different in the future. You can try out the branch that will be used on Photon right now on your Core if you setup the local gcc tool chain and build locally, but I don’t think it addresses these issues yet.

25

@bko please submit your write/endPacket fix. This seems to be in the realm of firmware under sparks’ control.

2 Likes
26

Having issue after flashing:

In setup has begin with binding to port
void loop()
{
if (Udp.parsePacket() > 0)
{
//
}
}

After it Photon is flashing with red. I comment parsepacket in loop works. Fw 0.4.4

27

Any ideas? Because it worked on 0.4.3

28

Hi @Aka_Abe

Can you show us the minimal program that demonstrates the problem? I have used 0.4.4 with my UDP code and it is working for me. Maybe something else is causing trouble for you?

29

Hi,

I think problem is in call to Wifi.LocalIp(). Please see code below:

char localIp[4];

UDP Udp;

void initLocalIp()
{
IPAddress mylIp = WiFi.localIP();
sprintf(localIp, “%d.%d.%d.%d”, mylIp[0], mylIp[1], mylIp[2], mylIp[3]);
}

void setup()
{
Udp.begin(8888);
initLocalIp();
}

void loop()
{
if (Udp.parsePacket() > 0)
{
}
}

30

This is way too small for the dotted IP address you are printing and so it overwrites something else in memory.

Try increasing it to char localIp[16]; or larger since there are 3 digits per address byte and three "."'s plus the trailing zero byte to terminate the string.

3 Likes
31

Solved. Thanks!

1 Like