AsyncLabs Forums

[rusty]

Just curious... well, more than that 'cause I've got some ideas for using UDP.
The question is -- are there plans to enable UDP transmit and receive with the
WiShield? It looks like it's been #define'd "off" for the time being. UDP would
be nice to have, especially for applications using DHCP or broadcasting sensor
readings or GPS data or whatever. And DHCP ain't just for getting an IP address,
ya know. (I'm sure you did

Just wondering what the Async Labs thoughts are along these lines.

-Rusty-

[gsxrex]

UDP is definitely coming. UDP makes a lot of sense for certain applications where the data integrity of TCP isn't quite needed. We just want to make sure that we can put in some quality cycles to test everything first before we release it to the wild. We don't want to throw any more curveballs to everybody when it comes to stack performance.

[benquark]

Alright, so UDP is working now. There is a new sketch on GitHub called UDPApp which shows a simple UDP endpoint implementation. To enable UDP and use the UDPApp sketch,

• Uncomment APP_UDPAPP in apps-conf.h
  

  Code: Select all

  //#define APP_WEBSERVER
//#define APP_WEBCLIENT
//#define APP_SOCKAPP
#define APP_UDPAPP
//#define APP_WISERVER


• Modify uip-conf.h as follows,
  

  Code: Select all

  #define UIP_CONF_UDP              1
#define UIP_CONF_UDP_CHECKSUMS    1
#define UIP_CONF_BROADCAST        1


[rusty]

Hotd*mn Sam!!! (woot)
That just made my weekend!
Thanks, guys!

[rusty]

Ooopss! The file 'UDPapp.pde' is... the simple webserver source file.

[benquark]

That was a trick to see if anybody would notice the similarity

Thanks for pointing it out. Fixed now.

[comperem]

benquark,

The UDP code looks great for bi-directional communications. From looking at stack.c it appears to be well suited to send out udp packets in response to incoming udp packets. The blocking protothreads conveniently provide this interlock without relying on polling. That's great but it not well suited to my application. The UDPApp does not appear to be well suited for sending udp packets out at a frequency determined by main() in loop(). Also, I do not want to wait on a timer to expire (at least not the timer in the uIP code)

What is the best way to send outbound udp packets without assuming a uIP timer will expire or that an incoming packet will trigger the sequence?

Marc

[benquark]

@comperem

That is true. The UDPApp is just a sample sketch to show how to get started with UDP. We just included something which can be quickly tested out with the included PC application out of the box.

For your application, you might have to make some modifications to call your UDP send() routines from the main loop. In the main loop, stack_process() is always called. In stack_process(), there is a check to determine if an incoming packet was received and if the timer expired. You can add another else clause here to include your UDP send() routine. To send a UDP packet, you need to call uip_send() and uip_process(UIP_UDP_SEND_CONN) in sequence. Look at the udpapp.c file to see an example of how uip_send() is called.

Hope this helps.

[comperem]

benquark,

Yes, that is helpful. I've read all the code but was unable to simplify the necessary steps to the two simple commands you suggested. I will try this shortly. In the mean time I have gotten something working but am still figuring out how the protothreads implementation works in conjunction with WiShield::run().

It seems WiShield::run() gets ticked very, very quickly. Wide open throttle on the arduino. But the handle_connection() function in udpapp.c (or socketapp.c) seems to be run as a blocking call as a result of PT_WAIT_UNTIL(&s.pt, uip_newdata());. Is this correct or even possible? I thought blocking calls, well..., blocked.

Is this a correct interpretation of how the loop() function operates? Can loop() really continue on being called even though handle_connection() is being blocked by the protothread?

Marc

[GregEigsti]

So after looking over the sketches that you provide I think that the UDP sample is what I'll be using for my first Arduino/WiShield project; just have a quick question and a couple of comments

In udpapp.c (of the UDPApp sample sketch) the function udpapp_init has a hardcoded IP addr of 192.168.1.100 which then has "bind" called on it. How is this IP different from the local_ip defined in the main UDPApp sketch file (the file with setup() and loop())? I looked at the "Sample PC network application" on the wiki and see no reference to the address 192.168.1.100 but I do see a reference to 192.168.1.2 which is the default value for local_ip.

And suggestions...
A better set of docs would be friggin awesome! Yeah I know that you are busy and its pretty obvious that you are still bootstrapping this project - but I just had to chime in!
I would buy you a beer or 12 if someday you provided a BSD socket like abstraction layer. A lot of folks are really used to BSD sockets and it would cut down the ramp up time considerably. Of course I am an Arduino newb so I am still learning the "Arduino way". And, uh, yeah, I guess that once I get to know your code a little better I could do that

Thanks for the awesome widget! Looking forward to having fun with it!!!
Greg