Witam, chciałbym zacząć zabawę z wysyłaniem danych przez internet. To znaczy chciałbym wysyłać dane pomiarowe z procesora na serwer (przez internet). Czy w takim zastosowaniu takie zestawienie tych układów będzie działać? Chciałbym dodać że o magistrali CAN i protokole MODBUS mam jakieś pojęcie, natomiast komunikacja po ETHERNECIE to dla mnie wielka niewiadoma.
Czy można prosić o jakieś wskazówki na początek?
Czy jest jakiś program na PC pod windows, którym będę mógł obejrzeć dane przychodzące po ETHERNECIE (coś jak REALTERM czy TeraTerm)?
Źle podchodzisz do tematu. Współcześnie nie trzeba się znać. Wystarczy mieć pojęcie jak korzystać z zasobów bibliotek, które daje Ci producent mcu (na którym się znasz) lub społeczność wokół tego mcu, która udostępnia biblioteki. Ty masz jedynie połączyć to do kupy. Ewentualnie w zamian możesz dać społeczności patche lub uwagi/doświadczenia. Z reguły tajemna wiedza jak "działa ethernet" nie jest potrzebna aby uzyskać cel, o którym pisałeś. No chyba, że chcesz się doktoryzować w tym temacie.
Nie chcę się doktoryzować. Zależy mi aby w miarę łatwo to uruchomić i cieszyć się z uruchomionego połączenia. Dopiero rozkminiam kwestię bibliotek dostępnych do modułów ethernetowych.
Mam taką płytkę:
formatting link
Do tego środowisko CooCox. Do tej płytki podłączyłem wyświetlacz graficzny 4,3 cala i działa mi to.
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. Ale wyczytałem że jest jeszcze coś takiego jak W5100/W5500 - tylko że droższy. Co polecacie na początek żebym nie poległ na trudności na początku.
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.
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.
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ą. ;)
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.
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.
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?
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 :)
W dniu 2014-11-03 19:13, Grzegorz Niemirowski pisze:
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.