Jakiś czas temu złożyłem sobie projekt radia internetowego/odtwarzacza
MP3 z wykorzystaniem mikrokontrolera PIC32MX795F512L i układu Ethernet
PHY DP83848. Firmware napisałem przy użyciu starych bibliotek MLA.
Wszystko działało całkiem sprawnie.
Później powstała nowsza wersja hardware'u, wykorzystująca znacznie
mocniejszy PIC32MZ2048EFM100 i bibliotekę Harmony. Sprawdzała się ona
znacznie lepiej - chociażby z uwagi na domyślne wykorzystanie RTOS-a.

Ostatnio postanowiłem backportować nową wersję softu pod stary hardware.
Z czystej ciekawości chciałem się przekonać jak dobrze starszy MCU
będzie sobie radził z nowymi bibliotekami. Gdyby eksperyment się udał,
to potencjalnie mógłbym wykorzystać w przyszłych projektach tych kilka
scalaków leżących w szufladzie. ;)

Oczywiście głównym problemem były mniejsze zasoby sprzętowe. O ile
PIC32MZ2048EFM100 miał 2MB flasha i 512kB RAMu, to PIC32MX795F512L ma
odpowiednio tylko 512kB i 128kB. Program się zmieścił, zajmując jakieś
75% flasha. Zmniejszając rozmiar kilku statycznych buforów, manipulując
rozmiarem sterty i rozmaitymi ustawieniami w konfiguracji udało mi się
także (chyba) upchnąć wszystko w RAM-ie.

Pierwsze wrażenie były jak najbardziej pozytywne. Oprogramowanie
działało na starym sprzęcie zaskakująco dobrze. Powiedziałbym nawet, że
lepiej niż na starych bibliotekach, co zapewne jest zasługą RTOS-a
(różne procesy wykonują się równolegle i np. stos TCP/IP nie łapie
przestoju, gdy inny proces utyka w jakiejś dłuższej pętli).

Dzisiaj jednak kilkukrotnie zaobserwowałem dziwną awarię: komunikacja po
sieci wykrzaczyła się zupełnie. Płytka przestała odpowiadać na pingi,
nie mogłem się dostać do webUI, również kod kliencki na MCU przestał
otrzymywać dane z internetu. W momencie wystąpienia awarii dioda ACT na
gniazdku Ethernetowym zaczęła się świecić cały czas. Co więcej - parę
razy awaria spowodowała wykrzaczenie się komunikacji po Ethernecie na
wszystkich urządzeniach podpiętych do tego samego routera!
Nie był to jednak całkowity zawias - ciągle mogłem wydawać polecenia w
konsoli UART i otrzymywałem sensowne odpowiedzi.

Raczej nie jest to wina sprzętu, bo na starym sofcie (biblioteki MLA)
płytka była testowana miesiącami i zawsze działała stabilnie. Taki
problem nigdy nie wystąpił. Odnoszę też wrażenie, że prawdopodobieństwo
wystąpienia awarii jest silne skorelowane z ilością przesyłanych danych
- problem występował zawsze podczas odtwarzania streamu audio z sieci
(radio internetowe po HTTP). Chociaż ta hipoteza musi jeszcze zostać
przetestowana, to na razie urządzenie działa odtwarzając lokalne pliki i
problem jeszcze nie wystąpił.

Ktoś ma jakąś hipotezę? Gdzie szukać potencjalnej przyczyny?

do góry

