Stosowałem już ten stos w swoich projektach na ENC28J60, ale do tej pory
raczej powierzchownie - zarówno sprzętowo jak i programowo opierając się
na opublikowanych przykładach.

Teraz jednak przyjrzałem się dokładniej i jedna rzecz nie daje mi
spokoju. Nie mogę znaleźć w kodzie procedury odpowiedzialnej za obsługę
przerwania sprzętowego od ENC28J60. Co więcej - różne przykłady
wykorzystują różne przerwania. Np. książka M. Kardasia "Pasja
programowania mikrokontrolerów" zawiera przykład, w którym wykorzystano
INT1. W przykładach tuxgraphics.org jest INT0. Nigdzie w opisie nie ma
mowy o tym, że trzeba dostosować kod.

Czyżby przykładowe płytki miały wykonaną ścieżkę tylko z myślą o
możliwym wykorzystaniu tej funkcji w przyszłości? Projektując własne
urządzenie mogę poprowadzić ścieżkę do dowolnego INT-a MCU (albo nawet
zupełnie z niej zrezygnować)? Czy też coś mi umknęło i faktycznie ten
sygnał jest gdzieś wykorzystywany?

do góry

On Mon, 24 Feb 2014 08:53:51 +0100, Atlantis <m...@w...pl>
wrote:
> Czyżby przykładowe płytki miały wykonaną ścieżkę tylko z myślą o
> możliwym wykorzystaniu tej funkcji w przyszłości? Projektując własne
> urządzenie mogę poprowadzić ścieżkę do dowolnego INT-a MCU (albo
nawet
> zupełnie z niej zrezygnować)? Czy też coś mi umknęło i faktycznie
ten
> sygnał jest gdzieś wykorzystywany?

Ostatnio też się nad tym zastanawiałem przy projektowaniu płytki,
nawet driver microchipa do ich stosu nie używa przerwania. Być może
dlatego, że wg dokumentacji do stosu, obsluga encj (w tym wywoływanie
funkcji obsługijących stos) nie jest time critical. Obsługa stosu
działa w modelu cooperative multitasking jako maszyna stanów.
Wystarczy funkcje tcp_task() wywoływać w main() periodycznie ci
kilka-kilkadziesiąt ms. Oczywiście rzadsze jej wywoływanie spowoduje
wolniejszy transfer ale na prawidłowe działanie stosu nie powinno
mieć wpływu.

Przy okazji można docenić genialność wynalazku jakim jest tcp/ip,
jego adaptacyjność i możliwość działania przy skromnych zasobach....

--
Marek

do góry

W dniu 2014-02-24 10:40, Marek pisze:

> Ostatnio też się nad tym zastanawiałem przy projektowaniu płytki, nawet

Mogę zapytać do jakich wniosków ostatecznie doszedłeś? Zostawiłeś
ścieżkę jak jest, tak dla świętego spokoju, czy może dałeś sobie z tym
spokój i zaprojektowałeś tak, jak było najwygodniej?


> driver microchipa do ich stosu nie używa przerwania. Być może dlatego,

Swoją drogą jak wygląda korzystanie z tego darmowego stosu od
Microchipa? Można go porównać do minimalistycznych wersji w stylu
tuxgraphics albo uIP? Występuje ograniczenie wielkości odpowiedzi TCP do
jednego pakietu, a obsługa polega na wpisaniu wartości do bufora i
wywołaniu odpowiedniej funkcji? A może dysponujemy socketami i
przypomina to raczej pisanie aplikacji sieciowych pod system operacyjny
albo sprzętowy stos W5100?

Muszę przyznać, że całkiem fajnie wyglądają procki z serii PIC18F* z
wbudowanym sterownikiem Ethernetu. Może warto się im bliżej przyjrzeć?


> że wg dokumentacji do stosu, obsluga encj (w tym wywoływanie funkcji
> obsługijących stos) nie jest time critical. Obsługa stosu działa w
> modelu cooperative multitasking jako maszyna stanów. Wystarczy funkcje
> tcp_task() wywoływać w main() periodycznie ci kilka-kilkadziesiąt ms.

Obsługi samego przerwania tam nie widzę. Zastanawiałem się jednak, czy
przypadkiem któraś z cyklicznie wywoływanych funkcji nie sprawdza zmiany
stanu samego pinu. W definicjach nie widzę takiego wejścia, jednak być
może autor odwołał się do niego bezpośrednio w którymś momencie? Nie
mogę się doszukać takiego fragmentu kodu, co nie znaczy jednak, że go
tam nie ma...


