On 28.12.2020 11:59, Grzegorz Niemirowski wrote:

> Natomiast powinno się unikać przelotek

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.

do góry

Atlantis <m...@w...pl> napisał(a):
> C48 jest podłączony do układu VS1003 (DAC/dekoder MP3) a przelotka po jego
> prawej stronie znajduje się na interfejsie SPI, któremu to nie powinno
> przeszkadzać. DP83848 znajduje się po lewej stronie płytki.

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

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

W dniu 2020-12-28 o 10:17, Atlantis pisze:
> On 28.12.2020 10:03, MKi wrote:
>
>> Musisz zrobić - uwaga modne słowa - analizę ryzyka. Jeśli wyjdzie Ci,
>> że prawdopodobieństwo zbyt dużego obciążenia przez device czy
>> dotkliwość takiej awarii są dostatecznie małe (albo szansa na
>> wykrycie odpowiednio wcześnie takiej sytuacji jest duża)
>> - to nie instaluj ogranicznika.
>>
>> Ja nie znam żadnych powodów oprócz tego, o którym pisałem wcześniej.
>
> Czyli wychodzi na to, że faktycznie raczej nie muszę instalować
> ogranicznika. Pendrive pobiera prąd mieszczący się w granicach
> wydajności układu zasilania, a ryzyko podłączenia czegoś innego przez
> użytkownika jest znikome, bo:
> 1) Port USB będzie zamknięty wewnątrz obudowy.
> 2) Tym użytkownikiem będę ja. ;)
>
> A w najgorszym razie po prostu przepali się bezpiecznik na wejściu.
> Rozumiem, że ogranicznik służy temu, żeby można było obsłużyć przypadek
> nadmiernego poboru prądu z USB bez przerywania pracy urządzenia? W moim
> przypadku jest to tak naprawdę zbędne. :)

O, to, to.
Tak powinna wyglądać analiza ryzyka ;)

Pozdrowienia,
MKi

do góry

On 28.12.2020 21:30, Grzegorz Niemirowski wrote:

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

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?

do góry

On Tue, 12 Jan 2021 08:45:53 +0100, Atlantis <m...@w...pl>
wrote:
> - 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ł.

--
Marek

do góry

On 12.01.2021 13:51, Marek wrote:

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

do góry

On Tue, 12 Jan 2021 17:55:13 +0100, Atlantis <m...@w...pl>
wrote:
> 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?

--
Marek

do góry

On 12.01.2021 20:16, Marek wrote:

> 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ć? ;)

do góry

Atlantis <m...@w...pl> wrote:
> On 28.12.2020 21:30, Grzegorz Niemirowski wrote:
>
> > 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?.
>
> 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?

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

--
Waldek Hebisch

do góry

2021-01-13 o 00:03 +0000, a...@m...uni.wroc.pl napisał:
> 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.

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

do góry