On 28.02.2024 19:52, Mirek wrote:

> Ale mówimy tu o utracie możliwości zainicjowania połączenia przy
> jednoczesnej możliwości połączenia do urządzenia czy o całkowitym
> zablokowaniu ethernetu - bo już się pogubiłem (i możliwe że sam to
> poknociłem)?

Mówimy o całkowitym zablokowaniu Ethernetu na poziomie całego switcha.
Dioda ACT na urządzeniu zaczyna się świecić cały czas, a ono samo traci
kontakt z siecią. Jednocześnie łączność tracą wszystkie inne urządzenia,
podłączone do tego samego switcha.
Problem z zainicjowaniem połączenia klienta był osobną kwestią, o której
wspominałem przy okazji. Najwyraźniej ustąpił po wgraniu poprawek kilku
błędów, które zauważyłem w międzyczasie (najpewniej chodziło o
korzystanie z malloc/free zamiast pvPortMalloc/vPortFree).


> Dwie uwagi: Dawno nie widziałem urządzenia, które wymaga kabla cross
> (chyba że PoE)

Tak, wiem. Ale to raczej siła przyzwyczajenia. Skoro miałem pod ręką
scrossowany kabel, to postanowiłem go wykorzystać, skoro już łączyłem
urządzenia bezpośrednio.
Raczej w niczym to nie zaszkodziło, a połączenie przez tydzień działało
stabilnie.


> Te ogonki usb <> ethernet bywają tak podłe, że nie mają nawet
> transformatorków - jaja są z potencjałami.

No cóż, to było jedynie urządzenie, jakie miałem pod ręką do
wykorzystania na szybko. No i jak mówię - w tym wypadku się sprawdziło.
A w tym konkretnym przypadku transformatorek jest - widać do przez
półprzezroczystą obudowę. ;)


> tygodni i pomagał restart switcha PoE. Aż któregoś pięknego dnia po
> burzy padł rzeczony switch - wymieniamy, ale ta jedna kamera nie
> wstaje. Podmieniamy kamerę... nie wstaje. Sprawdzamy kabel... szczena
> nam opada bo jest odwrócona para. Poprawiamy, podłączamy starą
> kamerę, która działa i już się później nie zawiesza.

Też o tym pomyślałem, ale taką opcję wyeliminowałem na samym początku,
testując z kilkoma różnymi kablami i switchami. Tak więc to nie jest
kwestia niekontaktującego styku, złego kabla albo uwalonego portu w switchu.

Prawdę mówiąc stawiałem na to, że przyczyna będzie leżała na warstwie
MAC lub wyżej. Ten sam układ PHY (DP83848) wykorzystałem już w kilku
różnych projektach, z kilkoma różnymi MCU, używając identycznego układu
ścieżek na PCB (oczywiście z pominięciem linii interfejsu RMII, które są
unikalne dla konkretnego typu mikrokontrolera) i podobny problem nigdy
nie wystąpił. Stawiałem albo na jakiś bug programowy, albo problem z
kontrolerem MAC w strukturze PIC32MX795F512, albo ewentualnie jakiś
problem na liniach interfejsu RMII. Wtedy jednak awaria powinna wystąpić
też przy testach z laptopem.
Tymczasem to zaczyna wyglądać na problem na warstwie fizycznej,
ograniczony do sytuacji, kiedy po drugiej stronie kabla znajdują się
dość konkretne urządzenia...