zakładam odrębną gałąź, żeby nie przeszkadzać w jedynie słusznej
wymianie b...

pierwsza strona z google wskazuje na:
coś tam
a to z kolei na:
http://tuxgraphics.org/electronics/200905/embedded-t
cp-ip-stack.shtml

Ktoś coś napisze na ten temat?

do góry

drugi link z google to:
http://www.mikroe.com/download/eng/documents/compile
rs/mikroc/pro/arm/help/ethernet_library.htm

ale to się da jakoś ściągnąć? tu przynajmniej jest jakiś opis...

do góry

no właśnie dużo jest ale nie na temat... jakieś avr pic i inne, ale nie
do stm... więc pytanie jest jak najbardziej na miejscu...

do góry

W dniu 2014-10-31 14:50, Marek Borowski pisze:

> Podejscie typowe dla 90% ludzi z ktorymi sie spotykam - rzemieslnicy
> niemajacy pojecia o tym co wlasciwie robia.

Czyli co? Każdy powinien w celach edukacyjnych nauczyć się sterować
każdym układem za pomocą machania pinami i wypisania heksadecymalnych
wartości do poszczególnych rejestrów? Tylko po co? Po co robić od nowa
pracę, którą ktoś już wykonał? Po co marnować czas na pisania już
istniejącej biblioteki?

Dla mnie jest to trochę tak absurdalne, jak twierdzenie, że początkujący
powinien móc sobie ten układ najpierw zaprojektować z bramek (a
najlepiej tranzystorów) a potem oprogramować go w assemblerze
określonego procesora.

Najważniejsze jest to, żeby zacząć i uruchomić układ. Jeśli początkujący
będzie zaczynał podejście od najbardziej stromego zbocza, to w końcu
spadnie, potłucze się i zniechęci. Nie ma nic złego w korzystaniu z
wydeptanej ścieżki. A pozostałą wiedzę kiedyś trzeba będzie opanować -
przy okazji portowania albo modyfikacjo biblioteki. Jednak wszystko w
swoim czasie.

do góry

W dniu 2014-10-30 13:05, pytajacy pisze:

> Ale chciałem podłączyć jeszcze jakiś interfejs ETHERNET i pomyślałem
> że układ z ENC28J60 będzie dobry bo łatwo podłącze do tej płytki.

W gruncie rzeczy od strony programowej potrzebujesz dwóch rzeczy, żeby
komunikować się ze światem za pomocą ENC28J60:
1) Drivera, czyli zbioru niskopoziomowych procedur, które są
odpowiedzialne za odczytywanie/zapisywanie informacji z/do rejestrów i
buforów układu za pośrednictwem magistrali SPI. Kod drivera jest rzecz
jasna specyficzny dla konkretnej rodziny procesorów (a w pewnym zakresie
także do konkretnego modelu). Musisz znaleźć driver przygotowany dla
twojego procesora, bądź też przygotować go samodzielnie, np. modyfikując
kod napisany pod jakąś inną rodzinę.
2) Stosu TCP/IP. Ta część odpowiada za przetwarzanie informacji
pobranych z lub wysyłanych do bufora ENC28J60. Kod sprawdza z jakim
typem pakietu mamy do czynienia (ARP, ICMP, TCP, UDP) i podejmuje
odpowiednie akcje - ustawia odpowiedni adres IP, odpowiada na ping, albo
udostępnia nam otrzymaną wiadomość. To samo w drugą stronę. Ta część
jest bardziej uniwersalna i mniej zależna od platformy, co nie znaczy
wcale, że z miejsca się skompiluje - być może trzeba będzie się pozbyć
elementów typowych dla określonej rodziny, jak np. PROGMEM w AVR-ach.

Generalnie masz kilka różnych stosów do wyboru, miedzy innymi:
1) Tuxgraphics.org - przygotowany pod AVR-y, ale pewnie bez problemu
będzie się dało go przeportować pod STM-y (może ktoś już to zresztą
zrobił). Gdy idzie o przesyłanie małych ilości danych, jest bardzo
prosty w obsłudze, nie zużywa dużych zasobów, dlatego też świetnie
sprawdza się na małych MCU. Te zalety mają jednak swoją cenę - cały
komunikat musi się mieścić w jednej ramce Ethernetowej, nie można też
utrzymać trwającej sesji TCP, więc nie da się na tym zrealizować np.
obsługi telnetu.
2) uIP - wciąż lekki stos, o nieco większych możliwościach. Istnieją
wersje pod różne platformy, więc nie powinno być problemów z STM-ami.
3) lwIP - cięższy stos, wymagający większych zasobów sprzętowych. Z tego
powodu nie bardzo nadaje się do stosowania z ośmiobitowymi MCU, ale
doskonale pasuje do STM32. Z tego co czytałem, to trzeba poświęcić
dłuższą chwilę na jego opanowanie. Od strony programistycznej obsługa
zbliżona do połączeń sieciowych na "dużych" komputerach.

