Skip to content
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

Verilog Ethernet Integration Steps #36

Closed
mkdigitals opened this issue May 4, 2023 · 2 comments
Closed

Verilog Ethernet Integration Steps #36

mkdigitals opened this issue May 4, 2023 · 2 comments

Comments

@mkdigitals
Copy link

mkdigitals commented May 4, 2023

The road-map from now on is (the order might change between some steps, since not all of them are depended to each other):
- Add LWIP to the current cli-test, with necessary functions filled with dummy functionalities.
- err_t vif_init(struct netif *netif)
- err_t vif_link_output(struct netif *netif, struct pbuf *p)
- err_t vif_output(struct netif *netif, struct pbuf *p, ip_addr_t *ipaddr)
- err_t vif_input(struct netif *netif)
- Add test options to current cli-test interface to manipulate the Lwip initialization settings, and trigger some test stimulus.
- Tie the output and input functions to the MAC (This might require some modifications on MAC)
- Test and debug the system using the current built-in loop-back in the MAC.
- Reroute the i2c interface to the PHY - test first using the current i2c functionality.
- Tie the init function to PHY control.
- Test the network on PHY loop-back. (I assume PHY has loop-back functionality).
- Test the network on Hardware tied to a PC. The tests beyond this point are to be evaluated.

@mkdigitals
Copy link
Author

last push : https://github.com/planvtech/robo-v-mcu-demo PROJ-11
TCP-IP was a bit too heavy for the system, I kept hitting memory overflow issues during compile time even though I reduced the functionalities. So I decided to change to UDP. LWIP is now calling the functions which are meant to be tied to the mac. Had to do a very small change in udma_uart_driver.c : Any printf operation was causing a stack overflow when called before the task scheduler; realized it is because of a semophore being taken for a short duration in putchar(), but during the semaphore being taken, putchar() is being called again and this was causing a runtime error during the LWIP initialization stage, so I made a change to release the semaphore after accessing to uart peripheral.

@vmayoral
Copy link
Member

vmayoral commented Jan 6, 2024

Closing in here for now. Follows from #39.

Thanks a lot for the effort @mkdigitals.

@vmayoral vmayoral closed this as completed Jan 6, 2024
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

No branches or pull requests

2 participants