SPWF01 limitations

[etesial]

Posted on January 13, 2015 at 16:29

Hi,

we are designing a VoIP (SIP/RTP) device with a stm32 microcontroller. It must also have WiFi connectivity, so SPWF01 would be a natural choice. However we've run into limitations of built-in TCP/IP stack while checking required functionality with devkit: 1) It's not possible to specify local port that client UDP socket binds to. We could do instead with a) creating socket, b) finding out local port it's bound to, c) specifying remote host:port to ''connect'' to, but that can't be done either. 2) Server UDP socket cannot communicate with several clients. Packets from the same IP from different ports are merged in common data stream. Packets from other addresses are ignored. 3) It's not possible to reliably identify boundaries of individual packets. UDP packets are merged in single datastream. Actually in command mode it's possible to calculate boundaries of packets from receive notifications, but in data mode notifications are not delivered and information about packet sizes is lost. So is there a way to solve those problems? Have I missed something in documentation? It would be great if there was a ''raw ip socket'' or ''raw ethernet socket'' so we could just receive/send raw frames and plug that into network stack on MCU. Is there a possibility to do so? #spwf01

[marcoelia9]

Posted on January 19, 2015 at 09:55

Hello all, I agree with Alexander. We have, more or less, the same problems pointed out by him, and the best solution would be to use the module as a network interface, running the TCP/IP stack on a separate MCU.

The module at its current status is pretty useless because the MCU on it has not enough resources to do the minimum stuff required in a REAL product with WiFi connectivity.I'm looking forward for some positive responses from ST.Marco

[Gerardo GALLUCCI]

Posted on January 19, 2015 at 10:43

Hi Alexander,

current module's limitations comes from  choices made by HW resources (your point #2) and best ''easy to use'' approach (your point #1, #3, and raw sockets possibility too).Next planned HW release will remove some current limitations. For sure your point #2.