> Przy okazji można docenić genialność wynalazku jakim jest tcp/ip, jego
> adaptacyjność i możliwość działania przy skromnych zasobach....

Jakby nie patrzeć, to sam stos TCP/IP został opracowany w latach
siedemdziesiątych. Idea transmisji pakietowej o ile mnie pamięć nie myli
powstała jeszcze w latach pięćdziesiątych. Pracownicy wywiadów
największych mocarstw daliby się wtedy zabić za najprostszą ATmegę. ;)

do góry

On Mon, 24 Feb 2014 12:07:49 +0100, Atlantis <m...@w...pl>
wrote:
> Mogę zapytać do jakich wniosków ostatecznie doszedłeś? Zostawiłeś
> ścieżkę jak jest, tak dla świętego spokoju, czy może dałeś sobie z
tym
> spokój i zaprojektowałeś tak, jak było najwygodniej?

Zostawiłem niepodłaczony, układ już u mnie działa od roku na plytce
testowej bez int, ze wzgledu na to, że driver do encj w stosie nie
korzysta z przerwań a wszystko działa ok to uznałem, że nie będzie mi
potrzebne podłączanie int.


> Swoją drogą jak wygląda korzystanie z tego darmowego stosu od
> Microchipa? Można go porównać do minimalistycznych wersji w stylu
> tuxgraphics albo uIP? Występuje ograniczenie wielkości odpowiedzi
TCP do
> jednego pakietu, a obsługa polega na wpisaniu wartości do bufora i
> wywołaniu odpowiedniej funkcji? A może dysponujemy socketami i
> przypomina to raczej pisanie aplikacji sieciowych pod system
operacyjny
> albo sprzętowy stos W5100?

Jest to w pełni funkcjonalny stos, z socketami, funkcje obsługi
używa się podobnie jak w "dużych systemach", aczkolwiek inaczej się
nazywają ale jest analogia bind, connect, read/write. Można czytać i
pisać na raz do kilku zestawionych połączeń.
Stos jest konfigurowalny, można na etapie kompilacji wybrać co ma być
(udp, tcp, icmp, ntp itp) oraz jakie zasoby (bufory) możemy
przydzielić per gniazdo. Daje to dużą elastyczność przy dostosowaniu
do dostępnych zasobów ram. Co ciekawe można nawet wskazać zewnętrzna
ram po spi jako bufor :).

> Muszę przyznać, że całkiem fajnie wyglądają procki z serii PIC18F* z
> wbudowanym sterownikiem Ethernetu. Może warto się im bliżej
przyjrzeć?

Można, ale pamiętaj, że tcp+udp+icmp+ntp + mininalistyczny httpd na
pic18f zajął mi ok 60kB flash, więc warto wybrać układ z min. 128kB.
Do wbudowanego sterownika eth. i tak potrzebujesz driver, więc
objętościowo kod zajmie tyle samo z encj zewnętrznym.
Ostatecznie, ze względu na ograniczony flash i ram w pic18 i dość
rozbudowany httpd przeniosłem się z tym projektem na pic32.

--
Marek

do góry

On Mon, 24 Feb 2014 12:07:49 +0100, Atlantis <m...@w...pl>
wrote:
> Jakby nie patrzeć, to sam stos TCP/IP został opracowany w latach
> siedemdziesiątych. Idea transmisji pakietowej o ile mnie pamięć nie
myli
> powstała jeszcze w latach pięćdziesiątych.

tak w temacie adaptacji tcp/ip:
http://www.anfractuosity.com/projects/ultrasound-net
working/

--
Marek

do góry

W dniu 2014-02-24 13:34, Marek pisze:

> tak w temacie adaptacji tcp/ip:
> http://www.anfractuosity.com/projects/ultrasound-net
working/

To jeszcze nic.
http://tools.ietf.org/html/rfc1149
http://pl.wikipedia.org/wiki/IP_over_Avian_Carriers

Tak swoją drogą jestem ciekaw, czy przypadkiem agencje wywiadowcze nie
korzystają z nietypowych mediów transmisyjnych, celem zmniejszenia
prawdopodobieństwa przechwycenia informacji.

