UDPApp out of the box

[zach]

Btw, the receiving side works if I just scale potValue down slightly. It would still be good to understand what's going on there, but it's not the most urgent matter at this point.

I do, however, need to get the multipoint communication working today if you have any ideas.

Thanks,
Zach

[GregEigsti]

UDP broadcast works just fine with the WiShield and sounds like the solution that you are looking for.

Greg

[zach]

Isn't UDP broadcast what I'm doing now? Do I just delete the line in your code where you specify the IP address of the Ubuntu box?

[GregEigsti]

From a very quick review of the code at the top of the thread, which I believe that you are using mostly unchanged, I would say no you are not using UDP broadcast. If I remember correctly there are a few things that you need to do in order to utilize UDP broadcast:

• The receiver of the UDP broadcast has to be configured to received broadcast rather than "point to point" packets.
• You need to enable UDP broadcast in the uIP/WiShield stack - UIP_CONF_BROADCAST in apps-conf.h
• The WiShield/Arduino "send to" address needs to be set to a broadcast value - 255.255.255.255 for broadcast everywhere or 255 as the last octet of your subnet to broadcast only within your subnet. For example if your subnet is 192.168.1.X then you would use 192.168.1.255 - most routers block UDP broadcasts at the subnet level so they will never make it past the subnet anyway. In the past I have used 255.255.255.255.

This all transpired a long time ago so I am a bit fuzzy on it; I have also since stopped using UDP as its uIP implementation is not as robust as the TCP implementation.

Greg

[zach]

That was easy. Already had UDP broadcast enabled per the UDP App instructions on your wiki and just had to set the IP addresses used in the init function in both to 255.255.255.255 and it worked. Didn't have to do any extra configuring on the receive side.

Thanks!

Zach

[GregEigsti]

Not my wiki - our wiki

Glad its working for you! There is a BSD sockopt that you need to set around UDP broadcast packets maybe its ti send and not receive - dunno, its been a while

Greg

[zach]

But you are the developer right?

Just out of curiosity (and I realize this isn't a C forum), is there a way I could have converted the string to an int on the receiving side (as in my code samples above) other than using atoi as to avoid the buffer overflow?

Thanks,
Zach

[GregEigsti]

But you are the developer right?

Nope, but I do play one on TV I do maintain the user contrib branch of the WiShield code but that is mainly adding new functionality and bug fixes.

What you are sending "across the wire" (or the air in this case) is just a bunch of bytes - where you choose to format them is totally up to you. If you are returning a web page then you will have to format on the server side as you cannot expect the browser to do that for you. If you are connecting with "custom code" then you are free to pass the values across in any format that you choose and format in any way (and anywhere) that you choose.

Greg

[zach]

But I don't seem to be able to set uip_appdata to an int. Referring to my code samples above, something like

Code: Select all

memcpy(uip_appdata, potValue, 5);

yields the error "invalid conversion from int to void*." It seems I can only set it to a string. I understand that I could write a custom library to pass ints via UDP, but the current one seems to only support strings. Or am I misunderstanding something here? My question was about a better way to convert the strings back into ints that would handle larger values without a buffer overflow.

[GregEigsti]

uip_appdata is (essentially) an array of bytes (or unsigned chars) and you cannot assign an int directly to it. Since, in Arduino/AVR land an int is two bytes you can split it apart and send those to two parts (HIBYTE and LOBYTE) as two bytes in uip_appdata but you do not need a library to do this - its one or two lines of code. And then you will need to reassemble those bytes on the other side - and if your intended data size will be larger than an int (or unsigned int) you will need to use a larger data type which uses more bytes.

In C there is no such thing as a "string" - there are arrays; what you might be thinking of as a string is likely an array of chars, bytes or unsigned chars.

Interestingly the Arduino environment (19) does not complain about the following code for me:

Code: Select all

int foo = 8;
memcpy(uip_appdata, foo, 2);


Greg