On Sun, 9 Apr 2023 19:29:27 +0200, Atlantis wrote:
> Jakiś czas temu złożyłem sobie projekt radia internetowego/odtwarzacza
> MP3 z wykorzystaniem mikrokontrolera PIC32MX795F512L i układu Ethernet
> PHY DP83848. Firmware napisałem przy użyciu starych bibliotek MLA.
> Wszystko działało całkiem sprawnie.
> Później powstała nowsza wersja hardware'u, wykorzystująca znacznie
> mocniejszy PIC32MZ2048EFM100 i bibliotekę Harmony. Sprawdzała się ona
> znacznie lepiej - chociażby z uwagi na domyślne wykorzystanie RTOS-a.
>
> Ostatnio postanowiłem backportować nową wersję softu pod stary hardware.
> Z czystej ciekawości chciałem się przekonać jak dobrze starszy MCU
> będzie sobie radził z nowymi bibliotekami. Gdyby eksperyment się udał,
> to potencjalnie mógłbym wykorzystać w przyszłych projektach tych kilka
> scalaków leżących w szufladzie. ;)
>
> Oczywiście głównym problemem były mniejsze zasoby sprzętowe. O ile
> PIC32MZ2048EFM100 miał 2MB flasha i 512kB RAMu, to PIC32MX795F512L ma
> odpowiednio tylko 512kB i 128kB. Program się zmieścił, zajmując jakieś
> 75% flasha. Zmniejszając rozmiar kilku statycznych buforów, manipulując
> rozmiarem sterty i rozmaitymi ustawieniami w konfiguracji udało mi się
> także (chyba) upchnąć wszystko w RAM-ie.
>
> Pierwsze wrażenie były jak najbardziej pozytywne. Oprogramowanie
> działało na starym sprzęcie zaskakująco dobrze. Powiedziałbym nawet, że
> lepiej niż na starych bibliotekach, co zapewne jest zasługą RTOS-a
> (różne procesy wykonują się równolegle i np. stos TCP/IP nie łapie
> przestoju, gdy inny proces utyka w jakiejś dłuższej pętli).
>
> Dzisiaj jednak kilkukrotnie zaobserwowałem dziwną awarię: komunikacja po
> sieci wykrzaczyła się zupełnie. Płytka przestała odpowiadać na pingi,
> nie mogłem się dostać do webUI, również kod kliencki na MCU przestał
> otrzymywać dane z internetu. W momencie wystąpienia awarii dioda ACT na
> gniazdku Ethernetowym zaczęła się świecić cały czas. Co więcej - parę
> razy awaria spowodowała wykrzaczenie się komunikacji po Ethernecie na
> wszystkich urządzeniach podpiętych do tego samego routera!

> Nie był to jednak całkowity zawias - ciągle mogłem wydawać polecenia w
> konsoli UART i otrzymywałem sensowne odpowiedzi.
>
> Raczej nie jest to wina sprzętu, bo na starym sofcie (biblioteki MLA)
> płytka była testowana miesiącami i zawsze działała stabilnie. Taki
> problem nigdy nie wystąpił. Odnoszę też wrażenie, że prawdopodobieństwo
> wystąpienia awarii jest silne skorelowane z ilością przesyłanych danych
> - problem występował zawsze podczas odtwarzania streamu audio z sieci
> (radio internetowe po HTTP).

Pomysl pierwszy - brak pamieci. Mozesz tam jakąs czujke dodac, która
diode zapali czy na konsole napisze, jak zacznie brakowac?

Tylko tak mysle o tym blokowaniu ethernetu ... co by moglo tak zrobic?
Radyjko w petle wpadlo i wysyla pakiety za szybko?
Czy spowodowało ze za duzo danych zaczelo napływać?
A moze jakies felerne pakiety?

Wszystko to moze byc skutkiem braku pamieci ... ale może nowy software
nie jest calkiem kompatybilny ze starym hardwarem od Ethernetu?

A moze jakies erraty do pica cos wyjasnią?

J.

do góry

