Ethernet STM32F7508-DK - Page 1
Forum section: electronics / general

author: Frankk
author_rank: Newbie
timestamp: February 18, 2020, 09:05:27 pm
content: Hello everyone,I have recently acquired the STM32F7508-DK board and what a beauty it is.My plan is to use this board as the brain behind my accescontrol system.Since it has an ethernet phy built in, I want to use this with LWIP but without freertos.The goal is to have the controller send a message to my database server in order to check an uid and open the door (or not).The problem i'm facing right now is that I can succesfully setup a tcp client or server on the STM, but I'm not sure how to have the device react to commands sent through ethernet.How do I extract the payload from the package to be processed?Also the device should listen for the server but also be able to send to the server. Is this done by defining the TCP_listen callback and the TCP send, both for the same protocol control block?So for a summary:2 options:- NFC tag is read- UID sent to server- Device gets green light from server and opens door- Device receives command from server- Device reacts to command from serverHopefully someone can help me or has example code which may help me.Kind regards,Frank

author: lucazader
author_rank: Regular Contributor
timestamp: February 18, 2020, 09:30:46 pm
content: Out of curiosity:Why do you wish not to use freeRTOS? Are you using an alternate OS?

author: ttt
author_rank: Regular Contributor
timestamp: February 18, 2020, 11:35:11 pm
content: Quote from: Frankk on February 18, 2020, 09:05:27 pmHow do you want/need to talk to the device? There are many options: raw UDP, raw TCP, HTTP REST etc.Easiest way to get going would be to start to listening on a UDP port on your microcontroller. You would do that with udp_new/udp_bind/udp_recv (https://gist.github.com/iwanbk/1399729). Raw TCP works similarly through tcp_new/tcp_bind/tcp_listen/tcp_accept (https://github.com/MCUapps/lwip-gnu/blob/master/STM32F4DIS-BB/tcp_echo_server/src/tcp_echoserver.c). In both cases you need to design a custom protocol and be able to send raw packets from whoever needs to send commands to your microcontroller. For UDP it's fairly easy:https://afterthoughtsoftware.com/posts/an-easy-way-to-send-udp-packets-in-linux. I generally recommend using UDP when you can as it's much easier to handle.HTTP REST is a modern standard way to talk to devices, but another ballgame to implement with LWIP. I have done it, but it's not trivial unless you are very familiar with internet standards and can debug that stuff.

author: Frankk
author_rank: Newbie
timestamp: February 19, 2020, 08:27:12 am
content: Quote from: lucazader on February 18, 2020, 09:30:46 pmThe application won't be that complicated so I thought an OS won't be needed. Is there a good reason to have an OS running anyway?Quote from: ttt on February 18, 2020, 11:35:11 pmMy preference would be TCP since there is a form of retransmission there and ACK's and my server works on tcp/ip.Would you in my case with TCP, keep the connection open? Or go through a syn -> syn ack each time a transfer takes place?Ill look into some UDP examples for now, thanks so far!

author: lucazader
author_rank: Regular Contributor
timestamp: February 19, 2020, 06:14:33 pm
content: You are correct, maybe not.Usually i find them no less convenient than just running bare metal however, and they can supply you with some nice in built features, like well tested message queues, timers etc which i always find come in very useful.I would have also thought that most of the examples of running lwip would also use freertos, so that way you can likely stick more closely to examples, which would be less work on your end. (but in this case i may be wrong, sorry dont have huge experience with lwip)

author: ajb
author_rank: Super Contributor
timestamp: February 21, 2020, 09:05:39 pm
content: Using an RTOS with lwip has some important implications for how you interact with lwip. Certain aspects of it are not reentrant and so must be accessed exclusively by one OS thread. (Of course this also means you must be careful about interacting with the lwip stack in ISRs, but hopefully you're not doing that!)Quote from: Frankk on February 18, 2020, 09:05:27 pmGenerally you will create a 'pcb' for each network endpoint, which holds the state for that endpoint. You will also need to create a _recv function for each endpoint, and that function will be attached to the pcb when you bind to the endpoint (UDP) or accept a connection (TCP). When data comes in, the LWIP stack will hand your _recv function a pbuf containing the IP payload, from there it's up to you how to handle the encapsulated data. Remember to free the pbuf when you're done with it!QuoteThe way TCP generally works in LWIP is:- create a tcp_pcb- tcp_bind it to a local endpoint- use tcp_accept to bind your accept callback to the pcb- use tcp_listen to start waiting for a remote host to connect to the local endpoint- at some point in the process (could be in the accept callback), use tcp_recv to attach your receive callbackFrom then on, you will receive data via the callback you attach to the pcb via tcp_recv. You can send data using tcp_write. You read and write via the same pcb for a given connection.As for whether to close and reopen the connection every time, that depends a lot on the use case--in particular how much data at what intervals. If you are only sending small amounts of data periodically, then maybe UDP is better. While TCP's apparent reliability can be tempting, it's not really a universal solution and it's quite common to implement protocols using UDP with in-protocol reliability features (acks, sequence numbers, etc) that better suit certain situations.

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: February 21, 2020, 11:00:15 pm
content: Why not use a VM/computer as a bastion?