Niestety nie znam języka Goethego, więc nie mogę doczytać w opisie.
Ktoś może mi powiedzieć, jaki stos TCP/IP został wykorzystany w tym
projekcie?

http://www.ulrichradig.de/home/index.php/avr/webserv
er

Na pewno nie jest to minimalistyczna wersja z tuxgraphics.org. To jakaś
wariacja na temat uIP czy zupełnie inny projekt, stworzony zupełnie od
podstaw? W źródłach widać m.in. sterowniki do ENC28J60 i RTL8019, jak
również jakieś biblioteki do obsługi telnetu.

do góry

Atlantis wrote:

> Niestety nie znam języka Goethego, więc nie mogę doczytać w opisie.
> Ktoś może mi powiedzieć, jaki stos TCP/IP został wykorzystany w tym
> projekcie?
>
> http://www.ulrichradig.de/home/index.php/avr/webserv
er
>
> Na pewno nie jest to minimalistyczna wersja z tuxgraphics.org. To jakaś
> wariacja na temat uIP czy zupełnie inny projekt, stworzony zupełnie od
> podstaw? W źródłach widać m.in. sterowniki do ENC28J60 i RTL8019, jak
> również jakieś biblioteki do obsługi telnetu.

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

jp

do góry

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

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

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.

do góry

Atlantis wrote:

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 14:06, jacek pozniak pisze:
>
>> Może napisz to autora to Ci powie.
>> Albo poprzeglądaj źródła i porównaj z sobie znanymi.
>
> 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.

do góry

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

> Odnoszę wrażenie, że szukasz rozwiazania sieciowego.
> Czemu po prostu nie zastosujesz uIP?

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.


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

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.

do góry

Atlantis wrote:

> W dniu 2014-03-23 20:41, jacek pozniak pisze:
>
>> Odnoszę wrażenie, że szukasz rozwiazania sieciowego.
>> Czemu po prostu nie zastosujesz uIP?
>
> 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.
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ć.
>
> 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.
>
>
>> 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).
>
> 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?
Moim zdaniem, kompilator firmy Hitech został spieprzony po wchłonięciu przez
Microchipa. Jedna wersja kompiluje dobrze inna nie (niedziałający kod!).
>
> 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.
No, ja, po różnych doświadczeniach, idę w przeciwną stronę.


jp

do góry

On Sun, 23 Mar 2014 20:41:21 +0100, jacek pozniak
<j...@f...pl> wrote:
> 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).

A co konktetnie poprawiales?

--
Marek

do góry

Marek wrote:

> On Sun, 23 Mar 2014 20:41:21 +0100, jacek pozniak
> <j...@f...pl> wrote:
>> 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).
>
> 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

do góry

W dniu 24.03.2014 08:34, jacek pozniak pisze:
> Marek wrote:
>
>> On Sun, 23 Mar 2014 20:41:21 +0100, jacek pozniak
>> <j...@f...pl> wrote:
>>> 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).
>>
>> 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.

do góry

On Mon, 24 Mar 2014 08:34:12 +0100, jacek pozniak
<j...@f...pl> wrote:
> TCP_SOCKET TCPConnect(NODE_INFO *remote, TCP_PORT remotePort)

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?

--
Marek

do góry