niedziela, 9 kwietnia 2023 o 19:29:31 UTC+2 Atlantis napisał(a):
> Jakiś czas temu złożyłem sobie projekt radia internetowego/odtwarzacza
> MP3 z wykorzystaniem mikrokontrolera PIC32MX795F512L i układu Ethernet
> PHY DP83848. Firmware napisałem przy użyciu starych bibliotek MLA.
> Wszystko działało całkiem sprawnie.
> Później powstała nowsza wersja hardware'u, wykorzystująca znacznie
> mocniejszy PIC32MZ2048EFM100 i bibliotekę Harmony. Sprawdzała się ona
> znacznie lepiej - chociażby z uwagi na domyślne wykorzystanie RTOS-a.
>
> Ostatnio postanowiłem backportować nową wersję softu pod stary hardware.
> Z czystej ciekawości chciałem się przekonać jak dobrze starszy MCU
> będzie sobie radził z nowymi bibliotekami. Gdyby eksperyment się udał,
> to potencjalnie mógłbym wykorzystać w przyszłych projektach tych kilka
> scalaków leżących w szufladzie. ;)
>
> Oczywiście głównym problemem były mniejsze zasoby sprzętowe. O ile
> PIC32MZ2048EFM100 miał 2MB flasha i 512kB RAMu, to PIC32MX795F512L ma
> odpowiednio tylko 512kB i 128kB. Program się zmieścił, zajmując jakieś
> 75% flasha. Zmniejszając rozmiar kilku statycznych buforów, manipulując
> rozmiarem sterty i rozmaitymi ustawieniami w konfiguracji udało mi się
> także (chyba) upchnąć wszystko w RAM-ie.
>
> Pierwsze wrażenie były jak najbardziej pozytywne. Oprogramowanie
> działało na starym sprzęcie zaskakująco dobrze. Powiedziałbym nawet, że
> lepiej niż na starych bibliotekach, co zapewne jest zasługą RTOS-a
> (różne procesy wykonują się równolegle i np. stos TCP/IP nie łapie
> przestoju, gdy inny proces utyka w jakiejś dłuższej pętli).
>
> Dzisiaj jednak kilkukrotnie zaobserwowałem dziwną awarię: komunikacja po
> sieci wykrzaczyła się zupełnie. Płytka przestała odpowiadać na pingi,
> nie mogłem się dostać do webUI, również kod kliencki na MCU przestał
> otrzymywać dane z internetu. W momencie wystąpienia awarii dioda ACT na
> gniazdku Ethernetowym zaczęła się świecić cały czas. Co więcej - parę
> razy awaria spowodowała wykrzaczenie się komunikacji po Ethernecie na
> wszystkich urządzeniach podpiętych do tego samego routera!
> Nie był to jednak całkowity zawias - ciągle mogłem wydawać polecenia w
> konsoli UART i otrzymywałem sensowne odpowiedzi.
>
> Raczej nie jest to wina sprzętu, bo na starym sofcie (biblioteki MLA)
> płytka była testowana miesiącami i zawsze działała stabilnie. Taki
> problem nigdy nie wystąpił. Odnoszę też wrażenie, że prawdopodobieństwo
> wystąpienia awarii jest silne skorelowane z ilością przesyłanych danych
> - problem występował zawsze podczas odtwarzania streamu audio z sieci
> (radio internetowe po HTTP). Chociaż ta hipoteza musi jeszcze zostać
> przetestowana, to na razie urządzenie działa odtwarzając lokalne pliki i
> problem jeszcze nie wystąpił.
>
> Ktoś ma jakąś hipotezę? Gdzie szukać potencjalnej przyczyny?
Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje jakieś dźwięki poza
tym że ciągle w nim coś nie działa. Czy czasami ono nie jest z tej samej serii co
traktor co ma trzy koła dobre?

do góry

On 10.04.2023 00:11, Zenek Kapelinder wrote:

> Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
> jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
> ono nie jest z tej samej serii co traktor co ma trzy koła dobre?

Oczywiście, że wydaje dźwięki. Skąd pomysł, że mogłoby być inaczej?
Stream audio odbierany przez HTTP (albo odczytywany z pliku) jest
kierowany do bufora cyklicznego, skąd trafia do dekodera VS1003 i na
głośniki. :)

do góry

