Maybe this is of use:
https://www.wolfssl.com/docs/stm32/AFAIK the F217 is similar to the F417, but it has a Cortex-m3 instead of m4f core.
I'm not too familiar how the TLS handshake works if there are any faster options in the SSL libraries, but I guess it kind of makes sense that the handshake time is quite slow.
But realistically performance also depends on the TCP/IP stack. If the TCP protocol can't push more than 1MB/s (although I think more should be possible on that MCU), then upgrading to 10MB/s hardware acceleration is kind of moot. On the other hand, every cycle saved is a nice bonus..
Got to wonder though, is it an application requirement to run HTTPS? Is it a server or client? It implies the device is connected to ethernet, and frankly I still prefer to connect embedded devices behind some kind of tunnel instead of straight to the internet.
@DiTBho, what are you on about? The world moves forward and so does internet standards. The new HTTP3 standard doesn't even use TCP anymore and the whole protocol is built around TLS as a integral part. The transport is based on QUIC, which still uses UDP as it's still compatible with many home routers, but if they had the option they would also have skipped that. QUIC also offers nice features like being able to prioritize certain file transfers (e.g. audio over video) or connection handovers when the IP (and thereby NAT) is switched over. The killer feature thouhg is that QUIC+HTTP3 can do connection handshake, TLS handshake and the first HTTP request in 1 round-trip.
They don't expect 100% adaption of HTTP3 , but there is going to be a time when things will need to move over, and that this enormous beast (as it implements TCP, TLS, and part of HTTP with header compression in 1) of a protocol stack will have to run on embedded. So it's always better start learning today (read: keep learning everyday)