[Libwebsockets] LWS on the Texas Instruments SimpleLink CC3220.

andy at warmcat.com andy at warmcat.com
Sun May 17 14:22:14 CEST 2020

On May 17, 2020 12:03:40 PM UTC, Ralph Corderoy <ralph at inputplus.co.uk> wrote:
>I've the ‘good fortune’ to be writing some code on TI's SimpleLink
>CC3220SF chip on a LaunchPad CC3220SFMODASF development board.  It has
>multiple ARM Cortex CPUs in it.  My code runs on a ‘host’ Cortex-M4 and
>the project is using FreeRTOS.  A second processor is the ‘network
>processor’ running closed-source TI software; my first foray with
>source in a long time.  It is between me on the host CPU and the MAC
>PHY which give Wi-Fi.  TI provide source to run on the host which
>interfaces to the network CPU giving a socket API and high-level
>concepts, e.g. a HTTP server, with the network CPU doing all the work.
>The network processor also provides crypto facilities, including the
>storage of certs and secrets, with tamper detection, etc.
>Unusually, TLS is built into the sockets API with a struct pointer on
>some socket operations indicating things like TLS 1.2 is required, the
>ciphers which are acceptable, etc, rather than be a separate thing
>layered on top.  (TI say this is to make it more awkward to
>have a plain-text connection.) 


>It follows from the above that FreeRTOS is providing threading, a heap,
>..., but not a TCP/IP stack.

Normally freertos is paired with lwip.  If there's no lwip on your cpu there's no posix sockets, no socket fd and no easy way for lws to talk to it IIUI.

>Having spent a lot of time trying to use one TI-provided feature after
>another, I keep arriving back at Go, without collecting £200.  For
>example, the network CPU's HTTP server does not allow a body to be
>specified in reply to a POST request!  (This is ‘documented’ by one
>on page 194 of the 312-page Network Processor Programmer's Guide PDF.)

Tbh it sounds like the kind of proprietary mess it's best to stay as far as possible from.

>My need is to have a TLS HTTP server which will have a limited chat to
>an app on the WLAN to ‘provision’, i.e. tell me what I need to know to
>use the user's access point.  After that, I make a TLS HTTP client
>connection to a cloud server, promptly upgrade to a WebSocket, and chat
>away.  I was wondering how much effort it would be to port LWS to this
>platform to get that functionality.

From lws side, if there's posix sockets api it can likely interface to it without huge pain, since the tls is handled transparently.  If there's not, the key point is how can you do the equivalent of a poll wait?  It seems yoll basically need to add a plat implementation if it's like that.

LWS_PLAT_FREERTOS is already supporting lwip + freertos, if it's basically that wired up to an opaque but transparent-in-operation tls proxy basically then it should work out.

If it's something else who knows.

>I've downloaded and searched the mailing-list archive for any mentions
>of Texas Instruments, SimpleLink, or a CC3[23]xx chip, and found
>nothing.  (BTW, there are lots of duplicate, or almost identical,
>in the archive; 4,577 unique ones.)
>I see
>might be a half-way house where I use TI's code to get the TLS
>connection ‘file descriptor’ which is then adopted by LWS; presumably
>with TI taking care of things like renegotiation and LWS treating it as
>a plain-text connection.  This may be easier than teaching LWS about
>unusual merged socket+TLS API.
>I wouldn't want to move TLS to the host processor as this code runs off
>battery and gains from the network-CPU's hardware having crypto
>So overall, I'm wondering if LWS is a good fit, and whether the amount
>of porting labour required would be less than implementing HTTP client,
>HTTP server, and WebSocket myself given I only need to be able to talk
>to me on the other side of the ether, not all the implementations in
>world at large.

If lwip or another posix sockets api you can consider it.  Compared to rolling your own lws offers h2, for rtos-class client this is a big advantage since multiple streams can share a single tls tunnel.

Literally no tcp stack... effort required depends on exactly what proprietary mess is there instead.


>LWS looks like a nicely designed and coded piece of work so even if
>not suitable for this I'd like to experiment with it in the future once
>I'm done with TI.
>One last thing.
>https://libwebsockets.org/git/libwebsockets/tree/lib/event-libs looks
>wrong; it's linked from the home page.
>Cheers, Ralph.
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list