Niestety, przelotek na RMII nie jestem w stanie uniknąć. Płytka ma tylko dwie warstwy, a kolejność wyprowadzeń na obydwu układach nie zgadza się, więc linie się krzyżują w paru miejscach.
Atlantis snipped-for-privacy@wp.pl napisał(a):
Uh, nie wiem czemu zasugerowałem się, że jest z prawej. Co do przelotek, to jeśli nie dało się inaczej, to będą musiały już tak zostać.
O, to, to. Tak powinna wyglądać analiza ryzyka ;)
Pozdrowienia, MKi
Hmm... Udało mi się złożyć i uruchomić układ wykorzystujący DP83848 na magistrali RMII. Na pierwszy ogień poszedł nieco starszy design tej płytki, wykorzystujący PIC32MX795F512L (w pisaniu kodu dla PIC-ów mam nieco większe doświadczenie niż STM32). Interfejs Ethernet znajduje się tam nieco dalej od MCU niż na płytce STM32, której obrazek wrzuciłem parę wiadomości wcześniej.
Efekty:
- Kontrolerowi Ethernet udaje się wynegocjować zestawienie połączenia
100 Mbps.- Układ działa. Klient DHCP pobiera adres, mogę spokojnie korzystać z prostego serwerka HTTP, odpalonego na urządzeniu.
- Test pingiem pokazuje, że na około 3500 wysłanych pakietów ICMP, jeden z jakiegoś powodu pozostał bez odpowiedzi.
Czy takie wyniki są akceptowalne?
Jak masz już http, to uruchom jakieś testowe transfery przez dobę. Na samym tescie ICMP (niewielki payload i obciążenie interfejsu) bym stabilności działania interfejsu nie opierał.
Nie jestem jeszcze na 100% pewnie, bo pierwszy test był odpalony relatywnie krótko, ale chyba udało mi się namierzyć przyczynę gubienia pakietów ICMP i nie była ona sprzętowa.
Kod n którym testuję urządzenie jest pożyczony z wcześniejszego projektu, w którym pracował ENC28J60. Poza testem Ethernetu, odpaliłem też testy innych peryferiów. Jeden z nich (odtwarzanie muzyki na VS1003) jest tymczasowo napisany w sposób nieoptymalny i niekiedy zatrzymuje pętlę główną nawet na kilkadziesiąt ms. Najwyraźniej przy 100 Mbps takie opóźnienie co jakiś czas powoduje czkawkę w pracy Ethernetu, podczas gdy ENC28J60 pracujący z prędkością 10 Mbps jeszcze wyrabiał.
Rozumiem, że używasz legacy drivera mchp, który działa na polling'u a nie na przerwaniach?
Tak, cały czas używam drivera i stosu TCP/IP z biblioteki MLA. Powinienem to zmienić? ;)
Zalazy co chesz. W sieci pecetowej moj standartowy test to
ping -f -l 10 -s 1200 -c 10000
Czyli: maksymalna szybkosc, 10 pakietow w locie, rozmiar 1200,
10000 pakietow w sumie. Warto tez testowac na malych pakietach, bo to mierzy jak szybko procek potrafi zareagowac na pakiet.Tak a propo: jak w sieci na koncentryku mialem straty rzedu
1 na kilka tysiecy, to TCP chodzilo bez problemu. Ale, np. nie dalo sie zbootowac komputera przez siec, bo nie bylo retransmisji a jeden zgubiony pakiet blokowal tranfer jadra i start. A przy tych statach i ilosci pakietow zgubiony pakiet byl praktycznie pewny. W sieci ze switachami przy malym ruchu nie powinno byc strat. Ten test wyzej potrafil rozlozyc kombinacje switch + hub tak ze straty byly bliskie 100%. To wyjasnilo problem z bardzo niska wydajnoscia sieci. A zmiana switcha na inny typ rozwiazala problem.Na MCU jest problem zeby soft zdarzyl zareagowac zanim bufory w interfejsie sie przepelnia. W komputerze ogolengo przeznacznie dostatecznie szybki procek i 50k na bufory powinno byc OK, ale sprzetowe bufory w STM sa znacznie mniejsze, wiec procek musi odpowiednio szybciej reagowac. Albo ograniczasz sie do malo wymagajacych zastosowan...
Czy aby na pewno to było przyczyną? TFTP posiada mechanizm zatwierdzania i powinien wykonać retransmisję. No chyba, że implementacja była skopana - ale w takim razie to nie protokół (ani sieć) była problemem.
Mateusz
Co prawda na w tej konkretnej wersji płytki zastosowałem jeszcze PIC32MX795F512L, ale to nie ma wielkiego znaczenia, bo te procki mają zasoby i wydajność zbliżone do popularnych STM-ów. Płytkę z STM32F107 też niedługo wykonam.
W każdym razie wygląd na to, że faktycznie problemem było przepełnianie się buforów pomiędzy kolejnymi wywołaniami funkcji odpowiedzialnej pobieranie pakietów i obsługę stosu. Zakomentowałem fragment odpowiedzialny za obsługę VS1003 i sytuacja się znacznie poprawiła. Czas odpowiedzi na ping to teraz nieco ponad 0.1 ms, a na 40 tysięcy wysłanych pakietów nie zgubił się ani jeden.
Będę musiał przepisać trochę kodu, żeby jego obsługa nie zajmowała tylko czasu w pojedynczym przebiegu pętli.
BTW ktoś z was eksperymentował może z DP83848 na STM32 z bibliotekami HAL? Próbuję to sobie wyklikać w STM32CubeMX, ale nigdzie nie widzę opcji wyboru konkretnego PHY. Można włączyć RMII, można dodać do projektu bibliotekę lwIP, ale nigdzie nie widzę możliwości zaznaczenia konkretnego PHY. PIC32 wymagał dodania do projektu odpowiednich plików .h oraz .c zakładam więc, że tutaj też będą potrzebne. Trzeba je wkleić ręcznie, czy też wyboru odpowiedniego układu dokonuje się jakąś makrodefinicją w kodzie?
Atlantis snipped-for-privacy@wp.pl napisał(a):
Mam projekty na DM9161. Nie trzeba było dodawać żadnych plików. Podejrzewam, że rejestry PHY (zdefiniowane w stm32f1xx_hal_conf.h) są w miarę ustandaryzowane. Ja potrzebowałem jedynie dodać definicję rejestru MDINTR, którego nie było w pliku od ST.
To bylo w 1993 roku, wtedy to dosc dokladnie badalem i raczej nie zrobilem grubego bledu. Z tego co pamietam nie bylo retransmisji na poziomie pakietow. Chyba byla retransmisja calego pliku, ale to nic nie dawalo bo kolejny transfer padal tak jak poprzedni. Wtedy zagladalem do dokumentow i OIDP to moje obserwacje zgadzaly sie opisem TFTP. ZTW to byla w miare stanartowa implementacja, innym dzialala OK. W sieci byly (ogolnie o starcie przez siec) komentarze "jak nie dziala to sprawdz czy siec nie gubi pakietow".
Pozniej w lepszej sieci glupszy protokol (testowy transfer, nie do normalnego uzycia) dzialal OK.
snipped-for-privacy@math.uni.wroc.pl snipped-for-privacy@math.uni.wroc.pl> napisał(a):
Mógłbyś już ogarnąć to kodowanie...
Nawet najstarsza wersja TFTP (ta sprzed poprawek z 1992) przewidywała mechanizm retransmisji zgubionych pakietów:
"If a packet gets lost in the network, the intended recipient will timeout and may retransmit his last packet (which may be data or an acknowledgment), thus causing the sender of the lost packet to retransmit that lost packet."
źródło:
Mi też działało OK, a testowałem m.in. na łączu na którym sam symulowałem losowe straty pakietów. Przy kilku procentach strat załadowanie kernela potrafiło trwać dobre kilka minut, za sprawą nieco długich domyślnych timeoutów (rzędu sekundy albo może dwóch). Ale działało - stąd moje zastanowienie.
Mateusz
Swoją drogą, lwIP dołączany przez biblioteki HAL posiada gotowe rozwiązania do obsługi poszczególnych usług (serwer HTTP, telnet) czy trzeba to sobie samodzielnie napisać albo ewentualnie zintegrować z projektem jakąś zewnętrzną bibliotekę?
Atlantis snipped-for-privacy@wp.pl napisał(a):
Kilka posiada, możesz sobie zajrzeć do źródeł. Telnetu nie ma bo nie ma shella.
Directory: C:\Users\Grzegorz\STM32Cube\Repository\STM32Cube_FW_F4_V1.25.2Middlewares\Third_Party\LwIP\src\apps
Mode LastWriteTime Length Name
---- ------------- ------ ---- d----- 19.12.2020 11:16 altcp_tls d----- 19.12.2020 11:16 http d----- 19.12.2020 11:16 lwiperf d----- 19.12.2020 11:16 mdns d----- 19.12.2020 11:16 mqtt d----- 19.12.2020 11:16 netbiosns d----- 19.12.2020 11:16 smtp d----- 19.12.2020 11:16 snmp d----- 19.12.2020 11:16 sntp d----- 19.12.2020 11:16 tftp
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.