Jest też całkiem rozbudowany i funkcjonalny stos od Mircochipa, ale on
działa tylko na PIC-ach, a licencja z tego co wiem zakazuje portowania
na inne platformy.


> Ale wyczytałem że jest jeszcze coś takiego jak W5100/W5500 - tylko
> że droższy.

W5500 jest w praktycznie tej samej cenie co ENC28J60 (mam tu na myśli
oczywiście sam układ, a nie całe moduły, bo tu faktycznie może być różnie).

Układy Wiznetu to trochę inna szkoła niż to, co opisałem powyżej. Tam
układ zajmuje się całą komunikacją, więc twój MCU nie musi dźwigać
ciężaru przetwarzania poszczególnych warstw stosu. Rejestry i bufory
wewnątrz zorganizowane są w sposób przypominający typowe sockety POSIX,
a ty jedynie musisz zapisywać i odczytywać z nich/do nich dane i
metadane. W paru miejscach trzeba też podejmować odpowiednie decyzje, w
zależności np. od statusu połączenia.
To chyba najprostszy sposób realizacji komunikacji sieciowej. Zwłaszcza,
jeśli znajdziesz dobrą i dopracowaną bibliotekę.

Oczywiście są jeszcze inne rozwiązania. Ostatnio coraz większą
popularnością cieszą się moduły WiFi, ze śmiesznie tanim ESP8266 na
czele. Dane przez Internet możesz też przesyłać za pośrednictwem modułów
GSM, np. SIM900 - dobre rozwiązanie, gdy w pobliżu nie masz żadnej
końcówki sieci lokalnej. Sam myślę o zrobieniu na tym systemu nadzoru
nad działką. ;)

do góry

On Sat, 01 Nov 2014 09:15:32 +0100, Atlantis <m...@w...pl>
wrote:
> W gruncie rzeczy od strony programowej potrzebujesz dwóch rzeczy,
żeby
> komunikować się ze światem za pomocą ENC28J60:

Ale po co mu encj jak ma stma z mac (już ktoś pisał). Po drugie nie
wiem czemu upiera się na ethernet i kable skoro są banalne gotowe
moduły z wifi typu esp8266 za 20pln, do wymiany danych z czujnikami
(i to bezprzewodowo!) wystarczające. Nie trzeba studiować etheretów,
stosów tcp itd.

--
Marek

do góry

W dniu 2014-11-01 09:59, Marek pisze:

> Ale po co mu encj jak ma stma z mac (już ktoś pisał).

Może dlatego, że to tego MAC trzeba jeszcze podpiąć PHY, a to wymaga
zastosowania kilkunastu linii sygnałowych. Użycie ENC28J60 może się
okazać prostsze dla początkującego, przynajmniej od strony sprzętowej.


> Po drugie nie wiem czemu upiera się na ethernet i kable skoro są
> banalne gotowe moduły z wifi typu esp8266 za 20pln, do wymiany danych
> z czujnikami (i to bezprzewodowo!) wystarczające. Nie trzeba
> studiować etheretów, stosów tcp itd.

Niby racja, jednak nie zawsze da się zastosować taki moduł, a Ethernet
też ma swoje plusy. Jeśli w pobliżu znajduje się jakaś końcówka lokalnej
sieci, to czemu nie?

do góry

Atlantis <m...@w...pl> napisał(a):
> Czyli co? Każdy powinien w celach edukacyjnych nauczyć się sterować
> każdym układem za pomocą machania pinami i wypisania heksadecymalnych
> wartości do poszczególnych rejestrów? Tylko po co? Po co robić od nowa
> pracę, którą ktoś już wykonał? Po co marnować czas na pisania już
> istniejącej biblioteki?
> Dla mnie jest to trochę tak absurdalne, jak twierdzenie, że początkujący
> powinien móc sobie ten układ najpierw zaprojektować z bramek (a
> najlepiej tranzystorów) a potem oprogramować go w assemblerze
> określonego procesora.
> Najważniejsze jest to, żeby zacząć i uruchomić układ. Jeśli początkujący
> będzie zaczynał podejście od najbardziej stromego zbocza, to w końcu
> spadnie, potłucze się i zniechęci. Nie ma nic złego w korzystaniu z
> wydeptanej ścieżki. A pozostałą wiedzę kiedyś trzeba będzie opanować -
> przy okazji portowania albo modyfikacjo biblioteki. Jednak wszystko w
> swoim czasie.

