Co to za stos?

Może napisz to autora to Ci powie. Albo poprzeglądaj źródła i porównaj z sobie znanymi.

jp

W dniu 2014-03-23 14:06, jacek pozniak pisze:

Próbowałem, ale brak odpowiedzi. W źródłach komentarze po niemiecku, a sam kod nie przypomina uIP. Wygląda więc na to, że to kolejny, autorski stos. Chciałem się jednak upewnić czy nie jest to nieoficjalna mutacja jakiegoś innego rozwiązania.

Jestem ciekaw czy ktoś testował to rozwiązanie, a jeśli tak, to jak się sprawdza w praktyce.

Odnoszę wrażenie, że szukasz rozwiazania sieciowego. Czemu po prostu nie zastosujesz uIP? Chodzi toto stabilnie i ma niewielkie ograniczenia-jest dość wygodny na małych procesorach. Albo, jeśli korzystasz z Microchipa, ichni stos (niestety którąś tam wersję musiałem sobie poprawić, głęgoko w bebechach, aby poprawnie działała).

jp

W dniu 2014-03-23 20:41, jacek pozniak pisze:

Na razie eksperymentuję z tuxgraphics. Na razie wystarcza, ale jestem coraz bardziej świadom jego ograniczeń. Mam kilka pomysłów i pewnie za jakiś czas będę potrzebował czegoś, co umożliwiłoby zainicjowanie stałego połączenia i normalne przesyłanie danych w formie streamu (coś jak telnet) a nie paczek o rozmiarze ograniczonym pojemnością jednej ramki Ethernet.

Po prostu przyglądam się poszczególnym rozwiązaniom. Pewnie uIP pójdzie na warsztat jako następny w kolejności, ale ten niemiecki stos też mnie zainteresował. Wygląda na dość rozbudowany, a jakoś o nim nie słyszałem do tej pory...

Oczywiście jest jeszcze W5100.

Z PIC-ami do tej pory nie miałem w ogóle do czynienia. Mając jako-takie pojęcie o programowaniu AVR-ów w C można w miarę bezboleśnie zapoznać się z tą rodziną mikroprocesorów, czy trzeba liczyć się z tym, że przez jakiś czas drobne różnice będą dawały o sobie znać, uniemożliwiają uruchomienie programu?

Bo jakby nie patrzeć, to procki z serii 18F z wbudowanym kontrolerem Ethernetu wyglądają całkiem interesująco i mogłyby stanowić ciekawą alternatywę dla AVR-ów z zewnętrznym scalakiem.

Pierwszy stos Microchipa miał taką właściwość. Chodzi to zadziwiająco dobrze, oczywiście uwzględniając ograniczenie do jednej ramki odpowiedzi, ale telnetu na tym nie da się postawić.

Moim zdaniem, kompilator firmy Hitech został spieprzony po wchłonięciu przez Microchipa. Jedna wersja kompiluje dobrze inna nie (niedziałający kod!).

No, ja, po różnych doświadczeniach, idę w przeciwną stronę.

jp

A co konktetnie poprawiales?

Jakby kogoś interesowało. Tylko nie wiem co to była za wersja, na pewno na picc18.

W module tcp.c, w funkcji łączenia jako klient. Nie wiem czy dobrze zrobiłem ale to wtedy pomogło, bez tego stos po minucie (chyba) nie mógł się łaczyć na serwer.

TCP_SOCKET TCPConnect(NODE_INFO *remote, TCP_PORT remotePort) { TCP_SOCKET s; SOCKET_INFO* ps; BOOL lbFound;

lbFound = FALSE; /* * Find an available socket */ for ( s = 0; s < MAX_SOCKETS; s++ ) { ps = &TCB[s]; if ( ps->smState == TCP_CLOSED ) { lbFound = TRUE; break; } } //DODANY ELEMENT: ps->TimeOut=TCP_START_TIMEOUT_VAL; ps->startTick = TickGet(); //KONIEC DODATKU /*

jp

Zapomniałeś tylko sprawdzić czy wskaźnik został ustawiony i jak ci się skończą sockety, to będziesz mazał po pamięci. Wypadałoby sprawdzić flagę lbFound.

To jakaś starsza wersja, terraz zastąpiono tą funkcję funkcją TCPOpen i kod już jest zupełnie inny. Domniemtwam, że Twój patch korygował obsługę timeout'u?

Być może, to kilka lat temu było i pewnie coś przeoczyłem. Urzadzenia chodzą więc nie ruszam i już nie ruszę do czasu wymiany urzadzeń.

jp

Tak starsza, ze starymi błędami; nowsze wersje mają pewnie nowsze błędy :-)

jp

Kiedyś nawet miałem w ręku płytkę zrobioną według tego projektu, tylko nie wiem czy akurat z oryginalnym oprogramowaniem, ale w tej był wykorzystany EtherSex.