On 13.01.2021 01:03, a...@m...uni.wroc.pl wrote:

> 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...

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?