ChibiOS Free Embedded RTOS

rubenswerk wrote:So I remembered Mabl's hint and I'm thinking of switching to the netconn API. After reading the lwip wiki I'm still not sure if the way I use the raw API is forbidden in an OS environment. However, I think it's worth a try to use the recommended netconn API.

That's a wonderful idea I'd bet your problems will disappear. If you are still not convinced, look at the Raw api documentation http://git.savannah.gnu.org/cgit/lwip.git/tree/doc/rawapi.txt

rubenswerk wrote:1. instead of using the raw API UDP callback function, create a new thread with an endless loop, waiting for UDP packets using netconn_recv(conn,&buf);

Correct. I think there is something like netconn_new_with callback. I've once tried to get it working with TCP for true full-dublex communication (which does not work if you use blocking, since each netconn may only be used from the same thread *argh* - I hate lwip )

rubenswerk wrote:2. the lwip_thread from the ehernet demo remains unchanged

Correct

rubenswerk wrote:3. what should be the netconn thread priority in comparison to the lwip_thread?

Hmm not sure. The netconn thread should not be able to starve the lwip_thread by sending. On the other hand, while receiving, the netconn thread should not be starved... I think I have it running at same prio - but i guess this might increase latency under high traffic?

rubenswerk wrote:4. will there be increased latency compared to a callback function? netconn_recv is a blocking function, which needs to be notified by the lwip kernel. I know it's possible to define a callback also for netconn, but I couldn't find examples for that and I think a thread is the better design choice if the performance/latency is similar.

I'd not worry about the blocking calls. But make sure you do not want to send while you block. There lie dragons here.

rubenswerk wrote:5. should the netconn setup (netconn_new, netconn_bind) be done in the main function before starting the netconn thread? Functions like netif_add are not thread safe. However, I hope that all netconn_xxx functions ARE thread safe.

Just do it in the netconn thread before the endless loop.

I posted my demo STM32F4Discovery + PHY-DP83848 on github
https://github.com/Nomados/STM32F4Disco ... mo-ChibiOS

mabl wrote:

iggarpe wrote:

You are using the lwip RAW API, which is forbidden when using LwIp with an operating system. You have to use netconn or sockets.

I think it is the other way around. The RAW API is the only one usable without an OS, because it does not require threads and synchronization stuff, but of course can be used with a OS (as I'm doing to keep the memory usage and number of threads low). However, forces you to implement everything as a state machine, which is quite cumbersome in most cases. The netconn and socket APIs are easier to use but require threads, and thus an OS.

The lwip code was written with no thread safety in mind. Later this code was encapsulated in a worker thread - aka. the "tcpip-thread". I'm convinced you will get into trouble using the RAW API. You can only use it via messages to the tcpip-thread. I'd be glad to be convinced otherwise, since I also made the error of writing a NTP client in RAW api once.

You had trouble because you did not use the raw API the proper way. The documentation states it pretty clear: all calls to the raw API must be done in the context of the tcpip thread. So yes, the raw API is non reentrant, and that is why you must always call it from the context of the tcpip thread.

(note: with the obvious exception of the functions used to set the callbacks)

The raw API is event driven. You set a callback function to be notified of events. It is the tcpip thread who calls your callback function, so you can safely use the raw API thread from THAT code. However, there is a downside: the tcpip thread is blocked until your callback returns, so you should place there only code that executes really fast.

Now, what happens if you need to use the raw API from a different thread context ?. This may happen, for example, if you need to do something that takes quite long and don't want to block the tcpip thread. The function tcpip_callback_with_block is there to let you do it. It will post a message to the tcpip thread that will make it call the passed callback function as soon as it can.

Finally, if you need to set timeouts or use the raw API at some later time, you can use sys_timeout. It will make tcpip call the passed callback function at the specified time.

Note that the maximum number of outstanding timeout callbacks is set at compile time using lwipopts.h. Make sure you allocate enough for both lwIP internals and your app.

BTW: as I was examining the code of lwIP to learn all the above, I noticed that the timeout mechanism is not very efficient. It just uses a list and walks the whole list each time to find the timeout that expires soonest. A priority heap would have been perfect for this application because the timeouts are fixed at compile time and in a static array of fixed size elements. lwIP internals use 6-9 timers so this is no big deal, but if you are writing a complex application using the raw API and need a lot of timeouts, this can become a burden.

Thanks for your explanations.
In fact, my problems remained also after switching to netconn API.
Simple cause: I use the IP address provided by a DHCP server for some 'random' calculations, and there was a bug when this IP address had a speacial value...

Hi all ,

quick qestion would be possile to use it also with STM32L discovery board or is it to weak?

Regards

Hi,

The STM32L1 does not have an Ethernet interface so no. If you need Ethernet there are a lot of ultra cheap STM32F4 boards to chose from, I would recommend the Olimex STM32-E407.

Giovanni

Hi,
I'm porting Olimex P107 config to my board and I was wondering about Port E setup in board.h. Specifically MDINT connection.


I did check the schematics to P107 and it is connected like this, but where in software it is defined/used? I couldn't find any mention of RMII_MDINT in datasheet either.
I checked lwipopts.h but didn't find anything. Any clues appreciated.

Hi,

It is not used but it is wired on the board so the definition is there.

Giovanni

Thank you for clarification

Hi everyone,

Im testing ChibiOS for the first time using an OLIMEX STM32 P107 board (rev C) and testing the LWIP demo.
So far I extracted the lwip under the ext directory and changed the BOARD_PHY_ID to MII_LAN8710A_ID.
The green LED blinks so the board is alive. The RJ54 LEDs also blink for about 1min (or less) and then the orange LED is kept ON (and green OFF).
However, I can't ping the board so I guess the HTTP is not working.

Am I missing something?
Whats the default IP address used by LWIP? I tried 127.0.0.1 and another static IP according to my local network, but it didn't work.