Sam się kiedyś zastanawiałem, czy nie dałoby się niepostrzeżenie
przekazać krótkiej wiadomości przez magnetyzację jakiegoś metalowego
przedmiotu (np. żeliwnej poręczy schodów) i przejechanie po nim głowicą
w chwilę później. :)

do góry

> On Mon, 24 Feb 2014 12:07:49 +0100, Atlantis <m...@w...pl>
> wrote:
> > Jakby nie patrzeć, to sam stos TCP/IP został opracowany w latach
> > siedemdziesiątych. Idea transmisji pakietowej o ile mnie pamięć nie
> myli
> > powstała jeszcze w latach pięćdziesiątych.
>
> tak w temacie adaptacji tcp/ip:
> http://www.anfractuosity.com/projects/ultrasound-net
working/
>
> --
> Marek
Się napracował.
Polecam komentarz:

Menachem Begin
February 18, 2014 Reply
Congratulations, you've invented 'the modem'.

Kidding, mostly.
admin
February 18, 2014 Reply
Hehe, yeah you're completely right though. It was fun learning
how to do it using Gnuradio though.

do góry

W dniu 2014-02-24 12:58, Marek pisze:

> Można, ale pamiętaj, że tcp+udp+icmp+ntp + mininalistyczny httpd na
> pic18f zajął mi ok 60kB flash, więc warto wybrać układ z min. 128kB.

Skłaniałbym się właśnie w kierunku czegoś takiego jak PIC18F67J60, ze
względu na 128kB flasha.
Zresztą tak naprawdę mam trochę inne podejście do komunikacji z MCU
przez TCP/IP. Zamiast stawiać serwer www na maleńkim układzie,
skłaniałbym się raczej ku wysyłaniu danych na zewnątrz w "surowej"
formie. Ich gromadzeniem i wyświetlaniem niech się zajmie oprogramowanie
odpalone na jakimś serwerze, niechby to miałoby nawet Raspberry Pi. :)

Dodatkowy plus takiego rozwiązania jest taki, że możemy sobie pozwolić
na posiadanie całej sieci takich małych płytek, które będą spokojnie
realizowały powierzone sobie funkcje, a kontrolą z użytkownikiem już
zajmie się odpowiednie "centrum".

Z tego powodu jak na razie ten minimalistyczny stos z tuxgraphics w
zupełności mi wystarczał, ale jak już mówiłem - dopiero zaczynam zabawę
z podłączaniem MCU do Sieci.

do góry

On Mon, 24 Feb 2014 14:34:33 +0100, Atlantis <m...@w...pl>
wrote:
> formie. Ich gromadzeniem i wyświetlaniem niech się zajmie
oprogramowanie
> odpalone na jakimś serwerze, niechby to miałoby nawet Raspberry Pi.
:)

Ja mam trochę inne podejście, staram się eliminować PC gdzie się
tylko da (rasp pi to też dla mnie PC), po stronie hosta (hub danych)
eliminuje wszystko co pobiera więcej niż 3W, zdalne czujniki zasilane
tylko fotowoltaniką itp.

--
Marek

do góry

W dniu 2014-02-24 16:30, Marek pisze:

> Ja mam trochę inne podejście, staram się eliminować PC gdzie się tylko
> da (rasp pi to też dla mnie PC), po stronie hosta (hub danych) eliminuje
> wszystko co pobiera więcej niż 3W, zdalne czujniki zasilane tylko
> fotowoltaniką itp.

Sęk w tym, że w chwili obecnej chyba już większość urządzeń embedded ma
pod spodem zaszytego jakiegoś Linuksa. Dochodzimy do sytuacji, kiedy
nawet części i akcesoria komputerowe są samodzielnymi komputerami z
własnym systemem operacyjnym. Jakiś czas temu popularny był temat
hackowania kart pamięci SD, z wbudowanym WiFi do synchronizacji z
chmurą. Okazuje się, że taka karta to też mały komputerek linuksowy. ;)

Wychodzę z założenia, że jeśli w domowej sieci i tak mam jeden
"serwerek" (w tej chwili właśnie RPi) pracujący cały czas, to nie
zaszkodzi zaprząc go do generowania WebUI. A zwykłe czujki/układy
wykonawcze na MCU niech wysyłają/przyjmują pakiety z surowymi danymi.

do góry