Jak nabędziesz praktyki, to zmienisz nieco zdanie. Zakładasz, że biblioteka
to gotowiec, który wystarczy wpiąć do projektu. Ale to tylko tzw. chłyt
makietinkowy autora/autorów. Tak może się wydawać przeglądając opis albo
uruchamiając przykłady. Jednak jak robisz własny projekt, nieco bardziej
rozbudowany, albo jest to już któryś kolejny projekt wykorzystujący daną
bibliotekę, to widzisz jak ona jest kanciasta, gdzie autor poszedł na
skróty, że poczynił pewne założenia, które w Twoim projekcie nie muszą być
prawdziwe, że coś jest nieudokumentowane, że coś się zmieniło w tej wersji
którą masz w porównaniu z wersją użytą w przykładach, że coś jest
niekompatybilne z Twoim kompilatorem, że biblioteka używa jakichś zasobów
(np. timery), które też chciałeś użyć, że definiuje jakieś makra i coś Ci
redefiniuje, że biblioteka ma błędy (nawet jak jest od renomowanego
producenta).
Tak, nie ma sensu wynajdować koła. Warto korzystać z bibliotek. Ale w
praktyce i tak się okazuje, że musisz wziąć manuala i obczaić jak ustawić
ten czy tamten bit w danym rejestrze. Szczególnie w naszym świecie embedded,
gdzie jesteś bardzo blisko sprzętu. To nie jest pecet, że system operacyjny
np. chroni pamięć jednego procesu przed modyfikacją przez inny proces. Tutaj
masz mikrokontroler i jesteś ciągle milimetry od strzelenia sobie w stopę.
Nie możesz traktować bibliotek jako czarnych pudełek, które się podczepia do
projektu i one działają. Potem ludzie piszą "wziąłem STM32CubeMX, wyklikałem
projekt i on nie działa!". Nie trzeba zaczynać koniecznie od stromego
zbocza, tylko potem bywa tak, że ktoś odpali "Hello World!" i sobie myśli,
że teraz kilkoma kliknięciami walnie sobie Ethernet. I Zonk, nie działa.
Albo działa, ale koszmarnie wolno. Lub tez działa, ale tylko przez godzinę.
I zaczyna się debugowanie, pisanie na elektrodę, rozczajanie jak działa
biblioteka i sięganie po ten straszny reference manual. I okazuje się, że
jednak jesteśmy na dosyć stromej ścieżce.
Nie zrozum mnie źle, nie neguję Twojego zdania. Tylko po prostu
rzeczywistość jest bardziej skomplikowana, a czaso(praco)chłonność projektu
znów jak zwykle okazuje się niedoszacowana :)

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 34 days, 23 hours, 56 minutes and 38 seconds

do góry

W dniu 2014-11-03 19:13, Grzegorz Niemirowski pisze:

> Tak, nie ma sensu wynajdować koła. Warto korzystać z bibliotek. Ale w
> praktyce i tak się okazuje, że musisz wziąć manuala i obczaić jak
> ustawić ten czy tamten bit w danym rejestrze. Szczególnie w naszym
> świecie embedded, gdzie jesteś bardzo blisko sprzętu. To nie jest pecet,

Ja sobie z tego doskonale zdaję sprawę. Teraz chociażby próbuję
przerzucić się z ENC28J60 na W5100. Niby układ jest prostszy w obsłudze
(nie trzeba się martwić stosem) ale sytuacja dokładnie taka, jak
opisujesz. Znalazłem co prawda prostą bibliotekę z przykładami dla AVR,
ale kod jest mocno niedopracowany. Tak naprawdę ktoś dociągnął projekt
tylko do momentu, w którym możliwe stało się odpalenie prostego serwerka
WWW. Brakuje większości najpotrzebniejszych funkcji: obsługi UDP,
przekazywania linijek do parsowania w transmisji TCP, dynamicznego
rezerwowania socketów i paru podstawowych funkcji związanych z obsługą
połączenia. Próbuję to teraz samemu dopisać, ale chyba bez ponownej,
dokładniejszej lektury manuala się nie obejdzie.

Jednak biblioteka bibliotece nierówna. Często już na starcie dysponuje
się produktem, na którym można zbudować kilka naprawdę zaawansowanych
projektów, nawet nie zauważając ograniczeń. Zresztą modyfikacja
istniejącej biblioteki pod własne potrzeby to jedno. Ja dyskutowałem z
opinią, że początkujący powinien sam sobie wszystko pisać od podstaw.
Dla mnie to powinno przyjść z czasem w miarę rosnących potrzeb.

do góry

W dniu 2014-11-03 22:49, Atlantis pisze:
> Teraz chociażby próbuję
> przerzucić się z ENC28J60 na W5100. Niby układ jest prostszy w obsłudze
> (nie trzeba się martwić stosem) ale sytuacja dokładnie taka, jak
> opisujesz. Znalazłem co prawda prostą bibliotekę z przykładami dla AVR,
> ale kod jest mocno niedopracowany. Tak naprawdę ktoś dociągnął projekt
> tylko do momentu, w którym możliwe stało się odpalenie prostego serwerka
> WWW. Brakuje większości najpotrzebniejszych funkcji: obsługi UDP,
> przekazywania linijek do parsowania w transmisji TCP, dynamicznego
> rezerwowania socketów i paru podstawowych funkcji związanych z obsługą
> połączenia. Próbuję to teraz samemu dopisać, ale chyba bez ponownej,
> dokładniejszej lektury manuala się nie obejdzie.

Na Twoim miejscu zostawiłbym W5100 i zajął się W5500. Biblioteki pod ten chip są
napisane od nowa.
Mi działają bez problemów.

do góry