poniedziałek, 10 kwietnia 2023 o 09:35:57 UTC+2 Atlantis napisał(a):
> On 10.04.2023 00:11, Zenek Kapelinder wrote:
>
> > Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
> > jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
> > ono nie jest z tej samej serii co traktor co ma trzy koła dobre?
> Oczywiście, że wydaje dźwięki. Skąd pomysł, że mogłoby być inaczej?
> Stream audio odbierany przez HTTP (albo odczytywany z pliku) jest
> kierowany do bufora cyklicznego, skąd trafia do dekodera VS1003 i na
> głośniki. :)
Jak działa to czy po tym jak roztrajbujesz ferszluz żeby droselklapa mniej o może
wcale nie ryksztosowala będą w nim lepsze dla ciebie wiadomości? Albo muzyka
symfoniczna przesyłana do głośników kablami że zwykłej miedzi będzie brzmiała jak by
była przesyłana kablami z miedzi wytapianiej na międzynarodowej stacji kosmicznej?

do góry

On 9.04.2023 20:09, J.F wrote:

> Pomysl pierwszy - brak pamieci. Mozesz tam jakąs czujke dodac, która
> diode zapali czy na konsole napisze, jak zacznie brakowac?

Wygląda na to, że namierzyłem przyczynę. Jeszcze nie na 100%, bo będę
musiał przeprowadzić dłuższe testy, jednak jak na razie urządzenie
działa od kilku godzin i problem nie wystąpił.

Po pierwsze potwierdziłem, że problem pojawiał się podczas odtwarzania
streamów z sieci. Prada w trybie "idle" albo odtwarzanie audio z
lokalnego nośnika nie powodowało jego wystąpienia.
Przyjrzałem się więc różnicom pomiędzy oryginalną wersją softu (z
PIC32MZ2048) a tą zmodyfikowaną pod PIC32MX795F512L. Jedną różnic było
ograniczenie rozmiaru bufora odbiorczego w gnieździe sieciowym z 4096 do
2048 bajtów. Po przywróceniu poprzedniego rozmiaru problem przestał
występować, a przynajmniej nie pojawił się w ciągu kilku godzin testów.

Jest to o tyle dziwne, że wartość domyślna wynosi 512 bajtów, jednak
przy niej stos nie radzi sobie z odbieraniem streamu audio w czasie
rzeczywistym i słychać wyraźne przycięcia.
Nie mam jednak pojęcia w jaki sposób za mały bufor może powodować taką
awarię - wykrzaczenie się całego stosu i zakłócenie działania innych
urządzeń na okolicznym Ethernecie.

do góry

On Mon, 10 Apr 2023 11:11:50 +0200, Atlantis wrote:
> On 9.04.2023 20:09, J.F wrote:
>> Pomysl pierwszy - brak pamieci. Mozesz tam jakąs czujke dodac, która
>> diode zapali czy na konsole napisze, jak zacznie brakowac?
>
> Wygląda na to, że namierzyłem przyczynę. Jeszcze nie na 100%, bo będę
> musiał przeprowadzić dłuższe testy, jednak jak na razie urządzenie
> działa od kilku godzin i problem nie wystąpił.
>
> Po pierwsze potwierdziłem, że problem pojawiał się podczas odtwarzania
> streamów z sieci. Prada w trybie "idle" albo odtwarzanie audio z
> lokalnego nośnika nie powodowało jego wystąpienia.
> Przyjrzałem się więc różnicom pomiędzy oryginalną wersją softu (z
> PIC32MZ2048) a tą zmodyfikowaną pod PIC32MX795F512L. Jedną różnic było
> ograniczenie rozmiaru bufora odbiorczego w gnieździe sieciowym z 4096 do
> 2048 bajtów. Po przywróceniu poprzedniego rozmiaru problem przestał
> występować, a przynajmniej nie pojawił się w ciągu kilku godzin testów.
>
> Jest to o tyle dziwne, że wartość domyślna wynosi 512 bajtów, jednak
> przy niej stos nie radzi sobie z odbieraniem streamu audio w czasie
> rzeczywistym i słychać wyraźne przycięcia.


A wiesz jak duze pakiety przychodzą?
Ethernet ma limit do 1.5kB, no ale nie musi byc wykorzystany w
calosci.

> Nie mam jednak pojęcia w jaki sposób za mały bufor może powodować taką
> awarię - wykrzaczenie się całego stosu i zakłócenie działania innych
> urządzeń na okolicznym Ethernecie.

Stos TCP/IP to łatwo podejrzewac - cos sie nie zmiescilo, cos
przepełniło, i różnie moze sie skonczyc. Aczkolwiek powinien byc przed
tym zabezpieczony. Trzeba by przesledzic wszystkie biblioteki,
co tam sie dzieje przy 2KB bufora.

Ale zakłócenie calej sieci jest bardzo ciekawe.

To jest bufor kołowy?
Bo moze przy 2kB jest przepelniany i zajezdza cos innego,
a przy 4KB nigdy nie był pelny ...
Ale przy kołowym nie powinno miec to znaczenia.

To ta?
https://github.com/Microchip-MPLAB-Harmony/net/blob/
master/release_notes.md

The following table provides the list of bug fixes in the 3.8.0
release:
SMTPC Increased the default socket buffer size to 2 KB

Cos tam sie działo złego przy małym buforze, ale 2KB powinny byc OK.


J.

do góry

On Mon, 10 Apr 2023 01:49:27 -0700 (PDT), Zenek Kapelinder wrote:
> poniedziałek, 10 kwietnia 2023 o 09:35:57 UTC+2 Atlantis napisał(a):
>> On 10.04.2023 00:11, Zenek Kapelinder wrote:
>>
>>> Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
>>> jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
>>> ono nie jest z tej samej serii co traktor co ma trzy koła dobre?
>> Oczywiście, że wydaje dźwięki. Skąd pomysł, że mogłoby być inaczej?
>> Stream audio odbierany przez HTTP (albo odczytywany z pliku) jest
>> kierowany do bufora cyklicznego, skąd trafia do dekodera VS1003 i na
>> głośniki. :)
> Jak działa to czy po tym jak roztrajbujesz ferszluz żeby droselklapa mniej o może
wcale nie ryksztosowala będą w nim lepsze dla ciebie wiadomości? Albo muzyka
symfoniczna przesyłana do głośników kablami że zwykłej miedzi będzie brzmiała jak by
była przesyłana kablami z miedzi wytapianiej na międzynarodowej stacji kosmicznej?

Chcial miec chłop wlasny "odbiornik internetowy", to ma, nie jest juz
skazany na sklepowe ... ktore nie wiadomo kiedy przestana dzialac.

J.

do góry

poniedziałek, 10 kwietnia 2023 o 11:42:04 UTC+2 J.F napisał(a):
> On Mon, 10 Apr 2023 01:49:27 -0700 (PDT), Zenek Kapelinder wrote:
> > poniedziałek, 10 kwietnia 2023 o 09:35:57 UTC+2 Atlantis napisał(a):
> >> On 10.04.2023 00:11, Zenek Kapelinder wrote:
> >>
> >>> Po co ci takie coś co nazwales radiem a nie napisałeś czy wydaje
> >>> jakieś dźwięki poza tym że ciągle w nim coś nie działa. Czy czasami
> >>> ono nie jest z tej samej serii co traktor co ma trzy koła dobre?
> >> Oczywiście, że wydaje dźwięki. Skąd pomysł, że mogłoby być inaczej?
> >> Stream audio odbierany przez HTTP (albo odczytywany z pliku) jest
> >> kierowany do bufora cyklicznego, skąd trafia do dekodera VS1003 i na
> >> głośniki. :)
> > Jak działa to czy po tym jak roztrajbujesz ferszluz żeby droselklapa mniej o może
wcale nie ryksztosowala będą w nim lepsze dla ciebie wiadomości? Albo muzyka
symfoniczna przesyłana do głośników kablami że zwykłej miedzi będzie brzmiała jak by
była przesyłana kablami z miedzi wytapianiej na międzynarodowej stacji kosmicznej?
> Chcial miec chłop wlasny "odbiornik internetowy", to ma, nie jest juz
> skazany na sklepowe ... ktore nie wiadomo kiedy przestana dzialac.
>
> J.
Jak do mnie piszesz to przedtem jakieś tabletki na dysleksję bierzesz? Wiesz że z
tobą nie gadam to po chuj się wpierdalasz? Uznaj że miły byłem.

do góry