nie znam tych bibliotek, ale na przykład w stmie to wyraźnie są
dołączane jakieś bzdety stdlib... może zdublowałeś jakieś pliki?

do góry

Atlantis wrote:

> Bo całe mnóstwo ludzi używa jej w takiej samej konfiguracji sprzętowej?

Kompilator na pewno mają wadliwy, więc czemu ne bibliotekę? :-)

A do rzeczy, to sprawdziłeś błędy trywialne? Ja ostatnio
spędziłem kilka godzin z analizatorem szukając błędów
w transmisji I2C, bo najprostszy przecież PCF8574
w przedziwny sposób czasem działał, a czasem nie,
a okazało się, że nie podłączyłem mu VDD i był
zasilany pasożytniczo. :-/

Pozdrawiam, Piotr

do góry

W dniu 2016-06-13 o 13:26, Piotr Wyderski pisze:

> A do rzeczy, to sprawdziłeś błędy trywialne? Ja ostatnio
> spędziłem kilka godzin z analizatorem szukając błędów
> w transmisji I2C, bo najprostszy przecież PCF8574
> w przedziwny sposób czasem działał, a czasem nie,
> a okazało się, że nie podłączyłem mu VDD i był
> zasilany pasożytniczo. :-/

Akurat od strony sprzętowej to sprawdziłem go na wszystkie możliwe
sposoby. Łącznie z demontażem i ponownym upewnieniem się, czy na pewno
pod żadnym układem nie przeoczyłem jakiegoś zwarcia/niedotrawienia.
Wymieniłem też wszystkie elementy poza kilkoma kondensatorami
odsprzęgającymi. Dopiero podłączenie zewnętrznego modułu z ENC28J60
utwierdziło mnie w przekonaniu, że problem NIE jest sprzętowy.

Jak już pisałem w innym miejscu - okazuje się, że biblioteka od TCP/IP
gryzie się z biblioteką USB MSD. Wystarczy, że usunę z pętli głównej
wywołanie funkcji USBTask(), a płytka pojawia się w sieci. Jest to o
tyle dziwne, że z tego co mi wiadomo ludzie korzystają z tych bibliotek
jednocześnie...

do góry

>
> Jak już pisałem w innym miejscu - okazuje się, że biblioteka od TCP/IP
> gryzie się z biblioteką USB MSD. Wystarczy, że usunę z pętli głównej
> wywołanie funkcji USBTask(), a płytka pojawia się w sieci. Jest to o
> tyle dziwne, że z tego co mi wiadomo ludzie korzystają z tych bibliotek
> jednocześnie...
Spróbuj zostawić USBTask() ale tak aby nigdy nie była wołana; np. uzależnić
wywołanie od jakiejś zmiennej volatile.
Jeśli nie będzie układ działał to może być jakiś problem linkera.

jp

do góry

W dniu 2016-06-13 o 17:27, jacek pozniak pisze:

> Spróbuj zostawić USBTask() ale tak aby nigdy nie była wołana; np. uzależnić
> wywołanie od jakiejś zmiennej volatile.
> Jeśli nie będzie układ działał to może być jakiś problem linkera.

main {

volatile uint8_t test = 0;
//Sporo innych instrukcji

while {
if (test) USBTasks();
//Sporo innych instrukcji
//Miedzy innymi funkcje obsolugi stosu TCP/IP
}
}

Tak wyglądający program działa prawidłowo.
Wystarczy jednak, że zmienna test zostanie zdefiniowana z wartością 1, a
program się wykrzacza. Tak więc winę musi ponosić coś, co się dzieje
wewnątrz tej funkcji.

do góry

>
> while {
> if (test) USBTasks();
> //Sporo innych instrukcji
> //Miedzy innymi funkcje obsolugi stosu TCP/IP
> }
> }
>
> Tak wyglądający program działa prawidłowo.
> Wystarczy jednak, że zmienna test zostanie zdefiniowana z wartością 1, a
> program się wykrzacza. Tak więc winę musi ponosić coś, co się dzieje
> wewnątrz tej funkcji.

1. Optymalizator 'za bardzo' zoptymalizował RAM -spróbuj z innymi
ustawieniami.
2. Ten USBTask wali gdzieś po pamięci (błąd biblioteki)
3. Albo linker przydzielił te same obszary RAM, to można podglądać w plikach
co je linker generuje.

Spróbowałbym pierwszej opcji, na początek
jp

do góry

W dniu 2016-06-12 o 18:01, Atlantis pisze:
> W dniu 2016-06-12 o 16:37, platformowe głupki pisze:
>
>> a jakby tak podpiąć gotowy modulik z ENC pod SPI? będzie wiadomo, czy
>> wina softu czy może układu...
>
> Wczoraj też mi to przyszło do głowy i w ten sposób udało mi się ustalić,
> że problem nie jest sprzętowy.
> Z pomocą jednego z kolegów z grupy (jeszcze raz dziękuję) udało mi się
> ustalić, że biblioteka do obsługi Ethernetu najwyraźniej gryzie się z
> biblioteką do USB MSD. Dlaczego? Jeszcze nie mam pojęcia...
>
Może Ci ramu brakuje? albo się pokrywają bo któraś bibloteka ma błąd.

--
Pozdr

Janusz_K

do góry

W dniu 2016-06-14 o 22:56, janusz_k pisze:

> Może Ci ramu brakuje? albo się pokrywają bo któraś bibloteka ma błąd.

Problem okazał się dużo bardziej kuriozalny. Użyty port SPI oraz USB
współdzielą pewien pin, który może pełnić funkcję linii USBID. Ponieważ
nie korzystam z funkcjonalności USB OTG, miałem tę funkcję wyłączoną. To
znaczy wydawało mi się, że miałem.

W kodzie znalazła się jedna, mała pomyłka. Zamiast "#pragma config
FUSBIDIO = OFF" napisałem po prostu "#pragma FUSBIDOO = OFF". O dziwo
taka konstrukcja została przyjęta, nie został nawet wygenerowany żaden
warning, po prostu fusebit pozostawał w domyślnie ustawionym stanie.
W efekcie dochodziło do zakłócenia komunikacji, bo obydwa interfejsy
próbowały korzystać z tej samej linii.

do góry

On Thu, 16 Jun 2016 11:01:09 +0200, Atlantis <m...@w...pl>
wrote:
> taka konstrukcja została przyjęta, nie został nawet wygenerowany
żaden
> warning, po prostu fusebit pozostawał w domyślnie ustawionym stanie.

No hmm u mnie warning był, ustaw sobie odpowiedni poziom warningów. A
może nie szukasz warningów tam gdzie trzeba w Twoim narzędziu.

--
Marek

do góry

no to skoro już problem z głowy to czy możemy liczyć na wyliczenie
pliczków dokumentacji do USB w PICach i ethernetu w PICach?

do góry