| Electronics > Microcontrollers |
| Ethernet interface for MCU |
| << < (6/7) > >> |
| nctnico:
That is another way of doing things (which I have promoted several times before) as the interrupt controller is essentially a pre-emptive task scheduler. |
| tellurium:
--- Quote from: Siwastaja on January 04, 2025, 01:05:24 pm ---But I recognize it does not work for everyone, and adding another layer of blocking calls (concurrently to blocking networking calls) is not possible without adding an OS with a task scheduler. --- End quote --- It is debatable what calls are "blocking". It is possible to make a TLS-enabled application totally non-blocking (i.e. no blocking IO functions) , it's just verification routines during the TLS handshake could be damn slow, so the app will be stuck for a long time in a slow crypto function (but not waiting for some condition, as usually blocking functions do). For example, a non-tuned mbedTLS example shipped with Cube gives ~2.7 seconds handshake time on STM32F756 board. A non-tuned Zephyr example on the same board gives ~4.2 seconds (also uses mbedTLS, but Zephyr's stack instead of LWIP). Mongoose on the same board gives ~0.4 seconds handshake time (Mongoose built-in TCP/IP and TLS). See this TLS explainer video for details: All these are too slow, so yeah, either an interrupt - based code would be needed, or an RTOS . Both solutions use interrupts to preempt CPU that is executing a long and expensive crypto function. |
| ulix:
Thank you to everyone for their contributions to my question. I had already looked at the W5500, but I was not familiar with Wiznet. I will be getting some modules from them. :-+ |
| tellurium:
--- Quote from: ulix on Yesterday at 03:56:06 pm ---Thank you to everyone for their contributions to my question. I had already looked at the W5500, but I was not familiar with Wiznet. I will be getting some modules from them. :-+ --- End quote --- I have used W5500 modules produced by Wiznet (so both W5500 chip and the module are by Wiznet), sourced from mouser and digikey: https://eu.mouser.com/ProductDetail/WIZnet/WIZ850io?qs=W0yvOO0ixfFLSlENQWBCKg%3D%3D They are quite pricey (even more expensive than their rpi pico devboards with integrated w5500) And also I've used Aliexpress clones of the aforementioned modules (around 4 bucks or less), e.g. https://www.aliexpress.com/item/1005006942624924.html And Wiznet's devboards with integrated W5500, both rp2040 and rp2350: https://eu.mouser.com/ProductDetail/WIZnet/W5500-EVB-Pico2?qs=iLKYxzqNS77FKgrqfXqzIQ%3D%3D https://eu.mouser.com/ProductDetail/WIZnet/W5500-EVB-PICO?qs=t7xnP681wgXCanyLhrM3cQ%3D%3D |
| peter-h:
But surely the OP is just doing something like reading remotely located electricity meters. He is not (I hope) building remotely controlled electricity substations in Ukraine ;) He could just use UDP and a very simple custom protocol. Very likely he can afford to lose some data. TCP gives you error correction and implicit flow control but if there is an actual wire break etc that won't help. TLS (X509) is a massively complicated way to get security, and in the self signed cert business (implicit in mass production) it doesn't get you much more than a simple shared key setup. But "capture via LAN" means a lot of things. If you want to use a modern browser then your customer (being an internet security expert) may "need" TLS. But you probably still can't avoid browser warnings. For now, plain HTTP works... but there are other ways to do this. If you can assemble the retrieving end, it can be much simpler. |
| Navigation |
| Message Index |
| Next page |
| Previous page |