Skip to content

Stm32 on board RMII ethernet #3671

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 43 commits into from

Conversation

forester3
Copy link
Contributor

@forester3 forester3 commented Mar 16, 2018

I added several definitions in boards/STM32F7DISC to work on board RMII ethernet.
And I tested script in wiznet_connect.py, too.

This PR is related to #3379 PR.

dpgeorge and others added 30 commits October 20, 2017 18:01
It works!  And provides a full socket implementation.

But some performance is lost: with a lot of memory allocated to lwIP it
gives Around 750,000 bytes/sec max TCP download, compared with 1M/sec
when using the TCP/IP stack on the Wiznet module.

TODO:
- probably put lwip polling in systick via a pending scheduled event
- could update wiznet driver since it fixes the -2 bug and buf size masks
  that are patched here
- update lwip to v2
libaxtls requires the build directory to exist, and lwip's dhcp.c can give
warnings on certain gcc versions.
Instead of including sys/types.h which leads to problems with the cc3000
driver.
Dramatically improves TCP sending throughput because without an explicit
call to tcp_output() the data is only sent to the lower layers via the
lwIP slow timer which (by default) ticks every 500ms.
…ects/STM32F767ZI-Nucleo/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS/Src)
ethernetif.c --- low level driver mainly derived from STM example code
network_ethernet.c --- MicroPython module code
Makefile and mpconfigport.mk are modified to build these files
modnetwork.c added ethernet
@dpgeorge
Copy link
Member

Thanks @forester3 for submitting this. I took this PR and rebased it on top current master code, cleaned it up, and made it work with the new lwIP 2.0 version. See #3808.

@boochow are you aware of this PR?

@dpgeorge
Copy link
Member

Do Rx_Buff and Tx_Buff need to be located in a special spot in RAM using the linker script? From what I can see they still have caching enabled so probably they don't need special handling (only DMARxDscrTab and DMATxDscrTab are special here). It would be simpler to define Rx_Buff and Tx_Buff as normal, static, global arrays.

@forester3
Copy link
Contributor Author

forester3 commented May 22, 2018 via email

@boochow
Copy link
Contributor

boochow commented May 22, 2018

@dpgeorge I borrowed this code from ST's example project "LwIP_HTTP_Server_Netconn_RTOS" (bundled with STM32CubeMX). I did so because ethernetif.c generated by STM32CubeMX(FW_F7_V1.8.0) did not work. I agree with you that these buffers could be defined as static global arrays but I couldn't get it worked. Actually, I don't know why Rx_Buff and Tx_Buff have to be placed at the fixed address.

@forester3 I am very sorry I have missed your comments on my blog. I'll answer your questions later.

@dpgeorge
Copy link
Member

@boochow thanks for your original work getting this going.

I borrowed this code from ST's example project "LwIP_HTTP_Server_Netconn_RTOS" (bundled with STM32CubeMX).

Ok. The license for this looks compatible with what we already have, for what we already use from the ST libraries, so that's good, we can use it.

I agree with you that these buffers could be defined as static global arrays but I couldn't get it worked.

I will try to make it work because it will be cleaner with them static globals.

@dpgeorge
Copy link
Member

This was superseded by #4541 (which was merged).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants